هزینه‌ی نرم‌افزار اختصاصی چطور برآورد می‌شود؟ (و چرا برآوردها می‌لنگند)

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

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

چرا برآوردها می‌لنگند؟ چیزی که شمرده می‌شود، کارِ اصلی نیست

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

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

همان فرمِ یک‌روزه، با جوابِ این چهار سؤال، چهار تا پنج روز کار است. و نکته این است که هیچ‌کدامِ این سؤال‌ها در جلسه‌ی اول پرسیده نمی‌شود — چون در جلسه‌ی اول همه دارند به مسیرِ درست فکر می‌کنند، نه به مسیرهای خراب.

پس قاعده‌ی اصلی: آنچه برآورد می‌شود مسیرِ خوش‌بینانه است؛ آنچه وقت می‌گیرد حالت‌های حاشیه‌ای است. سه عاملِ دیگر هم همین اثر را دارند:

1. داده‌ی موجود همیشه کثیف‌تر از تصور است. مهاجرت از اکسل یا سیستمِ قدیمی روی کاغذ یک کارِ ساده است؛ در عمل با نام‌های تکراری، فیلدهای خالی، تاریخ‌های بی‌قاعده و کدهای دستی روبه‌رو می‌شوید. پاک‌سازیِ داده اغلب از خودِ ساختِ سیستم بیشتر طول می‌کشد.
2. در یکپارچه‌سازی، زمان دستِ شما نیست. اتصال به حسابداری، انبار یا سرویسِ بیرونی به مستنداتِ آن طرف، دسترسیِ آزمایشی و پاسخ‌گوییِ تیمِ آن‌ها وابسته است. یک اتصال می‌تواند دو روز یا دو ماه باشد و تفاوتش ربطی به تیمِ توسعه ندارد.
3. تغییرِ نظر طبیعی است. تا چیزی را نبینید نمی‌دانید دقیقاً چه می‌خواهید. این عیب نیست، ولی اگر قرارداد جایی برای آن باز نگذاشته باشد، تبدیل به اختلاف می‌شود.

واحدِ شمارشِ درست برای نرم‌افزارِ سازمانی

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

چرا گردشِ کار گران‌ترین است؟ چون «مدیر تأیید می‌کند» یک حالت نیست، چند حالت است: رد کند چه شود، ارجاع بدهد به کی، در غیبتش جانشین کیست، آیا می‌شود به مرحله‌ی قبل برگشت، و اگر سندی بعد از تأیید عوض شد تأیید باطل می‌شود یا نه. هر تأییدیه در عمل یک زیرسیستمِ کوچک است. اگر بودجه‌تان محدود است، ساده‌ترین راهِ کم‌کردنِ هزینه کم‌کردنِ مراحلِ تأیید است — که اغلب فرایندِ سازمان را هم بهتر می‌کند (اصولِ اتوماسیونِ فرایند).

مدلِ قرارداد: ریسک کجا می‌نشیند؟

این بخش را کمتر کسی از دیدِ خریدار توضیح می‌دهد. سه مدلِ رایج وجود دارد و تفاوتشان در قیمت نیست، در جای ریسک است:

نکته‌ی مهم درباره‌ی قیمتِ ثابت: امنیتی که می‌دهد تا حدی ظاهری است. پیمانکاری که ریسک را می‌پذیرد، آن را در قیمت حساب می‌کند؛ و از آن مهم‌تر، انگیزه‌اش این می‌شود که دامنه را تنگ نگه دارد. نتیجه‌اش جلسه‌هایی است که در آن‌ها به‌جای حلِ مسئله، درباره‌ی «این در قرارداد بود یا نه» بحث می‌شود. فازبندی این مشکل را حل می‌کند، چون دامنه‌ی هر فاز کوچک و روشن است و تغییرِ نظر جای طبیعی‌ای برای نشستن دارد: فازِ بعد.

هزینه‌ای که در فاکتور نیست: وقتِ خودتان

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

• جلساتِ کشفِ نیاز و بازبینی — با حضورِ کسی که واقعاً فرایند را می‌داند، نه فقط مدیر.
• تهیه و پاک‌سازیِ داده — فهرستِ محصولات، مشتریان، قیمت‌ها. این کار را کسِ دیگری نمی‌تواند برایتان بکند.
• تستِ پذیرش — کسی از سمتِ شما باید سیستم را با کارِ واقعی امتحان کند. اشکالی که در این مرحله پیدا نشود، بعد از راه‌اندازی گران‌تر است.
• آموزشِ کاربران و پذیرشِ این‌که هفته‌های اول کندتر کار می‌کنند.
• دوره‌ی موازی‌کاری — مدتی هم سیستمِ قدیم کار می‌کند هم جدید. این دوره لازم است و کار را دو برابر می‌کند.

و نتیجه‌ی عملی که از همه مهم‌تر است: پروژه‌ای که یک «مسئولِ داخلی» با زمانِ اختصاصی ندارد، دیر می‌شود — بی‌ربط به توانِ پیمانکار. چون تصمیم‌ها روی زمین می‌مانند و هر انتظار برای یک جواب، به تعویق در زنجیره تبدیل می‌شود.

گران‌ترین هزینه: ساختنِ چیزی که استفاده نمی‌شود

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

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

نگهداری: بیشترش تغییرِ قانون و فرایند است، نه باگ

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

به همین دلیل قراردادِ نگهداری را با این نگاه ببندید: نه «ضمانتِ رفعِ باگ»، بلکه ظرفیتِ تغییرِ سالانه. سازمانی که این را از ابتدا در بودجه دیده، دو سالِ بعد مجبور نمی‌شود بین «سیستمِ کهنه» و «پروژه‌ی تازه» انتخاب کند.

پس چطور به یک عددِ قابلِ اعتماد برسیم؟

مسیرِ عملی، در سه قدم:

1. پنج قلمِ بالا را خودتان بشمارید و روی کاغذ بیاورید. همین یک صفحه، کیفیتِ همه‌ی جلساتِ بعدی را عوض می‌کند.
2. فازِ اول را کوچک ببندید — فقط چیزی که بدونِ آن سیستم بی‌فایده است. بقیه در فهرستِ فاز دو می‌ماند.
3. برآوردِ مکتوب با فرضیات بگیرید. برآوردی که فقط یک عدد است، عدد نیست؛ باید بگوید چه چیزی داخل است، چه چیزی نیست، و بر چه فرضی بسته شده.

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

جمع‌بندی

سه چیز را ببرید. اول: برآوردها به مسیرِ خوش‌بینانه نگاه می‌کنند و کارِ اصلی در حالت‌های حاشیه‌ای است؛ پس هر سؤالی که درباره‌ی «اگر خراب شد چه؟» بپرسید، برآورد را دقیق‌تر می‌کند. دوم: مدلِ قرارداد تعیین می‌کند ریسک کجا بنشیند؛ قیمتِ ثابت امنیتِ ظاهری می‌دهد و فازبندی انتخابِ عملی‌تری است. سوم: بخشی از هزینه در فاکتور نیست و وقتِ خودِ سازمان است؛ پروژه‌ای که مسئولِ داخلی ندارد دیر می‌شود.

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