1. Симулација на трошоци за повлекување
Sunk costs ја замаглуваат проценката на раководителите.
Споредете ја загубата кога проектот се стопира под традиционален fixed-bid договор наспроти флексибилен DaaS/Staff Augmentation модел.
Споредба на кумулативни трошоци
Поместете го лизгачот за да го смените месецот кога одлучувате да излезете (откажете).
Традиционален ризик (fixed-bid)
Често се применуваат казни за раскин и обврски за buyout на меѓуиспораки, што ја максимизира изложеноста на sunk cost.
DaaS ризик (флексибилен договор)
Плаќате само за извршената работа. Бидејќи можете да запрете во секое време, можете да излезете пред штетата да се зголеми.
Можноста за откажување во секое време го мотивира добавувачот да одржи висока квалитет.
2. Анатомија на vendor lock-in и "транспарентност"
Стравот од lock-in доаѓа од тоа што не гледате што има внатре.
Споредете ги елементите што спречуваат black box и враќаат автономна контрола.
Black-box развој
Деталната спецификација живее само во главата на добавувачот
-
Нејасна сопственост на код
Прилагодени framework-и и библиотеки го отежнуваат преземањето од друг тим.
-
Недостасува документација
Добивате функционален производ, но не и "зошто" зад него.
-
Зависност од луѓе
Ако клучно лице замине, системот може да запре.
White-box развој
Држете го системот подготвен за предавање во секое време
-
Избор на стандардна технологија
Изберете широко прифатени јазици и framework-и за да задржите опции за замена.
-
Секогаш споделено во GitHub и сл.
Правете дневни commit-и во repo на клиентот за напредокот и квалитетот да бидат видливи во реално време.
-
Стратегија за излез дефинирана од почеток
Дизајнирајте internalization/transition план од првиот ден.
Оси за евалуација при избор на партнер (Risk Radar)
При избор на партнер, евалуирајте ги петте оски подолу, не само цената, за да ја измерите реверзибилноста.
- Транспарентност: Пристап до информации
- Стандардна технологија: Колку е чест технолошкиот стек
- Флексибилност на договорот: Леснотија на откажување
- Документација: Запишана намера за дизајн
- Поддршка за самостојност: Подготвеност да помогне со internalization
3. Ослободете се од зависност: Стратегија за излез
Преминете од договорен lock-in кон однос базиран на вредност.
Дефинирајте roadmap за мазно повлекување и предавање кога е потребно.
Чекор 01 Обезбедете сопственост на средствата
Осигурајте дека изворниот код, дизајн податоците и документацијата се во сопственост на клиентот.
Клиентот создава repository (GitHub и сл.) и го поканува добавувачот.
Чекор 02 Направете го знаењето неперсонално
Документирајте не само белешки од состаноци, туку и коментари во код и ADR-и.
Задржувањето на контекстот "зошто" го минимизира трошокот за предавање.
Чекор 03 Период на преклопување
При internalization или промена на добавувач, овозможете 1-2 месеци преклопување.
Користете pair programming и code review за да пренесете авторитет на работно ниво.
Цел Целосна независност
Состојба во која системот продолжува да работи без надворешни партнери.
Ова е конечната цел на управувањето со ризик — здрав развоен став.