انتخاب پروژه نرمافزاری بر اساس قیمت کاملاً طبیعی است. هیچ کسبوکاری نمیخواهد بیدلیل بیشتر هزینه کند. مشکل از جایی شروع میشود که «ارزانتر» با «بهصرفهتر» اشتباه گرفته میشود.
دو پروژه ممکن است در زمان قرارداد چند ده میلیون اختلاف قیمت داشته باشند، اما هزینه واقعی آنها در دو سال بعد به دلیل نگهداری، بازنویسی و خطاهای عملیاتی کاملاً برعکس شود.
قیمت پایین چگونه به هزینه آینده تبدیل میشود؟
اگر برای کاهش قیمت، معماری بدون برنامه انتخاب شود، تست حذف شود، مستندات نوشته نشوند یا امنیت به بعد موکول شود، پروژه ممکن است سریعتر تحویل داده شود؛ اما تیم بعدی برای فهمیدن و اصلاح آن زمان زیادی مصرف خواهد کرد.
Technical Debt چیست؟
بعضی تصمیمهای فنی مثل گرفتن واماند. در کوتاهمدت سرعت میدهند، اما اگر عمداً و با برنامه گرفته نشوند، هزینه بازپرداخت ایجاد میکنند. کدی که فقط برای تحویل سریع نوشته شده، ممکن است در تغییرات بعدی چند برابر زمان بیشتری بگیرد.
اما پروژه گران هم الزاماً خوب نیست
این طرف ماجرا هم مهم است. قیمت بالا به خودی خود تضمین کیفیت نیست. ممکن است یک پروژه با هزینه زیاد هم نیازمندی مبهم، مدیریت ضعیف یا معماری نامناسب داشته باشد. بنابراین نباید فقط «ارزان یا گران» را مقایسه کرد؛ باید خروجی و کیفیت فرایند را سنجید.
چه چیزهایی را باید در پیشنهاد فنی بررسی کنیم؟
- تعریف دقیق محدوده پروژه
- معماری و تکنولوژیهای مورد استفاده
- روش تست و کنترل کیفیت
- امنیت و مدیریت دسترسی
- مستندسازی و قابلیت تحویل پروژه
- پشتیبانی و نگهداری بعد از انتشار
- هزینه تغییرات خارج از محدوده
قیمت پروژه را با عدد پروژه بعدی مقایسه نکنید؛ با هزینهای که قرار است در طول عمر محصول ایجاد کند مقایسه کنید.
سؤال مهمتر از «چقدر؟»
قبل از تصمیم بپرسید: «اگر این سیستم سه سال قرار است استفاده شود، چه چیزی باعث میشود در سال دوم و سوم هنوز قابل اتکا باشد؟» پاسخ باید در معماری، مستندات، امنیت، تست و برنامه نگهداری دیده شود.
هدف انتخاب گرانترین تیم یا ارزانترین تیم نیست. هدف انتخاب راهکاری است که نسبت مناسبی بین هزینه، کیفیت، ریسک و ارزش ایجاد کند.