Alex.Miller
New member
Скажу честно: за десять лет в разработке я так и не встретил проект, где требования стояли бы на месте. Первое время я воспринимал это как личную обиду. Ты в понедельник согласовал объём, разложил задачи по доске, расписал спринт до последнего часа, а в среду приходит сообщение: «Ребята, тут небольшая правка, нужно ещё интеграцию с новым сервисом и, желательно, к пятнице». И вот ты сидишь вечером, смотришь на горящий бёрн-даун и понимаешь, что всё, что ты планировал, планировалось в какой-то другой вселенной. Первый год я честно пытался догнать изменения героическими переработками. Заканчивалось это одинаково: выгорание, баги в проде, и главное — дедлайн всё равно сдвигался. Потому что проблема была не в скорости моих рук, а в том, как я договаривался об изменениях.
Один случай запомнился особенно. Мы делали личный кабинет для банка. К третьему спринту заказчик решил, что нужен не только веб, но и мобильное приложение, причём «на тех же технологиях, чтобы быстро». Мы с командой молча кивнули и начали работать по 12 часов. Через две недели выяснилось, что «то же самое, только в телефоне» означает совсем другую навигацию, другие сценарии входа и push-уведомления, о которых никто не думал. Мы сдали сырой продукт, получили месяц правок и очень неприятный разговор. Именно тогда я понял простую вещь: изменения требований — это не катастрофа, катастрофа — это изменения требований, которые никто не посчитал и не обсудил вслух.
Главный вывод, к которому я пришёл: любое новое требование стоит денег, времени или качества. Иногда — всех трёх сразу. Как только я перестал соглашаться на всё сразу и начал задавать вопрос «что мы убираем или сдвигаем взамен», разговоры с бизнесом стали совсем другими. Не потому, что заказчики злые, а потому, что у них просто не было перед глазами цены решения. Они видели кнопку, а не три дня работы, ревью, тесты и риск регресса в соседнем модуле.
Первая рекомендация, которая реально спасла мне нервы, — фиксировать не задачи, а результат. Мы перестали обещать «сделаем такой-то экран» и начали обещать «пользователь сможет оформить заявку за две минуты». Когда появляется новое пожелание, я открываю этот список результатов и спрашиваю: оно помогает дойти до цели или это новая цель? Если новая — добро пожаловать в следующий спринт или в отдельный этап. Такой подход не требует сложных инструментов, достаточно одной страницы текста, которую видят все участники.
Второе — короткие демо и быстрые прототипы вместо долгих согласований документов. Я перестал писать подробные спецификации на сорок страниц, которые никто не читает. Вместо этого раз в неделю показываю рабочую, пусть и кривую, версию. Люди реагируют гораздо честнее, когда видят кликабельный макет, чем когда читают абзац описания. Это экономит недели: правки, которые всплывают на демо, стоят в разы дешевле, чем переделка готового модуля за три дня до релиза.
Третье — технический запас, о котором обычно вспоминают в последний момент. Флаги функций, чтобы недоделанную историю можно было спрятать, а не тащить в релиз. Автотесты на критичные сценарии, чтобы каждая новая правка не ломала старое. И архитектура, где модули можно менять по отдельности. Это не про «правильно» и не про модные технологии, это про то, что при потоке изменений гибкость важнее скорости на старте. Команда, у которой есть запас прочности, спокойно принимает новое требование в середине спринта, а команда без него — снова работает ночью.
И отдельно про нервы — свои и командные. Я долго считал, что хороший разработчик должен вытянуть любой аврал. Теперь считаю иначе: хороший разработчик честно говорит, что не успевает, и предлагает варианты. Мы ввели простое правило: если к середине спринта появилось требование, которое съедает больше дня, оно не влезает молча, а проходит через короткий разговор с заказчиком. Иногда мы договариваемся исключить менее важное, иногда переносим, иногда добавляем людей. Но решение принимаем вместе и вслух, а не в чьей-то голове в два часа ночи.
В итоге дедлайны у меня всё ещё иногда сдвигаются, и это нормально, потому что живые проекты не бывают предсказуемыми. Но паники и выгорания стало заметно меньше, а доверие с бизнесом — выше. Потому что когда ты не молчишь, а объясняешь цену изменений, тебя начинают воспринимать как партнёра, а не как ресурс, который должен успевать всегда. А теперь вопрос к вам, коллеги: какой приём лучше всего помогал именно вам удерживать дедлайн, когда требования менялись прямо посреди спринта?
Один случай запомнился особенно. Мы делали личный кабинет для банка. К третьему спринту заказчик решил, что нужен не только веб, но и мобильное приложение, причём «на тех же технологиях, чтобы быстро». Мы с командой молча кивнули и начали работать по 12 часов. Через две недели выяснилось, что «то же самое, только в телефоне» означает совсем другую навигацию, другие сценарии входа и push-уведомления, о которых никто не думал. Мы сдали сырой продукт, получили месяц правок и очень неприятный разговор. Именно тогда я понял простую вещь: изменения требований — это не катастрофа, катастрофа — это изменения требований, которые никто не посчитал и не обсудил вслух.
Главный вывод, к которому я пришёл: любое новое требование стоит денег, времени или качества. Иногда — всех трёх сразу. Как только я перестал соглашаться на всё сразу и начал задавать вопрос «что мы убираем или сдвигаем взамен», разговоры с бизнесом стали совсем другими. Не потому, что заказчики злые, а потому, что у них просто не было перед глазами цены решения. Они видели кнопку, а не три дня работы, ревью, тесты и риск регресса в соседнем модуле.
Первая рекомендация, которая реально спасла мне нервы, — фиксировать не задачи, а результат. Мы перестали обещать «сделаем такой-то экран» и начали обещать «пользователь сможет оформить заявку за две минуты». Когда появляется новое пожелание, я открываю этот список результатов и спрашиваю: оно помогает дойти до цели или это новая цель? Если новая — добро пожаловать в следующий спринт или в отдельный этап. Такой подход не требует сложных инструментов, достаточно одной страницы текста, которую видят все участники.
Второе — короткие демо и быстрые прототипы вместо долгих согласований документов. Я перестал писать подробные спецификации на сорок страниц, которые никто не читает. Вместо этого раз в неделю показываю рабочую, пусть и кривую, версию. Люди реагируют гораздо честнее, когда видят кликабельный макет, чем когда читают абзац описания. Это экономит недели: правки, которые всплывают на демо, стоят в разы дешевле, чем переделка готового модуля за три дня до релиза.
Третье — технический запас, о котором обычно вспоминают в последний момент. Флаги функций, чтобы недоделанную историю можно было спрятать, а не тащить в релиз. Автотесты на критичные сценарии, чтобы каждая новая правка не ломала старое. И архитектура, где модули можно менять по отдельности. Это не про «правильно» и не про модные технологии, это про то, что при потоке изменений гибкость важнее скорости на старте. Команда, у которой есть запас прочности, спокойно принимает новое требование в середине спринта, а команда без него — снова работает ночью.
И отдельно про нервы — свои и командные. Я долго считал, что хороший разработчик должен вытянуть любой аврал. Теперь считаю иначе: хороший разработчик честно говорит, что не успевает, и предлагает варианты. Мы ввели простое правило: если к середине спринта появилось требование, которое съедает больше дня, оно не влезает молча, а проходит через короткий разговор с заказчиком. Иногда мы договариваемся исключить менее важное, иногда переносим, иногда добавляем людей. Но решение принимаем вместе и вслух, а не в чьей-то голове в два часа ночи.
В итоге дедлайны у меня всё ещё иногда сдвигаются, и это нормально, потому что живые проекты не бывают предсказуемыми. Но паники и выгорания стало заметно меньше, а доверие с бизнесом — выше. Потому что когда ты не молчишь, а объясняешь цену изменений, тебя начинают воспринимать как партнёра, а не как ресурс, который должен успевать всегда. А теперь вопрос к вам, коллеги: какой приём лучше всего помогал именно вам удерживать дедлайн, когда требования менялись прямо посреди спринта?