STRATEGY
پروژه‌ی نرم‌افزاری نیمه‌کاره مانده؛ حالا چه کنیم؟ راهنمای گام‌به‌گام نجات
· ۹ دقیقه · تیم یازیاپ
آخرین بازبینی محتوایی:
وقتی تیم قبلی رفته، پروژه نیمه‌کاره مانده و معلوم نیست چه چیزی کار می‌کند؛ این راهنما ترتیب درست تصمیم‌ها را توضیح می‌دهد: از پس گرفتن دسترسی‌ها تا انتخاب بین ادامه، بازنویسی یا توقف.
پاسخ کوتاه
اول همه‌ی دسترسی‌ها را پس بگیرید: کد، دامنه، هاست و حساب‌ها. بعد یک ارزیابی مستقل و کوتاه بگیرید تا بدانید چه چیزی کار می‌کند و تکمیلش چقدر است. فقط بعد از این دو قدم بین ادامه، بازنویسی بخشی یا توقف تصمیم بگیرید؛ تصمیم گرفتن پیش از ارزیابی معمولاً گران‌ترین اشتباه است.
داستان آشناست: پروژه با امید شروع شد، چند ماه گذشت، پرداخت‌ها انجام شد، و حالا برنامه‌نویس جواب نمی‌دهد یا تیم قبلی می‌گوید «باید از اول نوشت». شما مانده‌اید با چیزی که نیمه‌کاره است و نمی‌دانید چقدر به پایان نزدیک است.
ما در یازیاپ پروژه‌های زیادی از این دست را تحویل گرفته‌ایم و یک نمونه‌ی واقعی آن را در صفحه‌ی بازیابی صادقانه‌ی پروژه نوشته‌ایم. این راهنما ترتیب کارهایی است که در هر کدام از آن پروژه‌ها، صرف‌نظر از اینکه چه کسی ادامه‌اش داد، توصیه کرده‌ایم.
قدم اول: دسترسی‌ها را پس بگیرید
تا وقتی کد و دامنه و هاست در اختیار شما نیست، هیچ تیم دیگری نمی‌تواند کمکتان کند و تیم قبلی اهرم دارد.
پیش از هر بحثی درباره‌ی کیفیت یا هزینه، فهرست دسترسی‌ها را کامل کنید. دامنه باید به نام شما یا شرکت شما ثبت شده باشد. هاست باید حساب خودتان باشد یا دست‌کم دسترسی مدیریتی داشته باشید. کد باید در یک مخزن قابل دسترس باشد، نه فقط روی لپ‌تاپ برنامه‌نویس.
این گفت‌وگو را محترمانه و مکتوب انجام دهید. بسیاری از برنامه‌نویس‌ها با درخواست مشخص و فهرست‌وار همکاری می‌کنند. اگر همکاری نکردند، فهرست مکتوب برای هر مسیر بعدی، حتی حقوقی، به کارتان می‌آید.
- کد کامل در مخزن (مثلاً گیت) با تاریخچه
- مالکیت دامنه و دسترسی به پنل آن
- دسترسی مدیریتی هاست یا سرور
- پایگاه داده و آخرین پشتیبان
- حساب‌های سرویس‌های جانبی: درگاه پرداخت، پیامک، ایمیل، کافه‌بازار
- هر مستندی که وجود دارد، حتی ناقص
قدم دوم: ارزیابی مستقل
ارزیابی یعنی یک تیم دیگر کد را اجرا کند، بخش‌ها را بشمارد و بگوید کدام کار می‌کنند، کدام نیمه‌کاره‌اند و کدام آن‌قدر بد نوشته شده‌اند که ادامه‌شان پرهزینه‌تر از بازنویسی است. خروجی ارزیابی باید یک گزارش مکتوب باشد، نه یک نظر شفاهی.
در ارزیابی به دنبال سه چیز باشید: آیا کد اجرا می‌شود و قابل استقرار است؛ آیا ساختار آن قابل فهم است تا برنامه‌نویس دیگری بتواند ادامه دهد؛ و آیا ایرادهای امنیتی جدی دارد. ارزیابی خوب این سه را با مثال نشان می‌دهد.
در خدمت نجات پروژه‌ی یازیاپ، ارزیابی ۳٬۹۰۰٬۰۰۰ تومان هزینه دارد و اگر تصمیم به ادامه با ما بگیرید، از مبلغ اجرا کم می‌شود. این مدل را عمداً انتخاب کرده‌ایم تا ارزیابی تبدیل به ابزار فروش نشود؛ گزارش آن را می‌توانید به هر تیمی بدهید.
قدم سوم: ادامه، بازنویسی بخشی یا توقف؟
اگر هسته‌ی کد سالم است، ادامه بدهید؛ اگر بخش‌هایی خراب‌اند، همان بخش‌ها را بازنویسی کنید؛ اگر مسئله‌ی کسب‌وکاری عوض شده، شاید بهترین تصمیم توقف یا استفاده از محصول آماده باشد.
جمله‌ی «باید از اول نوشت» را با احتیاط بشنوید. گاهی درست است، ولی گاهی فقط یعنی تیم جدید ترجیح می‌دهد با ابزار خودش کار کند. بازنویسی کامل همه‌ی ریسک‌های پروژه‌ی اول را دوباره تکرار می‌کند. معمولاً راه میانه، یعنی نگه داشتن بخش‌های سالم و بازنویسی بخش‌های بحرانی، کم‌هزینه‌تر است.
| وضعیت کد | پیشنهاد | ریسک اصلی |
|---|---|---|
| هسته سالم، امکانات ناقص | ادامه و تکمیل | دامنه‌ی کار دوباره بزرگ شود |
| بخش‌هایی خراب یا ناامن | بازنویسی همان بخش‌ها | وابستگی بخش‌ها به هم |
| ساختار نامفهوم و بدون تست | بازنویسی مرحله‌ای با حفظ داده | هزینه و زمان بیشتر |
| نیاز کسب‌وکار عوض شده | توقف یا محصول آماده | هزینه‌ی رفته برنمی‌گردد |
چرا نجات پروژه گران‌تر از پروژه‌ی عادی است؟
کار روی کد ناشناخته کندتر است. هر تغییر باید با احتیاط انجام شود چون معلوم نیست چه چیز دیگری را خراب می‌کند. برای همین در یازیاپ نرخ اجرای نجات ۱٫۵ برابر نرخ عادی ساعتی است و گزارش پیشرفت هفتگی دارد تا بدانید پول کجا می‌رود.
چیزی که نمی‌توانیم تضمین کنیم، نجات کدی است که هنوز ارزیابی نشده؛ و پیگیری حقوقی با تیم قبلی هم کار ما نیست. ترجیح می‌دهیم این را صریح بگوییم تا انتظار نادرستی شکل نگیرد.
چطور دوباره گیر نیفتیم؟
بیشتر پروژه‌های نیمه‌کاره از یک نقطه شروع شده‌اند: دامنه‌ی کار مبهم و پرداخت بدون خروجی قابل بررسی. در پروژه‌ی بعدی، هر مرحله‌ی پرداخت را به خروجی قابل دیدن گره بزنید، کد را از روز اول در مخزنی که خودتان مالکش هستید نگه دارید و مستندسازی را جزو تحویل بخواهید.
چک‌لیست انتخاب تیم نرم‌افزاری در بلاگ و صفحه‌ی ۵ سؤال پیش از امضای قرارداد، دقیقاً برای جلوگیری از همین وضعیت نوشته شده‌اند.
- پرداخت مرحله‌ای در برابر خروجی قابل بررسی
- مخزن کد به نام خودتان از روز اول
- دامنه و هاست به نام خودتان
- مستندسازی جزو تحویل هر مرحله
پیش از سپردن پروژه به تیم جدید، چه چیزهایی را جمع کنیم؟
هرچه دسترسی‌ها و مستندات کامل‌تر باشد، بررسی پروژه‌ی نیمه‌کاره سریع‌تر و ارزان‌تر انجام می‌شود.
وقتی تیم قبلی رفته، اولین کار جمع کردن دارایی‌هاست، نه پیدا کردن تیم جدید. دسترسی به مخزن کد، هاست یا سرور، دامنه، پایگاه داده، حساب‌های فروشگاه اپ و سرویس‌های جانبی مثل پیامک و درگاه پرداخت را فهرست کنید و مطمئن شوید هر کدام به نام شما یا در اختیار شماست. اگر یکی از این‌ها فقط دست تیم قبلی است، پیش از هر کار دیگری آن را پس بگیرید.
قدم بعد، جمع کردن مستندات است، هرچقدر ناقص: قرارداد، شرح کار اولیه، پیام‌هایی که در آن تغییرات توافق شده، طرح‌های گرافیکی و هر فهرستی از مشکلات شناخته‌شده. تیم جدید از همین‌ها می‌فهمد پروژه قرار بود چه باشد و الان کجاست.
در جلسه‌ی اول با تیم جدید، از آن‌ها نخواهید که همان روز قیمت تکمیل را بدهند. تیم جدی ابتدا کد را بررسی می‌کند و گزارش می‌دهد کدام بخش‌ها قابل استفاده است، کدام باید بازنویسی شود و ریسک‌های اصلی کجاست. تصمیم بین ادامه و بازنویسی باید بعد از این گزارش گرفته شود.
در نهایت، قرارداد جدید را مرحله‌ای ببندید: اول بررسی و گزارش، بعد پایدارسازی، بعد تکمیل. این‌طوری اگر در هر مرحله نتیجه رضایت‌بخش نبود، دوباره در همان نقطه‌ی قبلی گیر نمی‌کنید.
- دسترسی مخزن کد، سرور، دامنه و پایگاه داده
- قرارداد، شرح کار و مکاتبات
- فهرست مشکلات شناخته‌شده
- قرارداد مرحله‌ای با تیم جدید
ادامه دادن یا بازنویسی؟
بازنویسی فقط وقتی منطقی است که هسته‌ی پروژه ناپایدار یا ناامن باشد؛ در بیشتر پروژه‌ها، نجات بخش‌های سالم ارزان‌تر و سریع‌تر است.
وسوسه‌ی بازنویسی کامل همیشه وجود دارد، چون کد دیگران همیشه کمی ناآشنا به نظر می‌رسد. اما بازنویسی یعنی پرداخت دوباره برای کارهایی که قبلاً انجام شده، و ریسک تکرار همان تأخیرها. معیار درست این است که آیا ساختار داده و منطق اصلی قابل اتکاست یا نه.
اگر پایگاه داده درست طراحی شده و مشکل بیشتر در ظاهر یا بخش‌های جانبی است، ادامه دادن منطقی است. اگر داده‌ها بی‌نظم‌اند، امنیت پایه رعایت نشده یا فناوری انتخاب‌شده دیگر پشتیبانی نمی‌شود، بازنویسی بخش‌های اصلی ممکن است در طول زمان ارزان‌تر باشد. این تصمیم را بعد از گزارش بررسی کد و با برآورد مکتوب هر دو مسیر بگیرید.
سؤال‌های پرتکرار
اگر کد را نداشته باشیم، کاری می‌شود کرد؟
اگر فقط سایت زنده در دسترس است، می‌توان داده و محتوا را تا حدی بازیابی کرد، ولی بدون کد معمولاً ساخت دوباره‌ی بخش‌ها لازم است.
ارزیابی چه خروجی‌ای دارد؟
گزارش وضعیت کد و زیرساخت، برآورد زمان و هزینه‌ی کار باقی‌مانده و برنامه‌ی پیشنهادی نجات.
مجبوریم بعد از ارزیابی با شما ادامه دهیم؟
خیر. گزارش متعلق به شماست؛ اگر با ما ادامه دهید، هزینه‌ی ارزیابی از مبلغ اجرا کم می‌شود.
امنیت کد قبلی را هم بررسی می‌کنید؟
ایرادهای امنیتی جدی در ارزیابی گزارش می‌شوند؛ برای بررسی عمیق‌تر، ممیزی امنیتی کامل جداگانه در دسترس است.
قدم بعدی
فهرست دسترسی‌ها را همین امروز کامل کنید. بعد صفحه‌ی نجات پروژه‌ی نیمه‌کاره را ببینید و یک توضیح کوتاه از وضعیت بفرستید. اگر نگرانی اصلی شما امنیت است، ممیزی امنیتی را در نظر بگیرید.