چرا ما در برآورد پروژه های نرم افزاری بد می شویم

می‌توانید یک پروژه را برای ساعت‌های بیشماری برنامه‌ریزی کنید، استراتژی‌سازی کنید، تکه‌کنید، تا کنید، دوک بکنید و آن‌ها را مثله کنید، و هنوز هم از مشکلاتی که در نوشتن کد واقعی پیش روی شماست آگاه نخواهید شد.

باشه، پس من فقط می‌روم و می‌گویم:

برآورد دقیق یک پروژه نرم افزاری با اهمیت غیرممکن است.

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

ببینید، کتاب‌های بی‌شماری نوشته شده، کنفرانس‌های بی‌شماری برگزار شده، ساعت‌های مشاوره ناگفته خریداری شده، و پست‌های وبلاگ بی‌پایانی در مورد چگونگی بهتر شدن در برآورد پروژه‌های نرم‌افزاری نوشته شده‌اند. من آن را دریافت می کنم. همه ما با جدیت تلاش می کنیم تا بهترین تلاش خود را در تلاش برای آرام کردن رئیس های گرسنه ای که می خواهند بدانند چه زمانی یک ویژگی جدید آماده می شود، انجام دهیم. همه ما بر اساس تاریخ کنفرانس و نه زمانی که نرم افزار واقعاً آماده می شود، ضرب الاجل تعیین می کنیم.

اما نکته اصلی این است که ما به سادگی نمی توانیم این کار را انجام دهیم. خوب، ما می‌توانیم آن را انجام دهیم – در واقع، ما همیشه آن را انجام می‌دهیم – اما نمی‌توانیم آن را به خوبی انجام دهیم. به عبارت دیگر، ما همیشه در اشتباهیم.

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

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

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

البته، این اتفاق می افتد زیرا مدیر نرم افزار معمولی همیشه بر این باور است که مسیر طی شده یک بزرگراه صاف و مستقیم با آب و هوای دلپذیر تا مقصد خواهد بود. و این به سادگی هرگز چنین نیست. الزامات تغییر می کند و هرگز پروژه را کوچکتر نمی کند. مردم PTO غیرمنتظره می گیرند. سایر پروژه ها یا اولویت ها تداخل دارند. بخش فروش برای بستن یک معامله بزرگ به این یک ترفند کوچک نیاز دارد. هیچ چیز بادهای منصفانه و دنبال کردن دریاها از ابتدا تا انتها نیست. همیشه.

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

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

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

من راه حلی ندارم، و حتی شک دارم که راه حلی وجود داشته باشد. پذیرش آن اولین قدم برای کنار آمدن با مشکلی است که به سادگی هرگز از بین نخواهد رفت.