Стабильный выпуск продукта
Релиз задерживается. Кто может сдвинуть его с места?
Команда может объяснить план, но довести работу до релиза предсказуемо уже не получается. Здесь разбираемся, где она застревает и какое решение поможет ей двигаться дальше.
Сигнал
Релизы отстают от плана. Кто отвечает за участок, на котором всё застряло, никто точно не знает.
Задержки становятся привычными. Пока команда объясняет их руководству и передаёт задачи друг другу, причина остановки остаётся без внимания.
Почему работа застревает
Выпуск продукта редко начинает буксовать из-за слабой команды. Чаще ожидания руководства расходятся с тем, как на самом деле готовят релизы и кто вправе принимать решения.
После смены задачи, ухода CTO или перезапуска продукта команда может быть полностью занята, а за результат при этом никто не отвечает. Это видно по простому признаку: никто не может назвать первое решение, которое сделает следующий релиз безопаснее.
С чего начинаю проверку
Сначала прослеживаю, как задача доходит до продакшена.
С чего начинаю проверку
- Ситуация
Релиз явно задерживается, а ответственность размыта.
- Ограничение
Каждая команда знает свой участок, но за весь путь от обещания до релиза не отвечает никто.
- Решение
Проследить одну реальную задачу до релиза, определить, кто принимает решение, и выбрать один участок для изменения.
- Что изменилось
Становится понятно, как выпускать релизы и управлять этим процессом. Для этого не приходится ждать большой реорганизации.
Что можно изменить за один шаг
Берём один реальный процесс и работаем с ним. У этого шага есть чёткие пределы.
Выпуск продукта удаётся наладить, когда для одного процесса согласованы порядок действий и ответственность, а у людей есть полномочия принимать нужные решения.
Здесь описан подход к диагностике. Числовой результат приведён в связанном основном кейсе.
- Контекст
- Переходный период: планы по продукту неясны, выпуск релизов теряет предсказуемость.
- Период
- Запись из практики автора
- Роль
- Operational CTO
- Откуда данные
- Материалы автора с оговорками к выводам. Часть данных нельзя раскрывать.
- Надёжность данных
- Источник подтверждает этот случай. Более широкие выводы нужно отдельно проверить и согласовать.
- Ограничения публикации
- Клиент не назван. Неподтверждённые показатели не приводятся.
Связанные кейсы
Что показывает практика
Стабильный выпуск продукта
Новые планы появлялись быстрее, чем команда успевала выпускать релизы.
- Решение
- Назначить ответственного за выпуск и проследить весь путь одной задачи до результата.
- Результат
- Изменение стало заметным после пересмотра зоны ответственности.
- Роль
- Operational CTO
Стабильный выпуск продукта
CTO ушёл, а текущие дела и знания о работе системы ещё никто не принял.
- Решение
- Временно взять ответственность на себя и определить, кто принимает решения. Уже затем менять процесс.
- Результат
- Команда смогла продолжить работу, не дожидаясь полной передачи дел.
- Роль
- Operational CTO
ИИ в разработке
Изменения тормозились: знания об архитектуре были разбросаны между людьми и документами.
- Решение
- Сначала собрать машиночитаемую модель системы, чтобы оценивать возможности ускорения на её основе.
- Результат
- Принимать решения стало возможно с опорой на модель, а не только на устные рассказы.
- Роль
- Operational CTO
Field Notes
Заметки, которые помогут разобраться
За внедрение ИИ должен кто-то отвечать
Инструменты уже пробуют. А кто решает, как менять работу нескольких команд? Разбираю, зачем внедрению ИИ нужен ответственный с полномочиями.
Открыть заметкуFractional CTO уйдёт. Кто примет работу?
Как передать команде ответственность за технические решения до ухода внешнего CTO, чтобы после него не осталось задач, за которые никто не отвечает.
Открыть заметкуFit / No-fit
Когда формат подходит
Подходит
- Работа уже застревает между продуктом и разработкой.
- Команда готова показать, как на самом деле выпускает релизы.
- Руководство готово начать с небольшого изменения в реальной работе.
Не подходит
- Нужны только советы по разработке, без полномочий что-либо решать.
- Компания хочет добавить проектный офис, но не готова распределять ответственность.
- Никто не готов показать участок, на котором работа останавливается.
Activation Sprint
Начать с Activation Sprint
Если выпуск продукта уже буксует, выберем один участок и внесём в него изменение. Назначим ответственного, проверим результат и решим, нужно ли продолжать.
Neutral start
Сначала опишите ситуацию
Если узнали свою ситуацию, но пока не можете точно назвать причину сбоя, расскажите, что происходит.