پروفایل برنامه ریزی و کنترل پروژه

نادر خرمی راد

تکلیف تیز کردن تبر چی میشه؟

تقریبا ۴ ماه پیش تمرین ویژه‌ای برای کسایی که اون زمان دوره آشنایی با مفهوم چابکی در پروژه رو تموم کرده بودن فرستاده شد و ازشون خواسته شد که جواب‌هاشون رو ارسال کنن. سوال این بود:

 

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

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

نظرتون در مورد این تضاد چیه؟

 

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

تو فرم سه سوال وجود داشت…

سوال ۱: کلا چقدر با حرف لینکلن موافقین؟

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

جواب‌ها مقادیری از ۱ (کاملا مخالف) تا ۷ (کاملا موافق) هستن.

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

این نمودار عملا ترکیبی از یه نمودار نرماله با یه نمودار دیگه که سمت راست انباشته شده. تحلیل این ماجرا یه کم پیچیده‌س؛ متاسفانه ساده‌ترین تعبیر اینه که حداقل بخشی از کسانی که «کاملا موافق» جواب دادن دارن یه مقدار ایدئولوژیک با مسئله برخورد می‌کنن و بهتره کمی چاشنی تردید به باورهاشون اضافه کنن!

سوال ۲: کلا چقدر با رویکرد چابک در اجرای پروژه‌ها موافقین؟

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

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

نکته: همبستگی دو گروه جواب

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

مقدار همبستگی بین پاسخ‌های اول و دوم ۰/۱۲ بود، که خیلی کمه و نشون می‌ده این‌که چقدر افراد با رویکرد چابک موافق بودن ارتباط چندانی به این‌که چقدر با رویکرد لینکلن موافق باشن نداره. به عبارت دیگه، از نظر کسایی که به تمرین جواب دادن تناقض چندانی بین این دو وجود نداره.

سوال ۳: آیا تضادی هست؟ اگه هست چطور اون رو توجیه می‌کنین و اگه نیست چرا؟

دلیل این‌که خیلی طول کشید این مطلب رو بنویسم این بود که سوال سوم انشایی بود و مجموع جواب‌ها بیشتر از هشت هزار کلمه؛ خوندنش وقت می‌بره. با این حال از خوندن جواب‌ها خیلی لذت بردم. مجموعا خیلی خوب بودن و بعضی‌ها نکته‌سنجی‌های خیلی جالبی هم کرده بودن.

تمام جواب‌ها تو یه فایل PDF در انتهای این مطلب قرار داره و می‌تونین دانلود کنین خودتون هم بخونین.

توضیح من

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

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

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

 

ماجرای روش اجرای کار هم همینه. روش‌ها متفاوتن و بسته به محیط کار انتخاب می‌شن. این «محیط» هم تحت تاثیر خروجی کار و هم ذی‌نفعانشه.

حالا ماجرا برای قطع کردن درخت چی می‌شه؟

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

 

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

 

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

 

در هر حال، ماجرا اینه که هر پروژه‌ای نیاز به آماده‌سازی داره. برنامه‌ریزی پروژه بخش خیلی مهمی از آماده‌سازیه. این‌که چطور و در چه زمانی آماده‌سازی رو انجام بدیم برمی‌گرده به روش اجرایی‌مون.

 

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

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

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

 

نکته آخر: چابکی به معنی عجولی نیست.

دریافت فایل پاسخ‌ها

تمام جواب‌ها تو یه فایل قرار داده شدن که می‌تونین دانلود کنین و بخونین؛ به نظرم خوندنشون جالبه:

 

پینوشت ۱

متوجه شدم که تو متن بعضی پاسخ‌ها حرف «ی» نقطه‌دار وجود داشت؛ مشکلی که خوشبختانه سال‌های اخیر خیلی کم شده، ولی متاسفانه هنوز وجود داره. تو فارسی از «ی» نقطه‌دار استفاده نمی‌شه و وجودش تو متن نشون‌دهنده کم‌توجهیه. اکیدا پیشنهاد می‌کنم که این ایراد رو تو کامپیوترهاتون رفع کنین. برای این کار راهنما تو اینترنت زیاده. برای محل کارتون هم می‌تونین از واحد IT درخواست کنین که براتون درستش کنه.

پینوشت ۲

یه نکته دیگه که می‌تونه تو متن‌ها اصلاح بشه، نقطه‌گذاریه. نقطه پایان خط و ویرگول باید به حرف قبلیشون بچسبن؛ به هیچ وجه بینشون فاصله ندین.

