Главное (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 года.

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