نجات پروژه شکست خورده توسط اسکرام

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

علت اینکه بازگردانی این پروژه ها سخت یا غیر ممکن می شود این است که دیر متوجه می شویم (دیر با واقعیت روبرو می شویم) پروژه شکست خورده است و در این موقع هم اکثر پل های پشت سرمان را بدون اینکه بدانیم شکسته ایم… . کنترل پروژه رفته رفته از دست خارج شده است – اصلا معلوم نیست چه میزانی از پروژه تکمیل و چه میزانی باقی مانده است – خروجی ها ارائه شده پر از مشکل می باشد – مشتری اعصبانی است – اعتماد بین اعضای تیم از بین رفته است و خبری هم از کار تیمی نیست و … .

در این مواقع اسکرام می تواند کمک کننده به احیای پروژه باشد. یعنی در هر جایی از پروژه که بودیم و با هر متدی که کار می کردیم می توانیم از این به بعد دست به دامن اسکرام شویم تا شاید اوضاع روبراه شود.

اولین کاری که اسکرام می تواند برای اینگونه پروژه ها انجام دهد این است که مشخص نماید هم اکنون پروژه در چه وضعیتی است زیرا که خاصیت شفاف سازی پروژه یکی از مزایای اصلی اسکرام می باشد. شفاف سازی اوضاع باعث می شود همه با واقعیت موجود روبرو شوند و مثلا از دادن قول هایی مانند «تا آخر هفته پروژه تکمیل است»پرهیز نمایند و بر اساس واقعیت ها برنامه ریزی نمایند.

شاید سوال پیش بیاید که چگونه باید شفاف سازی کرد؟

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

بک لاگ موارد ساخته نشده که دقیقا مانند بک لاگ محصول می باشد و بک لاگ موارد مشکل دار و تست نشده هم شامل آیتم هایی خواهد بود که یا تست نشده اند (تست پذیرش مشتری و تست یکپارچه سازی و … ) و یا مشکل دار هستند. گذشته از اینکه یک یا دو بک لاگ داشته باشید باید بک لاگ (ها) را برآورد نمایید که آن هم بر اساس Story Point  خواهد بود.

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

فرض کنید یک پروژه با زمان 1 سال داشتیم و بعد از 9 ماه فهمیدیم که در حال کج روی هستیم و خواستیم شفاف سازی نماییم. بعد از شفاف سازی فهمیدیم 200 پوینت آیتم داریم و 3 ماه هم وقت. طول اسپرینت های ما هم 4 هفته بود و با اندازه گیری سرعت به این نتیجه رسیدیم که تیم قادر است در هر اسپرینت 10 پوینت انجام بدهد. حالا این 200 پوینت با این سرعت 10 پوینتی به چند ماه کار نیاز دارد؟

بعد از این , مشکل مدیریتی خواهد بود. مثلا مدیریت می تواند با افزایش تعداد نفرات و تیم ها سرعت و ظرفیت انجام کار را بالا ببرد و یا می تواند با رایزنی از دامنه پروژه بکاهد و یا امثالهم.

اما بهترین تصمیم و یا عملکرد مدیریتی در این شرایط می تواند رفع موانع و درگیری های موجود می باشد, موانعی مانند موارد زیر :

• فشار بر روی تیم
• تست ها و پروسه های غیر موثر (مانند قوانین کدنویسی شرکتی)
• فقدان کار تیمی و انگیزه در نفرات
• انتظارات غیر واقعی
• عدم تمرکز شرکت بر روی پروژه
• مدیریت دستور- و – کنترل به جای خود سازماندهی

هر یک از این موارد ذکر شده تاثیر به سزایی بر روی ظرفیت و سرعت تیم و دیگر المان های موفقیت پروژه خواهد داشت مثلا فشار بیش از حد روی تیم باعث از بین رفتن انگیزه در تیم می شود و این نیز باعث افت شدید سرعت خواهد شد و … .