نوشته نادر خرمی راد (Nader Khorrami Rad)

دوره آموزشی رایگان مفهوم چابکی در پروژه

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

دوره آموزشی چابکی در پروژه

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

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

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

ثبت نام در دوره مفهوم چابکی در پروژه

نوشته نادر خرمی راد (Nader Khorrami Rad)

کدوم توصیه درسته؟

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

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

 

موارد متناقض اینچنینی زیاد می‌بینیم و شاید این سوال براتون پیش بیاد که کدوم درست می‌گه. جواب هم ساده‌س: سوال درست نیست!

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

 

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

نوشته نادر خرمی راد (Nader Khorrami Rad)

رویکرد چابک به محدودیت‌های سه‌گانه پروژه

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

به هر حال، یکی از تفاوت‌های عمده‌ای که تو رویکرد چابک Atern به پروژه هست رو می‌شه روی همین مثلث توضیح داد:

رویکرد چابک اترن

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

تو رویکرد چابک اترن (DSDM Aten) برعکس عمل می‌کنیم، یعنی هزینه و زمان و کیفیت رو از ابتدا مشخص و ثابت می‌کنیم و گستره رو کم و زیاد می‌کنیم.

به نظرتون عجیب میاد، نه؟ مثلا یه پیمانکار با کارفرماش قراردادی می‌بنده که توش مدت زمان و هزینه و کیفیت کار به دقت مشخص شده، ولی گستره کار اجازه داره که تغییر کنه!

 

کاری که با گستره می‌کنیم اینه که با تکنیک اولویت‌بندی مسکو مدیریتش می‌کنیم:

 

MoSCoW Prioritization

 

حروفی که تو مسکو (MoSCoW) هستن ابتدای این عبارت‌هان:

  • Must have – اون بخش‌هایی از گستره که حتما باید تولید بشن و اگه نباشن محصول نهایی پروژه اصلا به درد نمی‌خوره.
  • Should have – اون بخش‌هایی از گستره که واقعا بودنشون لازمه، ولی اگه نباشن باز هم می‌تونیم از محصول نهایی پروژه استفاده کنیم، فقط ممکنه لازم باشه یه راه حل‌های جانبی برای بعضی کمبودها در نظر بگیریم.
  • Could have – اون بخشی از گستره که خیلی خوشمون میاد تو محصول نهایی باشه، ولی نباشه هم اتفاقی نمی‌افته.
  • Won’t have this time – اون چیزهایی که فعلا قصد نداریم تو محصول نهایی پروژه باشه؛ هرچند که ممکنه به نظر مرتبط بیاد.

 

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

برعکسش، اگه محصول همه Mustها و Shouldها و Couldها رو داشته باشه، می‌شه محصول ایده‌ال.

 

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

 

از این روش تو پروژه‌هایی استفاده می‌شه که:

  • تغییرات و عدم قطعیت زیاد باشه
  • و تا وقتی کارفرما بخش‌هایی از کار رو ندیده باشه نتونه انتظارهای خودش رو به روشنی مشخص کنه

 

که عمدتا می‌شه:

  • پروژه‌های نرم‌افزاری
  • پروژه‌های تحقیقاتی
  • پروژه‌های تغییر سازمانی

 

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

 

ایده‌ای که پشت همه این‌ها هست همون قاعده ۲۰/۸۰ هست؛ این‌که حدود ۸۰ درصد ارزش محصول نهایی پروژه با حدود ۲۰ درصد گستره اون ایجاد می‌شه. پس چرا:

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

 

البته خوب، شکی نیست که تو هر نوع پروژه‌ای نمی‌شه این کار رو کرد، یا حداقل خیلی سخت می‌شه. مثلا تو پروژه احداث یه بیمارستان به این راحتی نمی‌شه گستره رو با تکنیک مسکو دسته‌بندی کرد.

نوشته نادر خرمی راد (Nader Khorrami Rad)

چطوری می‌شه پروژه‌ای رو چابک پیش برد؟

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

Agile

چه وقتی باید چابک بود؟

