معیار انتخاب شرکت برنامه‌نویسی: راهنمای ۱۰ معیار و چک‌لیست

برای انتخاب شرکت برنامه‌نویسی، همهٔ گزینه‌ها را با ده معیار یکسان بسنجید: درک نیاز، نمونه‌کار قابل‌بررسی، تناسب فناوری، تیم، فرایند، طراحی، تست و امنیت، شفافیت مالی، مالکیت کد و پشتیبانی. برای هر معیار سؤال بپرسید، مدرک بخواهید و نشانهٔ هشدار را امتیاز بدهید.

این راهنما برای صاحب کسب‌وکار، مدیر محصول یا مدیر فناوری‌ای است که چند پیشنهاد روی میز دارد و نمی‌داند کدام را باید جدی‌تر گرفت. در پایان، یک جدول امتیازدهی با وزن‌های قابل‌تغییر و یک چک‌لیست قابل‌کپی دارید که می‌توانید همین هفته پای هر جلسه ببرید.

چرا ارزان‌ترین، بزرگ‌ترین یا قدیمی‌ترین شرکت معمولاً انتخاب امنی نیست؟

همه می‌گویند سابقهٔ طولانی و تیم بزرگ یعنی اطمینان. در عمل، پروژه‌ها کمتر از کمبود نیرو خراب می‌شوند و بیشتر از سه ابهام: نیاز دقیق چه بوده، کد دست چه کسی است، و تغییر وسط کار چطور حساب می‌شود.

قیمت پایین، اندازهٔ تیم و تعداد سال‌های فعالیت سه ملاکِ رایج‌اند، اما هیچ‌کدام مدرک نیستند. جایگزینِ بررسی شده‌اند. قیمت پایین فقط می‌گوید پیشنهاد ارزان است، نه اینکه چه چیزی در آن حساب نشده. تیم بزرگ می‌گوید شرکت نیرو دارد، نه اینکه نیروی مناسب شما روی پروژه شما کار می‌کند. سابقهٔ طولانی هم می‌تواند ده سال تجربه باشد یا یک سال تجربه که ده بار تکرار شده.

موضع ما صریح است: نمونهٔ زیبا مدرک نیست؛ نمونهٔ قابل‌بررسی مدرک است. ملاک انتخاب «قابل‌راستی‌آزمایی‌بودنِ ادعا» است، نه خودِ ادعا. همین منطق پشت روش رتبه‌بندی وانوریکس و نظرهای راستی‌آزمایی‌شده است: حرفی که نشود چک کرد، وزنی ندارد.

یک باور رایج دیگر هم باید کنار برود: هیچ زبان برنامه‌نویسی یا فریم‌ورکی نشانهٔ قطعی حرفه‌ای‌بودن نیست. شرکتی که با فناوری مرسوم کار می‌کند ممکن است نظم مهندسی نداشته باشد، و شرکتی با فناوری کم‌سروصداتر ممکن است دقیق‌ترین فرایند را داشته باشد. چیزی که اهمیت دارد تناسب فناوری با پروژهٔ شماست و دلیلی که شرکت برای انتخابش می‌آورد.

در ادامه ابتدا نیاز خودتان را روی کاغذ می‌آوریم، بعد ده معیار را یکی‌یکی می‌گذرانیم، سپس به جدول امتیاز و چک‌لیست می‌رسیم.

پیش از مقایسهٔ شرکت‌ها، چه چیزی را باید روی کاغذ بیاورید؟

اگر نیاز شما روی کاغذ نیامده باشد، هر شرکتی پیشنهادی می‌دهد که با پیشنهاد دیگری قابل‌مقایسه نیست. در عمل دیده‌ایم که سه شرکت از سه جملهٔ مبهم، سه پروژهٔ متفاوت می‌سازند و بعد مدیر پروژه‌ای که هیچ‌کدام را مقایسه‌پذیر نمی‌بیند، ارزان‌ترینشان را برمی‌دارد.

نیازِ کسب‌وکار را از راه‌حل جدا کنید

