گزارش یک پروژه چابک Simplydesk – قسمت اول

در سه سال گذشته در کنار تمام فعالیت های آموزشی و مشاوره ای، به عنوان مدیرتوسعه و مربی چابک محصولی با نام Simplydesk نیز بودم. این محصول در همکاری مشترک دو شرکت ایرانی با یک شرکت فرانسوی به اسم PCI شروع شده بود. کسب کار این محصول میز خدمات و مدیریت دارایی فناوری اطلاعات مبتنی بر استانداردهای ITIL  و بازار هدف این محصول کشورهای فرانسوی زبان تعریف شده است.

این محصول که بر بستر Cloud یا رایانش ابری ارائه شده و امروز بیشتر از 80 مشتری سازمانی در اقصی نقاط فرانسوی زبان دنیا مانند شمال و جنوب فرانسه، کبک کانادا، شمال آفریقا، جزایر کارائیب و سوئیس دارد. بعلت اختلاف نظر در چند موضوع با ذی نفعان ایرانی این محصول و عدم دست یابی به توافق؛ همکاری بنده با این مجموعه خاتمه پیدا کرد ولی توسعه محصول همچنان ادامه خواهد داشت و امیدوار به موفقیت های بیشتر این محصول را در بازارهای بیشتر جهانی هستم.

