چکلیست تحویل نرمافزار: ۱۸ موردی که قبل از پرداخت نهایی باید بررسی کنید
پروژهی نرمافزاریتان تمام شده؟ با این چکلیست کاربردی، حتی بدون دانش برنامهنویسی، مالکیت، کارکرد، سرعت، امنیت و مستندات نرمافزار را قبل از تحویل نهایی بسنجید.
لحظهی تحویل یک پروژهی نرمافزاری، مهمترین لحظهی آن است. بعد از پرداخت نهایی، اهرم شما برای درخواست اصلاح کمتر میشود و مشکلاتی که امروز دیده نشوند، ماهها بعد با هزینهی بیشتر خودشان را نشان میدهند. این چکلیست را طوری نوشتهایم که بدون دانش برنامهنویسی هم بتوانید از آن استفاده کنید.
بخش ۱: مالکیت و دسترسیها (مهمترین بخش)
اگر فقط یک بخش از این چکلیست را بررسی میکنید، این بخش باشد. نرمافزاری که کلیدهایش دست شما نیست، در عمل مال شما نیست.
- کد منبع: کد کامل پروژه در یک مخزن Git (مثل GitHub یا GitLab) قرار دارد و شما مالک یا مدیر آن مخزن هستید، نه فقط یک فایل فشرده.
- دامنه: دامنه به نام خود شما یا شرکتتان ثبت شده و به پنل آن دسترسی دارید.
- هاست و سرور: حساب سرور یا سرویس ابری به نام شماست، یا دستکم دسترسی مدیریتی کامل به آن دارید.
- سرویسهای جانبی: درگاه پرداخت، سرویس پیامک، ایمیل، نقشه و هر سرویس دیگری که نرمافزار استفاده میکند، با حساب شما ثبت شدهاند.
- فهرست رمزها و کلیدها: فهرست کامل حسابها و کلیدها، از یک راه امن (نه پیام معمولی) به شما تحویل شده است.
بخش ۲: کارکرد
- مسیرهای اصلی: هر سناریوی مهم (ثبتنام، سفارش، پرداخت، گزارشگیری) را خودتان از اول تا آخر اجرا کنید؛ نه فقط در دموی تیم سازنده.
- ورودیهای غیرعادی: فرمها را خالی، با متن خیلی بلند، با اعداد فارسی و انگلیسی و با اطلاعات اشتباه امتحان کنید. نرمافزار خوب پیام خطای قابل فهم میدهد، نه صفحهی سفید.
- موبایل و دستگاههای مختلف: روی چند گوشی واقعی (اندروید و آیفون) و مرورگرهای مختلف بررسی کنید. بیشتر کاربران ایرانی با موبایل وارد میشوند.
- اینترنت ضعیف: با اینترنت کند یا ناپایدار هم امتحان کنید. آیا وضعیت بارگذاری نشان داده میشود؟ با قطع لحظهای اینترنت، اطلاعات فرم از بین میرود؟
- نقشها و دسترسیها: اگر کاربران با نقشهای مختلف دارید (مدیر، اپراتور، مشتری)، مطمئن شوید هر کس فقط چیزی را میبیند که باید ببیند.
بخش ۳: سرعت و عملکرد
- Core Web Vitals: آدرس سایت را در ابزار رایگان PageSpeed Insights گوگل وارد کنید. معیارهای رایج گوگل برای تجربهی خوب اینهاست: نمایش محتوای اصلی (LCP) زیر ۲.۵ ثانیه، پاسخ به تعامل (INP) زیر ۲۰۰ میلیثانیه و جابهجایی ناگهانی صفحه (CLS) کمتر از ۰.۱.
- رفتار با دادهی واقعی: سرعت با ده رکورد آزمایشی چیزی را ثابت نمیکند. بپرسید با هزار یا ده هزار سفارش، صفحهها و گزارشها چطور رفتار میکنند.
بخش ۴: امنیت
- HTTPS: کنار آدرس سایت علامت قفل وجود دارد و نسخهی http خودکار به https منتقل میشود.
- رمزهای پیشفرض: هیچ حساب مدیریتی با رمزهایی مثل admin یا 123456 باقی نمانده است.
- پشتیبانگیری: پشتیبانگیری خودکار از اطلاعات فعال است و یک بار واقعاً بازگردانی آن تست شده. پشتیبانی که بازگردانیاش امتحان نشده، فقط یک امید است.
فهرست کاملتر را در مقالهی حداقلهای امنیت نرمافزار ببینید.
بخش ۵: مستندات و ادامهی مسیر
- راهنمای اجرا و استقرار: یک سند (معمولاً فایل README) که توضیح میدهد پروژه چطور اجرا و روی سرور منتشر میشود. معیار ساده: برنامهنویس دیگری باید بتواند فقط با همین سند پروژه را بالا بیاورد.
- راهنمای کاربری پنل: برای بخشهایی که خودتان یا کارمندانتان کار میکنید، یک راهنمای کوتاه یا ویدیوی آموزشی.
- شرایط پشتیبانی: مکتوب و روشن: رفع باگ تا چه مدت رایگان است، زمان پاسخگویی چقدر است و تغییرات جدید چطور قیمتگذاری میشوند.
چکلیست خلاصه
| بخش | سؤال کلیدی |
|---|---|
| مالکیت | اگر فردا با تیم سازنده قطع رابطه کنم، همهچیز دست خودم است؟ |
| کارکرد | مسیرهای اصلی را خودم، روی گوشی خودم، از اول تا آخر رفتهام؟ |
| سرعت | PageSpeed چه میگوید و با دادهی زیاد چه میشود؟ |
| امنیت | HTTPS، رمزهای قوی و پشتیبانِ تستشده دارم؟ |
| مستندات | برنامهنویس دیگری میتواند کار را ادامه دهد؟ |
اگر موردی رد شد چه کنیم؟
رد شدن یکی دو مورد به معنای بد بودن تیم نیست؛ مهم واکنش آنهاست. فهرست موارد را مکتوب بفرستید، برای هر مورد زمان رفع توافق کنید و پرداخت نهایی را به رفع موارد بخش ۱ و ۴ گره بزنید. تیمی که به کیفیت کارش مطمئن است، از این شفافیت ناراحت نمیشود.
برای اینکه بدانید پشت این موارد چه اصولی قرار دارد، مقالهی اصول توسعه نرمافزار را بخوانید.