«اپ می‌خواهم» راه‌حل است، نه نیاز. نیاز یعنی چهار چیز: چه مسئله‌ای دارید، کاربرِ آن کیست، چه محدودیتی دارید (بودجه، مهلت، سیستم‌های موجود) و موفقیت را با چه معیاری می‌سنجید. مثلاً «مشتری‌ها سفارش تلفنی می‌دهند و نیمی از سفارش‌ها به‌خاطر خطای ثبت دوباره پیگیری می‌شود» نیاز است. «اپلیکیشن سفارش» فقط یکی از پاسخ‌های ممکن به آن است.

یک سند کوتاه نیازمندی‌ها (SRS سبک) یا یک درخواست پیشنهاد ساده (RFP) کافی است. لازم نیست چهل صفحه باشد. دو تا چهار صفحه که مسئله، کاربران، قابلیت‌های ضروری، قابلیت‌های قابل‌حذف برای نسخهٔ اول (MVP) و سیستم‌هایی که باید به آن‌ها وصل شود را بگوید. شرکتی که از روی چنین سندی پیشنهاد فنی و مالی بدهد، قابل‌مقایسه‌تر است.

سه سؤالی که وزن معیارها را تعیین می‌کند

قبل از دیدن هر پیشنهادی بنویسید: بودجه‌تان چقدر انعطاف دارد، مهلت‌تان چقدر سخت است، و داده‌ای که نرم‌افزار نگه می‌دارد چقدر حساس است. این‌ها برای قطعیت‌دادن به قیمت نیستند. فقط تعیین می‌کنند کدام معیار در جدول امتیاز وزن بیشتری بگیرد. پروژه‌ای که اطلاعات مالی یا هویتی کاربران را نگه می‌دارد، وزن امنیت را بالا می‌برد. پروژه‌ای با مهلت سخت، وزن فرایند و گزارش‌دهی را.

نتیجه را در یادداشتی یک‌صفحه‌ای جمع کنید و در همهٔ جلسه‌ها همان را به همهٔ شرکت‌ها بدهید. اگر شرکتی با همان یادداشت سؤال‌های دقیق‌تری نپرسید، همین خودش اولین نشانه است.

آیا شرکت مسئلهٔ شما را فهمیده و تجربهٔ قابل‌بررسی دارد؟ (معیار ۱ تا ۳)

سه معیار اول می‌گویند آیا شرکت اصلاً می‌فهمد دنبال چه هستید و پیش‌تر کاری شبیه آن کرده است یا نه. برای هر معیار چهار جزء داریم: چرا مهم است، چه بپرسید، چه مدرکی بخواهید و چه چیزی هشدار است.

معیار ۱: درک مسئله و نیاز کسب‌وکار

• چرا مهم است: شرکتی که مسئله را نفهمیده باشد، نرم‌افزاری می‌سازد که درست کار می‌کند ولی به درد شما نمی‌خورد.
• چه بپرسید: «کدام بخش نیاز ما را مبهم می‌بینید؟ چه فرض‌هایی کرده‌اید؟ بزرگ‌ترین ریسک این پروژه از نگاه شما چیست؟»
• چه مدرکی بخواهید: خلاصهٔ مکتوب برداشت شرکت از نیاز، فهرست فرض‌ها و ریسک‌ها، و پرسش‌هایی که پیش از پیشنهاد مطرح کرده است.
• هشدار: پیشنهاد آماده‌ای که بدون هیچ سؤالی رسیده، یا قیمتی که پیش از شنیدن جزئیات اعلام شده است.

معیار ۲: تجربهٔ مرتبط و نمونه‌کار قابل‌بررسی

• چرا مهم است: نمونه‌کار تنها شاهد بیرونی است که دارید، به شرط اینکه قابل‌بررسی باشد.
• چه بپرسید: «نقش دقیق شما در این پروژه چه بود؟ چه کسانی از تیم هنوز در شرکت هستند؟ بزرگ‌ترین مشکل آن پروژه چه بود و چطور حل شد؟»
• چه مدرکی بخواهید: نمونه‌ای که بتوان دید، دربارهٔ آن سؤال کرد و با پروژهٔ شما نسبت منطقی دارد؛ و امکان تماس با مرجع مشتری (Reference Check).
• هشدار: تصویرهای زیبا بدون توضیح مسئله، یا ناتوانی در گفتن اینکه کدام بخش را خود شرکت ساخته است.

