چگونه در یک شرکت پروژه محور، محصول محور باشیم؟

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

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

اما در دنیا محصول محور، یک محصول تا زمانی که برای مشتری/شرکت ارزش خلق کند زنده خواهد ماند و تا هر زمانی که زنده است، توسعه ادامه خواهد داشت(چرخه عمر محصول).

فرض کنیم، نرم افزاری مانند اینستاگرام را بخواهیم پروژه در نظر بگیریم که یک شرکت پیمانکار از شرکت فیسبوک گرفته تا انجام دهد، احتمالا در نظام مدیریت پروژه سوال این است که “کی این پروژه تمام می شود؟ ساختار شکست کار به چه صورتی است؟” اما در واقعیت امروز؛ دائما تیم اینستاگرام با مشتری در تماس است، بازخورد می‌گیرد، بر اساس همین بازخورد یا مشاهده رقبای خود، اقدام به توسعه قابلیت‌های جدید می‌کند. در نگاه محصولی، ارزیابی عملکرد با ارزشی که محصول برای مشتری خلق می‌کند، صورت می پذیرد، اما در نگاه پروژه محور، متر موفقیت، هماهنگ بودن پیشرفت پروژه با برنامه از پیش تعیین شده و یا عقب/جلو بودن از آن است.

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

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

باز تاکید میکنم، منظور من این نیست که نظام مدیریت پروژه بد است. اما در صنعت نرم افزار، 1- اساسا دامنه کار ما از اول مشخص نیست 2- بعد از تحویل محصول، بخش اعظمی از دامنه کار معلوم می شود 3- محصولات نرم افزاری معمولا انتها ندارند البته تا زمانی که کنار گذاشته شوند.

باید قبول کرد که بسیاری از سازمانهای ما با اینکه می‌خواهند ولی هنوز کامل محصول محور نشده اند(به دلایل مختلف، مانند کارفرما، ساختارهای سنتی و … )، اما در این نوشته می‌خواهم کمی سعی کنم ارتباطی بین دو دنیا را برقرار کنیم.

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

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

1- برای چیزی که داریم برنامه ریزی کنیم

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

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

1- مبتنی بر زمان

2- مبتنی بر فیچر

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

2- چند نسخه جلوتر را باید برنامه ریزی کنیم؟

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

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

3- قیمت چگونه تعیین می شود؟

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

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

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

اگر بودجه تعیین شده تمام شد، و همچنان مشتری خواهان توسعه بود، می‌توانیم بودجه جدیدی برای توسعه در نظر بگیریم، اینکه مشتری از کجا بداند ما سر او کلاه نمیگذاریم، با همراه دائمی او در فرآیند توسعه و تحویل اقلام در نسخه های کوچک خواهد بود. (واقعیت این است نظام قرارداد در ایران بسیار قدیمی است و کاملا مبتنی بر شرایط پایدار و قطعیت تعیین شده و در بسیاری اوقات نمیتوان در قرارداد چابک عمل کرد، و بهترین گزینه داشتن یک قرارداد اما تعامل با مشتری در طول انجام کارها و ایجاد توافق برای ادامه راه بر اساس همان بودجه تصویب شده است، یا برخی مواقع قرار داد بر اساس متریال و زمان T&M میتوان گزینه خوبی باشد یعنی هر چند تا ریلییز کار انجام شد کارفرما پول بپردازد. در این مدل قرار اعتماد بین طرفین بسیار حیاتی است)

4- چگونه پیشرفت را اندازه بگیریم؟

در روش قدیمی، پیشرفت به یک برنامه نیاز دارد، مثلا گانت چارت، و یک سیستم لاگ زدن. متر ما در اسکرام Done  شدن اقلام قابل تحویل به مشتری در انتهای اسپرینت خواهد بود.

ما معمولا پیشرفت انجام کار را در سطح نسخه و نه محصول/پروژه اندازه می‌گیریم، و دلیل آن عادت دادن تیم و مشتری به مهم بودن نتیجه هر نسخه است و اینکه هر نسخه را به چشم یک پروژه نگاه می کنیم. نمودار Release Burndown یکی از بهترین گزینه ها در این خصوص است.

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

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

حالا بعد از انجام چند اسپرینت اتوماتیک نمودار بردن داوون برای شما ایجاد خواهد شد(منظور باز شدن و بسته شدن اسپرینت ها در جیرا):

این نمودار کمک می‌کند مدیر پروژه/محصول و تیم روند پیشرفت نسخه را ببینند و اگر نیاز به تغییر باشد، آن را سریع اعمال کنند. مثلا در شکل بالا شاهد این هستیم که 6 اسپرینت برای انجام مابقی اقلام این نسخه لازم است، اگر فکر می‌کنیم، 6 اسپرینت خیلی دیر است، می‌توانیم در اسکوپ باقی مانده این نسخه تجدید نظر کنیم.

5- تغییرات در اسکوپ نسخه

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

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

فرض کنید برای مثال باید تا سه تا اسپرینت بعد یعنی 1.5 ماه دیگر نسخه را ارایه کنیم، ولی الان برای کار باقی مانده ما به 5 اسپرینت نیاز داریم(بر اساس نمودار)، و سرعت انجام کار 6 پوینت و کار باقی مانده 30 پوینت است. برای اینکه در 3 اسپرینت کار بسته شود، یا باید تیم سرعت را به 10 پوینت برسانند که معمولا نیاز به اضافه کاری خواهد بود که در بلند مدت اصلا توصیه نمی شود، اما راه حل دیگر، بازی با دامنه خواهد بود.

6- از تکنیک MoSCoW استفاده کنید

معمولا در این مرحله که شما نیاز دارید بر روی دامنه مذاکره کنید، تکنیک MoSCoW روش موثری است:

در اینجا همراه با ذینفعان بر روی الویت بندی باید کار کرد، مثلا مانند تصویر زیر:

آیتمهای با الویت Will معمولا از نسخه حذف می شوند و به بک لاگ یا نسخه بعد اضافه می شوند، پس در نتیجه نمودار ریلیز برن داوون چنین چیزی نشان خواهد داد:

ما شاید بتوانیم در تفکر چابک، یک نسخه یا یک اسپرینت را پروژه در نظر بگیریم( البته همچنان باید منتظر بازی کردن با دامنه باشیم)، اما مسلما نمیتوانیم کل یک محصول پیچیده را یک پروژه در نظر بگیریم و انتظار داشته باشیم که با قواعد دنیای پروژه محور، بیشترین ارزش ممکن را خلق کنیم.

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

اسد صفری

این نوشته قبلا در این آدرس نیز منتشر شده بود.