وقتی از روش‌های چابک استفاده می‌کنیم که عدم قطعیت‌ها و تغییرهای پروژه خیلی زیاد باشن. مثال همیشگی من اینه: فرض کنین قراره یه بیمارستان بسازین. ممکنه خیلی تغییرات به پروژه اعمال بشه، حتی ممکنه تعداد طبقه‌هاش کم و زیاد بشه، ولی احتمالا در آخر باز هم یه بیمارستان خواهد بود و مثلا یه شهر بازی از آب در نمیاد. غیر از اینه؟ ولی تو بعضی پروژه‌ها این‌طور نیست. مثلا تو پروژه‌های نرم‌افزاری ممکنه کار رو برای تولید یه «بیمارستان» شروع کنین و وقتی تموم می‌شه ببینین یه «شهر بازی» ساخته شده. روش‌های چابک برای این نوع پروژه‌ها در نظر گرفته شدن.

در حال حاضر از روش‌های چابک عمدتا برای پروژه‌های نرم‌افزاری و تا حدی برای پروژه‌های تحقیقاتی و تغییر سازمانی استفاده می‌شه. مثلا اگه می‌خواین یه ERP یا یه سیستم مدیریت اسناد تو سازمانتون پیاده‌سازی کنین می‌تونین چابک پیش ببرینش.

 

چابک بودن چطوریه؟

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

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

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

 

یعنی دقیقا چطوری پروژه رو انجام می‌دیم؟

مثلا تو اسکرام اینطوری پیش می‌ریم:

  1. لیستی از عملکردهایی که کارفرما نیاز داره تهیه می‌کنیم. این می‌شه گستره محصول. صبر نمی‌کنیم که لیست کامل بشه، همینقدر که یه مقدار از راه رو نشون بده کافیه، می‌ریم مرحله بعد. این لیست همیشه باید مرتب باشه، یعنی هرچقدر آیتمی مهم‌تره، بالاتر قرار بگیره.
  2. بر اساس ظرفیتی که از خودمون برآورد می‌کنیم تعدادی از آیتم‌ها رو از بالای لیست برمی‌داریم و می‌ذاریم برای «اسپرینت» پیش رو. هر «اسپرینت» یه مدت زمانه که از قبل برای کار مشخص می‌کنیم؛ مثلا یک ماه، یا دو هفته.
  3. تو مدتی که اسپرینت در حال پیش رفتنه آیتم‌هایی که انتخاب کرده بودیم رو تولید می‌کنیم و از طرف دیگه اگه تغییری کشف بشه هم به لیست محصول اعمال می‌کنیم، ولی یادمون می‌مونه که هیچ چیزی رو تو لیست اسپرینت تغییر ندیم، چون تمرکزمون رو از بین می‌بره.
  4. وقتی مدت زمان اسپرینت تموم می‌شه یه نسخه جدید از محصول ساخته شده که یه مرحله کامل‌تر از قبله. این محصول رو که فقط شامل آیتم‌های صد در صد کامله در اختیار کارفرما قرار می‌دیم و توضیح هم می‌دیم. بعد بازخورد کارفرما رو دریافت می‌کنیم و تو لیست محصول اعمال می‌کنیم. یادتون باشه که انقدر کار نمی‌کنیم که تمام آیتم‌های اسپرینت تولید بشن؛ مدت زمان اسپرینت ثابته و نه کمش می‌کنیم و نه زیاد. هرچقدر آیتم که بشه تو اون مدت زمان تولید می‌کنیم و اگه نشه هم نشده!
  5. اگه لیست محصول تموم شده باشه یا کارفرما به این نتیجه برسه که محصولی که تا همین مرحله تولید شده براش کفایت می‌کنه، پروژه تموم می‌شه. وگرنه برمی‌گردیم به مرحله ۲.

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

 

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

 

ولی مگه هر پروژه‌ای تدریجی و مرحله به مرحله انجام نمی‌شه؟

نه به اون معنی که تو روش‌های چابک در نظر داریم؛ مشکل اصلی اینه که من معادل خوبی برای عبارت‌های iterative و incremental به نظرم نمی‌رسه فعلا. اون محصول باید طوری باشه که هر نسخه‌ش هرچند به شکل محدود قابل استفاده باشه. ما باید همیشه این آمادگی رو داشته باشیم که پروژه در پایان یه اسپرینت تموم بشه و محصولش بره برای استفاده نهایی. وقتی داریم یه بیمارستان می‌سازیم هم اینطوریه؟ قطعا نه؛ معمولا تا وقتی پروژه تموم نشه محصولش قابل استفاده نیست.