هنگام تماس با مرجع مشتری، از رضایت کلی نپرسید. بپرسید زمان‌بندی چطور پیش رفت، تغییرات چطور حل شد، بعد از تحویل چه کسی پاسخ می‌داد و اگر دوباره انتخاب می‌کرد چه چیزی را در قرارداد عوض می‌کرد.

معیار ۳: تناسب راهکار و فناوری با پروژه

• چرا مهم است: فناوری انتخاب‌شده هزینهٔ نگهداری، سرعت توسعه و امکان پیدا کردن نیروی جایگزین را تعیین می‌کند. بدهی فنی از همین‌جا شروع می‌شود.
• چه بپرسید: «چرا این فناوری برای این پروژه؟ اگر تیم شما فردا عوض شود، چه کسی می‌تواند ادامه دهد؟ آیا راه‌حل آماده (SaaS) را هم بررسی کرده‌اید؟»
• چه مدرکی بخواهید: توضیح مکتوب دربارهٔ دلیل انتخاب فناوری و گزینه‌هایی که کنار گذاشته شده‌اند.
• هشدار: پیشنهادی که فناوری را فقط به‌خاطر عادت تیم انتخاب کرده و برای انتخابش دلیلی ندارد.

اینجا تفاوت توسعهٔ اختصاصی و SaaS هم مطرح می‌شود. اگر فرایند کسب‌وکار شما با ابزار آماده جور درمی‌آید، شاید اصلاً به پروژهٔ اختصاصی نیاز نباشید. شرکت درست‌حسابی گاهی همین را به شما می‌گوید. برای دیدن انواع خدمات و تخصص‌ها می‌توانید به دستهٔ خدمات برنامه‌نویسی و توسعه نرم‌افزار سر بزنید.

چه کسی دقیقاً کار شما را انجام می‌دهد و چطور خبر می‌گیرید؟ (معیار ۴ تا ۶)

سه معیار بعدی دربارهٔ آدم‌ها، روش کار و کیفیت چیزی است که کاربر می‌بیند. بیشترِ دعواهای میانهٔ پروژه از همین‌جا شروع می‌شود.

معیار ۴: ترکیب تیم و مسئولیت افراد

• چرا مهم است: کسی که در جلسهٔ فروش حرف می‌زند، اغلب کسی نیست که کد می‌نویسد.
• چه بپرسید: «چه کسانی روی پروژهٔ ما کار می‌کنند؟ مسئول فنی (Tech Lead) کیست؟ مدیر پروژه کیست؟ چه کسی تست را انجام می‌دهد (QA)؟»
• چه مدرکی بخواهید: نام و نقش افراد، و در صورت امکان یک جلسه با خود تیم اجرا.
• هشدار: تیم فروش و تیم اجرا دو گروه جدا هستند و تیم اجرا هرگز معرفی نمی‌شود.

نکته‌ای که اغلب اشتباه برداشت می‌شود: لازم نیست همهٔ تخصص‌ها داخل تیم شرکت باشند. شرکتی که طراحی یا تست امنیت را با شریک یا پیمانکار فرعی انجام می‌دهد، لزوماً مشکل ندارد. مشکل زمانی است که معلوم نیست چه کسی مسئول نتیجهٔ کل است. نقش‌ها و مسئولیت‌ها باید شفاف باشد، حتی اگر بخشی از کار بیرون از شرکت انجام شود.

معیار ۵: فرایند اجرا، ارتباط و گزارش‌دهی

