Главное (3 мин)Суть (10 мин)Подробно
Введение в практику

BizOpsDev321

Вы думаете, у вас уже есть команды. Восемь пунктов покажут, где именно «почти» превращается в «совсем нет».

Переиспользование

У вас уже есть все элементы. Бизнес-специалисты, разработчики, эксплуатация, внешние партнёры. Они просто сложены так, что работают на долю от возможного.

BizOpsDev321 не добавляет новых элементов. Он пересобирает существующие — и результат принципиально другой. Небольшие настройки главных рычагов — и вместо какофонии вы получаете звучание.

А вы уверены, что у вас нет тех же элементов, просто расстроенных?

Cynefin — контексты принятия решений
Модель выбора тактики в зависимости от сложности ситуации: не все контексты одинаковы
«У вас всё есть. Просто сложено не так. Как мебель из IKEA без инструкции — детали те же, а шкаф не стоит.» — сказал ии-агент Довлатов

Почти

Когда руководители знакомятся с BizOpsDev321, реакция почти всегда одна: «у нас это уже есть». И они правы — почти. Восемь пунктов покажут, где именно «почти»:

1

Нет формализованных ТЗ между бизнесом и ИТ

2

Бизнес-специалисты — постоянная часть команды, не «заказчики»

3

Кто написал — тот и эксплуатирует

4

Команда сама решает, что делать и в каком порядке

5

Команда распределена между 2+ организациями

6

Живёт со своей зоной 5+ лет

7

Никаких промежуточных ролей (Product Owner, бизнес-аналитик как посредник)

8

Команда подбирает свой состав сама

Пункт 7 вызывает больше всего сопротивления. Product Owner — переводчик между двумя мирами, не принадлежащий полностью ни одному. Он транслирует потребности бизнеса на язык ИТ. При трансляции теряется именно то, что важнее всего — контекст, нюансы, ежедневная реальность. В Команде321 этот стык закрывается изнутри: реальные специалисты в предметной области внутри команды, не рядом.

«Шесть из восьми если есть — хорошо. Меньше — настроить нужно, не изобретать.» — подумал ии-дух Лао

Сколько пунктов выполнено? Если меньше шести — у вас не BizOpsDev. Попробуйте донастроить — и посмотрите на результаты после этого.

Когнитивное Облако и иерархия 3-2-1

Когнитивное Облако — коллективные знания, навыки и отношения команды. То, что невозможно записать в документацию. То, что уходит, когда уходят люди.

Метафора намеренно противопоставлена термину «Когнитивная Нагрузка». Если когнитивная нагрузка описывает индивидуальное напряжение, то Когнитивное Облако подчёркивает коллективную, распределённую и поддерживающую природу знаний организации. Подробнее →

Когнитивное Облако, Кодовая База и Инструменты — три элемента Команды321 с весами 3-2-1
Когнитивное Облако (удельный вес 3) — всё, что знает команда и что уйдёт вместе с ней > Кодовая База (вес 2) > Инструменты (вес 1)

3 — Когнитивное Облако

Люди и их связи. В три раза важнее инструментов. Вместе с Кодовой Базой — в пять раз. Но на что уходит большая часть бюджета и внимания менеджмента?

2 — Кодовая База

Написанный, тестируемый артефакт. Если Когнитивное Облако команды не покрывает кодовую базу — это устаревший код, с которым никто не справится. По определению.

1 — Инструменты

Заменяемы. Неважно, написана система вчера на самом модном стеке.

Как восстановить покрытие? Первый шаг — построить защитное кольцо автоматических тестов вокруг ключевых пользовательских сценариев. Не юнит-тесты для разработчиков — а контрольные примеры, написанные на языке бизнеса.

Когнитивное облако vs когнитивная нагрузка
Когнитивное Облако vs когнитивная нагрузка

Кривая стоимости изменений — экспонента (закономерность Бёма): чем старше и больше система, тем дороже каждое следующее изменение. Ей всё равно, стоит ваш час $10 или $0.1. BizOps- определяет, на каком участке экспоненты вы находитесь. Инструменты — нет.

Конвейер — не лаборатория

Agile, DevOps, SAFe, продуктовые команды — всё это попытки починить конвейер, оставаясь внутри конвейера. Но цифровая работа — не конвейер. Ближайшая аналогия — научно-исследовательская лаборатория.

Это различие неочевидно даже для большинства ИТ-специалистов. И это корневая причина большинства ИТ-провалов.

Вы это уже видели. При каждом новом старте внутри организации BizOpsDev-команда возникает сама. Энтузиасты от бизнеса, пара технарей, тесная работа, полное владение. Узнаёте? А потом организация «дозревает» её до смерти за 3–5 лет: формализует, разделит, масштабирует в отдел.

«Вы узнали эту команду. Она была у вас. Три года назад её расформировали в рамках оптимизации.» — сказал ии-агент Довлатов

321 — чтобы не умерла. Не новый подход — защита того, что и так возникает.

BizOpsDev321: команды, которые нельзя «оптимизировать». С 1990 года.

Что есть организация? — теоретический фундамент.