پروژه‌های نرم‌افزاری رو هم قدیم مثل بیمارستان پیش می‌بردن؛ طوری مرحله به مرحله تنظیمش می‌کردن که تا وقتی کل مراحل انجام نشده بود محصول قابل استفاده‌ای وجود نداشت. ولی الان به اون سبک پیش نمی‌ریم.

 

از طرف دیگه، تو پروژه‌های کلاسیک گستره و کیفیت رو ثابت در نظر می‌گیریم و سعی می‌کنیم با بالا و پایین کردن زمان و هزینه خودمون رو منطبق کنیم. گستره تو پروژه‌های چابک ثابت نیست و نهایتا ممکنه زمان رو ثابت بگیریم (مثلا تو متود Atern). کاری که می‌کنیم اینه که حواسمون به ارزشی که هر بخشی از گستره تولید می‌کنه هست و طوری پروژه رو پیش می‌بریم که بیشترین ارزش ممکن در زودترین زمان به دست بیاد. معمولا هم این ماجرا با قاعده ۲۰/۸۰ پیش می‌ره، یعنی حدود ۸۰ درصد ارزش با ۲۰ درصد هزینه و زمان و انرژی تولید می‌شه. وقتی چابک پیش می‌ریم زمینه‌ای رو فراهم می‌کنیم که این مسئله به خوبی درک بشه و پروژه در زمان مناسب پایان داده بشه؛ جایی که پروزه با ۸۰ یا ۹۰ درصد ارزش نهاییش، ولی با ۲۰ تا ۴۰ درصد زمان و هزینه و انرژی تموم می‌شه. اگه تجربه‌ای تو پروژه‌های تغییر سازمانی داشته باشین (مثلا راه‌اندازی سیستم مدیریت اسناد) می‌تونین خیلی خوب درک کنین که تمرکز نکردن روی ارزش و وقت صرف کردن برای ریزه‌کاری‌های کم ارزش چقدر می‌تونه پروژه رو دچار مشکل کنه.

 

چطوری روش‌های چابک رو بیشتر یاد بگیرم؟

می‌تونین به این منابع مراجعه کنین:

نوشته نادر خرمی راد (Nader Khorrami Rad)

تولید در کارخانه، پروژه یا عملیات

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

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

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

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

نوشته نادر خرمی راد (Nader Khorrami Rad)

ایبوک رایگان کانبان و اسکرام در کنار هم

اکثر کسایی که کانبان رو می‌شناسن، جنبه‌ای از اون که تو تولید (عملیات) به کار می‌ره رو می‌شناسن. همون رویکرد تو بعضی پروژه‌ها هم به کار می‌ره. الان عمده‌ترین پروژه‌هایی که از کانبان کمک می‌گیرن پروژه‌های چابک هستن.

انجمن چابک ایران

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

به اسد صفری و بقیه کسانی که برای این کتاب زحمت کشیدن تبریک می‌گم.

نوشته نادر خرمی راد (Nader Khorrami Rad)

چابک سازی سازمان

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

نوشته نادر خرمی راد (Nader Khorrami Rad)

منابع یادگیری اسرام

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

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

 

ایبوک رایگان Scrum and XP from the Trenches، نوشته Henrik Kniberg

یا ترجمه رایگان فارسیش، اسکرام و اکس پی ساده شده، ترجمه اسد صفری

 

نسخه چاپی کتاب فارسی هم به تازگی منتشر شده.

نوشته نادر خرمی راد (Nader Khorrami Rad)

پادکست های فارسی درباره اجایل

آرش میلانی به تازگی داره پادکست‌هایی درباره مدیریت پروژه چابک (agile) ارائه می‌کنه. امروز برای اولین بار فرصت شد که گوش بدم؛ به نظرم خیلی خوب اومد.

پس اگه به این موضوع علاقه دارین یا این‌که می‌خواین به سادگی بفهمین که ماجرای اجایل و اسکرام چیه، به این دو قسمتی که تا الان منتشر شده مراجعه کنین:

 

  1. آشنایی با اجایل
  2. اسکرام، روشی برای شکست در سی روز یا کمتر
نوشته نادر خرمی راد (Nader Khorrami Rad)

پادکست های فارسی درباره اجایل

آرش میلانی به تازگی داره پادکست‌هایی درباره مدیریت پروژه چابک (agile) ارائه می‌کنه. امروز برای اولین بار فرصت شد که گوش بدم؛ به نظرم خیلی خوب اومد.