• چرا مهم است: پروژه‌ای که شفاف جلو نرود، تا لحظهٔ تحویل مشکلش را نشان نمی‌دهد.
• چه بپرسید: «ریتم جلسه‌ها چیست؟ با چه چرخه‌ای (مثلاً Sprint در روش Agile) کار می‌کنید؟ از چه ابزاری برای پیگیری کارها استفاده می‌کنید؟ آیا به محیط آزمایشی (Staging) دسترسی دارم؟»
• چه مدرکی بخواهید: نمونه‌ای از گزارش دوره‌ای، تقویم جلسه‌ها و دسترسی به ابزار پیگیری.
• هشدار: «هر وقت آماده شد نشان می‌دهیم.» پروژه‌ای که تا آخر دیده نشود، تا آخر هم نمی‌شود اصلاحش کرد.

معیار ۶: کیفیت طراحی و تجربهٔ کاربری

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

اگر طراحی تجربهٔ کاربری برای پروژهٔ شما وزن بالایی دارد، به‌جای اینکه آن را به تیم برنامه‌نویسی تحمیل کنید، می‌توانید شرکت‌های تخصصی طراحی UI/UX را هم بررسی کنید.

اگر پروژه خراب شود، چه چیزی شما را نجات می‌دهد؟ (معیار ۷ تا ۱۰)

چهار معیار آخر همان چیزهایی‌اند که کسی در جلسهٔ اول نمی‌پرسد و بعد از شش ماه همه‌چیز به آن‌ها بستگی دارد: کیفیت تست، شفافیت مالی، مالکیت کد و پشتیبانی. این‌جا همان جاست که ادعا باید به مدرک تبدیل شود.

معیار ۷: تست، امنیت و کنترل کیفیت

• چرا مهم است: باگ‌ها در هر پروژه‌ای پیدا می‌شوند. فرق شرکت‌ها در این است که پیش از تحویل پیدا می‌کنند یا بعد از آن، روی کاربر شما.
• چه بپرسید: «آیا بازبینی کد (Code Review) دارید؟ تست خودکار می‌نویسید؟ تست پذیرش (UAT) چطور انجام می‌شود؟ احراز هویت و ذخیرهٔ داده را بر چه اساسی طراحی می‌کنید؟ آیا با فهرست آسیب‌پذیری‌های OWASP کار می‌کنید و آیا تست نفوذ در برنامه است؟»
• چه مدرکی بخواهید: چک‌لیست تست، نمونهٔ گزارش باگ و رویکرد مکتوب امنیتی.
• هشدار: جواب‌هایی مثل «ما خودمان تست می‌کنیم» بدون هیچ فرایند یا مستند.

اگر پروژه داده‌های حساس دارد، ارزیابی مستقل امنیتی را جدی بگیرید. برای این منظور می‌توانید شرکت‌های خدمات امنیت سایبری را جداگانه بررسی کنید.

معیار ۸: شفافیت پیشنهاد مالی و مدیریت تغییرات

• چرا مهم است: پیشنهادی که اجزایش معلوم نیست، در میانهٔ کار به‌شکل هزینهٔ اضافه ظاهر می‌شود.
• چه بپرسید: «کدام بخش‌ها در این پیشنهاد هست و کدام نیست؟ اگر وسط کار قابلیتی را عوض کنم چه می‌شود؟ فرایند درخواست تغییر (Change Request) چطور است؟»
• چه مدرکی بخواهید: پیشنهاد مالی تفکیک‌شده بر اساس بخش‌ها، و توضیح مکتوب فرایند تغییر.
• هشدار: یک مبلغ یک‌جا و بدون شرح.

دقت کنید که ما اینجا قیمت یا زمان قطعی پیشنهاد نمی‌دهیم و نمی‌توانیم. نرم‌افزار هر کسب‌وکار متفاوت است. چیزی که می‌توانید بسنجید ساختار پیشنهاد است، نه رقم آن.

معیار ۹: مالکیت کد، مستندات و شرایط تحویل

• چرا مهم است: اگر کد، دسترسی‌ها یا مستندات پروژه دست شما نباشد، شرکت دیگری نمی‌تواند ادامه بدهد و عملاً به فروشنده وابسته می‌مانید (Vendor Lock-in).
• چه بپرسید: «مالکیت فکری و سورس کد با چه کسی است؟ آیا از ابتدا به مخزن کد (Repository در Git) دسترسی خواهم داشت؟ مستندات فنی و API چگونه تحویل می‌شود؟ دامنه، سرور و حساب‌های شخص ثالث به نام چه کسی ثبت می‌شود؟»
• چه مدرکی بخواهید: فهرست مکتوب تحویلی‌ها (کد، مستندات، دسترسی‌ها، اطلاعات استقرار و پشتیبان‌گیری) و نمونه‌ای از مستندات پروژهٔ قبلی.
• هشدار: جواب‌هایی مثل «در قرارداد مشخص می‌شود» بدون اینکه پیش از قرارداد روشن شود.

