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