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

در پروژه‌ی سفارشی شما یک محصول نمی‌خرید؛ یک فرایندِ تصمیم‌گیریِ مشترک می‌خرید.

و علتِ شکستِ بیشترِ این پروژه‌ها هم فنی نیست. کدِ بد کمتر پروژه‌ای را زمین می‌زند؛ آنچه زمین می‌زند نبودِ تعریفِ «تمام شد» است. یک آزمونِ یک‌خطی برای سنجیدنِ آمادگیِ خودتان:

می‌توانید در یک جمله بنویسید «این پروژه وقتی تمام است که…»؟ اگر جوابتان فهرستی از امکانات است و نه یک جمله‌ی قابلِ آزمون، هنوز آماده‌ی سفارش نیستید — و این خبرِ خوبی است، چون اصلاحش الان رایگان است.

این راهنما دربارهٔ خریدار بودن است: چطور نیاز را بنویسید، چه چیزی در قرارداد باید باشد، پرداخت را به چه گره بزنید، و نقشِ خودتان چیست. (بحثِ «آماده بخرم یا اختصاصی بسازم» جای دیگری است: راهنمای تصمیم؛ و برآوردِ هزینه در هزینه‌ی نرم‌افزار اختصاصی.)

مطالبی که در ادامه می خوانید:

هیچ مجری‌ای نمی‌تواند این سه را برای شما جواب بدهد، و بدونشان هر برآوردی حدس است:

همه می‌گویند «مستند بنویس». اشتباهِ رایج این است که مستند به فهرستِ امکانات تبدیل می‌شود: «سیستم باید فلان دکمه را داشته باشد»، «باید داشبورد داشته باشد». مشکلش این است که فهرستِ امکانات راه‌حل را قفل می‌کند و مسئله را نه — و بعد اگر راهِ سرراست‌تری وجود داشت، قراردادِ خودتان جلویش را می‌گیرد.

قاعده‌ی درست: نیاز را با «چه کسی، چه کاری، برای چه» بنویسید.

به‌جای این (امکانات)این را بنویسید (کار)
«داشبوردِ مدیریتی داشته باشد»«مدیرِ فروش باید هر صبح ببیند دیروز چند سفارش ثبت شد و چند تا معلق مانده»
«امکانِ خروجیِ اکسل داشته باشد»«حسابدار باید فهرستِ فاکتورهای ماه را برای اظهارنامه بردارد»
«سیستمِ اعلان داشته باشد»«انباردار باید وقتی موجودیِ یک قلم به مرزِ سفارشِ مجدد رسید خبردار شود»
«کاربران نقش داشته باشند»«فروشنده‌ی شعبه نباید قیمتِ خرید را ببیند»

ستونِ راست دو مزیتِ عملی دارد: قابلِ آزمون است (می‌شود گفت انجام شد یا نه) و مجری را آزاد می‌گذارد راهِ بهتری پیشنهاد بدهد. ستونِ چپ هیچ‌کدام را ندارد.

نکته

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

«با MVP شروع کنید» توصیه‌ی درستی است که تقریباً همیشه غلط فهمیده می‌شود. برداشتِ رایج این است: «نسخه‌ی ناقصِ همان چیزِ بزرگ» — یعنی همه‌ی بخش‌ها را نصفه‌نیمه بساز. این بدترین حالتِ ممکن است، چون هیچ بخشش قابلِ استفاده نیست.

MVP یعنی یک جریانِ کاملِ کار، از اول تا آخر — نه همه‌ی جریان‌ها به‌شکلِ نصفه.

دلیلش هم ساده است: فقط چیزی که کامل است استفاده می‌شود، و فقط چیزی که استفاده می‌شود بازخورد می‌دهد. یک مسیر که واقعاً کار می‌کند، ده مسیرِ نیمه‌کاره را از نظرِ یادگیری شکست می‌دهد.

و معیارِ انتخابِ آن یک جریان: پرتکرارترین کارِ روزانه، نه سخت‌ترین و نه جذاب‌ترین. تیم‌ها معمولاً وسوسه می‌شوند از بخشِ فنی‌جذاب شروع کنند؛ ولی جریانی که روزی چهل بار انجام می‌شود، هم سریع‌تر خطاهایش پیدا می‌شود و هم زودتر ارزش برمی‌گرداند.

