اقتصاد پروژه

هزینه توسعه نرم‌افزار اختصاصی چگونه محاسبه می‌شود؟

از تخمین اولیه تا صورتحساب نهایی؛ چه چیزی قیمت را می‌سازد

اگر از یک پیمانکار ساختمان بپرسید «ساخت یک خانه چقدر هزینه دارد؟»، اولین سؤالش این است: چند متر، چند طبقه، با چه متریالی، در کدام زمین؟ بدون این‌ها هر عددی که بدهد یا بی‌معناست یا آن‌قدر بالاست که خودش را بیمه کرده باشد.

نرم‌افزار دقیقاً همین است، با یک تفاوت مهم: در ساختمان همه می‌دانند متراژ یعنی چه، اما در نرم‌افزار «سیستم فروش» می‌تواند سه هفته کار باشد یا سه ماه — بسته به اینکه پشت آن کلمه چه فرایندی خوابیده باشد.

۱. اندازه‌ی دامنه. تعداد فرایندهای کسب‌وکار، تعداد موجودیت‌های اصلی (کالا، سند، مشتری، قرارداد) و تعداد صفحات. این ساده‌ترین و قابل شمردنی‌ترین عامل است. یک سامانه با شش موجودیت اصلی و چهار فرایند، با سامانه‌ای با سی موجودیت و بیست فرایند، دو دنیای متفاوت‌اند.

۲. پیچیدگی قواعد کسب‌وکار. این عامل بیشترین اثر و کمترین دیده‌شدن را دارد. یک فرم ساده‌ی ثبت سفارش، با فرمی که پشتش پانزده قاعده‌ی اعتبارسنجی، سه سطح تأیید و یک منطق قیمت‌گذاری پلکانی نشسته، از نظر ظاهری یکسان‌اند و از نظر تلاش چند برابر تفاوت دارند. اگر فقط یک عامل را دقیق بررسی می‌کنید، همین باشد.

۳. تعداد و عمق یکپارچگی‌ها. هر اتصال به یک سامانه‌ی بیرونی — سامانه‌های حاکمیتی، درگاه پرداخت، سامانه‌ی حمل، نرم‌افزار مالی موجود — هزینه‌ی توسعه، تست و نگهداشت خودش را دارد. یکپارچگی‌ها پرریسک‌ترین بخش‌اند، چون بخشی از رفتارشان خارج از کنترل شماست.

۴. تعداد نقش‌ها و کیفیت مورد انتظار رابط کاربری. هر نقش جدید یعنی مجموعه‌ای از دسترسی‌ها، صفحات و سناریوهای متفاوت. و بین «کار می‌کند» تا «کاربر بدون آموزش می‌فهمد چه باید بکند» فاصله‌ی قابل توجهی از کار طراحی و پیاده‌سازی وجود دارد.

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

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

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

    ▪      تحلیل فرایند و مستندسازی: حدود ۲۰ تا ۲۵ درصد کل پروژه. حذف آن، هزینه را جابه‌جا می‌کند نه کم.

    ▪      آزمون پذیرش با کاربر واقعی: برنامه‌ریزی سناریوها، اجرا، ثبت و رفع مشکلات.

    ▪      انتقال و پاک‌سازی داده: تقریباً همیشه از تخمین اولیه بیشتر طول می‌کشد.

    ▪      آموزش کاربران: به تفکیک نقش، به‌همراه راهنمای کاربری.

    ▪      پشتیبانی سال اول: رفع اشکال، پاسخ‌گویی و تغییرات کوچک.

    ▪      زیرساخت و راه‌اندازی: سرور، دامنه، گواهی امنیتی و پشتیبان‌گیری.

    ▪      تغییرات دامنه: بودجه‌ای برای چیزهایی که هنوز نمی‌دانید؛ حدود ۱۰ تا ۱۵ درصد ذخیره‌ی تغییرات واقع‌بینانه است.

این نسبت‌ها بر اساس پروژه‌های سازمانی متوسط است و بسته به نوع پروژه تغییر می‌کند، اما نقطه‌ی شروع خوبی برای بررسی منطقی بودن یک برآورد است:

۱. قیمت ثابت

