در قسمت قبلی به بررسی دلایل تقریبا بیهوده و بی فایده بودن زور کردن نیروهای برنامه نویس به ارائه زمان بندی پرداختیم و اقلا به این نتیجه رسیدیم که این زمان بندی دقیق و قابل اطمینان نخواهد بود!
فرضیه ما این است که در یک تیم، ارائه زمانبندی به هر دلیلیی اجباری است، پس وقتی چاره ای نیست، اقلا ببینیم چگونه می شود از میزان اثرات بد زمان بندیهای بد و غیر قابل اعتماد بکاهیم ؟!.
1- از طول زمانهایی که پیش بینی میشود و میزان مسئولیتها بکاهید.
مثلا برای 6 ماه و 500 تا Task بزرگ زمان بندی نکنید زیرا اینطوری تعداد Task ها در زمان عملا ضرب شده و اگر خطایی وجود داشته باشد، عملا فاجعه درست میشود !. همه چیز را Unit های کوچکتر تبدیل و Milestone های و Check Point های کوچکتر بگذارید ، اینطوری اقلا زودتر و بهتر و روشنتر به خطاها پی خواهید برد و می توان جلوی بروز خطا را زودتر گرفت .
2- یک نفر را برای پیش بینی همه چیز نگمارید !
ضمننا کسی را برای پیش بینی و زمان دهی دیگری قرار ندهید. هر کسی باید برای کار و مسئولیت خودش زمان بندی ارائه کند
3- پروژه را به کامپوننتهای کوچک تبدیل کنید تا به این وسیله بتوان همه چیز را روشن تر دید و زمان بندی درست تری ارائه نمود.
بدترین مشکل ما در حین زمان بندی، Surface Level Understanding می باشد . اگر یک پروژه به بخشهای کوچکتری تبدیل شود، میتوان به عمق نیازمندی و چالشهای آن نگاه بهتری کرد و اینگونه درصد خطا در زمان دهی و پیاده سازی کمتر خواهد بود
4- تکنولوژی و Stack هایی انتخاب کنید که تیم به آنها آشنا است.
وقتی مثلا تا الان با Rust پروژه ای انجام نداده اید، چگونه روی پیاده سازی یک پروژه سنگین با این زمان میشود به کسی زمان بندی درستی داد ؟. مشتری را قربانی R&D خودتان نکنید !
در پایان باز هم تکرار میکنم، اجبار تیمهای فنی به زمان بندی در کل بیهوده است. هیچ وقت هم واقعی نخواهد بود. حالا اگر علاقه دارید خودتان و دیگران را اذیت کنید، اقلا موارد بالا را در نظر داشته باشید تا درد و خونریزی کمتری متحمل شوید !
نظرات
بندها دقیق و فوق العاده بود. بنظرم بهترین و جامع ترین راه حل های ممکن هست. شاید تنها سوال من اینه که چطور مدیر شرکت می تونه به کارفرما یه زمان بندی حدودی اولیه بده؟ اگر بنا باشه بصورت تسک به تسک بره جلو و زمان بندی کنه؟ کاش در مورد اون زمان بندی اولیه و کلی به کارفرما هم بیشتر توضیح بدین. لذت بردم.