«کدِ منبع مالِ من است» بندِ لازمی است ولی کافی نیست. مالکیت شاملِ مخزنِ کد، دامنه، حسابِ فروشگاه‌های اپ، حسابِ سرور، و همه‌ی سرویس‌های جانبی (پیامک، نقشه، پرداخت، ذخیره‌سازی) است. قاعده‌ای که همه‌ی این‌ها را جمع می‌کند:

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

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

معیارِ پذیرش را قبل از شروع بنویسید و از جنسِ ستونِ راستِ همان جدولِ بالا: «انباردار می‌تواند فلان کار را انجام دهد» — جمله‌ای که جوابش بله یا خیر است.

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

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

حواستان باشد

اگر خروجیِ داده‌تان در قرارداد نباشد، پروژه قفلتان کرده — حتی اگر کد مالِ شما باشد. کدِ بدونِ داده و بدونِ دسترسی به سرویس‌ها، یک آرشیوِ بی‌فایده است. پس در بندِ مالکیت، دو کلمه‌ی «داده» و «دسترسی» را به کلمه‌ی «کد» اضافه کنید؛ همین دو کلمه تفاوتِ مالکیتِ روی کاغذ و مالکیتِ واقعی است.

مدل‌های قرارداد و اینکه ریسک در هرکدام کجا می‌نشیند بحثِ مستقلی است (برآوردِ هزینه‌ی نرم‌افزار اختصاصی). آنچه اینجا مهم است یک قاعده‌ی ساده‌ی فازبندی است:

هر فاز باید یک خروجیِ قابلِ استفاده داشته باشد، نه یک گزارشِ پیشرفت.

«پیشرفتِ اعلامی» راستی‌آزمایی‌شدنی نیست — هیچ‌کس از بیرون نمی‌تواند بگوید کارِ اعلام‌شده واقعاً انجام شده یا نه. در مقابل، «کاربر می‌تواند ثبت‌نام کند و سفارش ثبت کند» یک ادعای قابلِ آزمون است. پس:

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

و در مقابل، یک نشانه‌ی خوب که کمتر گفته می‌شود:

مجری‌ای که بخشی از خواسته‌ی شما را رد می‌کند، نشانه‌ی خوبی است. «این را در فازِ اول نسازیم» یا «این کار با ابزارِ آماده ارزان‌تر حل می‌شود» جمله‌هایی هستند که به ضررِ فروشِ خودِ گوینده‌اند — و همین آن‌ها را معتبر می‌کند. کسی که به هر چیزی «بله» می‌گوید، بعداً به همه‌ی آن بله‌ها فاکتور می‌دهد.

یک واقعیتِ ناخوشایند که کارفرماها کمتر می‌شنوند:

پروژه‌های نرم‌افزاری بیشتر از آنکه با کدِ بد شکست بخورند، با تأخیرِ تصمیمِ کارفرما شکست می‌خورند.

سه تعهدِ شما، که هرکدام مستقیم روی زمان و هزینه اثر دارد:

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

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

سه چیز را ببرید. اول: شما یک محصول نمی‌خرید، یک فرایندِ تصمیم‌گیریِ مشترک می‌خرید — و آزمونِ آمادگی‌تان این است که بتوانید در یک جمله بنویسید «این پروژه وقتی تمام است که…». دوم: نیاز را با کار بنویسید نه با امکانات، و MVP را یک جریانِ کامل بگیرید نه همه‌چیزِ نصفه. سوم: سه بندِ مالکیت (کد و داده و دسترسی)، معیارِ پذیرش، و بندِ خروج را در روزِ خوشِ اول بنویسید — و پرداخت را به خروجیِ قابلِ استفاده گره بزنید، نه به پیشرفتِ اعلامی.

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

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

بکاپی که بازگردانی‌اش آزمایش نشده، بکاپ نیست — یک فرض است؛ و ایمیلِ اصلی کلیدِ همه‌چیز است: امنیتِ سایتِ فروشگاهی.