تیم داخلی، فریلنسر یا استودیو؟ ماتریس تصمیم برای ساخت محصول دیجیتال

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

سه پرسشی که پیش از هر مقایسه باید جواب بدهید

1. اهمیت و افق محصول: اگر محصول هستهٔ کسب‌وکار است و سال‌ها تغییر می‌کند، با ابزار جانبی یا سایت معرفی که یک‌بار ساخته می‌شود فرق دارد.
2. ظرفیت نگه‌داری: رفع اشکال، به‌روزرسانی، پایش و تغییرات کوچک بعد از انتشار با کیست؟ اگر جواب «نمی‌دانیم» است، همین نکته باید قبل از انتخاب مجری روشن شود.
3. مالکیت دانش محصول: چه کسی می‌داند چرا هر تصمیم گرفته شد؟ اگر این دانش فقط در ذهن یک نفر بیرون از سازمان باشد، با خروج او دچار ریسک جدی می‌شوید.

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

ماتریس تصمیم: هر مدل کجا خوب است و کجا ریسک دارد؟

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

چیزهایی که در هر سه مدل ثابت می‌ماند

تصمیم‌گیرندهٔ محصول باید سمت شما باشد

راهنمای Scrum Product Owner را مسئول بیشینه‌کردن ارزش محصولی می‌داند که از کار تیم حاصل می‌شود، و تیم‌های Scrum را cross-functional معرفی می‌کند، یعنی اعضا مهارت‌های لازم برای ساخت ارزش را دارند. این‌ها توصیف یک چارچوب کاری‌اند، نه قانون خرید؛ اما یک نتیجهٔ عملی دارند: حتی اگر ساخت را بیرون بسپارید، کسی از سمت کسب‌وکار باید اولویت‌ها را تعیین و تصمیم‌ها را تأیید کند. اگر این نقش خالی بماند، مجری ناچار حدس می‌زند.

ریسک وابستگی به یک فرد را اندازه بگیرید

کتاب «Software Engineering at Google» ضریب اتوبوس (bus factor) را تعداد افرادی تعریف می‌کند که اگر از دسترس خارج شوند پروژه عملاً فلج می‌شود. فصل «How to Work Well on Teams» می‌گوید داشتن مستندات خوب، به‌علاوهٔ یک مالک اصلی و یک مالک پشتیبان برای هر حوزهٔ مسئولیت، این ضریب را بالا می‌برد. فصل «Knowledge Sharing» هم نشان می‌دهد نقطهٔ شکست واحد (SPOF) می‌تواند از نیت خوب بیاید: «بگذار من این را برایت انجام بدهم» در کوتاه‌مدت سریع‌تر است ولی تیم هرگز یاد نمی‌گیرد آن کار چگونه انجام می‌شود. معنای عملی برای شما: مهم نیست مجری کدام مدل است؛ بپرسید «اگر او فردا نباشد، چه کسی و با چه مستنداتی ادامه می‌دهد؟»

الزامات فنی و امنیتی را از اول بنویسید

NIST در راهنمای SSDF (نسخهٔ ۱٫۱، فوریهٔ ۲۰۲۲) می‌گوید چون چارچوب یک زبان مشترک برای توسعهٔ امن نرم‌افزار می‌دهد، خریداران نرم‌افزار هم می‌توانند از آن برای گفت‌وگو با تأمین‌کنندگان استفاده کنند و سازمان‌ها باید الزامات توسعهٔ امن را با همان قراردادهای SSDF به تأمین‌کنندگان بیرونی بگویند. این سند برای سازمان‌ها نوشته شده و نیازی نیست پروژهٔ کوچک شما همهٔ آن را اجرا کند؛ اما ایدهٔ آن مفید است: اینکه مجری چه شیوه‌هایی برای کد امن، وابستگی‌ها و انتشار دارد را بپرسید و بخواهید مکتوب شود، چه با فریلنسر طرف باشید و چه با شرکت.

الگوی ترکیبی: ساخت بیرونی، نگه‌داری داخلی

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

• مخزن کد و حساب‌های زیرساخت از روز اول به نام شما باشد.
• مستند راه‌اندازی دوباره (runbook) و فهرست تصمیم‌های مهم معماری تحویل داده شود.
• دست‌کم یک نفر از سمت شما در جلسه‌های فنی و بازبینی کد حاضر باشد.
• جلسهٔ انتقال دانش و یک دورهٔ هم‌پوشانی مشخص (مثلاً چند هفته) در قرارداد بیاید.
• قبل از اتمام قرارداد، یک نفر داخلی بدون کمک مجری نسخه را روی محیط آزمایشی بالا بیاورد.

سه سناریوی فرضی

این‌ها مثال‌های ساختگی برای تمرین‌اند، نه کیس واقعی.

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

اشتباه‌های رایج هنگام انتخاب

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

چک‌لیست تصمیم

1. اهمیت و افق محصول را در یک جمله نوشته‌ام.
2. مشخص است بعد از تحویل چه کسی نگه‌داری می‌کند.
3. یک تصمیم‌گیرندهٔ محصول از سمت ما تعیین شده است.
4. اگر مجری فردا از دسترس خارج شود، مستندات و مالک پشتیبانی داریم.
5. مخزن و حساب‌ها به نام ما هستند.
6. الزامات فنی و امنیتی مکتوب شده‌اند.
7. برنامهٔ انتقال دانش در صورت مدل ترکیبی روشن است.

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

منابع و مراجع

• How to Work Well on Teams — Brian Fitzpatrick، فصل ۲ کتاب Software Engineering at Google (نسخهٔ وب).
• Knowledge Sharing — Nina Chen و Mark Barolak، فصل ۳ کتاب Software Engineering at Google (نسخهٔ وب).
• The Scrum Guide — Ken Schwaber و Jeff Sutherland، نسخهٔ نوامبر ۲۰۲۰.
• Secure Software Development Framework (SSDF) Version 1.1 (NIST SP 800-218) — NIST، فوریهٔ ۲۰۲۲.