این بخش جایگزین مشورت حقوقی نیست. متن نهایی قرارداد را حقوقدان شما باید بررسی کند. کار شما این است که پیش از آن، مواضع شرکت را روشن بدانید.

معیار ۱۰: پشتیبانی، نگهداری و امکان توسعهٔ آینده

• چرا مهم است: نرم‌افزار بعد از تحویل تمام نمی‌شود. سرور، وابستگی‌ها و نیاز کاربران ادامه دارد.
• چه بپرسید: «دورهٔ ضمانت چه چیزی را پوشش می‌دهد؟ توافق سطح خدمات (SLA) چیست؟ هزینهٔ توسعهٔ بعدی چطور محاسبه می‌شود؟ استقرار (DevOps)، پشتیبان‌گیری و بازیابی چطور انجام می‌شود؟»
• چه مدرکی بخواهید: شرح مکتوب شرایط ضمانت و پشتیبانی، و زمان پاسخ‌گویی برای مشکلات با شدت‌های مختلف.
• هشدار: پشتیبانی بدون تعریف مرز بین «رفع باگ» و «قابلیت جدید».

اگر قصد دارید پشتیبانی را به شرکت دیگری بسپارید، خدمات پشتیبانی آی‌تی را هم در نظر بگیرید.

یک هشدار برای هر چهار معیار مشترک است: هر جا جواب «بعداً در قرارداد مشخص می‌شود» شنیدید، یعنی مدرکی برای نشان‌دادن ندارند.

چطور ده معیار را به یک عدد قابل‌مقایسه تبدیل کنید؟

ده معیار بدون جمع‌بندی فقط یک فهرست است. جدول زیر آن را به ابزار تصمیم تبدیل می‌کند. برای هر شرکت یک نسخه از آن را پر کنید.

جدول امتیازدهی با وزن‌های قابل‌تغییر

وزن هر معیار را قبل از دیدن پیشنهادها و بر اساس یادداشت یک‌صفحه‌ای بنویسید، از ۱ (کم‌اهمیت) تا ۵ (حیاتی). امتیاز هر شرکت از ۰ تا ۵ است. امتیاز نهایی هر ردیف حاصل‌ضرب وزن در امتیاز است و جمع ردیف‌ها نتیجهٔ کل. یک قاعده را سخت‌گیرانه رعایت کنید: معیاری که مدرکش را ندیده‌اید، امتیاز صفر می‌گیرد، حتی اگر حرف‌های خوبی شنیده باشید.

مثالِ کوتاه: وقتی پیشنهاد ارزان‌تر امتیاز کمتری می‌گیرد

فرض کنید یک رستوران زنجیره‌ای دو پیشنهاد برای اپلیکیشن سفارش گرفته است. اولی ارزان‌تر است و زودتر جواب داده. در آن نوشته نشده کد پس از تحویل دست چه کسی است و هیچ فرایندی برای تغییرات ندارد؛ فقط عبارت «موارد اضافه جداگانه محاسبه می‌شود». دومی گران‌تر است، اجزایش را تفکیک کرده، مالکیت کد را روشن گفته و فرایند درخواست تغییر را شرح داده است.

اگر فقط قیمت را ببینید، اولی برنده است. اگر جدول را پر کنید، معیارهای ۸ و ۹ برای اولی صفر می‌شود، و چون برای کسب‌وکاری که قرار است ماه‌ها قابلیت اضافه کند هر دو وزن بالایی دارند، فاصله به نفع دومی برمی‌گردد. جدول تصمیم را به شما نمی‌دهد. فقط ابهام‌ها را قابل‌دیدن می‌کند.

