برنامه‌نویس ماه‌هاست می‌گوید «پروژه ۸۰ درصد تمام است»، ولی هنوز چیزی تحویل نگرفته‌اید که بشود با آن کار کرد. حالا یا تیم متوقف شده، یا خودتان به این نتیجه رسیده‌اید که باید تیم را عوض کنید. سؤال اصلی این است: «با این پروژهٔ نیمهکاره چه کنم که دوباره پولم نسوزد؟»
پاسخ کوتاه: تکمیل پروژه نرمافزاری نیمهکاره با کد زدن شروع نمیشود. اول همهٔ دسترسیها و بکاپ‌ها را به نام خودتان بگیرید. بعد یک ممیزی مکتوب بخواهید. ممیزی کد یعنی بررسی مستقل کد، دیتابیس و روش راهاندازی، تا معلوم شود واقعاً چه چیزی کار می‌کند. فقط بعد از آن بین چهار مسیر تصمیم بگیرید: ادامه، اصلاح تدریجی، بازنویسی یک بخش یا بازنویسی کامل. پولی که تا امروز خرج شده معیار این تصمیم نیست.
چرا درصد پیشرفت گمراه‌کننده است
«۸۰ درصد» معمولاً یعنی ۸۰ درصد صفحه‌ها ساخته شده، نه اینکه ۸۰ درصد کار تمام است. بخش‌های سخت، مثل پرداخت، دسترسی نقش‌ها، گزارش‌ها و رفع خطا، معمولاً آخر کار می‌مانند.
درصد پیشرفت بدون معیار پذیرش بی‌معناست. معیار پذیرش یعنی جملهٔ روشنی که می‌گوید یک قابلیت کی «تمام‌شده» حساب میشود. توضیح کامل آن را در معیار پذیرش چیست آورده‌ایم.
مثال فرضی: صفحهٔ «ثبت سفارش» ساخته شده و ظاهرش کامل است. ولی سفارش در دیتابیس ثبت نمیشود و پیامک تأیید هم نمی‌رود. روی کاغذ «انجام‌شده» است، در عمل نه. برای همین هیچ تیم جدیدی نباید قیمت را از روی درصد پیشرفت بدهد.
سه روز اول، قبل از قرارداد جدید
اولویت این روزها دسترسی است، نه برنامه‌ریزی ویژگی‌های تازه. تا وقتی کد و سرور در اختیار شما نیست، هر قرارداد جدیدی روی هوا بسته میشود. ممیزی پروژه نرمافزاری یعنی گزارش مکتوب از کد، دسترسیها و بکاپ.
- دسترسیها را بگیرید: مخزن کد (جایی مثل گیت که کد و تاریخچهٔ تغییراتش نگه داشته میشود)، سرور، دیتابیس، دامنه و حساب‌های سرویسهای بیرونی.
- بکاپ بگیرید: یک نسخهٔ کامل از کد و دیتابیس، جایی که فقط خودتان به آن دسترسی دارید.
- آزمون راهاندازی بخواهید: یک نفر غیر از تیم قبلی باید بتواند با همین مستندات، پروژه را روی یک سرور تازه بالا بیاورد.
مثال فرضی: کارفرمایی اول با تیم تازه قرارداد می‌بندد و بعد سراغ دسترسی می‌رود. تیم قبلی دیر جواب می‌دهد و هفته‌های اول قرارداد جدید فقط صرف انتظار میشود.
چهار مسیر بعد از ممیزی
خروجی ممیزی باید یک گزارش مکتوب باشد که یکی از این چهار مسیر را با دلیل پیشنهاد کند:
| مسیر | چه زمانی منطقی است | ریسک اصلی | خروجی اولین قرارداد |
|---|---|---|---|
| ادامهٔ کد فعلی | ساختار کد قابل فهم است و بیشتر بخش‌ها درست کار می‌کنند | مشکل‌هایی که در ممیزی دیده نشده‌اند | فهرست کارهای باقی‌مانده با معیار پذیرش |
| اصلاح تدریجی | هسته سالم است ولی بخش‌هایی شلوغ و پرخطا هستند | طول کشیدن اصلاح‌ها اگر اولویت روشن نباشد | اصلاح یک بخش مشخص و تحویل قابل تست |
| بازنویسی یک بخش | یک بخش (مثلاً پرداخت یا گزارش‌ها) خراب است و بقیه سالم | اتصال بخش جدید به بخش‌های قدیمی | بخش بازنویسی‌شده با آزمون اتصال |
| بازنویسی کامل | کد قابل نگهداری نیست یا فناوری‌اش دیگر پشتیبانی نمیشود | هزینه و زمان دوباره، و تکرار اشتباه‌های قبلی | مستند نیازمندی تازه و نسخهٔ اول کوچک |
بازنویسی کامل فقط وقتی منطقی است که ممیزی نشان دهد اصلاح، از نوشتن دوباره پرهزینه‌تر یا پرخطرتر است. اگر هدف محصول هم عوض شده، بهتر است اول مستند نیازمندی پروژه (PRD) را تازه کنید؛ سندی که می‌گوید محصول چه کاری باید بکند و برای چه کسی.
مثال فرضی: در یک پنل فروش، ثبت مشتری و فاکتور درست کار می‌کند ولی گزارش‌ها کند و پرخطاست. اینجا بازنویسی بخش گزارش منطقی است، نه دور ریختن کل سیستم.
چک‌لیست تحویل گرفتن پروژه از تیم قبلی
برای تحویل گرفتن پروژه نرمافزاری از تیم قبلی، این موارد را به نام خودتان بگیرید:
این فهرست را برای تیم قبلی بفرستید و تک‌تک موارد را تیک بزنید:
- مخزن کد و تاریخچه: همهٔ شاخه‌ها، نه فقط یک فایل فشرده از آخرین نسخه.
- دیتابیس و بکاپ: آخرین نسخهٔ دیتابیس و روش بکاپ‌گیری.
- روش build و deploy: یعنی مراحل ساختن نسخهٔ اجرایی و نصب آن روی سرور، به‌صورت مکتوب.
- دامنه، سرور و ایمیل: همه به نام کارفرما، نه به نام برنامه‌نویس.
- کلیدها و سرویسهای بیرونی: کلید API (رمزی که اپ با آن به سرویس‌هایی مثل پیامک یا درگاه پرداخت وصل میشود)، پنل پیامک، درگاه و نقشه.
- مستندات: هر توضیحی دربارهٔ ساختار، حتی ناقص.
- موارد باز: فهرست خطاهای شناخته‌شده و کارهای نیمه‌تمام.
دام هزینهٔ ازدست‌رفته و پیشنهادهای خطرناک
هزینهٔ ازدست‌رفته یعنی پولی که خرج شده و برنمی‌گردد. «این‌همه پول داده‌ایم، پس باید ادامه بدهیم» دلیل خوبی برای ادامه نیست. سؤال درست این است: «از امروز به بعد، کدام مسیر با هزینهٔ کمتر به نسخهٔ قابل استفاده می‌رسد؟»
پیشنهاد «همه را از نو می‌نویسیم» را با این سؤال‌ها بسنجید:
- این تصمیم بعد از دیدن کد گرفته شده یا قبل از آن؟
- دلیل‌هایش مکتوب و مشخص است یا کلی، مثل «کد کثیف است»؟
- اولین تحویل کی است و چه چیزی را میشود با آن تست کرد؟
همین‌طور به وعدهٔ «بدون دیدن کد، زود تمامش می‌کنیم» شک کنید. کسی که کد را ندیده، نمی‌داند چه چیزی را قول می‌دهد.
اگر بخشی از سیستم در حال استفاده است
وقتی مشتری یا کارمندان هر روز با سیستم کار می‌کنند، نمیشود همه را یک‌شبه خاموش کرد. راه امن‌تر جایگزینی بخش‌به‌بخش است: هر بار یک بخش ساخته یا اصلاح میشود، روی یک نسخهٔ آزمایشی تست میشود و بعد جای بخش قدیمی را می‌گیرد.
مثال فرضی: فروشگاهی که سفارش‌ها را از همین سیستم می‌گیرد، اول پنل گزارش را عوض می‌کند و تا وقتی بخش سفارش جدید کامل تست نشده، بخش سفارش قدیمی روشن می‌ماند.
قبل از جلسهٔ بررسی این‌ها را آماده کنید
- هدف محصول: در یک یا دو جمله، این نرم‌افزار برای چه کسی چه مشکلی را حل می‌کند.
- چه چیزی امروز واقعاً کار می‌کند: نه آنچه قرار بود کار کند.
- دسترسیها: کدام را دارید و کدام هنوز دست تیم قبلی است.
- مشکل اصلی: خطا، کندی، توقف تیم یا نبود مستندات.
- مهلت نسخهٔ قابل استفاده: تا کی باید حداقل یک نسخهٔ کارا داشته باشید.
تکنوراه چطور وارد چنین پروژه‌ای میشود
ما وعدهٔ «هر پروژه‌ای را نجات می‌دهیم» یا «بدون بازنویسی تمامش می‌کنیم» نمی‌دهیم. اولین قدم ما یک بررسی محدود و خروجیمحور است: گرفتن دسترسیها، آزمون راهاندازی و گزارش مکتوب با یکی از چهار مسیر بالا. بعد، بسته به نتیجه، پروژه در قالب توسعه نرم‌افزار سفارشی ادامه پیدا می‌کند.
اگر تیم فنی داخلی ندارید و کسی را می‌خواهید که از طرف شما تصمیم‌های فنی را بگیرد و بر تیم نظارت کند، CTO as a Service را ببینید. نقش مدیر فنی را در CTO کیست توضیح داده‌ایم.
برای اینکه قرارداد بعدی دوباره به همین نقطه نرسد، دو مقاله کمک می‌کند: برون‌سپاری توسعه نرم‌افزار برای انتخاب تیم و قرارداد، و جلوگیری از Scope Creep، یعنی بزرگ شدن بی‌برنامهٔ محدودهٔ پروژه. برای نوشتن نیازها هم سند نیازمندی‌های نرم‌افزار را بخوانید، و برای تصویر کلی هزینه هزینه ساخت نرم‌افزار سفارشی را.
جمع‌بندی: سه قدم همین هفته
- دسترسی و بکاپ را بگیرید: مخزن کد، دیتابیس، سرور، دامنه و کلیدها، همه به نام خودتان.
- ممیزی مکتوب بخواهید: با یکی از چهار مسیر و دلیلش، نه فقط یک عدد.
- قرارداد اول را کوچک ببندید: بررسی محدود با خروجی مشخص، نه وعدهٔ تاریخ تحویل کل پروژه.
پروژهٔ نیمهکاره دارید؟ فرم برآورد را برای آن پر کنید. این فرم برای برآورد اپ ساخته شده، ولی برای پروژهٔ نیمهکاره هم مناسب است؛ نوع پروژه را انتخاب کنید و در تماس بعدی، وضعیت فعلی پروژه را با هم مرور می‌کنیم.
سوالات متداول
تکمیل پروژه نرمافزاری نیمهکاره چقدر هزینه دارد؟
تا کد و دسترسیها بررسی نشده، هیچ عدد قابل اعتمادی نمیشود داد. اول یک ممیزی محدود انجام میشود و بعد، بسته به مسیر انتخابشده، برآورد میآید. وضعیت پروژه را در فرم برآورد تکنوراه بنویسید.
آیا باید همه را از نو نوشت؟
نه لزوماً. بازنویسی کامل فقط وقتی منطقی است که ممیزی نشان دهد اصلاح کد فعلی پرهزینه‌تر یا پرخطرتر است. خیلی وقت‌ها ادامه، اصلاح تدریجی یا بازنویسی یک بخش کافی است.
قبل از تعویض تیم برنامهنویسی چه کنیم؟
دسترسی مخزن کد، دیتابیس، سرور، دامنه و کلیدهای سرویسهای بیرونی را به نام خودتان بگیرید، یک بکاپ کامل نگه دارید و بخواهید کسی غیر از تیم قبلی پروژه را روی سرور تازه راه بیندازد.
وقتی برنامه‌نویس می‌گوید ۸۰ درصد پروژه تمام است یعنی چه؟
بدون معیار پذیرش برای هر قابلیت، این عدد معنای روشنی ندارد. اغلب یعنی صفحه‌ها ساخته شده‌اند، ولی بخش‌های سخت مثل پرداخت، دسترسیها و رفع خطا مانده‌اند.
اولین قرارداد با تیم جدید بهتر است چه باشد؟
یک بررسی محدود و خروجیمحور: گرفتن دسترسیها، آزمون راهاندازی و گزارش مکتوب با پیشنهاد مسیر. وعدهٔ تاریخ تحویل کل پروژه قبل از دیدن کد را نپذیرید.