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"
- У. Эдвардс Деминг "Выход из кризиса"
Финальный блок школы 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"
- У. Эдвардс Деминг "Выход из кризиса"