Часть 1/4: Поиск ограничения.
Ко мне обратился CTO технологической компании с классической проблемой:
"Мы медленно выкатываем фичи. Бизнес недоволен, команда демотивирована. Я требую от них работать быстрее, но Time-to-Market только растет".
Знакомая история, правда?
Далее я расскажу в четырех частях, как мы решали задачу сокращения времени поставки.
Вместо того, чтобы искать виноватых, мы с CTO решили найти системное ограничение (то самое "бутылочное горлышко"), которое тормозило весь процесс.
Шаг 1: Визуализация и анализ потока:
Разложили весь процесс поставки ценности на этапы и замерили Cycle Time для каждого из них:
- Аналитика и проектирование: ~3 дня
- Разработка: ~5 дней
- Ревью кода (Code Review): ~8 дней!
- Тестирование: ~4 дня
- Релиз: ~1 день
Ограничение найдено. Задачи проводили в ожидании и прохождении ревью кода почти в два раза больше времени, чем в самой разработке. В целом, команда справлялась не плохо, но их результат просто "простаивал" в очереди.
Шаг 2: Первые быстрые решения:
Мы сфокусировались на решении проблемы именно с ревью. И начали с самого очевидного — размера задач, которые поступали на проверку. Команда часто отправляла на ревью огромные Merge Requests (MR).
———
справка для тех, кто не из ИТ:
Что такое MR?
Merge Request (или Pull Request) — это запрос от разработчика на добавление его нового кода в основной проект. Это стандартный этап проверки качества в современной разработке.
———
Проблема в том, что проверить огромный MR на 2000 строк кода — это ад для ревьюера. Такую задачу постоянно откладывают, она требует огромной концентрации.
Поэтому нашим первым и главным решением стало правило: "Ограничить размер MR". Мы договорились отправлять код на проверку маленькими, логически завершенными порциями.
Помимо этого, мы внедрили еще пару правил:
Приоритет №1 для тимлидов: Ревью кода стало их главной задачей.
Ввели SLA: Договорились, что любой MR должен получить первую реакцию в течение 4-х рабочих часов.
Результаты первого этапа.
Уже эти простые организационные изменения дали невероятный эффект:
1️⃣Среднее время на этапе ревью кода сократилось с 8 до 4 дней.
2️⃣Общий Time-to-Market уменьшился на 20%.
3️⃣Уровень стресса в команде снизился, так как исчезли "зависшие" на несколько дней задачи.
Но мы понимали, что это только начало. Ведь сказать команде "делайте задачи меньше" — легко. А вот КАК научить их это делать системно?
Об этом — в следующей части кейса.
Расскажу, как мы учили команду правильно декомпозировать задачи и почему это изменило всё.
Накидайте огня 🔥, если ждете продолжения!
Ну и всем скорости (там где надо)! 😁🙌
#кейс #теорияограничений #agile #kanban #timetomarket #cto #оргдизайн #devops