دقیقه
17 مهر 1405انتخاب شرکت توسعه نرم‌افزار اختصاصی فقط مقایسه چند قیمت نیست. شما تیمی را انتخاب می‌کنید که قرار است مسئله کسب‌وکار را بفهمد، آن را به معماری و محصول قابل اجرا تبدیل کند و احتمالاً ماه‌ها یا سال‌ها در توسعه و نگهداری سیستم نقش داشته باشد.
پیشنهاد ارزان‌تر می‌تواند انتخاب مناسبی باشد و پیشنهاد گران‌تر هم الزاماً کیفیت بالاتری ندارد. معیار مهم این است که تیم چگونه مسئله را تحلیل می‌کند، Scope را شفاف می‌کند، ریسک‌ها را مدیریت می‌کند و مالکیت و نگهداری محصول را از ابتدا جدی می‌گیرد.
در این مقاله یک چارچوب عملی برای ارزیابی شرکت‌های طراحی و توسعه نرم‌افزار اختصاصی ارائه می‌کنیم؛ از جلسه اول و Proposal تا قرارداد، Source Code، امنیت، QA و پشتیبانی.
قبل از مقایسه شرکت‌ها، نیاز خودتان را تا حدی شفاف کنید
اگر برای هر شرکت شرح متفاوتی از پروژه بفرستید، پیشنهادهای دریافتی قابل مقایسه نخواهند بود. حداقل مسئله، کاربران، Workflowهای اصلی، MVP، Integrationها و محدودیت‌های مهم را در یک Brief مشترک آماده کنید.
لازم نیست معماری فنی را تعیین کنید؛ هدف این است که همه شرکت‌ها درباره یک مسئله واحد پیشنهاد بدهند.
۱. به سؤال‌هایی که تیم در جلسه اول می‌پرسد دقت کنید
تیم خوب قبل از ارائه راه‌حل باید مسئله را بفهمد. اگر جلسه تقریباً بدون سؤال درباره فرآیند، کاربران، داده و محدودیت‌ها مستقیماً به قیمت و تکنولوژی برسد، احتمالاً بخشی از Scope هنوز ناشناخته مانده است.
سؤال‌های خوب معمولاً درباره استثناهای فرآیند، Roleها، حجم استفاده، سیستم‌های موجود، معیار موفقیت و آینده محصول هستند.
۲. آیا قبل از قیمت قطعی، Discovery انجام می‌شود؟
برای پروژه‌های ساده ممکن است برآورد سریع ممکن باشد، اما نرم‌افزار پیچیده بدون شناخت نیازها قیمت دقیق ندارد. تیم حرفه‌ای باید Unknownها را مشخص کند و در صورت نیاز مرحله Discovery یا تحلیل اولیه پیشنهاد دهد.
قیمت قطعی بسیار سریع برای Scope مبهم لزوماً مزیت نیست؛ ممکن است بعداً با Change Requestهای متعدد جبران شود.
۳. Proposal را فقط از روی عدد نخوانید
پیشنهاد خوب باید نشان دهد شرکت چه چیزی از مسئله فهمیده است، چه Scopeای را در قیمت دیده و چه مواردی خارج از آن هستند.
مواردی مثل Deliverableها، فازها، فرضیات، Integrationها، مسئولیت طرفین و شرایط پذیرش باید تا حد ممکن روشن باشند.
۴. نمونه‌کار مرتبط را بررسی کنید، نه فقط ظاهر Portfolio
وجود ده‌ها Screenshot زیبا نشان نمی‌دهد تیم توان حل مسئله مشابه شما را دارد. برای نرم‌افزار سازمانی، تجربه Workflow، Permission، Integration، Reporting یا Scale می‌تواند مهم‌تر از شباهت ظاهری پروژه باشد.
درباره نقش واقعی شرکت در نمونه‌کار سؤال کنید: آیا Backend و معماری را ساخته؟ فقط UI انجام داده؟ محصول هنوز فعال است؟ چه مسئله‌ای را حل کرده است؟
۵. کیفیت فنی را با سؤال‌های قابل‌فهم بسنجید
لازم نیست خودتان برنامه‌نویس باشید. از تیم بخواهید توضیح دهد چرا معماری پیشنهادی را انتخاب کرده، داده‌ها چگونه Backup می‌شوند، خطاها چگونه Monitor می‌شوند و توسعه قابلیت جدید چه اثری روی سیستم دارد.
پاسخ خوب باید قابل توضیح باشد؛ استفاده زیاد از اصطلاحات فنی بدون ارتباط با نیاز کسب‌وکار نشانه کیفیت نیست.
۶. انتخاب تکنولوژی باید دلیل داشته باشد
Laravel، Node.js، .NET، React، Next.js یا هر فناوری دیگری ابزار هستند. سؤال اصلی این است که چرا برای محدودیت‌ها و تیم شما مناسب‌اند.
اگر شرکت برای تمام پروژه‌ها بدون توجه به نیاز دقیقاً یک Stack پیشنهاد می‌کند، بررسی کنید آیا انتخاب از مسئله آمده یا صرفاً از عادت تیم.
۷. درباره معماری آینده‌پذیر سؤال کنید، نه معماری پیچیده
آینده‌پذیری به معنی Microservice از روز اول نیست. در بسیاری از پروژه‌ها Modular Monolith انتخاب ساده‌تر و قابل نگهداری‌تری است.
تیم باید بتواند توضیح دهد چگونه بدون Overengineering، مسیر رشد محصول را باز نگه می‌دارد.
۸. مالکیت Source Code را شفاف کنید
در قرارداد مشخص شود Source Code متعلق به چه کسی است، Repository کجا قرار دارد و کارفرما چه سطح دسترسی دارد.
اگر پروژه اختصاصی برای سازمان شما ساخته می‌شود، نباید در پایان متوجه شوید برای دریافت Source یا انتقال به تیم دیگر محدودیت پیش‌بینی‌نشده وجود دارد.
۹. Repository و تاریخچه توسعه اهمیت دارند
تحویل یک فایل ZIP در پایان پروژه با توسعه در Repository قابل ردیابی یکسان نیست. Version Control، Commit History و Branching مناسب انتقال و نگهداری را ساده‌تر می‌کنند.
بهتر است نحوه دسترسی کارفرما به Repository و زمان تحویل آن از ابتدا روشن باشد.
۱۰. مالکیت حساب‌ها و زیرساخت را مشخص کنید
دامنه، Cloud، Server، سرویس ایمیل، SMS، Storage و حساب‌های Third-party بهتر است تا جای ممکن با مالکیت و دسترسی روشن ایجاد شوند.
وابستگی کامل زیرساخت به حساب شخصی پیمانکار می‌تواند در زمان انتقال همکاری مشکل ایجاد کند.
۱۱. امنیت را با جمله «سیستم امن است» نپذیرید
بپرسید Authentication، Authorization، Secretها، Backup، Logging، Dependency Update و دسترسی Production چگونه مدیریت می‌شوند.
سطح امنیت باید متناسب با حساسیت داده و ریسک کسب‌وکار باشد. وعده «هک‌نشدن» معیار حرفه‌ای نیست.
۱۲. تست و QA باید بخشی از Scope باشد
مشخص کنید چه کسی تست می‌کند، چه محیط‌هایی وجود دارد و قبل از Release چه معیارهایی باید پاس شوند. برای بخش‌های حساس، Automated Test می‌تواند ریسک Regression را کاهش دهد.
همچنین روشن کنید UAT کارفرما چگونه انجام می‌شود و Bug با Feature جدید چگونه تفکیک می‌شود.
۱۳. درباره Monitoring و خطاهای Production سؤال کنید
بعد از Launch باید بتوان خطاهای مهم، وضعیت سرویس و رفتارهای غیرعادی را دید. سیستمی که فقط وقتی کاربر تماس می‌گیرد متوجه خرابی آن می‌شویم، نگهداری دشوارتری دارد.
۱۴. Backup فقط «بکاپ داریم» نیست
Frequency، محل نگهداری، Retention و مهم‌تر از همه Restore باید مشخص باشند. Backupی که هیچ‌وقت امکان بازیابی آن تست نشده، اطمینان کامل ایجاد نمی‌کند.
۱۵. مستندات و انتقال دانش را بررسی کنید
Documentation باید متناسب با پروژه باشد: راه‌اندازی محیط، Deployment، API، تنظیمات مهم و تصمیمات معماری می‌توانند برای تیم بعدی حیاتی باشند.
هدف تولید سند زیاد نیست؛ هدف کاهش وابستگی به حافظه افراد است.
۱۶. پشتیبانی بعد از تحویل دقیقاً یعنی چه؟
عبارت «سه ماه پشتیبانی رایگان» به‌تنهایی کافی نیست. باید معلوم باشد چه مواردی Bug محسوب می‌شوند، SLA پاسخ چیست، تغییر Feature چگونه قیمت‌گذاری می‌شود و بعد از دوره اولیه چه مدلی ادامه دارد.
۱۷. Change Request باید فرآیند مشخص داشته باشد
در پروژه واقعی نیازها تغییر می‌کنند. قرارداد خوب تغییر را ممنوع نمی‌کند؛ روش مدیریت آن را مشخص می‌کند.
باید معلوم باشد تغییر Scope چگونه بر هزینه و Timeline اثر می‌گذارد و چه کسی آن را تأیید می‌کند.
۱۸. پرداخت را به Milestoneهای قابل سنجش وصل کنید
تقسیم پرداخت بر اساس مراحل مشخص معمولاً از پرداخت‌های مبهم زمانی بهتر است. هر Milestone باید Deliverable و معیار پذیرش قابل فهم داشته باشد.
مدل پرداخت به نوع پروژه بستگی دارد، اما باید انگیزه دو طرف برای پیشرفت و تأیید منظم را حفظ کند.
۱۹. قیمت خیلی پایین را بدون بررسی نپذیرید
اختلاف قیمت می‌تواند ناشی از تفاوت Scope، تیم، کیفیت QA یا معماری باشد. ابتدا بررسی کنید آیا پیشنهادها واقعاً یک خروجی را قیمت داده‌اند.
قیمت پایین زمانی خطرناک است که موارد ضروری عمداً یا ناخواسته از Scope حذف شده باشند و بعداً به هزینه اضافه تبدیل شوند.
۲۰. قیمت خیلی بالا هم به‌تنهایی نشانه کیفیت نیست
برای قیمت بالاتر باید ارزش قابل توضیح وجود داشته باشد: تجربه مرتبط، ریسک کمتر، کیفیت تیم، SLA، معماری، امنیت یا Scope گسترده‌تر.
برند شرکت می‌تواند ارزش داشته باشد، اما همچنان باید بدانید دقیقاً بابت چه چیزی هزینه می‌کنید.
۲۱. تیم واقعی پروژه را بشناسید
گاهی جلسه فروش با افراد ارشد برگزار می‌شود اما اجرای پروژه به تیم دیگری واگذار می‌شود. بپرسید Project Manager، Tech Lead و اعضای اصلی چه کسانی هستند و چه میزان در پروژه حضور دارند.
۲۲. ظرفیت و همزمانی پروژه‌های شرکت را بپرسید
شرکت خوب هم اگر ظرفیت کافی نداشته باشد ممکن است Deadline شما را از دست بدهد. برنامه شروع، Availability تیم و پروژه‌های همزمان روی واقع‌بینی Timeline اثر دارند.
۲۳. ارتباط و گزارش‌دهی را قبل از قرارداد تجربه کنید
کیفیت پاسخ‌گویی در مرحله فروش نشانه کاملی از آینده نیست، اما می‌تواند اطلاعات بدهد. مشخص کنید جلسات با چه ریتمی برگزار می‌شوند، Taskها کجا ثبت می‌شوند و گزارش پیشرفت چگونه ارائه می‌شود.
۲۴. از شرکت بخواهید ریسک‌های پروژه را خودش بگوید
تیمی که فقط از مزایا حرف می‌زند احتمالاً تصویر کاملی ارائه نمی‌دهد. سؤال کنید بزرگ‌ترین Unknownها و ریسک‌های این پروژه چیست و چگونه می‌توان آنها را زودتر کاهش داد.
۲۵. Reference Check برای پروژه‌های بزرگ ارزش دارد
برای قراردادهای مهم می‌توانید با اجازه شرکت با یکی از مشتریان قبلی صحبت کنید. سؤال‌های مفید درباره تحویل، مدیریت تغییر، کیفیت ارتباط و پشتیبانی بعد از Launch هستند.
Red Flagهایی که باید جدی بگیرید
- قیمت قطعی برای Scope بسیار مبهم بدون سؤال جدی
- وعده زمان غیرواقعی بدون فازبندی
- ابهام درباره مالکیت Source Code
- عدم دسترسی روشن به Repository یا زیرساخت
- نبود فرآیند QA و Acceptance
- وابستگی شدید به یک فرد بدون Documentation
- استفاده از عبارت‌های امنیتی مطلق مثل «غیرقابل هک»
- نامشخص‌بودن پشتیبانی و Change Request
- Proposal عمومی که مسئله شما را منعکس نمی‌کند
چطور سه پیشنهاد را منصفانه مقایسه کنیم؟
یک ماتریس ساده بسازید و شرکت‌ها را بر اساس معیارهای یکسان مقایسه کنید: فهم مسئله، Scope، تجربه مرتبط، معماری، امنیت، QA، مالکیت، پشتیبانی، Timeline و هزینه.
لازم نیست برای همه معیارها وزن برابر بگذارید. برای یک سیستم مالی امنیت و Audit ممکن است وزن بیشتری از Animation رابط داشته باشد.
امتیاز فنی و تجاری را جدا ببینید
ممکن است یک شرکت از نظر فنی عالی باشد اما قرارداد یا پشتیبانی نامناسبی ارائه دهد، یا برعکس. بهتر است Technical Fit و Commercial Fit جدا ارزیابی شوند و بعد تصمیم نهایی گرفته شود.
جلسه نهایی قبل از قرارداد چه چیزهایی را روشن کند؟
- Scope و موارد خارج از Scope
- Milestoneها و Deliverableها
- Timeline و Dependencies
- Acceptance Criteria
- مالکیت کد، داده و حساب‌ها
- پشتیبانی و SLA
- فرآیند Change Request
- شرایط پرداخت و خاتمه همکاری
جمع‌بندی
بهترین شرکت توسعه نرم‌افزار لزوماً ارزان‌ترین، گران‌ترین یا بزرگ‌ترین شرکت نیست. گزینه مناسب تیمی است که مسئله شما را درست بفهمد، Unknownها را پنهان نکند، Scope و مسئولیت‌ها را شفاف کند و محصولی قابل نگهداری تحویل دهد.
اگر برای انتخاب مسیر فنی یا تعریف Scope پروژه نرم‌افزاری نیاز به مشورت دارید، از صفحه تماس با ما درباره مسئله، فرآیند و محدودیت‌های پروژه توضیح دهید تا قبل از شروع توسعه، مسیر مناسب بررسی شود.
