هزینه ساخت MVP از کجا شروع میشود؟
برای برآورد هزینه ساخت MVP ابتدا باید معلوم باشد کاربر در نسخه اول چه کاری را واقعاً تا پایان انجام میدهد. «یک اپلیکیشن شبیه نمونه معروف» تعریف قابل قیمتگذاری نیست؛ اما «مشتری خدمت را انتخاب کند، درخواست بدهد و وضعیت آن را ببیند؛ کارشناس هم درخواست را بررسی کند» دامنهای قابل گفتگو است. تعداد صفحهها فقط بخشی از کار را نشان میدهد. اتصال به سامانههای دیگر، وضعیتهای خطا و مسئولیت تیم پشتیبانی معمولاً در برآورد اولیه دیده نمیشوند.
این راهنما یک روش پیشنهادی برای آمادهکردن درخواست قیمت است. اعداد مثال آموزشیاند و تعرفه بازار یا پیشفاکتور ستایش محسوب نمیشوند. هدف این است که پیشنهادهای مختلف را بر اساس خروجی مشابه مقایسه کنید.
قبل از سفارش، این شش سؤال را پاسخ دهید
- چه کسی کاربر اصلی است و امروز مسئلهاش را چگونه حل میکند؟
- کدام مسیر باید در نسخه اول کامل باشد و کدام قابلیت میتواند منتظر بماند؟
- چه اطلاعاتی از سامانه فعلی وارد میشود و چه کسی کیفیت آن را تأیید میکند؟
- چه نقشهایی لازم است و هر نقش چه اطلاعاتی را میتواند ببیند یا تغییر دهد؟
- اگر پرداخت، پیامک یا اتصال بیرونی قطع شد، چه اتفاقی برای درخواست میافتد؟
- موفقیت آزمایش با چه نشانهای سنجیده میشود: تکمیل درخواست، زمان انجام کار یا استفاده مجدد؟
شناخت مسئله پیش از تعهد به ساخت، با رویکرد مرحله کشف در راهنمای خدمات GOV.UK نیز همسو است. برای پروژه خودتان، نتیجه این مرحله را به مسئله، کاربران، محدودیتها و معیار موفقیت تبدیل کنید؛ انتخاب فناوری باید بعد از روشنشدن این موارد انجام شود.
کار را به بستههای قابل تحویل تقسیم کنید
برای مثال یک سامانه درخواست خدمات میتواند شش بسته داشته باشد: بررسی نیاز، طراحی تجربه، پیادهسازی مسیر اصلی، اتصالهای بیرونی، آزمون و آمادهسازی انتشار. برای هر بسته، خروجی و مسئول پذیرش بنویسید. «پنل مدیریت» بیش از حد کلی است؛ «کارشناس درخواست را جستجو کند، وضعیت را با ثبت دلیل تغییر دهد و تاریخچه را ببیند» قابل ارزیابی است.
از تیم بخواهید حد پایین و بالای برآورد را همراه با فرضها اعلام کند. اتصال مستند و آزمایششده با سامانهای که API آن هنوز مشخص نیست، ریسک یکسانی ندارد. ابهام را پنهان نکنید؛ یک مرحله بررسی محدود برای اتصال نامعلوم تعریف کنید و سپس برآورد را اصلاح کنید.
یک مثال محاسبه شفاف
فرض کنید برآورد آموزشی شامل ۳۵ ساعت شناخت نیاز، ۵۵ ساعت طراحی، ۱۸۰ ساعت توسعه، ۵۰ ساعت اتصال، ۷۰ ساعت آزمون و ۲۰ ساعت آمادهسازی انتشار باشد. جمع کار ۴۱۰ ساعت میشود. اگر برای این مثال ۲۰ درصد ذخیره عدم قطعیت در نظر بگیریم، سقف برنامهریزی ۴۹۲ ساعت است. این درصد نسخه ثابت برای همه پروژهها نیست؛ میزان ابهام و نتیجه بررسی اولیه باید آن را تعیین کند.
با نرخ فرضی ۲۰ دلار برای هر ساعت، بودجه این مثال ۹۸۴۰ دلار است. نوشتن فرمول «ساعت × نرخ» جلوی خطای مقایسه را میگیرد. این محاسبه هنوز هزینه سرور، سرویس بیرونی، محتوای اولیه، ورود داده و نگهداری را شامل نمیشود. هنگام مقایسه دو پیشنهاد، ارز، مالیات و دوره پشتیبانی را هم یکسانسازی کنید.
چه چیزهایی را میتوان عقب انداخت؟
گزارش بسیار پیشرفته، چند زبان، اپ جداگانه برای هر سیستمعامل یا پیشنهادهای هوشمند ممکن است برای فرضیه نسخه اول ضروری نباشند. اما کنترل دسترسی، حفظ اطلاعات ثبتشده، پیام خطای روشن و امکان رسیدگی به درخواستهای مشکلدار معمولاً بخشی از مسیر قابل استفادهاند. کمکردن دامنه باید پیچیدگی محصول را کم کند، نه اینکه مسیر اصلی را نیمهکاره بگذارد.
یک فهرست «اکنون / بعداً» تهیه کنید و برای انتقال هر قابلیت به بخش بعداً دلیل بنویسید. اگر نبود قابلیت مانع آزمودن فرضیه اصلی نیست، نامزد خوبی برای مرحله بعد است. طرح بصری قابل کلیک هم برای بررسی فهم کاربر مفید است، ولی بهتنهایی صحت پرداخت یا اتصال واقعی را ثابت نمیکند.
معیار تحویل و بودجه پس از انتشار
- یک کاربر تازه بتواند مسیر اصلی را با داده آزمایشی معتبر کامل کند.
- نقشهای مختلف فقط عملیات مجاز خود را انجام دهند.
- قطع اتصال بیرونی، درخواست را گم یا چند بار ثبت نکند.
- تیم روش پشتیبانگیری، بازیابی و رسیدگی به خطا را بداند.
- داده لازم برای سنجش فرضیه اولیه قابل مشاهده باشد.
در هزینه سال اول، ساخت اولیه را از نگهداری ماهانه و خدمات مصرفی جدا بنویسید. پیش از انتخاب پیمانکار، دامنه مالکیت و تحویل، مستندات، مسئول حساب سرویسها و شرایط تغییر درخواست را روشن کنید. برای تنظیم این دامنه میتوانید از مشاوره راهاندازی کسبوکار دیجیتال و توسعه نرمافزار اختصاصی استفاده کنید. اگر بخش مهمی از ایده شما خودکارسازی کارهای تیم است، راهنمای انتخاب فرایند برای اتوماسیون هوش مصنوعی به اولویتبندی کمک میکند.
دیدگاهها(0)