بام چگونه روش برنامه‌ریزی خود را تغییر داد؟

چند مدتی هست که افتخار همکاری با شرکت داده ورزی سداد را دارم، این شرکت متعلق به بانکی ملی است و معمولا پروژه‌های بانک را انجام می‌دهد. یکی از این پروژه‌ها یا بهتر بگویم محصول‌، بام است. بام پرتال بانکداری اینترنتی بانک ملی است و نزدیک 4 تیم از سداد نزدیک 25- 30 نفر (اسامی تیم ها: برمودا – پایونر – منتخب – پویا) بر روی آن به صورت تمام وقت کار می‌کنند.

پروژه و تیم بام، واقعا یکی از بهترین تجربیات چابک در ایران در سطح Scale است، چه از نظر زیر ساخت فنی و چه از نظر تعدد تیم‌های روی یک پروژه و استفاده از مفاهیم چابک و اسکرام.

در این نوشته قصدم بررسی و ارائه یکی از روش‌های خوبی است که در بام انجام شد و نتیجه خوبی به همراه داشت، و امید بر اینکه تیم‌های دیگر خود سداد و دیگر شرکت‌ها بتوانند از این تجربه بهره لازم را ببرند.

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

از یک طرف در بک‌لاگ محصول، از قبل کلی ویژگی پیاده‌سازی نشده وجود داشت و از طرف دیگر، ذی نفعان (بانک – مشتری – سازمان‌ها) دوست داشتند ایده‌های جدیدشان سریع‌تر پیاده سازی شوند. این مورد باعث ایجاد عارضه‌ای بنام لیست آرزوهای بابانوئل می شد.

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

وقتی اولویت بندی مناسبی وجود نداشته باشد یا اولویت‌ها در حالت تغییرات باشند(حتی وسط اسپرینت)، این باعث می شود که تیم دائما تحت فشار باشد، میزان پیشرفت خود را نتوانند بسنجند، میزان تاثیر خود بر کسب‌کار را درک نمی‌کنند، و هدفمند بودن کار را از دست می‌دهند(اسپرینت پشت اسپرینت، خوب که چی؟) و اصطلاحا کار تبدیل به کار گل می‌شود.

برای مواجهه با این داستان، تصمیم گرفته شد که سرمایه‌گذاری بر روی برنامه‌ریزی بیش از مفهوم اسپرینت صورت گیرد، یعنی مفهوم Release Plan به مفاهیم تیم اضافه شود. ولی Release Plan در سطح گسترده و صنعت بانکی(بخاطر تغییرات زیاد و لحظه‌ای) کار ساده‌ای نیست.

برنامه‌ریزی انتشار به چه صورتی انجام شد؟

1- فضای بزرگ لازم بود

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

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

2- مهمانان وابسته دعوت شده بودند تا وابستگی‌ها رفع شود

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

3- دمو برای کارهای انجام شده

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

3- مدیر محصول در جلسه حضور داشت و نقش پر رنگی بازی می‌کرد

گام اول: بررسی وضعیت در بازار

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

هدف مدیرمحصول در این بخش، آشنایی بیشتر و گره زدن بچه‌های فنی به نیازهای واقعی مشتریان بود.

(صحبت‌های این بخش باید کاملا تاثیر گذار یا Inspire کننده باشد تا تیم از کار قبلی خود کیف کند و برای ادامه انرژی ذخیره کند).

گام دوم: تعیین اولویت‌های نسخه بعدی

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

برای همین منظور مدیر محصول باید آماده وارد جلسه شود، و اولویت ها  و هدفگذاری او بیش از 3-4 مورد نباشد تا تیم‌ها بتوانند تمرکز لازم را داشته باشند.

4- طول نسخه

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

5- برنامه ریزی آیتم‌ها

در بام، یک بک لاگ محصول کلی وجود دارد که همه درخواست‌ها در آن نگه‌داری می شوند، یک بک‌لاگ تیم نیز وجود دارد که نمایی از بک‌لاگ محصول است. تحلیل‌گرها و اسکرام مسترهای تیم‌ها، بر اساس اولویت ها، بک‌لاگ تیم را آماده کرده بودند.