اما در این پست چه خواهد گذشت؟ در این چند سال تجربیات زیادی اندوخته شد، بخصوص از اینکه با کشورهای خارجی کار می  کردیم و فرصت های زیادی برای یادگیری ایجاد شده بود. در این پست سعی شده است بخشی از این موارد و تجربیات و خاطرات جبهه جنگ به اشتراک گذاشته شود (:

  •  کج فهمی : مشکل اول

کج فهمی یا درست نفهمیدن نیازمندی مشکل اساسی همه پروژه های نرم افزاری است که این پروژه هم از این قاعده مستثنی نبود بخصوص اینکه یکی از بزرگترین مشکلات ما در دسترس نبودن مالک محصول بود، چرا که او در لیون فرانسه بود و ما در تهران. ارتباط به صورت مکاتبه ای بود و کج فهمی بشدت بالا. یک چیزی او می فرستاد، ما میخواندیم و اجرا می کردیم و نهایتا دیالوگ معروف “این چیه ساختید؟ منظور من این نبود!”

اما چگونه این مشکلات کمتر شد؟

  • ارتباط حضوری و چهره – به – چهره به جای ارتباطات مکاتبه ای

همانطوری که در بیانیه چابک خوانده ایم بهترین نوع ارتباط چهره-به-چهره است، منتهی بدلیل مسافت این کار امکان پذیر نبود. برای همین موضوع طرح جایگزین، ارتباط از طریق اسکایپ(بدلیل سرعت اینترنت خیلی روش نمی شد حساب کرد) به جای ایمیل بازی و سفر مالک محصول هر سه – تا – چهار ماه یکبار به ایران جهت شفاف سازی بود.

رده بندی موثر بودن ارتباط از بالا به پایین: دو نفر حضوری در جلوی وایت برد- تلفنی – چت – ایمیل یا مکاتبه ای

  • سوال پرسیدن به جای حدس و گمان

یکی از بزرگترین موارد که در اوایل ما را بسیار اذیت کرد همین قضیه حدس زدن بود، در بعضی موارد مسئله کامل درک نمی شد و حدس زده می شد که منظور فلانی این است و شروع به انجام کار می شد. یکی از قوانین ما این بود که به جای حدس زدن حتی در اواخر اسپرینت باید از مالک محصول سوال پرسیده شود. حتی مدیر تیم تولید هم حق ندارد به جای مالک محصول اظهار نظر نماید.

  • مکتوب کردن نتایج جلسات

توافقات در جلسات حاصل می شد ولی بدلیل مکتوب نشدن دوباره از یادها می رفت و دوباره موقع انجام کار چیزهای ناقص به یاد مانده انجام می شد و دوباره باید زمانی برای بهبود کار انجام شده صرف می شد. برای همین یکی  دیگر از قوانین مکتوب ساختن نتایج همه جلسات در قالب Condition of Satisfaction بود.

نمونه ای از Condition of Satisfaction:

Conditions

  • Bulk Edition should let the possibility to the agent to:
    • Set or Change Assignee on many open tickets
    • Set or Change Priority on many open tickets
    • Set or Change Source on many open tickets
  • First, user should select tickets in list, then in nav bar, press on a button called “Bulk”
    • When some tickets selected are in closed state, Bulk button should not be visible
  • کار شفاهی ممنوع

یکی دیگر از قوانین خوب ما، ممنوع شدن کار شفاهی بود، هر کسی حتی مدیرعامل، باید درخواست خود را کانال مالک محصول رد می کرد و حتی خود مالک محصول هم نمی توانست کاری از تیم بخواهد که در بک لاگ محصول نیست. خود کانالیزه شدن این مسئله باعث بالا رفتن تمرکز تیم و کم شدن کج فهمی ها می شد. البته این قانون بعد اینکه چندین بار کارهایی شفاهی انجام شد و بدلیل عدم مکتوب بودن، مورد اعتراض ذی نفعان و یا خود مالک محصول شد، به این قانون دست پیدا کردیم.

  • Sketch

یکی از بهترین ابزارهای جلسات برنامه ریزی اسکچ کشیدن است، یعنی صد ساعت جلسه مثل دو تا اسکچ کار نخواهد کرد. بارها شده بود کسی در مورد یک چیز توافق کرده بودند ولی بعد از دیدن اسکچ هم، با هم مخالفت کرده بودند.

  • شکستن به اندازه کارها

شکستن کارها همیشه خوب است، ولی یکی از عادت های بد ما در اوایل این تیم زیاد شکستن کارها بود، این کار باعث از دست دادن تصویر بزرگ کار می شد. یا به عبارتی در جزئیات گیر می کردیم و هدف کلی کار را از دست می دادیم. برای این منظور سعی می کردیم قبل از شکستن کارها، ابتدا Condition of Satisfaction کلی کار استخراج شود و سپس بر اساس آن کار بزرگ شکسته شود.
جلسه گرومینگ لازم نبود بلکه حیاتی بود: در این پروژه بدلیل اینکه دائم از مشتریان فیدبک گرفته می شد، بک لاگ دائم در حال تغییر بود، برای همین منظور مالک محصول باید دائم آیتم های بک لاگ محصول را بازبینی، اولویت بندی می کرد.

جلسات برنامه ریزی مشکل بعدی

یکی دیگر از مشکلات ما در این تیم خود جلسات برنامه ریزی اسپرینت بود؛ مشکل ما در دو حوزه بود: یک- مشکل در فرم و نوع جلسات. دوم- دید بزگتر و بلند مدت از اسپرینت

  • مشکل در فرم و نوع جلسات برنامه ریزی: یکی از شایع ترین مشکلات در اکثر تیم های چابک، خسته کننده شدن جلسات یا بی اثر شدن جلسات است که در این نوشته مفصل توضیح داده شده است. 
  • دید بزرگتر و بلند مدت تر: در این مورد این مسئله در ادامه نوشته توضیح داده شده است.

 

  • برنامه ریزی اسپرینت کافی نبود باید به فکر Release Plan بود 

به واقع می توان گفت یکی از بزرگترین و انقلابی ترین تغییرات ما همین Release Plan بود. اما مشکل چه بود که به این نیاز بود؟ در اوایل پروژه، ما چندین اسپرینت را انجام داده بودیم که خوشحال هم بودیم، اما یک نارضایتی نسبی هم مشاهده می شد، خوب که چی؟ اسپرینت بعد اسپرینت تمام می شد و در هر اسپرینت یک تعداد کار انجام می شد ولی انگیزه خاصی به نفرات داده نمی شد زیراکه این اسپرینت ها هدف خاصی را دنبال نمی کردند یا حداقل برای نفرات فنی واضح نبودند.

برای همین ما مفهوم Road Map را اضافه کردیم به نحوی که پروژه شکسته می شد به چندین Milestone که هر نقطه را یک Release می نامیدیم، هدف این بود که هر چند اسپرینت یک ریلیز باشد، در اواخر توانسته بودیم حتی ریلیز ها را هم ثابت نگه داریم یعنی هر دو اسپرینت یک ریلیز.

اما قالب Release Plan به چه شکلی بود و چگونه مدیریت می شد؟

قالب Release Plan برای هر نسخه به این شکل بود:

  1. نام نسخه 
  2. تاریخ انتشار
  3. مشتریان و کاربران هدف این نسخه
  4. مشکلاتی که مشتریان هدف با آن درگیر هستند
  5. سه – چهار ویژگی یا Feature عمده این نسخه
  6. ویژگی منحصر به فرد این نسخه
  7. متریک هایی برای اندازه گیری موفقیت بعد از انتشار نسخه

طرح برنامه ریزی نسخه ارائه

در هر زمان مالک محصول موظف بود دو تا سه نسخه بعدی را مانند قالب بالا آماده کرده و با ذی نفعان به اشتراک بگذارد و پس از بررسی و کسب توافق با آنها در مورد اجراییات با تیم صحبت کند. البته بعضی مواقع قبل از صحبت با ذی نفعان، لازم بود حتما مالک محصول با تیم در مورد مسائل فنی به بحث بنشیند.

ایده های و فیدبک های جدید چگونه مدیریت می شدند؟

وقتی محصول لایو شد، کلی ایده جدید از سمت خودمان یا مشتری ها، ارائه می شد. مدیریت این ایده ها و توانایی کنترل بسیار کار سختی بودزیرا که اگر این ایده و نظرات جدید را در نظر نمی گرفتیم شاید محصول نهایی برای مشتریان رضایت بخش نمی شد و اگر همه این ایده ها را در نظر می گرفتیم محصول از چارچوب اصلی خارج می شد یا کلی Feature اضافه به محصول اضافه می شد که کسی از آنها استفاده نمی کردند.

برای همین منظور یک ساختار در ترلو ایجاد کردیم با دو ستون “ایده ها و نظرات” + “تایید شده ها”  که همه ذی نفعان به ان دسترسی داشتند و می توانستند ایده های خود را در ستون “ایده ها و نظرات” بنویسند، و یا در مورد ایده های دیگران با خبر شوند و نظرات خود را در قالب کامنت بنویسند. اما فقط مالک محصول می توانست این ایده ها را در ستون “تایید شده ها” بیندازد.

مکانیزم به این صورت بود، مالک محصول موظف بود، ایده های مطرح شده در ستون اول را ارزیابی نماید ( اینکه چند درصد از مشتریان این قابلیت را می خواهند؟ آیا محصولات مشابه چنین قابلیتی دارند؟ آیا این قابلیت ارزش آفرین است؟) اگر ایده تایید می شود به ستون دوم؛ “تایید شده ها”  منتقل می شد. در غیر اینصورت باید حذف می شد. آیتم های ستون دوم، نیز به تدریج وارد Release Plan ها شده و نسبت به میزان درخواست یا ارزش آفرینی اولویت بندی می شدند.

تابلوی ایده ها

 آیا ما همه جلسات اسکرام را برگزار می کردیم؟

یکی از سوالاتی که همیشه از من پرسیده می شد این بود که شما در آنجا واقعا همه جلسات را برگزار می کنید، جواب بله بود. اما با شرایط خودش.

یکی از بهترین مثال ها جلسات روزانه که بود، اوایل برگزار می شد ولی بعد از مدتی دیگر این جلسه را نداشتیم. علت اینکه دیگر این جلسه را نداشتیم این بود که جلسه مسخره به نظر می رسید که هر روز مثل طوطی بگیم من دیروز اینکار رو انجام دادم و امروز می خوام اینکار رو انجام بدهم.

برای این منظور این جلسه را برای مدتی تعطیل کردیم، بعد از چندین اسپرینت، یکی از کارهایی که می کردم این بود که سعی کنم مشکلاتی که در صورت عدم نبودن این جلسه ایجاد می شود را نشان دهم و از خود بچه ها نظر بخواهم که چگونه این موضوع را حل کنیم؟ مثلا یک نفری دو هفته زمان گذاشته بود یک باگ را رفع کرده بود و نفر دیگر چند ماه قبل تر این باگ را رفع کرده بود، یا نفرات از کار هم خبر نداشتند و بخاطر این در برنامه ریزی گیج می شدند.

در جلسات بازنگری به این نتیجه رسیدیم که صبح ها یک جلسه ای داشته باشی، حالا نه عین جلسات روزانه، ولی با فرمت خاص، اینکه کارهای امروز به صورت دسته جمعی طراحی بشوند و همه نظر بدهند در موردشون و اگر کسی جایی مشکلی داشت سریع مطرح بشود.

درس هایی که یاد گرفتیم با دوباره آنها را دوره کردیم؟ 

1- وقتی کمیت حرف اول را می زند 

یکی از بدترین تله های ممکن در ساخت محصولات نرم افزاری این است که Feature بیشتر به معنای محصول بهتر باشد. ما هم این اشتباه را کردیم، یعنی در هر اسپرینت که قابلیت بیشتر و جدید تری تولید می کردیم بیشتر خوشحال بودیم، این  به خودی خود بد نیست اما وقتی می فهمیم از این قابلیت کسی استفاده نمی کند کاملا ضدحال می خوردیم.

برای مثال، در یک موردی مالک محصول از برنامه نویس پرسید این قابلیت چقدر طول می کشد، برنامه نویس” فقط دو ساعت”، بعد پیاده سازی، خوب چرا این رو نذاشتی؟ یعنی بدنبال یک قابلیت دو ساعتی، حدود 58 درخواست ثبت شد که این ها هم به آن اضافه شود، ولی میزان استفاده فقط 3% بود.

اما درسی که یاد گرفتیم چه بود؟

اول- اینکه قابلیت نیم ساعت طول می کشد بزنیم نداریم

دوم – باید میزان استفاده از قابلیت ها اندازه گیری بشود

سوم – اگر قابلیتی استفاده نمی شود، باید شجاع بود و ان را کلا حذف کرد، اینکه بگذار حالا شاید یکی استفاده کرد نداریم.

2- محصول مهم است ولی تیم مهم تر

اسپرینت پشت اسپرینت تمام می شود و کلی قابلیت تولید می شوند، ولی به تیم چه چیزی اضافه می شود؟ با انگیزه نگه داشتن نفرات تیم در طول تمام پروژه بسیار امر ضروری است. یکی از اشتباهات همیشه این هست که در گیر و گرفتاری تولید قابلیت بیشتر تیم را فراموش می کنیم و فقط تمرکز می کنیم بر روی خود محصول.

اما درسی که یاد گرفتیم

اول- یک تیم خوب یک محصول خوب می سازد

دوم – یادگیری و تفریح در کار دو امر ضروری برای نفرات فنی هستند، برای نفرات باید برنامه داشت

3- تست کردن جزئی از کار است نه یک کار اضافی یا نمایشی

  • محصول را باید با کیفیت ساخت، نه اینکه از اول بزن درویی باشه حالا بعدا درست بشه
  • کارهای یک اسپرینت باید در همان اسپرینت تست شوند، هم توسط خود برنامه نویس و هم توسط تسترها
  • تست دستی هم خوب است، لازم نیست فقط گیر بدهیم به یونیت تست یا تست های یکپارچه
  • هر باگ که از اسپرینت در برود هزینه رفع آن بسیار بالا خواهد رفت

4- نصف تیم سازی در استخدام است

حقیقا امر استخدام بسیار کار سخت و مهمی است. در تیم سازی، اغراق نیست که شما نصف کار را در همان مرحله استخدام انجام می دهید. اگر بدنبال ساخت یک تیم هستید آدم هایی را انتخاب کنید که اهل صحبت کردن، اهل همگرایی، هم افزایی باشند.  این یک حقیقیت است که ما در استخدام فقط بر روی مسائل فنی تمرکز می کنیم و هر کسی بالاتر باشد برای ما ترجیح بیشتری دارد ولی تجربه ما یک چیز دیگر بود.

  • مهارت فنی را  بیشتر از 30% در نظر نگیرید
  • مهارت های غیر فنی و نرم را جدی بگیرید، مهارت در حل مسئله، مهارت در حل تعارض. مثلا سوال بپرسید آخرین باری که با کسی یا مدیری در سرکار مشکل داشته کی بوده و چطوری ان را حل کرده است؟
  • افرادی که کنترل بهتری نسبت به هیجانات خود دارند را در اولویت قرار بدهید
  • توجه کنید طرف مقابل پشت سر دیگران بیشتر از خوبی آنها می گوید یا بدی ها
  • آدم های حسود، خاله زنک، تملق گو بدترین نوع نفرات برای کارهای جمعی و تیمی هستند

 

این گزارش بخش اول بود، گزارش بخش دوم به مسائل فنی خواهیم پرداخت، و البته با نظرات دوستان می توانیم به موارد دیگر نیز بپردازیم (:

چابک و موفق باشید

اگر به تازگی با چابک یا اسکرام آشنا شده اید پیشنهاد می کنم این کتابچه چند صفحه را بخوانید و اگر مطالب بیشتری نیاز داشتید شاید این مطلب اول تا آخر چابک برای شما مفید باشد.

مطالب را هم دوست داشتید می توانید از طریق این لینک عضو فید دنیای چابک شوید تا مطالب جدید برای شما ارسال شود

در ضمن دوره های آموزشی نیز برگزار می کنیم که شاید برای شما یا تیم شما نیز مفید باشند اگر اینگونه بود خوشحال می شوم با من تماس بگیرید

اسد صفری

اسد صفری – مربی تحول چابک سازمان و تیم های نرم افزاری. مدارک حرفه ای: CSP - CSM - PSM - PSPO - CDA - Management 3.0 برخی تجربیات: رئیس دفتر تحول چابک شرکت داده ورزی سداد(بیشتر از ده تیم نرم افزاری) - مربی چابک شرکت رامند (تیم های موبایل و گیم سازی) - مدیر تولید نرم افزار SimplyDesk برای شرکت فرانسوی PCI - مربی مشاور شرکت های:خدمات انفورماتیک، ارکید فارمد، فراداده، الفبا برخی از سوابق مشاوره کوتاه مدت و تدریس : علی بابا، فناپ، تجارت الکترونیک پارسیان، بیمه سامان، انیستیتو ایزایران، مهندسین مشاور تجارت (بانک تجارت)، بیمه ایران، پارس آنلاین، شرکت رهنما، ورانگر، انتشارات پزشکی کوثر و صنایع ارتباطی آوا، فولا آلیاژی یزد، پارک علم فناوری کردستان و ... . عضو انجمن های بین المللی Agile Alliance - Scrum Alliance

10 دیدگاه

  1. مجتبی صفوی   •  

    با سلام و خسته نباشید. دورادور درجریان پروژه شما از طریق دوستان قرارداشتم. نکاتی که شما اشاره کردین به عنوان راهبر تیم کاملا تجربه کردم ، نمیدونم مواردی که اشاره کردین درمورد تیم رو اینطور من تصور میکنم که کل اعضای تیم باید محصول را جزو دارایی های معنوی خودبدونند اگر لری بگم اینه که درسته سهام دار نیستی ولی بدون خلاقیت تو میتونه اون محصول رو ایجاد کنه و شکوفاش کنه. مرسی سال خوبی داشته باشید

  2. Pingback: لینک‌های هفته (۲۸2) | گزاره‌ها

  3. مهیار ابراهیمی وفا   •  

    با سلام
    در مورد این نوشته چند نکته به نظرم می رسد…
    1- اسکرام با وجود اینکه چارچوب مشخص و حتی به نظر سفت و سختی دارد، اما می شود در هر پروژه با شرایط خاص آن، ضمن پایبندی به اصول اسکرام رویه متفاوتی اتخاذ کرد که در مورد آن پروژه بخصوص ایجاب می کند
    2- ایده آل این است که هنگام استخدام افراد با ویژگی هایی که برشمردید استخدام شوند اما واقعیت این است که حداقل در جاهایی که من کار کردم با همان افراد موجود باید تیم تشکیل داد و اغلب امکان استخدام برای تیم پروژه وجود ندارد. این به نظرم یکی از بزرگترین چالشهای اسکرام در شرکتهای ایرانی است
    3- یک چیزی که برای خود من جالب است و دوست دارم بدانم اینکه با توجه به اینکه جامعه هدف محصول جامعه فرانسوی زبان بوده و قاعدتا محصول باید در استانداردهای بین المللی و با کیفیت مناسب تولید می شده، این مساله چه تاثیری روی محصول داشته. در واقع اگر این محصول قرار بود برای کاربران ایرانی تولید شود چه تفاوتهایی با محصول فعلی پیدا می کرد… البته بیشتر منظورم تفاوت های فنی و کیفیت خروجی ها است… چون تفاوتهای کاربری و نیازمندیها که طبیعتا وجود دارند.
    ممنون

    • اسد صفری   •     Author

      سلام
      1- در مورد اول اینکه مسلما میشه اسکرام رو با وضع جاری آداپته کرد، ولی متاسفانه تو ایران حذف کردن و کم کردن از اسکرام یا به نوعی بومی کردنش شده آداپته کردن. قصد ما بیشتر این بود که آداپته اش کنیم به جای اینکه ازش کم کنیم (:

      2- در مورد دوم مسلما همینطوره، الان حتی استخدام آبدارچی هم کار سختی است و پیدا نمیشه. ولی مسئله این است که بعضی وقت ها از نبود نیرو گیر نفرات بد میوفتیم که نبودنشون بهتر از بودنشون است.

      3- مسلما کیفیت خروجی برای کاربران ایرانی و فرانسوی متفاوت نخواهد بود، مگر اینکه کارفرما تعریف کیفیت متفاوتی داشته باشد. فقط روی نیازمندی فانکشنال و نان فانکشنال فرق داریم. برای مثال در فرانسه وجود کارکترهای خاص باعث بروز باگ های عجیبی میشد یا برای مثال، چند زبانه یا چند فرهنگی بودن سیستم. اما یک فرق اساسی در خرید نرم افزار ایرانی ها و فرانسوی است، اونها نسبت به ما در هنگام خرید نرم افزار به قابلیت ها و نیاز خود نگاه می کنند ولی در ایران، وقتی یک سیستم خریداری میشه، اگر حسابداری باشه، باید اندازه یک ERP کار کنه،

  4. Pingback: دنیای چابک – گزارش یک پروژه چابک – Simplydesk – بخش دوم

  5. افشار محبی   •  

    سلام،

    خیلی خوشحال شدم که تجربیات خودتان را به اشتراک گذاشتین. خصوصاً در مورد این پروژه که کم و بیش از آن خبر داشتم. خیلی از نکاتی که نوشتید را خودم در بعضی تیم‌ها لمس کرده بودم.

  6. رضا ترابی   •  

    بسیار تجربیات ارزشمندی بود .

  7. مجتبی محمودزاده   •  

    ممنون از اینکه تجربیات خودتون رو در اختیار بقیه قرار میدید .
    خیلی خوب بود .
    سپاس .

  8. محمد آزاد   •  

    اسد جان چه خوب شد که این تجربیاتت رو عنوان کردی .واقعا simplyDesk یه تجربه عالی از اسکرام هست به خاطر تمام چالش هایی که توش بود و تیم به مرور اونها رو حل کرد.

  9. Pingback: دنیای چابک – در توسعه نرم افزار چه چیزی را باید اندازه بگیریم؟

پاسخ دهید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *