Dmitry_Novikov
New member
Я много лет работаю в разработке и не раз попадал в ситуацию, когда требования меняются каждый день. В теории нужно дать точную оценку, но на практике заказчик приносит новую хотелку раньше, чем команда успевает закрыть предыдущую. Поэтому я перестал обещать одну дату и начал продавать не срок, а управляемый процесс с регулярной переоценкой.
Нажать чтобы Перейти на сайт
Однажды мы делали внутренний CRM для отдела продаж. Изначально я оценил MVP в два месяца. Через месяц выяснилось, что интеграций стало в три раза больше, а логика согласования переписывалась каждую неделю. Я честно сказал: если продолжать в том же режиме, срок не определён. Мы ввели еженедельный пересмотр бэклога и стали фиксировать, сколько задач добавляется и сколько исчезает.
Главный приём — оценивать не весь проект целиком, а горизонт одной-двух итераций. Я использую декомпозицию до небольших задач, story points или идеальные часы и считаю velocity. Для руководства даю диапазон: оптимистичный, реалистичный и пессимистичный. Если требования меняются ежедневно, то оценка всего проекта — это не прогноз, а гадание.
Ещё я разделяю discovery, дизайн и разработку. Пока требования не устоялись, мы не строим детальный план на полгода, а делаем прототип, проверяем гипотезы и уточняем критерии приёмки. Любое изменение после старта получает цену: сколько часов оно добавит, что придётся сдвинуть и от чего отказаться. Так появляется бюджет на изменения, а не бесконечная лояльность к правкам.
Узнать подробнее →
Помогает прозрачность. Я показываю заказчику burn-up по объёму, скорость команды и количество изменений за спринт. На одном проекте мы так вышли на разговор: либо фиксируем MVP и запускаем его через три месяца, либо расширяем объём и получаем релиз через пять-шесть. Заказчик выбрал MVP, а остальное ушло в следующие фазы. Это спасло и сроки, и нервы команды.
В итоге я считаю, что при ежедневных изменениях требования нельзя оценивать как неизменный контракт. Нужно оценивать скорость, стоимость изменений и вероятность уложиться в диапазон, а дату делать результатом договорённости о приоритетах. А как вы оцениваете сроки, когда требования меняются каждый день? Что помогает вам сохранять предсказуемость?
По теме советую почитать: Искусственный интеллект в бизнесе: 10 сценариев без хайпа
Однажды мы делали внутренний CRM для отдела продаж. Изначально я оценил MVP в два месяца. Через месяц выяснилось, что интеграций стало в три раза больше, а логика согласования переписывалась каждую неделю. Я честно сказал: если продолжать в том же режиме, срок не определён. Мы ввели еженедельный пересмотр бэклога и стали фиксировать, сколько задач добавляется и сколько исчезает.
Главный приём — оценивать не весь проект целиком, а горизонт одной-двух итераций. Я использую декомпозицию до небольших задач, story points или идеальные часы и считаю velocity. Для руководства даю диапазон: оптимистичный, реалистичный и пессимистичный. Если требования меняются ежедневно, то оценка всего проекта — это не прогноз, а гадание.
Ещё я разделяю discovery, дизайн и разработку. Пока требования не устоялись, мы не строим детальный план на полгода, а делаем прототип, проверяем гипотезы и уточняем критерии приёмки. Любое изменение после старта получает цену: сколько часов оно добавит, что придётся сдвинуть и от чего отказаться. Так появляется бюджет на изменения, а не бесконечная лояльность к правкам.
Помогает прозрачность. Я показываю заказчику burn-up по объёму, скорость команды и количество изменений за спринт. На одном проекте мы так вышли на разговор: либо фиксируем MVP и запускаем его через три месяца, либо расширяем объём и получаем релиз через пять-шесть. Заказчик выбрал MVP, а остальное ушло в следующие фазы. Это спасло и сроки, и нервы команды.
В итоге я считаю, что при ежедневных изменениях требования нельзя оценивать как неизменный контракт. Нужно оценивать скорость, стоимость изменений и вероятность уложиться в диапазон, а дату делать результатом договорённости о приоритетах. А как вы оцениваете сроки, когда требования меняются каждый день? Что помогает вам сохранять предсказуемость?