مدلهای برونسپاری توسعه نرمافزار
وقتی تصمیم میگیرید توسعهٔ نرمافزار را به بیرون بسپارید، سؤال بعدی «به چه کسی» نیست. «با چه مدلی» است.
انتخاب مدل غلط، حتی با پیمانکار خوب، به پروژهای ختم میشود که هیچکس از آن راضی نیست — چون انتظار طرفین از روز اول با ساختار قرارداد نمیخوانده.
سه مدل، و آنچه واقعاً تفاوتشان است
تفاوت اصلی در قیمت نیست. در این است که چه کسی ریسک را برمیدارد و چه کسی تصمیم میگیرد.
پروژهای با دامنهٔ مشخص
شما میگویید چه میخواهید، پیمانکار میگوید چقدر و چهمدت، و مسئول رساندن همان است.
ریسک با پیمانکار است. اگر بیشتر طول بکشد، هزینهاش را او میدهد.
مناسب: سامانهای با مرز روشن که قبلاً نمونهاش را دیدهاید — فروشگاه اینترنتی، پنل ادمین، اپلیکیشن با دامنهٔ معلوم. یا وقتی سازمان شما تیم فنی ندارد که بتواند روزانه هدایت کند.
نامناسب: وقتی خودتان هم دقیقاً نمیدانید چه میخواهید. آنگاه پیمانکار برای پوشش ریسک، حاشیهٔ بزرگ میگذارد و شما بابت عدمقطعیت خودتان پول میدهید — و هر تغییری تبدیل به مذاکره میشود، با همان الگویی که در تغییر دامنه گفتیم.
تیم اختصاصی
تیمی ثابت که تماموقت روی کار شما کار میکند، معمولاً ماهانه. اولویتها را شما تعیین میکنید.
ریسک تقسیم میشود. پیمانکار مسئول کیفیت و ترکیب تیم است؛ شما مسئول اینکه تیم روی چیز درستی کار کند.
مناسب: محصولی که ادامه دارد و تکامل مییابد، جایی که اولویتها هر ماه عوض میشوند، و وقتی نمیخواهید هر تغییر یک مذاکرهٔ جدید باشد. برای بیشتر محصولات نرمافزاری که «تمام نمیشوند» این مدل درست است. تفصیلش در راهنمای تیم اختصاصی.
نامناسب: اگر کسی از سمت شما نمیتواند هفتگی اولویت بدهد. تیم اختصاصی بدون مالک محصول فعال، تیمی است که حدس میزند.
نیروی افزوده
یک یا چند نفر به تیم موجود شما اضافه میشوند و زیر مدیریت خودتان کار میکنند.
ریسک تقریباً کامل با شماست. پیمانکار آدم میدهد، مدیریت با شماست.
مناسب: وقتی تیم فنی توانمندی دارید و فقط ظرفیت کم دارید، یا مهارت خاصی موقتاً لازم است.
نامناسب: وقتی تیم داخلی ندارید. آدمهای خوب بدون هدایت، خروجی خوبی نمیدهند و این را نباید به حساب تواناییشان گذاشت.
جدول تصمیم
| پروژهای | تیم اختصاصی | نیروی افزوده | |
|---|---|---|---|
| دامنه | ثابت | متغیر | متغیر |
| ریسک زمان | پیمانکار | مشترک | کارفرما |
| تصمیم روزانه | پیمانکار | مشترک | کارفرما |
| نیاز به تیم داخلی | کم | متوسط | زیاد |
| هزینهٔ تغییر | زیاد | کم | کم |
| مناسب برای | سامانهٔ با مرز روشن | محصول در حال تکامل | کمبود ظرفیت |
قرارداد متناسب هر مدل
قیمت ثابت فقط با دامنهٔ واقعاً روشن معنی دارد. اگر دامنه مبهم باشد و اصرار بر قیمت ثابت کنید، یکی از این دو اتفاق میافتد: یا عدد بالا میگیرید، یا پیمانکار در پایان از کیفیت میزند تا به عدد برسد. هیچکدام به نفع شما نیست.
زمان و مواد برای کار با دامنهٔ باز طبیعی است و بدون شفافیت، اعتمادسوز. اگر این را انتخاب میکنید، گزارش هفتگی قابل بررسی بخواهید.
سقف تضمینی — پرداخت بر اساس کار انجامشده با سقف مشخص — در عمل برای بیشتر پروژههای سازمانی متعادلترین است. ریسک را تقسیم میکند بدون اینکه تغییر را غیرممکن کند.
ماهانه (برای تیم اختصاصی) سادهترین و شفافترین است، به شرطی که ترکیب تیم و نرخ هر نقش در قرارداد بیاید.
بندهایی که نبودشان گران تمام میشود
فهرستی که از پروژههای واقعی درآمده — هر بند اینجاست چون جایی نبودش هزینه ساخته:
مالکیت کد و داراییها، صریح. کد، دامنه، حساب سرویسها، حساب فروشگاههای اپلیکیشن، مخزن. تعداد سازمانهایی که تازه در لحظهٔ اختلاف میفهمند مالک دامنهٔ خودشان نیستند کم نیست.
تحویل مرحلهای، نه یکجا. پرداختها به تحویلهای قابل بررسی گره بخورند. اگر اولین چیزی که میبینید در ماه ششم است، پنج ماه ریسک انباشتهاید.
دسترسی مستمر به مخزن کد، از روز اول. نه در پایان پروژه. اگر پیمانکاری با این مخالفت کند، همانجا بحث را جدی بگیرید.
تعریف اتمام، تا «تحویل شد» معنای مشترکی داشته باشد.
دورهٔ گارانتی و سپس پشتیبانی، با تفکیک روشن بین رفع باگ (گارانتی) و قابلیت جدید (پشتیبانی یا قرارداد تازه). جزئیاتش در SLA.
شرط خروج و انتقال. اگر همکاری تمام شود، چه چیزی تحویل میشود و در چه مدت؟ بندی که همه امیدوارند لازم نشود و وقتی لازم شود، تنها چیزی است که اهمیت دارد.
محرمانگی و محل نگهداری داده. بهویژه اگر دادهٔ مشتریان یا اطلاعات مالی در میان است.
هزینهٔ واقعی برونسپاری
عددی که در قرارداد است، کل هزینه نیست. اینها هم هست:
- وقت خودتان. تیم برونسپاریشده به هدایت نیاز دارد. اگر کسی از سمت شما هفتهای چند ساعت نگذارد، نتیجه از دستتان درمیرود.
- انتقال دانش، در ابتدا و در انتها.
- بازبینی کیفیت. اگر توان فنی ارزیابی ندارید، کیفیت را در تحویل نمیبینید؛ در سال دوم میبینید.
- وابستگی. هرچه دانش بیشتری فقط دست پیمانکار باشد، قدرت چانهزنی شما کمتر است. راه کاهشش، همان بند دسترسی مستمر به کد و مستندسازی است.
و مدل ترکیبی، که اغلب درستترین است
در عمل، بیشتر سازمانهای موفقی که دیدهایم یک ترکیب دارند: هستهٔ فنی داخلی کوچک — یک یا دو نفر که سامانه را عمیق میشناسند و تصمیم میگیرند — بهعلاوهٔ ظرفیت بیرونی برای ساخت.
این ترکیب دو مسئله را همزمان حل میکند: دانش سازمانی داخل میماند، و ظرفیت بدون هزینهٔ ثابت استخدام بالا و پایین میشود.
اگر امروز هیچ تیم داخلی ندارید، شروع با یک نفر — کسی که مالک فنی از سمت شما باشد — بیشترین بازده را در کل این تصمیم دارد. بحث اینکه این نفر را استخدام کنید یا از فریلنسر استفاده کنید، در شرکت یا فریلنسر آمده.