براساس اولویت‌های مدیر محصول، و آیتم‌های انتخاب شده، تیم قادر به انجام برنامه ریزی برای دو اسپرینت بعدی خود بود.

این برنامه‌ریزی باید سطح بالا انجام شود و لازم نیست که دقیقا مانند برنامه‌ریزی اسپرینت باشد.

6- کشف مشکلات و وابستگی‌ها

یکی از اهداف برنامه ریزی سبک و سطح بالای آیتم‌ها، کشف وابستگی به دیگر تیم و مشکلات است: 1- تیم‌های دیگر زودتر بدانند که چنین وابستگی به آنها وجود دارد و دلیل آن چیست تا بتوانند سریعا برای رفع آن برنامه ریزی کنند 2- مدیران زودتر مشکلات را بدانند و بتوانند برای رفع سریع آن اقدام کنند.

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

7- بستن برنامه ریزی

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

درس هایی که از برنامه ریزی گسترده انتشار یاد گرفتیم:

1- مدیرمحصول باید آماده وارد جلسه شود(در آنجا شروع به فکر کردن نکند) و باید تاثیر گذار ارایه کند.

2- تمامی ذی‌نفعان جهت ایجاد هماهنگی و حمایت از این برنامه‌ریزی باید حضور داشته باشند.

3- به دلیل تعداد زیاد نفرات، زمانبندی باید دقیق رعایت شود.

4- در انتهای هر جلسه؛ بازنگری برای خود جلسه نیاز است، که چگونه جلسه بعدی را بهتر برگزار کنیم.

5- کشف مشکلات و وابستگی به اندازه بخش اول جلسه مهم است، نباید آن را فراموش کنیم.

6- پیشرفت تیم ها در طول این یک ماه، باید به صورت بصری قابل مشاهده و در جلوی دید اعضای تیم باشد.

7- محیط این جلسه، باید انرژی بخش باشد.

8- نقش خوراکی در جلسه را دست کم نگیرید.

9- این جلسات باید به صورت منظم برگزار شوند.

10- اگر برنامه‌ریزی اولیه در طول یک ماه عوض شد، در برنامه‌ریزی بعدی حتما باید این مورد بررسی شود.

من تجربه، اجرای برنامه ریزی انتشار، برای تیم‌های زیادی داشتم، اما برای تیم‌ها گسترده و بیش از سه تیم داستان متفاوت‌تر، هیجان انگیزتر و سخت تر است. در این مسیر نیز دائم در حال یادگیری هستیم و ادعایی در مورد اختراع چیز جدیدی نداریم (:

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

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

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

اسد صفری

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

11 دیدگاه

  1. Alireza   •  

    مطلب خیلی عالی بود… فقط یک نکته، شاید مشکل داشتن تنها یک مدیر محصول (product owner؟) هست. PBI ها اگر در طول اسپرینت اولویت بندی و تخمین زده شوند، در شروع اسپرینت همه چیز آماده است. همانطور که گفتید product owner باید برای ارایه به اندازه 2 اسپرینت در sprint planning آمادگی داشته باشد.

    • اسد صفری   •     Author

      داخل تیم ها، تحلیل گرهایی وجود دارند که نقش PO تیمی رو هم بازی می کنند، و درواقع مدیرمحصولی که گفته شد در واقع PO نیست، بلکه Chief Product Owner هست.

  2. محسن عرب   •  

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

  3. علی دیشیدی   •  

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

    • اسد صفری   •     Author

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

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

  4. کاظم   •  

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

    • اسد صفری   •     Author

      بستر بام backbase هست، یک نوشته جامع آماده کردیم در مورد جزئیات بیشتر که بزودی چاپ خواهد شد

  5. Jimmy Heller   •  

    اینکه تجربه خوبت رو داری به اشتراک میگذاری خیلی ممنونم. من همیشه استفاده می کنم.

پاسخ دهید

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