رفتن به محتوای اصلی
دانشنامه ← مدیریت پروژه

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

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

۳ دقیقه مطالعه به‌روزرسانی: مرداد ۱۴۰۵
راهنمای دیجیتال و ارتباط میان وب‌سایت و اپلیکیشن

۱. تعداد صفحه کافی نیست

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

  • —نقش و دسترسی
  • —مسیر و استثنا
  • —قواعد محاسبه
  • —تعداد پلتفرم
  • —حساسیت داده
  • —اتصال بیرونی
  • —آفلاین
  • —گزارش و پنل
  • —طراحی
  • —آزمایش

۲. محدوده و سناریو

برای هر قابلیت بپرسید:

  • —چه کسی استفاده می‌کند؟
  • —ورودی و خروجی چیست؟
  • —مسیر عادی چیست؟
  • —استثنا چیست؟
  • —چه کسی تأیید می‌کند؟
  • —چه سابقه‌ای لازم است؟
  • —معیار پذیرش چیست؟
  • —چه چیزی خارج از نسخه است؟

۳. طراحی

طراحی می‌تواند شامل تحقیق، معماری اطلاعات، جریان، وایرفریم، نمونهٔ اولیه، رابط، واکنش‌گرایی، تست کاربر و دسترسی‌پذیری باشد.

تصمیم‌گیری پیش از توسعه ممکن است هزینهٔ بازنویسی بعدی را کاهش دهد.

۴. داده و اتصال

وجود API اتصال ساده را تضمین نمی‌کند. مستندات، نرخ، امنیت و محیط آزمایش مهم‌اند.

انتقال دادهٔ قدیمی به کیفیت، تکرار، قالب ناسازگار و کنترل انسانی بستگی دارد.

مالک حساب سرویس‌ها، هزینه و نحوهٔ تحویل دسترسی باید روشن باشد.

۵. امنیت و کیفیت

  • —احراز هویت
  • —دسترسی
  • —رمزنگاری انتقال
  • —ثبت رویداد
  • —نسخهٔ پشتیبان
  • —مدیریت secret
  • —حفاظت فایل
  • —تست
  • —مانیتورینگ
  • —استقرار و rollback

سطح کنترل باید با ریسک محصول متناسب باشد.

۶. ابهام و فاز شناخت

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

  • —تعریف مسئله
  • —محدودهٔ نسخهٔ اول
  • —جریان و نمونه
  • —معماری اولیه
  • —ریسک و وابستگی
  • —برنامهٔ مرحله‌ای
  • —برآورد با فرض مشخص

۷. مدل‌های همکاری

محدودهٔ مشخص

خروجی، مبلغ، مرحله و تغییر مکتوب‌اند.

زمان و ظرفیت

برای محصول در حال رشد و اولویت متغیر مناسب است.

شناخت سپس برآورد

برای پروژهٔ مبهم.

بازهٔ برآورد

عوامل بالا و پایین رفتن عدد توضیح داده می‌شوند.

۸. هزینهٔ مالکیت

  • —میزبانی
  • —دامنه
  • —پیامک و ایمیل
  • —API
  • —حساب فروشگاه
  • —مانیتورینگ
  • —نسخهٔ پشتیبان
  • —رفع خطا
  • —امنیت
  • —پشتیبانی
  • —توسعهٔ بعدی
  • —انتقال به تیم دیگر

۹. مقایسهٔ پیشنهادها

بررسی کنید:

  • —محدوده چیست؟
  • —چه چیزی خارج است؟
  • —طراحی شامل چیست؟
  • —تست و امنیت چگونه است؟
  • —هزینهٔ ثالث چیست؟
  • —سورس و دسترسی چگونه تحویل می‌شوند؟
  • —پشتیبانی چه تعریفی دارد؟
  • —تغییر چگونه مدیریت می‌شود؟
  • —فرض برآورد چیست؟

هشدارها

  • قیمت قطعی بدون سؤال
  • زمان کوتاه بدون محدوده
  • ابهام مالکیت
  • پشتیبانی نامحدود
  • یک فناوری برای همه
  • نبود معیار پذیرش
اگر فقط یک نکته یادتان بماند

پیشنهاد خوب فقط عدد نمی‌دهد؛ توضیح می‌دهد چه چیزی، با چه فرضی، در چه مرحله‌ای تحویل می‌شود و تغییر چگونه مدیریت خواهد شد.

راهکار مرتبط

طراحی و توسعه نرم‌افزار سازمانی

پیگیری کارها، اطلاعات مشتریان و گزارش‌های تیم را در نرم‌افزاری متناسب با شیوهٔ کار شما کنار هم می‌آوریم.

مشاهده خدمت ←
قدم بعدی

برای برآورد قابل اتکا، محدوده و ابهام‌های اصلی را روشن کنیم.

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