Кіруйце нявызначанасцю
у распрацоўцы сістэм

Прывязка да пастаўшчыка і зрывы праектаў — найбуйнейшыя траўмы для кіраўнікоў.

Мы тлумачым ролю "празрыстасці", якая дазваляе быць гатовымі выйсці ў любы момант і пазбягаць гэтых рызык.

1. Мадэляванне выдаткаў на выхад

Патопленыя выдаткі замутняюць меркаванне кіраўнікоў.

Параўнайце страты пры спыненні праекта па традыцыйным кантракце з фіксаванай цаной супраць гнуткай мадэлі DaaS/Staff Augmentation.

Параўнанне назапашаных выдаткаў

Перамясціце паўзунок, каб змяніць месяц, калі вы вырашаеце выйсці (скасаваць).

Момант выхаду:

Традыцыйная рызыка (фіксаваная цана)

Часта ўжываюцца штрафы за скасаванне і абавязкі выкупу прамежкавых паставак, што максімізуе экспазіцыю да патопленых выдаткаў.

Рызыка DaaS (гнуткі кантракт)

Вы плаціце толькі за выкананую працу. Паколькі можна спыніцца ў любы момант, вы можаце выйсці да таго, як шкода вырасце.

Магчымасць скасаваць у любы момант матывуе пастаўшчыка падтрымліваць высокую якасць.

2. Анатомія прывязкі да пастаўшчыка і "празрыстасці"

Страх прывязкі ўзнікае з-за таго, што не бачна, што ўнутры.

Параўнайце элементы, якія прадухіляюць чорную скрыню і вяртаюць аўтаномны кантроль.

Традыцыйны пастаўшчык
📦

Black-box распрацоўка

Падрабязная спецыфікацыя жыве толькі ў галаве пастаўшчыка

  • Нявызначанае валоданне кодам

    Кастомныя framework-і і бібліятэкі ўскладняюць перадачу іншай камандзе.

  • Адсутнічае дакументацыя

    Вы атрымліваеце працоўны прадукт, але не "чаму" за ім.

  • Залежнасць ад людзей

    Калі ключавы чалавек сыходзіць, сістэма можа спыніцца.

Рэкамендаванае мадэль (DaaS)
🔍

White-box распрацоўка

Трымайце сістэму гатовай да перадачы ў любы момант

  • Выбар стандартнай тэхналогіі

    Выбірайце шырока распаўсюджаныя мовы і framework-і, каб захаваць опцыі замены.

  • Заўсёды падзелена ў GitHub і г.д.

    Штодня рабіце commit у рэпазіторый кліента, каб прагрэс і якасць былі бачныя ў рэальным часе.

  • Стратэгія выхаду вызначана з пачатку

    Спраектуйце plan internalization/transition з першага дня.

Восі ацэнкі для выбару партнёра (Risk Radar)

Пры выбары партнёра ацэньвайце пяць восей ніжэй, не толькі цану, каб вымераць зваротнасць.

  • Празрыстасць: Доступ да інфармацыі
  • Стандартная тэхналогія: Наколькі распаўсюджаны тэхналагічны стек
  • Гнуткасць кантракта: Лёгкасць скасавання
  • Дакументацыя: Зафіксаваная дызайнерская задумка
  • Падтрымка самастойнасці: Гатоўнасць дапамагчы з internalization

3. Вызваліцеся ад залежнасці: Стратэгія выхаду

Перайдзіце ад кантрактнай прывязкі да адносін на аснове каштоўнасці.

Вызначце roadmap для плаўнага выхаду і перадачы пры неабходнасці.

Крок 01 Забяспечце права ўласнасці на актывы

Пераканайцеся, што зыходны код, дызайн-дадзеныя і дакументацыя належаць кліенту.

Кліент стварае рэпазіторый (GitHub і г.д.) і запрашае пастаўшчыка.

Крок 02 Зрабіце веды неперсанальнымі

Дакументуйце не толькі пратаколы сустрэч, але і каментары ў кодзе і ADR-ы.

Захаванне кантэксту "чаму" мінімізуе кошт перадачы.

Крок 03 Перыяд перакрыцця

Пры internalization або змене пастаўшчыка забяспечце 1-2 месяцы перакрыцця.

Выкарыстоўвайце pair programming і code review для перадачы паўнамоцтваў на працоўным узроўні.

Мэта Поўная незалежнасць

Стан, у якім сістэма працягвае працаваць без знешніх партнёраў.

Гэта канчатковая мэта кіравання рызыкамі — здаровая пазіцыя развіцця.