پیش از انتخاب پیمانکار نرم‌افزار چه سؤال‌های فنی بپرسیم؟

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

چرا باید پرسش مکتوب و شاهددار باشد؟

هدف سؤال، فریب‌دادن پیمانکار نیست؛ هدف این است که پاسخ‌ها قابل‌مقایسه و قابل‌راستی‌آزمایی باشند. برای هر پرسش از پیمانکار بخواهید پاسخ را با یک شاهد نشان دهد: نمونهٔ مخزن، سند، گزارش یا ارائهٔ زنده.

هشت دسته پرسش

برای پرسش دربارهٔ تیم، آیا یک نفر می‌تواند تمام نقش‌های یک تیم نرم‌افزاری را انجام دهد؟ و نقش‌های پروژهٔ نرم‌افزاری زمینهٔ خوبی می‌دهند.

مالکیت و دسترسی به کد

در چارچوب NIST SSDF (نسخهٔ ۱٫۱، فوریهٔ ۲۰۲۲) تسک PS.1.1 توصیه می‌کند همهٔ اشکال کد، یعنی کد منبع، کد اجرایی و پیکربندی به‌صورت کد، در یک مخزن نگه‌داری شود و دسترسی بر پایهٔ حداقل امتیاز به کارکنان، ابزارها و سرویس‌های مجاز محدود شود. تسک PS.3.1 هم می‌گوید فایل‌ها و داده‌های پشتیبان هر نسخهٔ منتشرشده (مثل اطلاعات صحت‌سنجی و provenance) به‌صورت امن بایگانی شود. این‌ها توصیهٔ سازمانی دربارهٔ توسعه‌دهنده‌اند، نه شرط قانونی؛ ولی سؤال خوبی می‌سازند: مخزن کجاست، چه کسی دسترسی دارد، و نسخهٔ تحویلی چطور حفظ می‌شود؟ OWASP نیز در سند نمونهٔ قرارداد امنیتی پیشنهاد می‌کند از سیستم کنترل نسخه‌ای استفاده شود که اعضای تیم مرتبط با هر تغییر را احراز و ثبت می‌کند؛ این سند خودش را راهنما می‌خواند و توصیه می‌کند حتماً با وکیل مشورت شود.

وابستگی‌ها و امنیت

NIST در تسک PW.4.1 می‌گوید اجزای سومشخص، تجاری یا متن‌باز، قبل از استفاده بازبینی و ارزیابی شوند. سند OWASP هم در بند ۷ می‌خواهد توسعه‌دهنده همهٔ نرم‌افزارهای شخص ثالث، چه تجاری، رایگان، متن‌باز یا بسته، افشا کند. پیشنهاد عملی ما: فهرست وابستگی‌ها را به‌عنوان تحویل‌دادنی بخواهید و مجوز هر کدام را با وکیل بسنجید.

کیفیت و تحویل

Scrum Guide، Definition of Done را توصیف رسمی وضعیت یک Increment می‌داند و می‌گوید کاری که به آن نرسد جزو Increment نیست. اگر پیمانکار چنین تعریف مکتوبی ندارد، ببینید در عمل بازبینی کد و آزمون را چطور انجام می‌دهد. معیار پذیرش را پیش از امضا مکتوب کنید.

شواهد نمونه‌کار: چه چیزی را بخواهید و چه چیزی را راستی‌آزمایی کنید؟

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

نشانه‌های هشدار (قضاوت نویسنده)

• پاسخ‌های کلی بدون شاهد («همه‌چیز امن است»).
• نداشتن مخزن مستقل از حساب شخصی یک نفر.
• اصرار بر اینکه فهرست وابستگی‌ها یا مستندات «لازم نیست».
• عدم‌تمایل به تعریف مکتوب «انجام‌شده».
• مبهم‌بودن اینکه پس از تحویل چه کسی پاسخ‌گو است.

چطور از پاسخ‌ها استفاده کنیم؟

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

منابع و مراجع

• Secure Software Development Framework (SSDF) Version 1.1 (NIST SP 800-218) — NIST، فوریه ۲۰۲۲.
• Secure Software Contract Annex — OWASP Foundation (Jeff Williams).
• The Scrum Guide — Ken Schwaber و Jeff Sutherland، نسخهٔ نوامبر ۲۰۲۰.