Окно Овертона в разработке продукта

"Алихан, сдвинем на понедельник? API еще не готово".

Раньше я бы ответил: "ок" и начал думать как перестроить спринты и аргументировать перенос сроков владельцу продукта.

А теперь смотрю на сообщение и думаю: "действительно проблема или по срокам продавить меня хочешь?"

Сначала: "Алихан, там API, сдвинем на день".

Потом: "задача оказалась сложнее чем я оценил изначально, надо ещё два дня".

А через месяц просто: "не успеваю, переносим".

В какой то момент я перестал удивляться, подстроился и стал изначально закладывать это в планирование, потому что всё равно сроки поедут вправо.

То, что раньше было исключением, в какой то момент стало нормой.

Так оно и работало, пока однажды, пролистывая историю спринтов за квартал, я не увидел 7 переносов сроков. Из них 6 - за два дня до дедлайна. И это был перенос уже моих расширенных сроков!

Надо это прекращать - подумал я. Такие постоянные сдвиги недопустимы при нашей небольшой команде - всего 8 разработчиков, плюс лиды и пара тестировщиков...

Прикинул совокупные затраты на перепланирование, пересогласование - получилось около 150 человеко-часов. Это потерянное время команды, которое мы могли бы потратить на разработку ключевых фич, а мы его просто сожгли.

Опасность не в первом сдвиге вправо. А в том, что он меняет норму. Сначала смещение на день - "серьезная причина". Потом сдвиг на два дня - "ну ок". А потом внезапно оказывается, что разработчик просто пишет "не успеваю", и никто уже даже не спрашивает почему. Граница допустимого отодвинулась так далеко, что ты замечаешь это только по итоговым цифрам.

Это и есть окно Овертона в разработке: постепенное расширение зоны нормального, пока ты не просыпаешься в ситуации, где фичу делают три месяца вместо одного, и у всех есть причины, а результата нет.

Когда я впервые заметил паттерн, я начал задавать вопросы:

Сначала помогло. После четырех таких разборов количество "объективных причин" резко упало. Разработчики сами стали говорить о рисках заранее. Но быстро выяснилось, что этого мало.

Post-mortem - это реакция. Если использовать как единственный инструмент, ты просто становишься придирчивым начальником, который периодически задает неудобные вопросы и капает на мозги. С изменением твоей роли меняется и эффективность: разборы становятся все более формальными и часто наталкиваются на психологические блоки от разработчиков, команда перестает раскрываться, рефлексировать и "окукливается".

В неформальных разговорах за спиной витает: "он перешел на темную сторону и с потрохами продался заказчикам, несите нового".

В общем надо идти глубже - от разовых разборов к настройке процессов до старта работ.

Я не погружаюсь детально в каждую проблему, на это есть лиды. Моя задача - видеть паттерны. Для этого хватило еженедельных синков с лидами и дашборда Jira. Когда мы выгрузили данные за полгода и разметили причины переносов, картина стала очевидной.

Оказалось, что 80% систематических переносов - это не настоящий форс-мажор, а риски, которые можно было выявить до старта:

Мы внедрили три простых вещи:

Сдвиги вправо неизбежны. Бывают эпидемии, кризисы, внезапное изменение концепции продукта... много разных причин.

Важно оцифровать и проанализировать каждый случай. Научиться на своих и чужих ошибках и постараться недопустить их в будущем.

P.S. Кстати, пока писал текст, кот прыгнул на клавиатуру и чуть не отправил черновик в прод. Вот это - объективная причина (и даже её можно было предусмотреть, просто закрыв ноутбук). А непроверенный API - это косяк планирования. Разницу чувствуете?