پروژه ام چقدر طول میکشه؟ (قسمت دوم)

همیشه بهتره که از اشتباهات دیگران درس بگیریم. در زیر چندین روش اشتباه برای تخمین زدن قرار دادیم که باید مثل خوردن نوشابه موقع شکم خالی ازشون پرهیز کنید (نگید که تا حالا نوشابه رو با شکم خالی خوردید!):

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

این خیلی مهمه که وقتی درخواست کننده به شما میگه که "من یک فروشگاه میخوام" منظورش رو به درستی بفهمید، به این دلیل که ممکنه اون تصوری که شما از فروشگاه دارید با اون تصوری که طرف مقابل داره زمان تا آسمون فرق کنه!

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

۱- اول روی تسک کار میشه.
۲- اطلاعات جدیدی کشف میشن.
۳- زمان های تخمین زده شده بهبود پیدا میکنن و در موردشون با بقیه صحبت میشه.
۴- برمیگردیم به قدم اول.

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

• تسک ها رو به قسمت های قابل مدیریت تر تقسیم کنید: تخمین زدن زمان مورد نیاز برای تسک های بزرگ و سنگین میتونه خسته کننده و سخت باشه. با تقسیم کردن تسک ها به قسمت های کوچک تر و قابل مدیریت تر میشه زمان و انرژی مورد نیاز برای هر قسمت رو بهتر تخمین زد. اگه با دنیای برنامه نویسی آشنایی دارید احتمالا اسم تابع بازگشتی یا recursive function رو شنیدید. برای این مثالمون فرایند تخمین زدن یک تسک رو به عنوان یک تابع بازگشتی در نظر میگیریم. ورودی این تابع محصولیه که میخوایم بسازیم. آیا میشه اون رو توی دو هفته کامل کنیم؟ نمیشه؟ پس به دو قسمت تقسیمش میکنیم و دوباره تابع رو با این دو قسمت جدید کال میکنیم؛ اگه این دفعه میشه، پس یک مقدار عددی نشون دهنده بازه زمانی دو هفته برگردونده میشه و در نهایت همه این مقادیر با هم جمع میشن.
• از اطلاعات و تجربه های قبلی استفاده کنید: زمانی که تسک های مشابه در تجربه های گذشته شما گرفتن رو در نظر بگیرید و از اون اطلاعات به عنوان پایه تخمین هاتون استفاده کنید (نمیگم دقیقا همون زمان رو برای تسک های مشابه در نظر بگیرید، که بالاتر از روش های اشتباه تخمین زدن بود). هیچ راهی برای تخمین زدن دقیق وجود نداره و همونطور که توی این سری از مقاله های ما قراره ببینید، باید چند تا پروژه رو گند بزنید تا بتونید تجربه های درست و درمون به دست بیارید و درس بگیرید.
• از تکنیک های مختلف تخمین زدن استفاده کنید: در مورد تکنیک های مختلف تخمین زدن مثل Planning Poker یا Wideband Delphi مطالعه کنید و خودتون رو باهاشون آشنا کنید. اگه وقتش رو دارید میتونید از این روش ها، مخصوصا توی شرکت ها و تیم های بزرگ، برای افزایش چشمگیر دقت تخمین زدن هاتون استفاده کنید. پایه و اساس پیاده سازی این تکنیک ها همکاری و ارتباط اعضای تیم با همدیگه هست، این طوری همه میتونن نظر ها و دیدگاهشون رو به اشتراک بذارن. هرکسی میتونه با توجه به نیاز های پروژه و سلیقه خودش یک متد رو از بین چند صد متد موجود توی اینترنت انتخاب کنه. هر کدوم از این متد ها بر اساس تجربه و نظر افراد مختلف با تخصص های گوناگون بنا شدن.
• بر اساس درصد اطمینان و خطا یک محدوده از زمان های مختلف رو در نظر بگیرید: بجای اینکه فقط یک زمان رو تخمین بزنید، یک محدوده از زمان های مختلف رو در نظر بگیرید که هر کدوم مربوط به یه درجه از خطا هستن. این کمک میکنه تا با توسعه و بزرگتر شدن پروژه انعطاف پذیری بیشتری در زمان بندی ها و انتظارات داشته باشید. با این حال در صورتی که دارید در مورد یک محدوده از زمان با دیگران صحبت میکنید باید تاکید کنید که اگه دارید میگید حداقل یک سال دلیل نمیشه که دقیقا همون یک سال زمان میبره.
• دنبال راهنمایی از منابع مختلف و افراد باتجربه تر بگردید: از توسعه دهنده های باتجربه تر یاد بگیرید که در طول زمان تجربه های زیادی از تخمین زدن زمان بندی پروژه های مختلف به دست آوردن. ویدیو های یوتوب در مورد اینکه چطوری غول های تکنولوژی مثل گوگل، اسپاتیفای، شاپیفای، و متا قسمت های مختلف پروژه ها رو مدیریت میکنن. پژوهش و مطالعات دیگران در مورد نحوه ساخته شدن ماژول های مورد علاقه خودتون رو ببینید. اصلا برید در مورد اینکه چطور یه سایتی مثل ردیس ساخته شده، یا چطوری دیتابیس های مختلف در پروژه های گوناگون به کار گرفته شدن مطالعه کنید. این دیدگاه ها و مطالعات میتونن به شما کمک کنن و یه دید کلی بهتون بدن تا توی تله های رایج گیر نکنید. اینترنت جای بزرگیه و صد در صد میتونید روزی نیم ساعت هم که شده در مورد این موضوع ها مطالعه کنید و اطلاعاتتون رو بالا ببرید.
• تحت تاثیر خواسته های بالادستی ها قرار نگیرید: اگه تخمینی که زدید ۵ هفته برای اتمام یک تسک رو نشون میده اما مدیرتون یا یک توسعه دهنده سنیور میگه باید ۳ هفته باشه به تخمین خودتون بچسبید و نگذارید تخمین های بی منطق سد راهتون بشن. تنها در صورتی باید این کار رو بکنید که دلایل منطقی و درست پشت این خواسته ها باشه.

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

توی قسمت بعدی منتظرتون هستیم :)