نباید تخمین بزنید!
برنامه‌ریزی برای یه پروژه نرم‌افزاری موضوع پیچیده‌ایه. اگه بخواین که هرگونه تخمینی بزنین به احتمال زیاد در نهایت باعث سوء مدیریت توی زمان و منابع می‌شین. بنابراین نباید تخمین بزنین. اگه تا اینا با من موافقین احتمال داره که بقیه مقاله هیچ نکته‌ای براتون نداشته باشه. ولی اگه به نظرتون حرفم درست نیست یا می‌خواین دلایلش رو بدونین من امروز اینجا راجع به این ادعا توضیح میدم.
توسعه نرم‌افزار کار پیچیده‌ای هست
تقریبا همه روی این موضوع متفق‌القول هستیم. توسعه نرم‌افزار پیچیده است. اصلا به همین دلیل فرایندهای اجایل بوجود اومدن.
طبق تعریف فرایندهای چابک یه رویکرد تکاملی و بهبود مستمر دارن. در نتیجه الزامات و راه‌حل‌ها در طول اجرای پروژه تغییر می‌کنن. همین موضوع باعث میشه که حتی برنامه‌ریزی کامل یک پروژه از ابتدا کار عملی‌ای نباشه. در نتیجه مشخصه که به برنامه‌ای که وجود نداره نمیشه عمل کرد!
هم انتظارات ذی‌نفعان و هم راه‌حل‌های تیم در طول پروژه تغییر می‌کنن. ایده‌ها عوض می‌شن. بعلاوه برنامه‌ریزی معماری، بهینه‌سازی ویژگی‌ها و بهینه‌سازی تجربه کاربری (همه بخش‌های کلیدی فرآیند) مممکنه چیزی کاملاً جدید به وجود بیارن.
یه تیم نرم‌افزاری ممکنه بتونه یه فرض نزدیک ارائه بده، اما این صرفا یه فرض نزدیکه و نه یه محدودیت دقیق. توی راهنمای اسکرام ۲۰۱۷ هم بوضوح میگه که پیش‌بینی با کار انجام شده متفاوته.
در نتیجه ما هیچ نیازی به ضرب العجل دقیق نداریم. کافیه تیم با هم کار کنن تا اولویت بندی مناسبی انجام بشه.
پروژه نرم‌افزاری مثل پروژه تحقیقاتیه
هر پروژه نرم‌افزاری در واقع یه سرویس کاربردیه که قراره یک مشکل مشخص رو حل کنه یا یک سری نیازمندی مشخص رو جواب بده. مهمه که با تجزیه تحلیل فرض‌هامون شروع کنیم. و فقط اینجوری می‌تونیم وارد مرحله برنامه‌ریزی بشیم و ابزارهای لازم رو انتخاب کنیم.
پروژه نرم‌افزاری شبیه پروژه ساختمان‌سازی نیست. ما توی ساخت ساختمان یه نقشه مشخص داریم و یک سری مصالح مشخص. همه جواب ها از قبل معلومه و فقط باید بهشون عمل بشه.
توی یه پروژه مهندسی نرم‌افزار ما معمولا با یک سری سوال بی‌پاسخ کارمون رو شروع می‌کنیم. خیلی وقت‌ها باید زمینه‌های جدیدی ایجاد بشن. و باید چیزهایی ساخته بشن که پیش از این اصلا وجود نداشتن.
شاید بشه نتیجه نهایی رو تصور کرد اما برنامه‌ریزی مسیر رسیدن به نتیجه از همون اول واقعا سخته.
تخمین عامل گمراهیه
برای هر کارفرمایی پیدا کردن تیم توسعه مناسب فرایند پیچیده‌ایه. همیشه یه لیست از تیم‌ها هستن که باید پیشنهادها، تجربه‌ها و فرایندهای کاریشون رو با هم بررسی کنین.
تیم‌های توسعه هم این رو می‌دونن و تلاششون رو می‌کنن که توی این لیست بمونن و خط نخورن. نتیجه؟ تیم‌ها معمولا تخمین حداقلی می‌زنن!
این همون چیزیه که کارفرما می‌خواد؟ به نظر چیز بدی هم نمیاد درسته؟ خب جواب منفیه! فرضیات حتما تغییر می‌کنن اما تیم توسعه تلاش می‌کنه تا کارفرما رو متقاعد کنه با کمترین زمان و هزینه پروژه رو انجام می‌ده. در نتیجه تیم نرم‌افزاری فرضیات پروژه رو ثابت فرض می‌کنه.
توی بحث توسعه نرم‌افزار چسبیدن به واقعیت‌های اقتصادی یه جورایی تلاش برای کنترل چیزیه که شما هیچ وقت نمی‌تونین کنترلش کنین.
پس ما نتیجه می‌گیریم که این کار نمی‌کند!
برداشتی آزاد از جمله مشهور کیان پیرفلک
لیست ویژگی و مشخصات برای شما محصول نمیشه
هرچه محدودیت‌های صفت‌وسخت‌تری برای پروژه داشته‌باشیم امکان ایجاد ارزش افزوده رو کمتر می‌کنیم.
البته که ما یه لیستی از ویژگی‌های مورد نیاز داریم. ولی باید به این نکته توجه کنیم که تیم توسعه همیشه می‌تونه راه‌حل‌های بهتری بده. خیلی وقت‌ها این راه‌حل‌ها می‌تونه با نیاز کاربر نهایی سازگاری بیشتری داشته باشه.
یه توسعه دهنده خوب صرفا یه برنامه‌نویس خوب نیست. بلکه معمولا پیشنهادات خوبی هم ارائه می‌ده. پس به جای داشتن یه لیست بسیار محکم، بهتره که توی کار تا حدودی انعطاف داشته باشیم تا با کمک تیم توسعه بتونیم به محصول بهتری برسیم.
تخمین وقت رو تلف می‌کنه
تخمین به نوبه خودش یه کاره. یعنی تیم توسعه باید بخشی از زمانش رو روی این بذاره که حجم کار رو تخمین بزنه. خود تخمین زدن زمان مهمی رو از تیم توسعه می‌گیره. این زمان به جای تلف شدن سر تخمین، می‌تونه برای تولید یه محصول مفید استفاده بشه
تخمین یا حجم کار رو افزایش می‌ده یا کیفیتش رو کاهش
می‌دونیم که بسیار بعیده یه تخمینی دقیقا به اندازه میزان زمان مود نیاز برای انجام کار باشه. حتی راجع به کارهای ساده‌تر هم این بعید به نظر میاد. پس دو حالت ممکنه پیش بیاد:
۱. تخمین کمتر از زمان واقعی
توی این حالت فشار روی تیم زیاد میشه. در دراز مدت تیمی که هیچ‌وقت زمان کافی واسه انجام دادن کارهاش نداره همیشه بخشی از کار رو عقب میندازه. مثلا تست‌هاش رو انجام نمی‌ده و … که اصطلاحا بهش می‌گن بدهی فنی. بعد مدتی حجم بدهی فنی زیاد میشه و این کار هم مستقیما کیفیت محصول رو میاره پایین و هم خودش فشار رو مضاعف می‌کنه و این چرخه هربار سریعتر و قوی‌تر می‌چرخه.
۲. تخمین بیشتر از زمان واقعی
این یه اصل توی مدیریته. کارها حداقل به اندازه زمانی که بهشون اختصاص داده بشه طول می‌کشن. تخمین بیش تر از زمانی که واقعا مورد نیازه باعث میشه تیم اجرای کار رو بیشتر از چیزی که واقعا نیاز هست کش بدن. نکته مهم اینه که تیم عمدا این تصمیم رو نمی‌گیره. این اتفاق بصورت ناخودآگاه می‌افته و مقصرش تیم نیست بلکه تخمینه.
پس باید چی کار کنیم؟
۱. دامنه پروژه رو محدود کنین
به جای اینکه صد در صد مشخصات مود نیاز رو مشخص کنید، نقاط عطف و اولویت‌هلا رو مشخص کنید. به عنوان مثال مشخص کنید مهمترین چیزی که در هر بازه سه ماهه قراره بهش برسین چیه. بقیه چیزها و جزییات رو اجازه بدین در طول روند توسعه مشخص بشن.
۲. اولویت‌بندی کنین.
مهمترین کار یک مالک محصول (مدیر محصول)، اولویت‌بندی نیازهاست. اگه شما خودتون مالک (مدیر) محصول نیستین حتما این نقش باید توی تیمی که باهاش کار می‌کنین وجود داشته باشه. به هر حال من قبلا یه مقاله دیگه به اسم «۳ تکنیک اولویت بندی که همه مدیران محصول باید بدانند» نوشتم که فکر می‌کنم اگه تا اینجای این مقاله رو خوندین حتما از خوندن اون هم لذت می‌برین.
۳. چشم‌انداز پروژه رو تعیین کنید
در درجه اول روی کاربر تمرکز کنین. نیاها و مشکلات کاربر و روشی که این محصول قراره به اونها جواب بده رو مشخص کنین.
داشتن یک خلاصه واضح و مختصر به تیم پروژه کمک می‌کنه تا بهتر محصول رو درک کنن. وقتی افراد درک درستی از محصول داشته باشن پیشنهادات بهتری می‌دن
۴. با تیم توسعه همکاری مستمر داشته باشین
هرچقدر همکاری شما با تیم توسعه نزدیکتر باشه شانس تبدیل پروژه به یک محصول موفق بیشتره. چون توسه دهندگان می‌تونن راه‌حل‌های بهتری پیدا کنن.
ممنون مفید بود
همیشه چالش داشتم سر این تخمین. مخصوصا اونجا که به جای تخمین زمان رو پروژه وقت بذاریم نتیجه بهتری می‌گیرم
ترجیح میدم یکی دیگه اینکارو انجام بده
من فکر می‌کنم تیم توسعه نه تنها نباید تخمین بزنه بلکه اصلا اگه کس دیگه‌ای هم تخمین می‌زنه نیم توسعه نباید در جریان تخمین باشه. اصلا نباید تخمین یا ددلاین رو به تیم توسعه داد.