برای رفع این موانع می توان از توصیه های روش Agile بهره برد مثلا در Agile توصیه شده است به جای روش های دیگر مدیریتی از روش خود سازمانده سازی استفاده کرد که این خود باعث ایجاد نوآوری و انگیزه و … در تیم (ها) می شود. به عبارت ساده تر در این وضعیت می توان با ایجاد یک محیط چابک (Agile)  به موفقیت پروژه شکست خورده کمک شایانی کرد.

یاشیاسیز

خروجی کارآ در Agile

در پست قبلی در تعریف Agile Software Development بیان شد که خروجی اصلی Agile نرم افزار یا محصول کارآ می باشد و منظور از محصول کارآ نرم افزاری می باشد که بتواند نیازهای کسب و کار مشتری را به بهترین نحو پاسخ گو باشد.

حال سوالی مهمی که قابل طرح است این می باشد که : در محیط های Agile یا چابک چگونه می توان به نرم افزار کارآ دست یافت؟ و پروسه های قدیمی چگونه بودند که نمی توانستد به این مهم دست یابند؟

شکل های زیر جوابگوی این سوالات خواهند بود :

شکل بالا (به خاطر بی کیفیت بودن شکل عذر خواهی می کنم) نشانگر روند توسعه نرم افزار در متدهای قدیمی می باشد. همانطورکه قابل ملاحظه است مشتری در فاز ابتدایی پروژه اقدام به سفارش محصول A می کند و تیم توسعه بر حسب این سفارش اقدام به پیاده سازی بر اساس قرار داد مندرج می کند. بالاخره خروجی فاز توسعه بعد از مدت زمانی آماده و تحویل مشتری می شود. اما مشتری در هنگام استفاده از خروجی فاز توسعه متوجه می شود که «این آنی نیست که من می خواستم یا این آنی نیست که بتواند نیاز های من را رفع کند» . به طور خلاصه این محصول برای مشتری ناکارآمد می باشد.

شاید این ذهنیت به وجود بیاید که «باعث به وجود آمدن این خروجی ناکارآمد مشتری بوده است زیرا او در ابتدا نمی دانسته است چه می خواهد و این مشکل ربطی به تیم توسعه ندارد».  البته شاید در این مثال بدین گونه باشد ولی همیشه اینطور نیست و نخواهد بود. برای مثال شاید مشتری از اول B را در ذهن خود داشته ولی در ارتباطات و قرار داد بدلیل تعامل کم و کج فهمی تیم توسعه محصول ناکارآمد به وجود آمده است.خیلی دلایل می تواند باعث کج روی تیم بشود که این دلایل اصلا مهم نیستند و مهم این است که خروجی کارآ باشد.

اما در محیط Agile برای این که بتوانیم همان محصول را به گونه کارآ توسعه دهیم می توانیم به گونه زیر عمل نماییم:

همانطور که کاملا واضح است پروژه با Vision محصول A شروع می شود ولی در انتها مشتری صاحب محصول B است زیرا تیم توسعه و مشتری طی تعاملات دائمی در طول Iteration ها دائما در حال یادگیری هستند (یادگیری اینکه Business Value در چه سمتی و با چه محصولی به حداکثر خود خواهد رسید؟). اگر در شکل دقت نمایید متوجه می شوید  طی Iteration  ها به جای اینکه به جلو برویم (به طرف A ) کم کم به طرف B متمایل می شویم (محصول کارآ) . حتی در Iteration های آخر شاهد یک ثبات حرکتی هستیم که فقط و بدون تغییر جهت به سمت هدف حرکت می کنیم(بالاترین حد یادگیری).

در این حالت هزینه تغییر بسیار و بسیار پایین تر و مقرون به صرفه تر خواهد بود. از همه مهم تر خروجی پروژه یک محصول کارآ خواهد بود و محصول کارآ مشتری را از ما خوشحال خواهد نمود و مشتری خوشحال یعنی دست یابی به سود بیشتر و مشتری دائم.

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

یاشیاسیز

برنامه نویسی که مدیر پروژه شد