کل پروژه با یک عدد مشخص. بودجه‌ی شما امن است، اما این امنیت رایگان نیست: تأمین‌کننده ناچار است حاشیه‌ی ریسک بالایی در نظر بگیرد و در برابر هر تغییری مقاومت کند، چون هر تغییر مستقیماً از حاشیه‌ی سود او کم می‌کند. مناسب پروژه‌هایی با دامنه‌ی کاملاً روشن و ثابت.

۲. زمان و مواد

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

۳. مرحله‌ای (پیشنهاد ما)

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

مزیت این مدل برای هر دو طرف روشن است: کارفرما با یک تعهد کوچک شروع می‌کند و پیش از تصمیم بزرگ، سند دامنه‌ای در دست دارد که حتی اگر ادامه ندهد، دارایی ارزشمندی است. تأمین‌کننده هم مجبور نیست برای ابهام، حاشیه‌ی ریسک سنگین بگذارد.

نشانه‌های برآورد قابل اعتماد

    ▪      به‌جای یک عدد، یک بازه می‌دهد؛ مثلاً کمینه و بیشینه با اختلاف ۳۰ تا ۴۰ درصد در مراحل اولیه.

    ▪      مفروضات را صریحاً می‌نویسد: بر چه اساسی این عدد محاسبه شده.

    ▪      موارد خارج از دامنه را فهرست می‌کند: چه چیزهایی در این قیمت نیست.

    ▪      روش محاسبه‌ی تغییرات را از قبل مشخص می‌کند.

    ▪      سهم مراحل غیرتوسعه‌ای در آن دیده می‌شود.

نشانه‌های هشدار

    ▪      عددی که بدون هیچ سؤالی درباره‌ی فرایند شما داده می‌شود.

    ▪      برآوردی که تحلیل و آزمون پذیرش در آن دیده نمی‌شود.

    ▪      قیمتی که به‌طور محسوسی از بقیه پایین‌تر است؛ در پروژه‌های نرم‌افزاری، پایین‌ترین قیمت معمولاً یعنی چیزی از دامنه حذف شده — و معمولاً همان چیزی که بعداً بیشترین هزینه را می‌سازد.

    ▪      وعده‌ی «همه‌چیز در این قیمت هست» بدون فهرست مکتوب.

۱. فاز اول را کوچک کنید. یک فرایند کامل و واقعی را انتخاب کنید و تا انتها تحویل بگیرید. هم زودتر ارزش می‌گیرید و هم برآورد فازهای بعد دقیق‌تر می‌شود.

۲. برای بخش‌های استاندارد، آماده بخرید. حقوق‌ودستمزد یا حسابداری پایه را نسازید. بودجه را جایی خرج کنید که تمایز می‌سازد.

۳. سریع تصمیم بگیرید. تصمیم‌های معلق، گران‌ترین بخش پروژه‌اند و در هیچ فاکتوری هم دیده نمی‌شوند.

۴. داده‌تان را از قبل آماده کنید. پاک‌سازی داده‌ی قدیمی کاری است که تیم داخلی شما می‌تواند موازی با توسعه انجام دهد و هزینه‌ی قابل توجهی صرفه‌جویی کند.

۵. دامنه را در فاز اول محدود کنید، نه کیفیت را. حذف یک ماژول از فاز اول تصمیم درستی است؛ حذف آزمون پذیرش نیست.

قیمت نرم‌افزار اختصاصی، عددی نیست که از قبل وجود داشته باشد و کسی آن را پنهان کرده باشد. محصول مستقیم دو چیز است: میزان روشنی مسئله و اندازه‌ی دامنه‌ای که انتخاب می‌کنید. هر دوی این‌ها تا حد زیادی در کنترل شماست.

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

در فناوری اطلاعات گارنت با مدل مرحله‌ای کار می‌کنیم: اول تحلیل با دامنه و قیمت مشخص، و بعد برآورد دقیق فازهای بعد بر اساس سندی که در دست دارید — سندی که مالک آن شما هستید، حتی اگر تصمیم بگیرید ادامه ندهید.

متن کامل مقالات و نمونه‌کارها: garnetapp.ir

    ▪      چگونه یک پروژه نرم‌افزاری را بدون شکست اجرا کنیم؟

    ▪      معماری نرم‌افزارهای سازمانی مدرن

    ▪      تجربه‌های واقعی از طراحی سیستم‌های مالی، انبارداری و ERP