چرا من هنوز با برآوردها مشکل دارم

چرا؟

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

من 100٪ مطمئن نیستم که آیا ناامیدی ناشی از ناتوانی در به پایان رساندن پروژه ها است یا از ناتوانی درک شده در پایبندی به یک ضرب الاجل خود تحمیلی (هر چند مصنوعی).

بنابراین این بار شما برخی از تفکرات من در مورد تخمین ها و برخی جنبه های جالب را می خوانید که می توان در کتاب اخیری که خواندم یافت و برخی چیزها را برای من در نظر گرفت.

چگونه؟

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

کجا اشتباه می کند؟

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

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

لحظه A-HA من

من نتوانسته بودم این را رسمی کنم، و تا زمانی که مطالعه موردی را مطالعه نکردم، به اصطلاحی که در من طنین انداز باشد، برخورد نکرده بودم. “چقدر کارهای بزرگ انجام می شود” توسط Bent Flyvbjerg و Dan Gardner.
داستان به ستون نویس روزنامه ای اشاره دارد که مشغول نوشتن بیوگرافی است. تخمین او بر اساس تجربه اش از نوشتن مقالات طولانی بود. این سوگیری تجربه قبلی “لنگر” نامیده می شود.
در داستان، نویسنده زندگی‌نامه 17 فصل را 9 ماه تا یک سال تخمین می‌زند، با استفاده از این واقعیت که یک مقاله طولانی 3 هفته طول می‌کشد تا تحقیق و نگارش شود. نیازی به گفتن نیست که این تخمین با ضریب ۷ کاهش یافت. در نهایت ۷ سال طول کشید.
این داستان در مورد او پایان خوشی دارد، با این حال این در میان مطالعات موردی مختلف، دور از ذهن است.
به نظر می رسد که لنگرها یک الگوی بسیار متداول هستند که ما برای تخمین مدت زمانی که چیزی طول می کشد استفاده می کنیم.

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

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

نتیجه گیری

• پروژه ها مجموعه ای از آزمایش ها هستند
• پروژه ها مجموعه ای از تجربیات شرکت کنندگان است
• تخمین فناوری خسته کننده آسان تر است
• اجتناب از ریزش کارکنان به تخمین پروژه ها کمک می کند