این جریان مدیر پروژه شدن برنامه نویس ها در ایران حکایتی بس طولانی دارد که در این پست قصد مختصر بررسی در این باب را دارم . قبل از شروع بحث موردنظر  لازم می بینم  نظر خودم را در مورد لزوم مدیر پروژه در پروژه های توسعه نرم افزار عرض کنم : به نظر بنده در 90% پروژه های توسعه نرم افزار در ایران نیازی به نقشی با نام مدیر پروژه نیست زیرا این پروژه  ها دارای خصوصیات یک پروژه واقعی نیستند که نیازی به مدیریت پروژه باشد : مثلا به مدیر پروژه بودجه اختصاص داده نمی شود که او بتواند Cost Management بکند یا بتواند نیروی کار مورد نیاز را استخدام بکند و یا … . به طوری کلی مدیر پروژه ای که در اینگونه پروژه ها فعالیت می کند دارای مجوز و اختیارات لازم نیست : یعنی عملا Iron Triangle پروژه در دستان او نیست . البته علاوه بر اینکه مالکان شرکت او را محدود کرده اند ,  او وظایف یک مدیر پروژه را نیز انجام نمی دهد . برای مثال یک شرکت آگهی زده است که :

به یک مدیر پروژه نرم افزاری  حاذق نیازمندیم با شرایط ذیل :

• توانایی کامل طرح ریزی کامل پروژه
• توانایی مدیریت
• توانایی برنامه نویس با زبان #C

کاملا از شرایط درخواستی معلوم است کسی که قرار است این کارها را انجام بدهد اسمش مدیر پروژه نیست (البته با توجه به تعاریف انیستیتو PMI ) . در ایران انتظار میرود که مدیر پروژه کل پروژه را طرح ریزی و طراحی کند . یعنی او عملا کار تحلیل گر و طراح را انجام می دهد  . بلی بنده قبول دارم که مدیر پروژه باید توانایی طرح ریزی داشته باشد ولی نه تحلیل و طراحی محصول  در بعد فنی و تکنیکی مثلا استخراج Class Diagram ؟ ! بلکه او در سطح مدیریت  باید طرح ریزی نماید : Road Map پروژه را مشخص کند ,  ریسک های پروژه را معلوم بکند و … .

انتظار بعدی این است توانایی مدیریت داشته باشد : خوب خیلی خوب است ولی توانایی مدیریت یعنی اینکه تقسیم وظایف برعهده او خواهد بود . مدیریت منابع انسانی (HR) تقسیم وظایف نیست . (مثلا از او انتظار میرود که وظایف برنامه نویسان را در هر ساعت مشخص کند) .

توانایی برنامه نویسی که فکر نکنم نیازی به توضیحات اضافی باشد . یعنی او همانند یک برنامه نویس در کنار زیردستان خویش باید بتواند برنامه نویسی بکند .

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

حکایت اینکه برنامه نویس مدیر پروژه می شود دقیقا مانند حکایت دندانپزشک شدن سلمونی ها در قدیم بود :

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

به نقل از نادر خرمی راد

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

اما و اما اخطار به مالکان شرکت ها : من قصد ندارم عرض بکنم که پروژه خود را به دست برنامه نویس ها ندهید ,  (بنده به عنوان برنامه نویس , مدیریت پروژه هم کرده ام ) ,  پروژه را به دست برنامه نویس های با تجربه بدهید و منتظر عواقب خوب و بد آن نیز باشید  مثلا امکان دارد عین سلمونی های قدیمی , دندون را طوری بکشد که پروژه درجا به دیار باقی بشتابد . یک مدیر پروژه واقعی می داند که در موقع شکست پروژه باید جوابگو باشد (ولی برنامه نویس چی ؟) یک مدیر پروژه می داند که باید در شرایط بحرانی چه کاری انجام دهد (برنامه نویس چی ؟) یک مدیر پروژه توانایی مدیریت منابع را دارا می باشد (یک برنامه  نویس چی ؟) و در کل کار و تخصص مدیر پروژه در حوزه مدیریت پروژه است ولی برنامه نویس در حوزه توسعه پروژه که در واقع سطح بندی متفاوتی دارند .

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

یاشیاسیز