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

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

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

در زیر دلایلی مبنی بر اینکه چرا توی دنیای توسعه نرم افزار به پروسه زمان بندی پروژه ها نیاز داریم آورده شده:

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

۲- همکاری بهتری اعضای تیم: زمان بندی ها یک درک مشترک بین اعضای تیم در رابطه با حجم و اندازه پروژه ایجاد میکنن. زمانی که همه ایده یکسانی در مورد کار هایی که باید انجام بشه و زمان انجام اونها داشته باشن، اعضای تیم همکاری بهینه تری با هم خواهند داشت و تیمتون میتونه روی چیزی که به بهترین شکل میتونه انجام بده تمرکز کنه: نوشتن کد خفن!

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

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

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

خیلی راحت تر میشه به یک نفر گفت که "بعد از یک هفته بررسی و تحقیق در مورد پروژه شما میشه گفت که بجای ۲۴ ماهی که به شما قول دادیم توی ۱۲ ماه این پروژه تموم میشه." تا اینکه بگیم "شرمنده! الان که داریم میبینیم بجای ۲۴ ماه گفته شده ۴۸ ماه دست ما رو بند میکنه!"

در زیر یک سری قوانین مربوط به تخمین مدت زمان مورد نیاز اتمام توسعه یک پروژه رو توضیح دادیم:

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

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

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