تحویل پروژه اپلیکیشن؛ پیش از تایید نهایی چه چیزهایی باید بگیریم؟
فایل نصبی فقط نتیجه کاره، نه خود کار. تو این نوشته می گیم پیش از تایید نهایی چه چیزهایی باید دستت برسه: از کد منبع و مستندات تا دسترسی ها، محیط تست و آموزش.
تحویل پروژه اپلیکیشن فقط گرفتن یه فایل نصبی نیست. پنج چیز باید دستت برسه: کد منبع و روش ساخت برنامه، مستندات فنی، دسترسی ها و حساب ها به نام خودت، یه محیط تست که واقعاً اجرا بشه و آموزش کافی. تا این ها رو نگرفتی و خودت امتحان نکردی، تایید نهایی و تسویه آخر زوده. تو این نوشته به همون سوال هایی جواب می دیم که کارفرماها معمولاً روز تحویل می پرسن.
تحویل پروژه اپلیکیشن با فایل نصبی تموم می شه؟
نه. فایل APK یا نسخه منتشرشده فقط نتیجه کاره، نه خود کار. بدون کد منبع، حتی عوض کردن یه متن یا یه رنگ هم به پیمانکار قبلی وابسته می مونه.
تحویل اپلیکیشن شبیه تحویل آپارتمانه. فقط نشون دادن خونه کافی نیست. سند، کلید اصلی و یدک، نقشه لوله کشی و برق و قبض ها رو هم باید تحویل بگیری. کد و ساختار پروژه همون نقشه ساختمونه و دسترسی ها همون کلیدها.
| مورد | یعنی چی | نشانه تحویل کامل |
|---|---|---|
| کد منبع | مخزن Git با تاریخچه کامل | روی حساب خودت هست |
| مستندات | راهنمای نصب، ساختار، API | یه نفر دیگه با اون کار رو جلو می بره |
| دسترسی ها | سرور، دامنه، فروشگاه، سرویس ها | همه به نام و ایمیل تو |
| محیط تست | نسخه جدا از نسخه زنده | سناریوها رو خودت اجرا کردی |
| آموزش | جلسه و راهنمای کاربردی | بدون پیمانکار هم کارهای روزمره رو انجام می دی |
کد رو چطور و به چه شکلی بگیرم؟
مخزن باید به نام خودت باشه
بهترین حالت اینه که مخزن Git روی حساب خودت ساخته بشه یا مالکیتش به تو منتقل بشه. تاریخچه کامل تغییرات هم باید توش باشه. یه فایل فشرده از کد به دردت نمی خوره، چون نمی فهمی چی کی عوض شده و برگشتن به نسخه قبلی هم سخت می شه.
وابستگی ها و تنظیمات
فهرست کتابخانه ها با نسخه هاشون، سرویس های جانبی و فایل های تنظیمات محیطی باید همراه کد باشه. رمزها و کلیدها نباید داخل خود کد نوشته شده باشن. اگه توی مخزن رمز پایگاه داده یا کلید درگاه پرداخت رو دیدی، همین الان بگو جداشون کنن و عوضشون کنن.
آزمون ساده: ساخت از صفر
این مهم ترین تستیه که می تونی بگیری. از پیمانکار بخواه جلوی تو یا یه متخصص دیگه، پروژه رو روی یه سیستم تمیز بالا بیاره و از اول بیلد بگیره. اگه فقط روی سیستم خودش اجرا می شه، یعنی چیزی جا مونده. ایراد رایج اینه که برنامه فقط روی لپ تاپ توسعه دهنده کار می کنه، چون یه تنظیم یا فایل پنهان اون جاست و توی مخزن نیست.
مالکیت کد
اینکه کد مال کیه باید توی قرارداد صریح نوشته شده باشه. جزئیات حقوقی و مجوزها به شرایط پروژه بستگی داره. بهتره پیش از امضا با یه مشاور حقوقی بررسیش کنی.
مستندات باید چند صد صفحه باشه؟
نه. مستندات خوب کوتاهه و به کار میاد. حداقلش اینه:
- راهنمای نصب و اجرا، قدم به قدم
- ساختار پوشه ها و نقش هر بخش
- فهرست سرویس ها و ارتباطشون با هم
- توضیح پایگاه داده و جدول های اصلی
مستندات API
اگه اپ بک اند داره، فهرست endpoint ها با نمونه درخواست و پاسخ لازمه. یه مجموعه Postman یا یه صفحه Swagger برای این کار کافیه. اگه نمی دونی بک اند چه شکلی باید مستند بشه، صفحه طراحی و توسعه API یه دید کلی بهت می ده.
انتشار رو قدم به قدم بنویسن
باید دقیق نوشته شده باشه که بیلد چطور گرفته می شه، چطور امضا می شه و کجا آپلود می شه، چه روی فروشگاه های اپ چه روی سرور. اگه انتشار دستیه، هر مرحله رو با ترتیبش بخواه. اگه خودکاره، استقرار خودکار با CI/CD رو با تنظیماتش ببین.
یه نمونه رایج: بعد از انتشار، بعضی فایل ها خطای ۴۰۴ می دن، چون تنظیمات تازه وب سرور بارگذاری نشده. اگه این مرحله جایی نوشته نشده باشه، فقط کسی که پروژه رو ساخته یادشه. این جور جزئیات باید روی کاغذ بیاد.
سند «اگه مشکل پیش اومد»
چند مشکل رایج با راه حلشون کافیه: از کار افتادن پیامک، پر شدن فضای سرور، خطای بعد از انتشار یا قطع شدن ارتباط با درگاه پرداخت. ارزش این سند توی اولین شب بحرانی معلوم می شه.
چه دسترسی هایی باید به نام خودم باشه؟
این بخش بعدها بیشترین دردسر رو درست می کنه. فهرست رو یکی یکی بپرس:
- مخزن کد
- سرور یا هاست، همراه دسترسی مدیریتی
- دامنه. اگه دامنه .ir داری، مطمئن شو حساب ایرنیک و مالکیت دامنه به نام خودته، نه پیمانکار.
- حساب توسعه دهنده در فروشگاه های اپلیکیشن، مثل گوگل پلی یا فروشگاه های ایرانی
- پنل پیامک، سرویس اعلان و سرویس های ثالث مثل نقشه
- اطلاعات پذیرنده درگاه پرداخت، که باید به نام خود کسب و کار تو باشه
اشتباه رایج: حساب روی ایمیل پیمانکار
اگه حساب ها با ایمیل یا شماره موبایل پیمانکار ثبت شده، بعداً بازیابیشون دردسر داره. بخواه مالکیت منتقل بشه و بعد از تحویل، رمزها عوض بشن.
یه چیز دیگه هم بپرس: پایگاه داده و سرویس های داخلی از بیرون در دسترسن یا نه؟ معمولاً فقط وب سرور پورت باز داره و بقیه توی شبکه داخلی هستن. اگه پایگاه داده روی اینترنت باز مونده، این یه ایراد جدیه، نه یه سلیقه.
برای پنل مدیریت هم ببین چه نقش هایی تعریف شده. طراحی نقش و دسترسی کاربران در پنل مدیریت رو بخون تا بدونی چی رو باید بپرسی.
محیط تست یعنی چی و چرا لازمه؟
محیط تست یه نسخه جدا از نسخه زنده است که می تونی بدون ترس روش کار کنی. اگه نباشه، هر آزمایشی روی داده واقعی مشتری هات انجام می شه.
چیزهایی که باید توش باشن:
- داده نمونه، نه داده واقعی کاربران
- درگاه پرداخت و پیامک در حالت آزمایشی
- یه آدرس مشخص که خودت بهش دسترسی داری
سناریوهایی که باید خودت اجرا کنی
قبل از تایید، خودت ثبت نام کن، یه پرداخت موفق و یه پرداخت ناموفق انجام بده، اینترنت رو وسط کار قطع کن و دوباره وصل کن. اگه می تونی، توی ساعت اوج ترافیک هم امتحانش کن. قطعی یا کندی اینترنت و برگشت از درگاه پرداخت جاهایی هستن که اپ ها توی ایران زیاد توشون گیر می کنن. اگه بعد از پرداخت سفارش ثبت نشد، مشکل بازگشت از درگاه پرداخت رو دنبال کن.
اگه از Docker استفاده شده
بپرس محیط با چه فایل هایی بالا میاد و آیا خودت می تونی دوباره اجراش کنی. Docker Compose برای پروژه کوچک توضیح می ده این ابزار کجا کافیه.
آموزش چقدر لازمه؟
لازم نیست برنامه نویس بشی، ولی باید کارهای روزمره رو خودت بتونی انجام بدی: عوض کردن محتوا، ساخت کاربر، دیدن گزارش ها و گرفتن نسخه پشتیبان.
- یه جلسه آموزشی بخواه و اگه می شه ضبطش کن.
- برای هر نقش یه راهنمای کوتاه بخواه، یکی برای مدیر و یکی برای پشتیبان.
- یه نفر از تیم خودت رو هم توی جلسه بنشون، نه فقط خودت رو. اگه تو جابه جا شدی، دانش از بین نره.
اشتباه رایج اینه که آموزش رو می ندازن به آخرین روز و در حد چند دقیقه می مونه. زودتر هماهنگش کن.
کی تایید نهایی رو بدم؟
وقتی این پنج شرط جمع شد:
- کد از صفر ساخته شد.
- یه نفر غیر از نویسنده، با مستندات پروژه رو بالا آورد.
- دسترسی ها منتقل شدن و رمزها عوض شدن.
- سناریوهای تست خودت درست جواب دادن.
- آموزش انجام شد.
بعدش صورتجلسه تحویل بنویس و مدت رفع اشکال بعد از تحویل رو توی قرارداد مشخص کن. این مدت به توافق تون بستگی داره. تسویه آخر هم بهتره بعد از همین مرحله باشه، نه قبلش.
اگه می خوای پروژه از اول با این چک لیست جلو بره، صفحه توسعه وب اپلیکیشن و اپلیکیشن موبایل نشون می ده ما چطور کار می کنیم. برای بعد از تحویل هم پشتیبانی فنی هست.
سوالات متداول
اگه پیمانکار کد منبع رو نده چی؟
اول ببین توی قرارداد چی نوشته شده. اگه تحویل کد ذکر شده، کتبی و رسمی بخواه. اگه نوشته نشده، پیش از هر پرداختی با یه مشاور حقوقی صحبت کن، چون وضعیت به متن قرارداد بستگی داره.
مستندات رو بعد از تحویل هم می شه گرفت؟
می شه، ولی معمولاً سخت تر و گرون تره. بعد از تحویل، جزئیات از ذهن تیم می ره و تو هم دیگه اهرم تسویه آخر رو نداری. بهتره مستندات جزو شرط تایید نهایی باشه.
محیط تست حتماً باید روی سرور جدا باشه؟
نه همیشه. برای پروژه کوچیک ممکنه یه محیط جدا روی همون سرور کافی باشه، به شرطی که داده و تنظیمات از نسخه زنده جدا بمونن. اگه پرداخت و کاربر واقعی زیاده، سرور جدا امن تره.
بعد از تحویل هم باید به پیمانکار وابسته باشم؟
اگه کد، مستندات و دسترسی ها دستت باشه، نه. می تونی با همون پیمانکار ادامه بدی یا یه تیم دیگه بیاری. وابستگی وقتی پیش میاد که یکی از این سه مورد جا مونده باشه.
قبل از تایید یه بار همه چیز رو امتحان کن
تحویل خوب یعنی اگه فردا پیمانکار در دسترس نبود، پروژه هنوز مال خودته و می تونی اجراش کنی. پنج مورد رو یکی یکی تیک بزن و بخش «ساخت از صفر» و «تست سناریوها» رو شخصاً ببین. بقیه چیزها بعد از این ها جا می افته.
