چطور تیم یا شرکت توسعه‌ی نرم‌افزار را انتخاب کنیم؟ چک‌لیست
انتخاب تیم ساخت، مهم‌ترین تصمیم یک پروژه‌ی نرم‌افزاری است. اینجا هفت سؤال و چند نشانه‌ی هشدار دارید که کمک می‌کند پیش از امضای قرارداد درست تصمیم بگیرید.
وقتی تصمیم می‌گیرید محصولی بسازید، مهم‌ترین انتخاب شما فناوری نیست؛ تیمی است که آن را می‌سازد. بیشتر پروژه‌هایی که خراب می‌شوند، دلیل فنی ندارند. دلیلشان ارتباط، انتظار نادرست و نبودن مسئول روشن است.
پیش از جست‌وجو، خودتان را آماده کنید
اگر نمی‌دانید دقیقاً چه می‌خواهید، هیچ تیمی نمی‌تواند درست پیشنهاد بدهد. حداقل این‌ها را بنویسید:
- مسئله‌ای که می‌خواهید حل شود
- کاربران اصلی
- مهم‌ترین سه جریان
- تاریخ یا رویدادی که به آن وابسته‌اید
اگر این‌ها را ندارید، شروع از مرحله‌ی کشف بهتر از شروع از ساخت است.
هفت سؤال که باید بپرسید
- نمونه‌ی زنده‌ی مشابه دارید؟ نه عکس و فایل ارائه؛ لینکی که بتوانید خودتان باز کنید.
- نقش شما در آن پروژه دقیقاً چه بود؟ گاهی تیمی نمونه‌ای نشان می‌دهد که فقط بخش کوچکی از آن را ساخته.
- چه کسی پاسخ‌گوی کل پروژه است؟ باید یک نفر مشخص باشد، نه «تیم».
- چطور دامنه را مدیریت می‌کنید؟ تغییر وسط کار قطعی است؛ سؤال این است که با آن چه می‌کنند.
- چطور از وضعیت مطلع می‌شوم؟ گزارش‌دهی منظم و نسخه‌ی قابل‌دیدن در هر مرحله.
- کد و مستندات مال چه کسی است؟ باید به‌صراحت مال شما باشد و در پایان تحویل داده شود.
- بعد از انتشار چه می‌شود؟ نگهداری، رفع خطا و پشتیبانی چگونه است.
نشانه‌های هشدار
- قیمت بدون پرسش. پیشنهادی که بدون هیچ سؤالی درباره‌ی نیازتان آمده، حدس است.
- «بله» به همه‌چیز. تیمی که هیچ‌وقت نمی‌گوید «این لازم نیست» یا «این را بعداً بسازیم»، شریک خوبی نیست.
- نبودن نسخه‌ی میانی. اگر اولین چیزی که می‌بینید محصول نهایی است، خطر بزرگ است.
- وعده‌ی تضمین نتیجه. رشد و فروش تضمین‌شدنی نیست؛ کیفیت ساخت و شفافیت است که قابل‌تعهد است.
- مبهم بودن مالکیت. اگر کد و دسترسی‌ها شفاف نیست، بعداً گرفتار می‌شوید.
الگوهای همکاری
| الگو | مناسب برای | ریسک |
|---|---|---|
| فریلنسر | کار کوچک و مشخص | وابستگی به یک نفر |
| شرکت بزرگ | پروژه‌ی سازمانی با فرایند رسمی | هزینه و انعطاف کم |
| تیم کوچک با مسئول واحد | محصول در حال شکل‌گیری | به ظرفیت تیم بستگی دارد |
| تیم داخلی | محصول بلندمدت | استخدام و زمان |
هیچ‌کدام برنده‌ی مطلق نیست. مهم این است که یک مسئول پاسخ‌گو از نیاز تا تحویل داشته باشید.
چطور نمونه‌کار را درست ارزیابی کنید
به ظاهر نگاه نکنید. این‌ها را بررسی کنید:
- آیا محصول واقعاً زنده است و کاربر دارد؟
- روی موبایل و شبکه‌ی ضعیف چطور کار می‌کند؟
- متن‌ها و خطاها دقیق و فارسی درست هستند؟ طراحی راست‌به‌چپ چیزی است که فوراً دیده می‌شود.
- آیا درباره‌ی نتیجه ادعای عددی بدون منبع شده است؟
قرارداد و مراحل تأیید
پروژه را به مراحل با خروجی مشخص بشکنید و بعد از هر مرحله تأیید کتبی بگیرید. دروازه‌های تأیید هم شما را از غافلگیری حفظ می‌کنند و هم تیم را از «پایان‌ناپذیری» پروژه.
جمع‌بندی
تیم مناسب را با نمونه‌ی زنده، مسئول واحد، شفافیت و فرایند تأیید می‌شناسید، نه با قیمت یا سرعت وعده‌شده. پیش از امضا، هفت سؤال بالا را بپرسید و آهسته‌تر تصمیم بگیرید.
برای صحبت درباره‌ی پروژه‌تان، از اینجا شروع کنید.