پس اگه به این موضوع علاقه دارین یا این‌که می‌خواین به سادگی بفهمین که ماجرای اجایل و اسکرام چیه، به این دو قسمتی که تا الان منتشر شده مراجعه کنین:

 

  1. آشنایی با اجایل
  2. اسکرام، روشی برای شکست در سی روز یا کمتر
نوشته نادر خرمی راد (Nader Khorrami Rad)

دریافت گواهی CSM

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

image

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

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

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

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

نوشته نادر خرمی راد (Nader Khorrami Rad)

آخرین روزهای ثبت نام دوره CSM

قراره تو ایران دوره‌ای برای CSM (مخفف Certified Scrum Master) برگزار بشه، که به نوعی پیش‌نیاز اجباری دریافت گواهی اون هم هست. ثبت نام این دوره که قراره 19 و 20 اردیبهشت (روز تولد من!) برگزار بشه به زودی تموم می‌شه و خواستم بهتون خبر داده باشم. هزینه دوره هم 688 تومنه، که البته کم نیست، ولی مشابه هزینه اکثر گواهی‌های بین‌المللیه.

image

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

نکته جالب در مورد SCRUM، البته در حدی که من باهاش آشنا هستم و به هیچ وجه هم متخصصش به حساب نمیام، اینه که توش مدیریت پروژه به عهده فرد یا گروه خاصی نیست، بلکه بین اعضای تیم پروژه توزیع می‌شه (نکته خیلی جالب) و به جای مدیر پروژه، شخصی به نام Scrum Master هست که به اجرای صحیح سیستم کمک می‌کنه و می‌شه عملا اون رو متا-مدیرپروژه دونست.

نوشته نادر خرمی راد (Nader Khorrami Rad)

گواهی Agile از PMI

چند روز پیش مطلع شدم که PMI (موسسه مدیریت پروژه، همونی که استاندارد پم‌باک و گواهی PMP رو می‌ده) یه امتحان و گواهی برای مدیریت پروژه Agile تهیه کرده.

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

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

در هر حال، PMI هم توجهش به Agile خیلی بیشتر شده و آزمون و گواهی براش طراحی کرده، که نشون می‌ده از نظر اون‌ها هم این متود رو می‌شه به شکل وسیع‌تری به کار برد. اگه مطالب سایت رو دنبال کرده باشین می‌دونین که گواهی دیگه‌ای هم برای Agile هست، به اسم CSM (مخفف Certified Scrum Master) که خاص Scrum طراحی شده (یکی از انواع Agile) و در آینده نزدیک دوره آموزشیش هم در ایران برگزار می‌شه. تفاوت عمده آزمون PMI با اون در اینه که علاوه بر Scrum، انواع دیگه Agile رو هم پوشش می‌ده.

اگه علاقه‌مند به این موضوع باشین می‌تونین اطلاعات بیشتر رو از سایت PMI بگیرین.

نوشته نادر خرمی راد (Nader Khorrami Rad)

ایبوکی فارسی درباره اسکرام و XP

یکی از همکارانمون که تو حوزه مدیریت پروژه‌های نرم‌افزاری کار می‌کنه کتاب ساده، مفید و معروفی به اسم Scrum and XP from the Trenches: How we do Scrum رو ترجمه کرده. می‌تونین برای دریافتش به صفحه نسخه فارسی کتاب، با نام اسکرام و اکس پی ساده شده، مراجعه کنین.

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

نوشته نادر خرمی راد (Nader Khorrami Rad)

برگزاری دوره CSM در ایران

کسایی که با مدیریت پروژه‌های نرم‌افزاری سر و کار دارن همه Agile و Scrum و اینطور چیزا رو می‌شناسن. کسایی هم که مثل من با پروژه‌های ساخت و ساز سر و کار دارن، معمولا اسم این چیزا به گوششون خورده.

حالا قراره یه دوره برای CSM، یعنی Certified Scrum Master تو ایران برگزار بشه. اگه تو حوزه مدیریت تولید نرم‌افزار و اینطور چیزا کار می‌کنین که تقریبا واجبه برین، اگر هم مثل من هستین که احتمالا زیاد به دردتون نمی‌خوره، ولی ممکنه مثل من از سر کنجکاوی برین.

دوره دو روزه، به احتمال زیاد اول و دوم آذر 89.

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

نوشته نادر خرمی راد (Nader Khorrami Rad)
اشتراک مطالب سایت

با اشتراک در فرم زیر مطالب جدید برایتان ایمیل می‌شوند:

اشتراک مطالب در تلگرام