پیش از انتخاب پیمانکار نرم‌افزار چه سؤال‌های فنی بپرسیم؟
5 min read
بانک پرسش‌های فنی برای مصاحبه با پیمانکار نرم‌افزار، با نشانهٔ پاسخ خوب و هشدار در هشت حوزه: مالکیت کد، تحویل، کیفیت، امنیت، وابستگی‌ها و دانش.
رزومه و نمونه‌کار می‌گویند یک تیم چه ساخته؛ پرسش‌های فنی نشان می‌دهند چگونه می‌سازد و بعد از تحویل چه چیزی دست شما می‌ماند. این بانک پرسش برای مصاحبه یا پاسخ مکتوب پیمانکار است. مقایسهٔ قیمت و محدودهٔ پیشنهادها موضوع ارزیابی پروژهٔ نرم‌افزاری است و اینجا فقط به پرسش‌های فنی می‌پردازیم. جملات آمادهٔ حقوقی هم نمی‌دهیم؛ بندهای قرارداد را با وکیل نهایی کنید.
چرا باید پرسش مکتوب و شاهددار باشد؟
هدف سؤال، فریب‌دادن پیمانکار نیست؛ هدف این است که پاسخ‌ها قابل‌مقایسه و قابل‌راستی‌آزمایی باشند. برای هر پرسش از پیمانکار بخواهید پاسخ را با یک شاهد نشان دهد: نمونهٔ مخزن، سند، گزارش یا ارائهٔ زنده.
هشت دسته پرسش
| حوزه | پرسش | پاسخ خوب چه شکلی است؟ |
|---|---|---|
| مالکیت کد | کد در چه مخزنی و با مالکیت چه کسی نگه‌داری می‌شود؟ | مخزن زیر حساب شما یا با انتقال مشخص؛ دسترسی مدیر برای شما |
| تحویل | در پایان هر مرحله دقیقاً چه چیزی تحویل می‌دهید؟ | فهرست تحویل‌دادنی همراه شاهد، نه فقط «نسخهٔ جدید» |
| تیم | چه کسی دقیقاً روی پروژهٔ من کار می‌کند و نقش هر نفر چیست؟ | نام‌ها یا نقش‌ها و درصد زمان مشخص؛ جانشین در صورت خروج |
| کیفیت | «انجام‌شده» یعنی چه؟ | یک Definition of Done مکتوب شامل بازبینی کد و آزمون |
| امنیت | اسرار، دسترسی‌ها و ورودی کاربر را چطور مدیریت می‌کنید؟ | جدا بودن محیط‌ها، رازها خارج از کد، توضیح مشخص نه کلی |
| وابستگی‌ها | از چه کتابخانه‌ها و سرویس‌های بیرونی استفاده می‌کنید؟ | فهرست مکتوب با نسخه و نوع مجوز |
| دانش | چطور دانش پروژه به ما منتقل می‌شود؟ | مستندات، جلسهٔ تحویل و اجرای نصب توسط فردی غیر از سازنده |
| پشتیبانی | بعد از تحویل چه چیزی شامل می‌شود و چه چیزی جدا برآورد می‌شود؟ | جدول دامنهٔ پشتیبانی با زمان و روش درخواست |
برای پرسش دربارهٔ تیم، آیا یک نفر می‌تواند تمام نقش‌های یک تیم نرم‌افزاری را انجام دهد؟ و نقش‌های پروژهٔ نرم‌افزاری زمینهٔ خوبی می‌دهند.
مالکیت و دسترسی به کد
در چارچوب 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، نسخهٔ نوامبر ۲۰۲۰.
Author
SE
Soheil Ebrahimpour is the founder of FutureForge. He works on product design, architecture, and getting custom software into production.
Related notes
If you are unsure about architecture or the build path, we can talk about the project.
Describe the problem and the constraints. If there is a fit, we will schedule a conversation.
