Дневник изменений
Как улучшить что-то в 6 раз?
Инструменты тимлида. Дневник изменений Как улучшить что-то в 6 раз?
Если нас что-либо не устраивает - нужно это менять. Но как понять, что что-то не устраивает? Нужно это измерить. Нормальный тимлид "обожает" метрики. Я - не особо. Но смотреть и работать с ними - обязан. Потому что никого метрика «я так чувствую» в корпоративном мире не устраивает,** прости Олег _🤬**_ Что такое не устраивает... а как должно быть, чтобы устраивало? А что если таких «не устраивает» слишком много - можно запутаться. Cобственно, тут на помощь приходит простой инструмент - дневник. Дорогой дневник…
Сегодня хочу рассказать про такой управленческий инструмент, как «Дневник изменений». Дневник изменений - это структурированный список всех изменений в системе или проекте. В дневнике мы отражаем: что меняем, для чего мы это делаем, что хотим получить, сроки и МЕТРИКИ, на которые мы смотрим.
Проще на примере: У нас есть задачи, которые долго доходят до пользователя. Опять? Ну да. Смотри на флоу команды, понимаем, что в процессе доставки фичей самый долгий процесс - ожидание релиза.
Разбираемся почему так. Потому что за релизы отвечают QA, а их всего… мало их. Выдвигаем гипотезу. Если перенести релизы с QA на последнего, кто "потрогал" задачу (они ж не все тестируеются), сократим время в колонке до 3-4 дней. То есть, например, если задачу влил разраб и её не нужно тестировать - пусть раскатит её этот же разраб.
Определяемся на что смотреть**. Что такое долго?** Предметно, по 50 перцентилю, задача вылетает из «ожидания релиза» за 3 дня, а по p95 - за 15 дней… _👀_
—————
Вы скажете: "как вообще может быть такое огромное время в ПРОМЕЖУТОЧНОМ статусе?"
Не может - если задачи ДВЕ... но их пара десятков, а контекстов - по несколько на человека.
Люди между ними переключаются, поток не линеен... если мы живем в идеальном мире - такого нет…
Но мы живем НЕ в идеальном мире.
—————
Окей, наша метрика - время в конкретном взятом за жопу статусе - «Ready4Release.»
Так же, имеем в виду, что нам нужно смотреть на общий лид-тайм и на количество тасок, выпускаемых командой.
В теории, мы можем люто ускорить прохождение задач в DONE, но какой в этом толк, если разрабы твои плачут задач стало доставляться кратно меньше, или общий лид-тайм не поменялся?
Ну вот, мы нашли проблему; выдвинули гипотезу по решению.
Инициируем это изменение, определяем** срок** для нашего «теста» - через сколько дней/недель мы посмотрим, а есть ли улучшение.
Если есть - принимаем изменение, если нет - откатываем его.
Всё. Ровно ЭТО и фиксируем в дневнике изменений.
Масштаб начинает чувствоваться, когда система большая и сложная, а изменений вы производите много, такое бывает часто, особенно, при формировании новой команды или полностью нового процесса. Тут как раз-то дневник изменений и помогает!
А стоит ли что-то менять? Ведь, в данном случае, как я говорил выше, это 95 перцентиль. Но вот в этих 5 процентах тоже есть задачи, которые ждет бизнес и пользователи.
Кстати, время в колонке «Ready4Release» по p95 упало с 15 до 2.5 дней…