1. Симуляція витрат на вихід
Потонулі витрати затуманюють судження керівників.
Порівняйте втрату при зупинці проєкту за традиційним fixed-bid контрактом проти гнучкої моделі DaaS/Staff Augmentation.
Порівняння накопичених витрат
Перемістіть повзунок, щоб змінити місяць, коли вирішуєте вийти (скасувати).
Традиційний ризик (fixed-bid)
Часто застосовуються штрафи за розірвання та зобов'язання викупу проміжних поставок, що максимізує експозицію до потонулих витрат.
Ризик DaaS (гнучкий контракт)
Ви платите лише за виконану роботу. Оскільки ви можете зупинитися будь-коли, можете вийти до того, як шкода зросте.
Можливість скасувати будь-коли мотивує постачальника підтримувати високу якість.
2. Анатомія vendor lock-in та "прозорості"
Страх lock-in виникає через те, що не видно, що всередині.
Порівняйте елементи, які запобігають чорній скриньці та відновлюють автономний контроль.
Розробка black-box
Детальна специфікація живе лише в голові постачальника
-
✕
Нечітке право власності на код
Кастомні framework-и та бібліотеки ускладнюють передачу іншій команді.
-
✕
Відсутня документація
Ви отримуєте працюючий продукт, але не "чому" за ним.
-
✕
Залежність від людей
Якщо ключова людина йде, система може зупинитися.
White-box розробка
Тримайте систему готовою до передачі будь-коли
-
✓
Вибір стандартної технології
Обирайте широко поширені мови та framework-и, щоб зберегти опції заміни.
-
✓
Завжди спільно в GitHub тощо
Робіть щоденні commit-и в репозиторій клієнта, щоб прогрес і якість були видимі в реальному часі.
-
✓
Стратегія виходу визначена з початку
Спроєктуйте план internalization/transition з першого дня.
Осі оцінки для вибору партнера (Risk Radar)
Під час вибору партнера оцінюйте п'ять осей нижче, а не лише ціну, щоб виміряти оборотність.
- Прозорість: Доступ до інформації
- Стандартна технологія: Наскільки поширений технічний стек
- Гнучкість контракту: Легкість скасування
- Документація: Зафіксований задум дизайну
- Підтримка самодостатності: Готовність допомогти з internalization
3. Звільніться від залежності: Стратегія виходу
Перейдіть від контрактного lock-in до відносин, заснованих на цінності.
Визначте дорожню карту для плавного виходу та передачі, коли потрібно.
Крок 01 Забезпечте право власності на активи
Переконайтеся, що вихідний код, дизайн-дані та документація належать клієнту.
Клієнт створює репозиторій (GitHub тощо) і запрошує постачальника.
Крок 02 Зробіть знання неперсональним
Документуйте не лише протоколи зустрічей, а й коментарі в коді та ADR-и.
Збереження контексту "чому" мінімізує вартість передачі.
Крок 03 Період перекриття
Під час internalization або зміни постачальника забезпечте 1-2 місяці перекриття.
Використовуйте pair programming і code review для передачі повноважень на робочому рівні.
Мета Повна незалежність
Стан, у якому система продовжує працювати без зовнішніх партнерів.
Це кінцева мета управління ризиками — здорова позиція розвитку.