وزن‌دهی بر اساس نوع پروژه

وزن‌ها را برای هر پروژه دوباره بنویسید. پروژهٔ مالی یا هر نرم‌افزاری که داده‌های حساس نگه می‌دارد، وزن معیار ۷ را بالا می‌برد. فروشگاه اینترنتی روی معیارهای ۶ و ۱۰ حساس‌تر است، چون تجربهٔ خرید و پایداری بعد از راه‌اندازی مستقیم روی فروش اثر می‌گذارد. محصول نوپایی که هنوز بازار را نمی‌شناسد، به انعطاف و مدیریت تغییرات (معیار ۸) بیشترین نیاز را دارد.

برای تکمیل جدول، از منطق خود ما هم می‌توانید کمک بگیرید. در روش رتبه‌بندی وانوریکس توضیح داده‌ایم که چرا نظرهای راستی‌آزمایی‌شده بر ادعای خودِ شرکت مقدم است، و همین اصل را می‌توانید در مرجع‌گیری خودتان به کار ببرید.

کدام نشانه‌ها گزینهٔ پرریسک را از گزینهٔ مناسب جدا می‌کند؟

امتیاز بالا همیشه کافی نیست. بعضی نشانه‌ها آن‌قدر سنگین‌اند که هر امتیاز کلی را بی‌اثر می‌کنند.

معیارهای حذفی که امتیاز کل را بی‌اثر می‌کنند

سه مورد را «حذفی» بدانید: امتناع شرکت از معرفی هر مرجع مشتری یا هر بدیلی برای آن، ابهام در مالکیت کد، و نبودِ فرایند روشن برای تغییرات. شرکتی که یکی از این‌ها را دارد، حتی با جمع امتیاز بالا از رقابت کنار می‌رود. دلیلش ساده است: این سه مورد ریسکی می‌سازند که با کیفیت بقیهٔ کار جبران نمی‌شود.

اشتباه‌های میدانی و نشانهٔ عینی هرکدام

• تصمیم بر مبنای دمو: نشانه‌اش این است که فقط ظاهر نرم‌افزار دیده شده و دربارهٔ فرایند ساخت سؤالی نپرسیده‌اید. دمو را بسنجید، ولی مدرک فرایند را جدا بخواهید.
• قرارداد پیش از روشن‌شدن نیاز: نشانه‌اش این است که فهرست قابلیت‌ها هنوز مبهم است و می‌گویید «در حین کار مشخص می‌شود».
• نپرسیدن از تیم اجرا: نشانه‌اش این است که هیچ‌کدام از افراد فنی را ندیده‌اید و فقط با فروش حرف زده‌اید.
• باور به فناوری خاص: نشانه‌اش این است که شرکت برای انتخاب فناوری فقط نام آن را برده و نه دلیلش را.

یک مرز کاربرد هم هست. توصیهٔ «مرجع مشتری بگیرید» همیشه شدنی نیست؛ بعضی قراردادها محرمانه‌اند. در این حالت جایگزین بخواهید: یک دموی زنده روی نسخهٔ واقعی، یا بازبینی بخشی از کد نمونه با رضایت مشتری قبلی. هدف همان است، یعنی ادعا بتواند چک شود. اگر هیچ‌کدام ممکن نبود، همان معیار امتیاز صفر می‌گیرد.

موضع ما را یک بار دیگر ساده می‌گوییم: ادعای قابل‌راستی‌آزمایی بر ادعای پرطمطراق مقدم است، هر قدر هم اولی ساده‌تر به نظر برسد.

اگر شرکتی همهٔ تخصص‌ها را ندارد، یا پروژه اصلاً نیاز به شرکت ندارد، چه؟

دو پرسش بعدیِ معمول خواننده این‌جاست: آیا تیمی که همهٔ تخصص‌ها را ندارد مشکل دارد، و آیا اصلاً باید پروژهٔ اختصاصی بسازید.

شریک و پیمانکار فرعی: چه زمانی مشکل نیست

