تخمین‌زنی با درصد چقدر قابل‌اعتماد است؟
اگر مدیر باتجربه‌ای باشید که سال‌ها را در زمینۀ روش‌های سیستمی سپری کرده‌اید شاید بارها از شما سؤال شده باشد که چه درصدی از زمان یک پروژه معمولاً به یک فاز معین کار، مثلاً فاز ۱ مطالعۀ امکان‌پذیری، فاز ۲ طراحی سیستم‌ها و غیره تخصیص داده شود. اساساً علت این است که می‌خواهند از پاسخ برای تخمین میزان باقیماندۀ پروژه استفاده کند. به‌طورمثال اگر قرار بود که بگویم فاز، ۱۰درصد از کل پروژه است، آن‌ها به‌سادگی میزانِ زمان صرف‌شده در فاز ۱ پروژه را ضرب‌‌در ۱۰ می‌کنند. این روش مطمئنی برای تخمین نیست، برای همین بهتر است مدیران پروژه چنین تخمین‌هایی را اعلام نکنند.
ابعاد پروژه‌های توسعه‌های سیستم‌ها از بزرگ به کوچک متغیر است؛ هرچند مطمئناً می‌توان آمار را درنظر گرفت، روش تخمین بازهم یک رویکرد خطاپذیر است. درعوض پیشنهاد می‌شود که طراحی تقریبی محصولی که باید ساخته شود (سیستم)، با تمام بخش‌ها و قسمت‌های مختلف آن مانند ورودی‌ها، خروجی‌ها، فایل‌ها، ثبت‌ها و مولفه‌های داده‌ها مبنا قرار بگیرد. برخی از این مؤلفه‌ها ممکن است در دیگر سیستم‌ها مجدداً استفاده شوند؛ ممکن است برخی به اصلاح و تغییر نیاز داشته باشند، و برخی کاملاً جدید باشند. به این کار تخمین برمبنای «لیست مواد» [۱] یا BOM گفته می‌شود که مفهوم ساده‌ای است که از مهندسی و ساخت‌وساز گرفته شده است. حتی اگر پروژه‌ای فقط شامل یک برنامه باشد (برعکس یک سیستم بزرگ) بازهم تعداد و انواع مؤلفه‌های تأثیرگذار بر یک وظیفه را بررسی کنید.
بااین‌همه در این مقاله برای نسبت کار در یک پروژۀ معمولی توسعۀ سیستم‌ها پیشنهادی می‌دهیم. شاهد شرکت‌های بسیاری هستیم که از فاز اولیه عبور می‌کنند تا به فازهای برنامه‌نویسی، که آن را مهم‌ترین فاز می‌دانند، برسند. در سناریوِ این شرکت‌ها، برنامه‌نویسی ۸۵ درصد پروژه است. اما در سناریویی که ما پیشنهاد می‌کنیم زمان بیشتری بر فازهای اولیه سپری می‌شود تا تعریف نیازمندی‌ها شفافیت بیشتری بیابد و برای برنامه‌نویس‌ها مشخصات و DBAهای بهتری فراهم شود.
در این سناریو، ۶۰ درصد زمان در فازهای اولیه، شامل طراحی و تحلیل سیستم، و ۱۵درصد در برنامه‌ریزی و ۲۵درصد در پیاده‌سازی و بررسی صرف می‌شود. بله درست شنیدید فقط ۱۵درصد در برنامه‌نویسی!
علت این تفاوت چیست؟ فقط به این دلیل است که برنامه‌نویسان مدتی طولانی گرفتارِ مشخصات مناسب را ندارند و بارها و بارها برای تحویل آنچه لازم است تقلا و دوباره‌کاری می‌کنند. اما اگر ازقبل تلاش شود که مشخصات بهتری تحویل داده شود، برنامه‌نویس مجبور نیست زمانی را صرف حدس زدن دربارۀ کار کند.
برخی تلاش ازقبل را بی‌فایده و پوج می‌دانند و فکر می‌کنند کار واقعی حین برنامه‌نویسی انجام می‌شود. معلوم نیست چرا؛ شاید به این دلیل که برنامه‌نویسی برای مردم محسوس‌تر است؛ زیرا می‌توانند در صفحه‌نمایش و گزارش‌ها کار را به‌وضوح ببینند و به دیگران نشان بدهند. اما این طرزفکر در سناریوِ ما پسندیده نیست.
در این سناریو اعتقاد داریم که کار اصلی را باید در فازهای اولیه انجام داد؛
این طرزتفکر درنظر کسانی که چابک (Agile) کار می‌کنند شاید فسیلی و دایناسوری به نظر برسد! به‌هرحال اگر لازم است چیزی بسازید، یک پل، یک آسمان‌خراش، یک خودرو یا یک سیستم یا برنامۀ منفرد، اول باید کار خودتان را انجام بدهید، درغیراین‌صورت بارها و بارها مجبور می‌شوید که کار را خراب کنید و از اول بسازید.
سخن پایانی
برای استفاده از درصدها در تخمین‌های پروژه‌ها، این خطر وجود دارد که حساب کنید تا ۹۰درصد کار را تکمیل کرده‌اید، اما متوجه بشوید که ۱۰درصد باقیمانده تاابد طول می‌کشد! بنابراین پیشنهاد می‌شود که در دام درصدهای تخمینی نیفتید و از لیست موارد (BOM) استفاده کنید.
[۱] Bill of Materials
