برونسپاری توسعه نرمافزار یعنی چه و چه زمانی منطقی است؟
در برونسپاری، طراحی و ساخت نرمافزار را یک تیم بیرونی انجام می‌دهد؛ اما تصمیم درباره اینکه چه چیزی ساخته شود و چرا، همچنان با شماست.
برون سپاری پروژه نرم افزاری معمولاً در این موقعیت‌ها انتخاب درستی است: نرمافزار، کسبوکار اصلی شما نیست و فقط ابزار آن است؛ استخدام و نگهداری یک تیم کامل فنی برای شما صرفه ندارد؛ یا باید در چند ماه نسخه اول را به دست مشتری برسانید و وقت ساختن تیم ندارید.
در مقابل، اگر محصول نرمافزاری قلب کسبوکار شماست و قرار است سال‌ها هر هفته تغییر کند، بهتر است به‌مرور دانش فنی را داخل سازمان بیاورید. حتی در این حالت هم شروع کار با یک شریک فنی و طراحی و توسعه نرمافزار سفارشی می‌تواند مسیر را کوتاه‌تر کند، به شرطی که کد و مستندات از ابتدا در اختیار خودتان باشد.
تیم داخلی، فریلنسر یا شرکت برنامه نویسی؟
هیچ‌کدام از این سه گزینه همیشه بهتر نیست. انتخاب درست به اندازه پروژه، مدت نیاز و میزان دانش فنی خود شما بستگی دارد. جدول زیر تفاوت‌های اصلی را کنار هم می‌گذارد.
| معیار | تیم داخلی | فریلنسر | شرکت نرمافزاری |
|---|---|---|---|
| مناسب برای | محصولی که هسته کسبوکار است و دائم توسعه می‌یابد | کارهای کوچک و مشخص با یک تخصص | پروژه‌های چندتخصصی با زمان‌بندی مشخص |
| پوشش تخصص‌ها | به تعداد افرادی که استخدام می‌کنید | معمولاً یک تخصص | تحلیل، طراحی، برنامه‌نویسی، تست و استقرار |
| وابستگی به یک فرد | متوسط | زیاد | کمتر؛ دانش در تیم پخش است |
| نیاز به مدیریت فنی از سمت شما | زیاد | زیاد | کمتر، اگر فرایند شرکت شفاف باشد |
انتخاب شرکت نرم افزاری؛ چهار چیزی که باید بسنجید
برای انتخاب شرکت نرم افزاری لازم نیست برنامه‌نویسی بلد باشید. کافی است چهار موضوع زیر را با سؤال‌های ساده بررسی کنید.
۱. نمونه‌کار واقعی و قابل بررسی
از شرکت بخواهید محصولی را نشان دهد که الان در حال استفاده است، نه فقط تصویر طراحی. شباهت نمونه‌کار به پروژه شما از تعداد نمونه‌ها مهم‌تر است.
۲. فرایند کار
بپرسید قبل از کدنویسی چه اتفاقی می‌افتد. تیمی که بدون تحلیل نیاز، مستقیم قیمت و زمان می‌دهد، در عمل ریسک را به آینده منتقل کرده است. در تکنوراه کار با فاز صفر «تشخیص و هم‌راستاسازی» شروع میشود؛ یعنی جداکردن نیاز واقعی از نیاز کاذب، تعیین محدوده و نوشتن مستند نیازمندی.
۳. شفافیت در طول پروژه
باید بدانید هر چند وقت یک‌بار خروجی قابل دیدن تحویل می‌گیرید و پیشرفت را کجا می‌بینید. گزارش شفاهی «هفتاد درصد کار انجام شده» کافی نیست؛ نسخه قابل تست معیار است.
۴. مالکیت کد و دسترسی‌ها
بپرسید کد منبع و دسترسی سرور از چه زمانی در اختیار شماست. پاسخ قابل قبول «از روز اول» است، نه «بعد از تسویه نهایی». این اصل یکی از ارزش‌های ماست که در صفحه درباره تکنوراه و شیوه همکاری ما توضیح داده‌ایم.
مدل‌های قرارداد توسعه نرم افزار
سه مدل رایج برای قرارداد وجود دارد. مدل مناسب به این بستگی دارد که محدوده کار چقدر روشن است و چقدر احتمال تغییر دارد.
| مدل | چطور کار میکند | مناسب چه زمانی | ریسک اصلی |
|---|---|---|---|
| پروژه‌ای با محدوده ثابت | محدوده، زمان و مبلغ از ابتدا مشخص و قفل میشود | نیازها روشن و مکتوب است | هر تغییر بعدی نیازمند توافق و هزینه جداگانه است |
| ماهانه (ریتینر) | ظرفیت مشخصی از تیم در هر ماه در اختیار شماست | محصول در حال کار که توسعه و نگهداری مداوم می‌خواهد | بدون اولویت‌بندی روشن، ظرفیت ماه هدر می‌رود |
| اسپرینت‌محور | کار در دوره‌های کوتاه (معمولاً دو هفته‌ای) برنامه‌ریزی و تحویل میشود | محصول نو که مسیرش با بازخورد کاربر اصلاح میشود | بودجه کل از ابتدا قطعی نیست و باید سقف تعیین کنید |
چه چیزهایی باید در قرارداد نوشته شود؟
قرارداد خوب، قراردادی است که در روز اختلاف بتوان به آن رجوع کرد. شش بند زیر را حتماً در متن یا پیوست قرارداد ببینید.
- محدوده کار: فهرست امکانات باید به‌صورت پیوست مکتوب باشد، نه در حد «یک اپلیکیشن فروشگاهی». ابزار این کار مستند نیازمندی است که در راهنمای نوشتن مستند نیازمندی (PRD) قدم‌به‌قدم توضیح داده‌ایم.
- معیار پذیرش: برای هر امکان مشخص باشد چه زمانی «تحویل‌شده» حساب میشود. مقاله معیار پذیرش چیست نمونه‌های آماده دارد.
- مراحل تحویل و پرداخت مرحله‌ای: هر پرداخت به یک خروجی قابل تست گره بخورد، نه به گذشت زمان.
- مالکیت کد منبع: صریح نوشته شود که کد، طراحی‌ها و داده‌ها متعلق به شماست و دسترسی مخزن کد و سرور به نام شما ثبت میشود.
- دوره پشتیبانی: مدت، نوع خطاهایی که رایگان رفع میشود و زمان پاسخ‌گویی روشن باشد. ما پس از تحویل، ۶ ماه پشتیبانی اولیه ارائه میکنیم.
- محرمانگی: ایده، داده مشتریان و اطلاعات تجاری شما نباید بدون اجازه جایی استفاده یا منتشر شود.
یک بند دیگر هم ارزش اضافه‌کردن دارد: روال تغییر. مشخص کنید اگر وسط کار امکان تازه‌ای خواستید، چطور برآورد، تأیید و به برنامه اضافه میشود. نبود این بند دلیل اصلی خزش محدوده پروژه (Scope Creep) است. برای متن حقوقی نهایی هم بهتر است از یک مشاور حقوقی کمک بگیرید.
نشانه‌های هشدار هنگام برون سپاری پروژه نرم افزاری
اگر در جلسه‌های اولیه یکی از موارد زیر را دیدید، قبل از ادامه توضیح بخواهید.
- بدون پرسیدن درباره کسبوکار و کاربران شما، در همان جلسه اول قیمت و زمان قطعی می‌دهند.
- به هر درخواستی «بله» می‌گویند و هیچ امکانی را زیر سؤال نمی‌برند.
- بخش بزرگی از مبلغ را پیش از تحویل هر خروجی قابل تست میخواهند.
- تحویل کد منبع یا دسترسی سرور را به پایان پروژه یا شرایط مبهم موکول می‌کنند.
- درباره تست، مستندسازی و نگهداری پس از تحویل پاسخ روشنی ندارند.
چک‌لیست قبل از امضای قرارداد
این فهرست را قبل از امضا مرور کنید. اگر پاسخ یکی از موارد «نه» بود، همان مورد را پیش از شروع حل کنید.
- فهرست امکانات نسخه اول مکتوب و پیوست قرارداد است.
- برای امکانات اصلی معیار پذیرش نوشته شده است.
- مراحل تحویل، تاریخ‌ها و مبلغ هر مرحله مشخص است.
- مالکیت کد منبع و دسترسی‌ها به نام من ثبت میشود.
- روال درخواست تغییر و هزینه آن روشن است.
- مدت و شرایط پشتیبانی پس از تحویل نوشته شده است.
- می‌دانم هزینه نگهداری سالانه حدوداً چقدر خواهد بود؛ این عدد معمولاً ۱۵ تا ۲۰ درصد هزینه ساخت اولیه است.
اگر دانش فنی ندارید، چه کسی کار را ارزیابی کند؟
معیارهای بالا عمداً غیرفنی‌اند: نسخه قابل تست، معیار پذیرش مکتوب و دسترسی کامل به کد. اگر بیش از این می‌خواهید، یک فرد فنی مستقل می‌تواند پیشنهادها را بررسی و تحویل‌ها را کنترل کند. اگر مدیر فنی تمام‌وقت ندارید، خدمت مدیر فنی پاره‌وقت (CTO as a Service) برای همین موقعیت طراحی شده است.
قدم بعدی
اگر در حال بررسی برونسپاری هستید، از یک گفت‌وگوی کوتاه شروع کنید. در جلسه مشاوره رایگان ۱۵ دقیقه‌ای، نیاز شما را می‌شنویم و صادقانه می‌گوییم برونسپاری برای شما مناسب است یا نه و کار از کجا باید شروع شود.
جزئیات مدل همکاری چهارفازی، از تشخیص نیاز تا استقرار و رشد، در صفحه خدمات توسعه نرمافزار سفارشی تکنوراه آمده است. برای هماهنگی جلسه می‌توانید با شماره ۰۹۲۱۰۳۲۷۴۰۷ هم تماس بگیرید.
سوالات متداول
برونسپاری توسعه نرمافزار برای چه کسبوکارهایی مناسب است؟
برای کسبوکارهایی که نرمافزار ابزار کارشان است نه محصول اصلی، تیم فنی داخلی ندارند یا میخواهند نسخه اول را سریع به بازار برسانند. اگر محصول نرمافزاری هسته کسبوکار شماست و دائم تغییر میکند، بهتر است در کنار برونسپاری، بهتدریج دانش فنی را هم داخل سازمان بسازید.
مالکیت کد منبع در پروژه برونسپاری با کیست؟
این موضوع به متن قرارداد بستگی دارد و باید صریح نوشته شود. توصیه ما این است که کد منبع، طراحی‌ها و داده‌ها متعلق به کارفرما باشد و دسترسی مخزن کد و سرور از روز اول به نام او ثبت شود. در تکنوراه همین روال اجرا میشود تا هیچ بخشی از پروژه برای شما جعبه سیاه نباشد.
قرارداد با محدوده ثابت بهتر است یا اسپرینت‌محور؟
اگر نیازها روشن و مکتوب است و انتظار تغییر زیادی ندارید، محدوده ثابت پیش‌بینی‌پذیرتر است. اگر محصول تازه‌ای می‌سازید که مسیرش با بازخورد کاربران عوض میشود، مدل اسپرینت‌محور انعطاف بیشتری می‌دهد. در مدل دوم حتماً سقف بودجه و نقطه‌های بازبینی مشخص کنید تا هزینه از کنترل خارج نشود.
هزینه برونسپاری پروژه نرمافزاری چطور برآورد میشود؟
هزینه به تعداد و پیچیدگی امکانات، تعداد پلتفرمها، سطح طراحی، اتصال به سیستمهای دیگر و نیازهای امنیتی بستگی دارد. بدون محدوده مکتوب، هر عددی حدس است. پیشنهاد میکنیم ابتدا فهرست امکانات نسخه اول را بنویسید و بعد در جلسه مشاوره رایگان، برآورد را بر اساس همان فهرست بگیرید.