معیار درست «همه‌چیز داخل تیم» نیست، «شفافیت و مسئولیت» است. اگر شرکت بخشی از کار را به شریک می‌سپارد، بپرسید چه کسی پاسخ‌گوی کل پروژه است، قراردادش با شما چگونه است، و اگر شریک کار را رها کند چه تضمینی وجود دارد. اگر این پاسخ‌ها روشن بود، ساختار شریک‌محور ایرادی ندارد. اگر نبود، حتی تیم تماماً داخلی هم تضمین نیست.

توسعهٔ اختصاصی یا راه‌حل آماده (SaaS)؟

چهار سؤال انتخاب را روشن می‌کند. فرایند کسب‌وکار شما چقدر با ابزار آماده فرق دارد؟ هزینهٔ مالکیت در طول زمان (نگهداری، به‌روزرسانی، پشتیبانی) برای هر گزینه چقدر است؟ وابستگی به فروشنده را چقدر می‌پذیرید؟ و آیا سیستم باید با ابزارهای دیگرتان یکپارچه شود؟ اگر فرایند شما استاندارد است و یکپارچگی ساده است، راه‌حل آماده منطقی‌تر است. اگر فرایندتان مزیت رقابتی شماست، ساخت اختصاصی را بسنجید.

وقتی نیاز شما در حوزهٔ خاصی است (موبایل، هوش مصنوعی، فروشگاه اینترنتی)، به صفحه‌های دقیق‌تر دایرکتوری سر بزنید. برای مطالعهٔ بیشتر هم می‌توانید مقاله‌های برنامه‌نویسی و توسعهٔ نرم‌افزار را دنبال کنید.

چک‌لیست قابل‌کپی و کاری که فردا صبح باید انجام دهید

چک‌لیست جمع‌بندی قبل از امضا

این فهرست را در سند خودتان کپی کنید و برای هر شرکت جدا پر کنید. موردی که تیک نخورده، یعنی هنوز مدرک ندیده‌اید.

• [ ] سند نیازمندی‌ها یا RFP کوتاه نوشته شده و به همهٔ شرکت‌ها داده شده است.
• [ ] شرکت پیش از پیشنهاد سؤال پرسیده و برداشتش از نیاز را مکتوب داده است.
• [ ] دست‌کم یک نمونهٔ مرتبط را دیده‌ام و با مرجع مشتری (یا جایگزین آن) صحبت کرده‌ام.
• [ ] دلیل انتخاب فناوری مکتوب و قانع‌کننده است.
• [ ] افراد تیم اجرا با نام و نقش معرفی شده‌اند و مسئول فنی و مدیر پروژه معلوم است.
• [ ] ریتم جلسه‌ها، ابزار پیگیری و گزارش دوره‌ای تعریف شده و به محیط آزمایشی دسترسی دارم.
• [ ] پروتوتایپ یا فرایند طراحی را دیده‌ام.
• [ ] فرایند تست، بازبینی کد، رویکرد امنیتی و تست پذیرش مکتوب است.
• [ ] پیشنهاد مالی تفکیک‌شده است و فرایند درخواست تغییر دارد.
• [ ] مالکیت کد، دسترسی به مخزن، مستندات، دامنه، سرور و حساب‌های شخص ثالث روشن است.
• [ ] شرایط ضمانت، SLA، پشتیبانی و هزینهٔ توسعهٔ بعدی روشن است.
• [ ] متن قرارداد را یک حقوقدان بررسی کرده است.

سه کار برای فردا

1. یادداشت یک‌صفحه‌ای نیاز را بنویسید: مسئله، کاربران، محدودیت‌ها و معیار موفقیت.
2. وزن ده معیار را در جدول بنویسید، پیش از آنکه پیشنهادی ببینید.
3. از هر شرکت فهرست مدارک بخواهید: نمونهٔ قابل‌بررسی، مرجع، تیم اجرا، گزارش نمونه و شرایط تحویل.

تصمیم نهایی دست شماست، با یک قاعده: فقط شرکت‌هایی که مدرک نشان دادند وارد مرحلهٔ قرارداد شوند. بقیه، هر قدر هم قیمت یا سابقه‌شان جذاب باشد، هنوز ادعا هستند.