"Алихан, сдвинем на понедельник? API еще не готово".
Раньше я бы ответил: "ок" и начал думать как перестроить спринты и аргументировать перенос сроков владельцу продукта.
А теперь смотрю на сообщение и думаю: "действительно проблема или по срокам продавить меня хочешь?"
Как сдвигается норма
Сначала: "Алихан, там API, сдвинем на день".
Потом: "задача оказалась сложнее чем я оценил изначально, надо ещё два дня".
А через месяц просто: "не успеваю, переносим".
В какой то момент я перестал удивляться, подстроился и стал изначально закладывать это в планирование, потому что всё равно сроки поедут вправо.
То, что раньше было исключением, в какой то момент стало нормой.
Так оно и работало, пока однажды, пролистывая историю спринтов за квартал, я не увидел 7 переносов сроков. Из них 6 - за два дня до дедлайна. И это был перенос уже моих расширенных сроков!
Надо это прекращать - подумал я. Такие постоянные сдвиги недопустимы при нашей небольшой команде - всего 8 разработчиков, плюс лиды и пара тестировщиков...
Прикинул совокупные затраты на перепланирование, пересогласование - получилось около 150 человеко-часов. Это потерянное время команды, которое мы могли бы потратить на разработку ключевых фич, а мы его просто сожгли.
Опасность не в первом сдвиге вправо. А в том, что он меняет норму. Сначала смещение на день - "серьезная причина". Потом сдвиг на два дня - "ну ок". А потом внезапно оказывается, что разработчик просто пишет "не успеваю", и никто уже даже не спрашивает почему. Граница допустимого отодвинулась так далеко, что ты замечаешь это только по итоговым цифрам.
Это и есть окно Овертона в разработке: постепенное расширение зоны нормального, пока ты не просыпаешься в ситуации, где фичу делают три месяца вместо одного, и у всех есть причины, а результата нет.
Три вопроса, которые почти бесполезны
Когда я впервые заметил паттерн, я начал задавать вопросы:
- Когда понял, что не успеваешь?
- Что пошло не так?
- Что сделаем, чтобы не повторилось?
Сначала помогло. После четырех таких разборов количество "объективных причин" резко упало. Разработчики сами стали говорить о рисках заранее. Но быстро выяснилось, что этого мало.
Post-mortem - это реакция. Если использовать как единственный инструмент, ты просто становишься придирчивым начальником, который периодически задает неудобные вопросы и капает на мозги. С изменением твоей роли меняется и эффективность: разборы становятся все более формальными и часто наталкиваются на психологические блоки от разработчиков, команда перестает раскрываться, рефлексировать и "окукливается".
В неформальных разговорах за спиной витает: "он перешел на темную сторону и с потрохами продался заказчикам, несите нового".
В общем надо идти глубже - от разовых разборов к настройке процессов до старта работ.
Что помогло изменить ситуацию
Я не погружаюсь детально в каждую проблему, на это есть лиды. Моя задача - видеть паттерны. Для этого хватило еженедельных синков с лидами и дашборда Jira. Когда мы выгрузили данные за полгода и разметили причины переносов, картина стала очевидной.
Оказалось, что 80% систематических переносов - это не настоящий форс-мажор, а риски, которые можно было выявить до старта:
Внешние зависимости (вроде непроверенного API)
Неочевидная сложность (оценка делалась без декомпозиции)
Отсутствие "раннего оповещения" (разработчик понимал, что не успевает, но сообщал за день до дедлайна)
Мы внедрили три простых вещи:
Pre-mortem на планировании. Перед тем как утвердить задачу, команда отвечает на вопрос: "Что может пойти не так, из-за чего мы не успеем?" Ответы записываем прямо в таск. Поначалу это воспринималось как лишняя бюрократия, но после первого же спринта, где pre-mortem помог избежать сдвига, отношение изменилось.
Культура "раннего оповещения". Я открыто сказал: "Если вы видите риск за четыре дня до дедлайна - это круто. Если за три часа - это большая проблема". И начал поощрять первое, а не наказывать за второе.
Чек-лист зависимостей. После кейса с непроверенным API мы добавили обязательный пункт в чек-лист перед стартом спринта: "Проверены доступность и SLA всех сервисов?"
Что в итоге
Сдвиги вправо неизбежны. Бывают эпидемии, кризисы, внезапное изменение концепции продукта... много разных причин.
Важно оцифровать и проанализировать каждый случай. Научиться на своих и чужих ошибках и постараться недопустить их в будущем.
P.S. Кстати, пока писал текст, кот прыгнул на клавиатуру и чуть не отправил черновик в прод. Вот это - объективная причина (и даже её можно было предусмотреть, просто закрыв ноутбук). А непроверенный API это косяк в планировании. Разницу чувствуете?