هزینهٔ ساخت وب‌اپلیکیشن را چگونه برآورد کنیم؟ روش بازه و سناریو
7 min read
برآورد هزینهٔ وب‌اپلیکیشن را از یک عدد ثابت به یک بازهٔ قابل‌دفاع تبدیل کنید: اجزای هزینه، سه سناریو و راه‌های باریک‌کردن عدم‌قطعیت؛ بدون قیمت بازار.
هزینهٔ ساخت وب‌اپلیکیشن را نمی‌شود با یک عدد ثابت از روی عنوان پروژه برآورد کرد؛ روش درست این است که هزینه را به اجزای قابل‌توضیح بشکنید، برای هر جزء یک بازه با فرض‌های روشن بنویسید و اجازه بدهید با شفاف‌شدن نیازمندی‌ها بازه باریک‌تر شود. در این مقاله هیچ قیمت بازاری نمی‌آید، چون عدد معتبر و تاریخ‌دار و قابل‌استناد برای بازار ایران در دسترس نبود؛ به‌جای آن، یک روش سناریویی می‌دهیم که با اعداد خودتان کار می‌کند.
چرا اولین برآورد همیشه یک بازه است، نه یک عدد؟
Steve McConnell در توضیح «مخروط عدم‌قطعیت» (Cone of Uncertainty) می‌نویسد: در آغاز پروژه، جزئیات نیازمندی‌ها، راه‌حل، برنامه و نیروی انسانی هنوز روشن نیست و همین ابهام به برآورد منتقل می‌شود. به نوشتهٔ Construx، برآوردی که در مرحلهٔ «ایدهٔ اولیه» ساخته شود می‌تواند تا ۴ برابر بیشتر یا ۴ برابر کمتر از واقعیت باشد (کل بازه ۱۶ برابر). این توصیف بهترین حالت دقت برای برآوردکنندگان ماهر است؛ برآورد ضعیف‌تر می‌تواند بدتر هم باشد.
پیام عملی مهم‌تر این است: «یک هفته وقت بدهید تا برآورد را دقیق‌تر کنیم» معمولاً جواب نمی‌دهد. Construx می‌گوید دقت برآورد به میزان شفافیت تعریف نرم‌افزار بستگی دارد و تنها راه کم‌کردن عدم‌قطعیت برآورد، کم‌کردن عدم‌قطعیت خود پروژه است؛ یعنی تصمیم‌گرفتن دربارهٔ چشم‌انداز، نیازمندی‌ها (از جمله اینکه چه چیزی ساخته نمی‌شود) و طراحی رابط. پس بهترین سرمایه‌گذاری قبل از قرارداد کامل، یک مرحلهٔ کشف کوتاه است. برای نحوهٔ نوشتن همین ورودی‌ها به برنامه‌ریزی پروژه پیش از نوشتن کد نگاه کنید.
هزینه از چه اجزایی ساخته می‌شود؟
برای اینکه عدد قابل‌دفاع باشد، آن را به اجزایی بشکنید که هرکدام فرض و مالک مشخصی دارند. جدول زیر فهرست پیشنهادی است، نه فهرستی از قیمت‌ها.
| جزء هزینه | پرسش کلیدی | چه چیزی بازه را عریض می‌کند؟ |
|---|---|---|
| کشف و تحلیل | مسئله، کاربر و محدودهٔ نسخهٔ اول چیست؟ | نیازمندی‌های مبهم یا در حال تغییر |
| طراحی تجربه و رابط | چند جریان اصلی و چند حالت (خطا، خالی، نقش‌ها) داریم؟ | نقش‌های متعدد، پنل مدیریت، چندزبانگی و راست‌چین |
| توسعهٔ بک‌اند و دیتابیس | قوانین کسب‌وکار و مدل داده چقدر پیچیده است؟ | گزارش‌گیری، فرایندهای چندمرحله‌ای، همگام‌سازی داده |
| یکپارچگی با سرویس‌های بیرونی | با چه سامانه‌هایی (پرداخت، پیامک، حسابداری، CRM) ارتباط داریم؟ | مستندات ضعیف، محیط آزمایشی ناپایدار، تغییر API طرف مقابل |
| امنیت و حریم خصوصی | چه دادهٔ حساسی ذخیره می‌شود؟ | نقش‌ها و مجوزها، ردگیری، الزامات سازمان مشتری |
| تست و کیفیت | چه سطحی از آزمون خودکار و دستی لازم است؟ | جریان‌های مالی یا حساس، تنوع دستگاه‌ها |
| استقرار و زیرساخت | چند محیط، چه سطحی از دسترس‌پذیری و پشتیبان‌گیری؟ | هدف دسترس‌پذیری بالا، چندمحیطی بودن |
| مدیریت پروژه و ارتباط | چه کسی تصمیم می‌گیرد و بازبینی چقدر طول می‌کشد؟ | چند ذی‌نفع با نظر متفاوت |
| نگه‌داری پس از انتشار | چه کسی رفع اشکال، به‌روزرسانی و پایش را انجام می‌دهد؟ | وابستگی‌های قدیمی، نبود مستندات |
دو جزء معمولاً دست‌کم گرفته می‌شوند: یکپارچگی با سرویس‌های بیرونی و نگه‌داری. اولی چون فقط وقتی وارد کار شوید معلوم می‌شود طرف مقابل چه رفتاری دارد؛ دومی چون بعد از انتشار هم هزینه ادامه دارد. اگر دربارهٔ آمادگی انتشار مطمئن نیستید، مقالهٔ چه چیزی یک محصول نرم‌افزاری را Production-Ready می‌کند کمک می‌کند بدانید چه کارهایی پیش از «تمام‌شدن» باید دیده شوند.
هدف دسترس‌پذیری و کیفیت هم هزینه دارد
یکی از بزرگ‌ترین اهرم‌های هزینه، سطح قابلیت اطمینانی است که از سیستم انتظار دارید. کتاب Site Reliability Engineering گوگل می‌گوید هزینه با افزایش قابلیت اطمینان خطی بالا نمی‌رود و یک پله بهبود اضافه ممکن است ۱۰۰ برابر پله قبلی هزینه داشته باشد. پس «سایت همیشه بالا باشد» بدون عدد، یک درخواست بی‌سقف است. بنویسید چه میزان قطعی برای کسب‌وکار قابل‌تحمل است و بعد ببینید ارزشش از هزینهٔ بیشترش بیشتر است یا نه؛ همان منطق هزینه/فایدهٔ ساده‌ای که SRE برای انتخاب هدف دسترس‌پذیری پیشنهاد می‌دهد. این گزاره دربارهٔ سیستم‌های بزرگ گوگل است و عدد ۱۰۰ برابر را نباید قانون عمومی دانست؛ فقط یادآور غیرخطی‌بودن است.
روش سناریویی: سه عدد به‌جای یک عدد
برای هر جزء جدول بالا سه سناریو بنویسید:
- حداقل منطقی: نسخهٔ اول با کمترین قابلیت‌هایی که هنوز مشکل کاربر را حل می‌کند.
- مورد انتظار: قابلیت‌های اصلی به‌علاوهٔ حاشیهٔ معقول برای بازبینی و اشکال.
- گسترش‌یافته: قابلیت‌هایی که فقط در صورت موفقیت نسخهٔ اول ارزش دارند.
سپس برای هر سناریو، زمان کار تیم را بر اساس نقش‌ها تخمین بزنید و در نرخ همان نقش ضرب کنید؛ هزینهٔ سرویس‌های بیرونی، زیرساخت و نگه‌داری را جدا اضافه کنید. فرمول کلی، با واحدهای فرضی خودتان:
هزینهٔ سناریو = (جمع زمان نقش‌ها × نرخ هر نقش)
+ هزینهٔ سرویس‌ها و مجوزها
+ هزینهٔ زیرساخت دورهٔ ساخت
+ ذخیرهٔ ریسک (درصدی که خودتان با توجه به ناشناخته‌ها تعیین می‌کنید)
هزینهٔ سالانهٔ نگه‌داری = زیرساخت + پایش + زمان رفع اشکال و بهروزرسانیاین فرمول یک چارچوب محاسبه است و منبعی آن را به‌عنوان استاندارد تأیید نکرده است؛ هر عددی که وارد می‌کنید باید از نرخ‌ها و تخمین‌های واقعی خودتان بیاید.
مثال فرضی و غیرواقعی (با «واحد» به‌جای پول): اگر برای یک جزء ۱۰ واحد کار در سناریوی حداقل و ۱۸ واحد در سناریوی مورد انتظار می‌بینید، اختلاف ۸ واحد همان چیزی است که باید دربارهٔ آن تصمیم بگیرید: «این ۸ واحد چه قابلیتی می‌خرد؟» این اعداد ساختگی‌اند و فقط برای نمایش روش آمده‌اند؛ نه دادهٔ پروژه، نه دادهٔ بازار.
چه کسی باید تخمین بزند؟
راهنمای Scrum می‌گوید Developerهایی که کار را انجام می‌دهند مسئول اندازه‌گیری (sizing) هستند و Product Backlog فهرستی در حال تکامل است. معنای عملی‌اش برای خریدار: برآورد را از کسانی بخواهید که قرار است کار را بسازند، نه فقط از فروشنده. و انتظار نداشته باشید فهرست قابلیت‌ها از روز اول ثابت بماند؛ اگر بعضی قابلیت‌ها در سناریوی «گسترش‌یافته» هستند، نتیجهٔ طبیعی یک backlog اولویت‌بندی‌شده است.
بازه چطور باریک می‌شود؟
طبق توضیح Construx، با تصمیم‌هایی که ابهام را حذف می‌کنند مخروط باریک می‌شود: تعریف چشم‌انداز (از جمله چیزهایی که ساخته نمی‌شوند)، تعریف نیازمندی‌ها و طراحی رابط. همان منبع می‌گوید راه میانی رایج این است که تا حدود ۳۰٪ زمان تقویمی پروژه (عبور از طراحی رابط) نسبتاً ترتیبی جلو بروند و بعد به‌صورت تکرارشونده ادامه دهند؛ این رویکرد عدم‌قطعیت را تا حدود ±۲۵٪ می‌رساند. این رقم دربارهٔ نوع خاصی از مدل کار است و تضمینی برای پروژهٔ شما نیست، اما نشان می‌دهد چرا مرحلهٔ کشف و طراحی اولیه ارزان‌ترین راه کم‌کردن ریسک مالی است.
- قبل از قرارداد کل، یک مرحلهٔ کشف و طراحی با خروجی مکتوب جدا قیمت‌گذاری کنید.
- فهرست «چیزهایی که ساخته نمی‌شود» را بنویسید.
- تصمیم‌های بلندمدت را بعد از شفاف‌شدن جریان‌های اصلی ببندید، نه قبل.
- برای مرحله‌های بعد، بازبرآورد دوره‌ای در قرارداد بگنجانید.
اشتباه‌های رایج در برآورد هزینه
- مقایسهٔ دو پیشنهاد بدون یکسان‌کردن محدوده؛ یکی ارزان است چون چیز کمتری می‌سازد.
- فراموش‌کردن هزینهٔ سالانهٔ نگه‌داری، زیرساخت و مجوزها.
- تکیه بر «عدد شبیه پروژهٔ دیگر» بدون بررسی تفاوت نقش‌ها، یکپارچگی‌ها و حساسیت داده.
- نداشتن ذخیرهٔ ریسک برای ناشناخته‌ها.
- قطعی‌کردن بودجه پیش از بسته‌شدن جریان‌های اصلی.
اگر بین ساخت اختصاصی و راهکار آماده مردد هستید، چگونه تکنولوژی مناسب یک پروژه را انتخاب کنیم و انتخاب معماری وب‌اپلیکیشن دو مسیر مکمل‌اند، چون پشته و معماری مستقیم روی ردیف‌های جدول بالا اثر می‌گذارند.
قدم بعدی
یک جدول با ردیف‌های بالا و سه ستون سناریو بسازید و اول فقط «فرض‌ها» را پر کنید. برای یک برآورد اولیه در سایت ما می‌توانید تخمین هزینهٔ پروژه را امتحان کنید، و اگر ایده‌تان به یک محصول دیجیتال کامل نزدیک است، صفحهٔ طراحی و ساخت محصول را ببینید. این‌ها فقط نقطهٔ شروع گفت‌وگو هستند، نه قیمت قطعی.
منابع و مراجع
- Software Development's Cone of Uncertainty — Steve McConnell، Construx، White Paper نسخهٔ ۱، ژانویهٔ ۲۰۱۰.
- Embracing Risk — Site Reliability Engineering، Google.
- The Scrum Guide — Ken Schwaber و Jeff Sutherland، نسخهٔ نوامبر ۲۰۲۰.
Author
SE
Soheil Ebrahimpour is the founder of FutureForge. He works on product design, architecture, and getting custom software into production.
Related notes
If you are unsure about architecture or the build path, we can talk about the project.
Describe the problem and the constraints. If there is a fit, we will schedule a conversation.
