Как оценить сроки разработки, если требования меняются каждый день

Dmitry_Novikov

New member
Я много лет работаю в разработке и не раз попадал в ситуацию, когда требования меняются каждый день. В теории нужно дать точную оценку, но на практике заказчик приносит новую хотелку раньше, чем команда успевает закрыть предыдущую. Поэтому я перестал обещать одну дату и начал продавать не срок, а управляемый процесс с регулярной переоценкой.


🔗 Нажать чтобы Перейти на сайт


Однажды мы делали внутренний CRM для отдела продаж. Изначально я оценил MVP в два месяца. Через месяц выяснилось, что интеграций стало в три раза больше, а логика согласования переписывалась каждую неделю. Я честно сказал: если продолжать в том же режиме, срок не определён. Мы ввели еженедельный пересмотр бэклога и стали фиксировать, сколько задач добавляется и сколько исчезает.

Главный приём — оценивать не весь проект целиком, а горизонт одной-двух итераций. Я использую декомпозицию до небольших задач, story points или идеальные часы и считаю velocity. Для руководства даю диапазон: оптимистичный, реалистичный и пессимистичный. Если требования меняются ежедневно, то оценка всего проекта — это не прогноз, а гадание.

Ещё я разделяю discovery, дизайн и разработку. Пока требования не устоялись, мы не строим детальный план на полгода, а делаем прототип, проверяем гипотезы и уточняем критерии приёмки. Любое изменение после старта получает цену: сколько часов оно добавит, что придётся сдвинуть и от чего отказаться. Так появляется бюджет на изменения, а не бесконечная лояльность к правкам.


🔗 Узнать подробнее →


Помогает прозрачность. Я показываю заказчику burn-up по объёму, скорость команды и количество изменений за спринт. На одном проекте мы так вышли на разговор: либо фиксируем MVP и запускаем его через три месяца, либо расширяем объём и получаем релиз через пять-шесть. Заказчик выбрал MVP, а остальное ушло в следующие фазы. Это спасло и сроки, и нервы команды.

В итоге я считаю, что при ежедневных изменениях требования нельзя оценивать как неизменный контракт. Нужно оценивать скорость, стоимость изменений и вероятность уложиться в диапазон, а дату делать результатом договорённости о приоритетах. А как вы оцениваете сроки, когда требования меняются каждый день? Что помогает вам сохранять предсказуемость?

📖 По теме советую почитать: Искусственный интеллект в бизнесе: 10 сценариев без хайпа
 
Ох, знакомая боль. Если требования меняются каждый день, любые сроки — это гадание на кофейной гуще. Я бы оценивал не всю фичу, а маленькие вертикальные срезы на 1–3 дня, закладывал буфер 30–50% на переделки и каждое новое требование считал отдельной задачей с влиянием на общий план. Иначе команда выгорает, а дедлайн всё равно уезжает.

А у вас есть человек, который финально решает, что попадает в текущий спринт? Без жёсткого фриза требований хотя бы на неделю даже agile не спасёт. Мне помогает доска «сейчас / потом / никогда» и правило: всё новое — только в обмен на какую-то старую задачу. Как вы договариваетесь с заказчиком, когда он приносит очередную «гениальную» идею?
 
Назад
Вверх