60% времени задачи - это ожидание, а не работа

60% времени задачи - это ожидание, а не работа

Финальный блок школы CTO от Стратоплана - шесть занятий про операционный менеджмент: оргструктуры, построение и оптимизация бизнес-процессов, метрики, инфраструктура и закупки. Этот блок не столько про новые концепции, сколько про то, как собрать уже знакомые вещи в систему более высокого уровня

Оргструктуры

Нет одной правильной оргструктуры на всю компанию. Каждый вид решает свою задачу: функциональная дает специализацию и качество экспертизы, проектная фокусирует команду на delivery, матричная балансирует первое и второе, дивизионная позволяет масштабироваться и автономно развивать отдельные продукты. Внутри одной компании разные подразделения могут жить в разных структурах. И отдельно важно отделять роль от сотрудника - роль это набор функций, а закрывать ее может один человек, несколько или целая команда

Построение процессов

Базовая модель "Цель-Ограничение-Зависимость" - для любого процесса задаем три вопроса: зачем он существует, что нельзя нарушать и от чего он зависит. Отдельно стоит запомнить разницу process-first и work-first подходов. Первый - сначала проектируем, потом запускаем, долго и контролируемо. Второй - сначала работаем, потом фиксируем, быстро и гибко, но есть риск зафиксировать и неудобства

Оптимизация процессов

Структура времени выполнения задачи - рабочее время 10-20%, ожидание 60-70%, принятие решений 20%. Когда хотят ускорить delivery, инстинктивно лезут в рабочее время, хотя весь резерв в ожиданиях. И ожидание это не простой человека, а ожидание других - код-ревью, согласования архитектуры, прохождение тестирования, ответа от заказчика

Из этой же темы три понятия из Lean, которые дают язык для разговора о потерях:

- Mura (неравномерность) - когда одна задача делается 3 дня, а похожая 15. Замеряется отношением p90 к медиане времени выполнения, если больше трех - поток рваный

- Muri (перегруз) - когда люди работают на пределе. Замеряется количеством задач в работе на человека и тем, как давно они висят без движения

- Muda (потери) - все, что съедает ресурсы без создания ценности: переделки, лишние согласования, ожидания на стыках

Метрики и KPI

Пирамида из четырех уровней - сотрудники, процессы, продукт, финансы. Каждый нижний уровень это прогноз верхнего. Текущее состояние проектов прогнозирует удовлетворенность клиентов, а удовлетворенность прогнозирует финансы

Важно, чтобы метрики уравновешивали друг друга, если ставим метрику на количество, обязательно нужна балансирующая метрика на качество. Иначе получаем разработчиков, которые закрывают много задач, но половина возвращается с багами. Velocity идет в паре с индексом качества, звонки менеджера - с конверсией, скорость найма - с прохождением испытательного срока

Инфраструктура и софт

Разбирали интеграционный сценарий - когда нужно встроить что-то новое в существующий ландшафт после поглощения или миграции. Понравилось правило "Ядро vs Контекст" - конкурентное преимущество разрабатываем сами, вспомогательное берем у подрядчиков. И матрица решений по legacy-сервисам по осям бизнес-ценность и техническое состояние - что-то отключаем, что-то оптимизируем, что-то переписываем, во что-то инвестируем

Закупки

Главный тезис - правильный контракт это 80% качественной закупки. Три типа под разные ситуации: fixed price для тендеров и фиксированного скоупа, cost plus fee для сторонних сервисов и инфраструктуры, time and materials для agile и плавающего скоупа. И сильная мысль про контроль подрядчиков - роадмапы и ганты не работают, работает фактура: метрики, демо и доска или код. Все остальное это интерпретация подрядчика

Книги, которые попали в обойму на прочитать после этого блока:

- Э. Голдратт "Цель"

- Дж. Лайкер "Дао Toyota"

- У. Эдвардс Деминг "Выход из кризиса"