Идея написать статью пришла ко мне, когда я читала книгу «Цветы для Элджернона». Кто не знаком с произведением, советую его прочитать: это пронзительный психологический роман, в котором мужчина с нарушениями интеллектуального развития по имени Чарли стал гением благодаря научному эксперименту. И хотя цель была высокой и благородной, а результат — достойным, герой доставил достаточно хлопот ученым на своем пике развития интеллекта. Что-то все-таки пошло не так, и постепенно Чарли потерял все знания, которые ему открылись. В какой-то момент чтения я подумала: а ведь похожим образом ведут себя требования. Они сначала простые, понятные. Потом бац! Они начинают умнеть, эволюционировать, требуют больше ресурсов и в конечном счете создают хаос и порой даже рушат текущие процессы.
В одном из проектов, где я работала аналитиком, эволюция требований была не гипотезой, а стилем жизни. Хотелки менялись как при проработке новых фич, так и просто из ниоткуда.
Сегодня в блоге ЛАНИТ на Хабре я хочу поделиться десятью шагами из своего опыта, которые помогали моей команде справляться с ситуациями, когда требования росли быстрее, чем их успевали зафиксировать.
Для тех, кому удобнее краткая выжимка, ниже прикладываю чек-лист 10 приемов по борьбе с растущими требованиями, а далее в статье раскрою каждый из шагов детальнее.
Оценка задач на стадии идей.
Переоценка при изменениях — без жалости.
Разбивка задач на детали и снятие эффекта «просто кнопка».
Подготовка двух вариантов оценки — MVP и Full Scope.
Закладывание буфера (коэффициента) на форс-мажоры.
Оперативное привлечение разработчиков к обсуждению «рискованных» задач.
Умение говорить «нет» через факты.
Эскалация противоречий, чтобы не оставаться в одиночку.
Замораживание требований на этапах релиза.
Письменное фиксирование договоренностей.
А теперь подробнее.
Оценка задач на начальном этапе
Хорошей практикой может быть оценивание фичей сразу после их появления. Это позволит понять объем работ и ресурсов, необходимых для реализации.
Даже на стадии идеи может быть полезно дать предварительную, пусть и грубую, оценку. Например, «это займет минимум 10 спринтов (или 100 человеко-дней)». Такая информация может повлиять на решение бизнеса: либо отказаться от задумки, либо подойти к ней более осознанно.
Даже если требований нет до конца, черновая оценка помогает определить границы — насколько это сложно, дорого, долго.
Из практики
В начале каждого квартала мы с командой получали от бизнеса большой список потенциальных задач на ближайшие 3 месяца (часто этот перечень оказывался настолько перегружен, что не укладывался не только в квартал, но и в полгода). Каждую хотелку нам нужно было верхнеуровнево оценить — хотя бы грубо прикинуть трудозатраты. Далее именно на основе этих оценок руководство приоритезировало доработки и формировало финальный список задач, которые уже реально можно было успеть реализовать за квартал и которые спускались к нам в работу.
Переоценка задач при изменении требований
«Я начал замечать, что вещи, которые я делал раньше легко, теперь требуют гораздо больше усилий», — Чарли, когда начал терять способности (из книги «Цветы для Элджернона», Дэниел Киз).
Оценки оценками, но меняющиеся требования никто не отменял. А если они изменились, то предыдущая оценка скорее всего теряет актуальность.
В таком случае полезно возвращаться к первичным расчетам и пересматривать их с учетом новых вводных. Это помогает сохранить реалистичное представление о трудозатратах и сроках. А далее актуализированные оценки можно использовать для общения с бизнесом — это способствует прозрачности и совместному принятию решений (об этом еще немного в пунктах ниже).
Из практики
Нашей команде достаточно часто приходилось пересматривать изначальные оценки, потому что уровень неопределенности некоторых задач на бизнес-уровне изначально был очень высок. По мере того, как уровень неопределенности снижался, требования становились прозрачнее и зачастую сложнее.
Однажды от бизнеса пришел запрос внедрить в нашу систему возможность подписания контрактов новым способом, с чем ранее наша система вообще не сталкивалась. Требования при этом были очень верхнеуровневые. Тем не менее, был проведен первоначальный анализ, и на основе его были оценены приблизительные трудозатраты. После получения результатов оценок и открытых вопросов от всех команд, на кого спустилась доработка, заказчики сформировали более четкое видение задачи и более детальные требования. Далее потенциальным участникам доработки (и нашей команде в том числе) пришлось все переоценить (или дооценить), и, как оказалось, оценка фичи кратно увеличилась и стало понятно, что на наших системах данную доработку делать просто невыгодно.
Разбивка оценки задач на детали
Уже неплохо, если команда дает хотя бы приблизительную оценку на доработку целиком. Но в части оценок может быть очень полезным представление ее в деталях, то есть в разбивке по составляющим (например, правка макетов, доработка интеграции, которая, в свою очередь, включает изменение маппинга и логику передачи атрибутов, и т.д.) и оценивание каждой выявленной составляющей по направлениям (аналитика, разработка, тестирование).
Это помогает заказчикам лучше понять структуру трудозатрат, а команде, особенно аналитикам, — быстрее вспомнить контекст задачи при дальнейшей проработке.
Такая детализация может помочь избежать высказываний вроде «Почему так долго?» или «Это же просто кнопка!», формируя доверие и общее понимание процесса между командой и заказчиками.
Из практики
Однажды нам нужно было снять обязательность одного поля в интеграции со смежной системой. Оценка была около 10 человеко-дней. Бизнес удивился, но подробная детализация (доработка старой интеграции, правки avro-схемы на обеих системах, а еще аналитика и тестирование) сняла все вопросы.
Оценивание и MVP, и полного Full Scope
На этапе обсуждения новых требований хорошей практикой может быть оценивание сразу двух сценариев:
минимальный объем (MVP) — что нужно сделать, чтобы задача заработала в принципе;
максимальный охват (Full scope) — что будет, если реализовать все, что заказчик попросил, чтобы все было красиво и без «костылей».
Такой подход может помочь заказчику увидеть варианты и принять более осознанное решение. Вместо одной жесткой оценки появляется возможность выбора: «сделать минимально за 3 недели» или «полноценно за 3 месяца».
Это также может привести к снижению количества типичных вопросов вроде «А можно как-то попроще?» и «А потом допилите?», позволяя лучше управлять ожиданиями и ресурсами.
Из практики
После внедрения данного подхода количество уточнений от заказчиков типа «А можно что-то из изначальной оценки убрать?» или «А можно как-то оценку сократить?» уменьшилось, так же, как и время на поиск устраивающего всех решения.
Конечно, такие вопросы все равно порой поступали, но уже скорее в разрезе: «А можно все-таки Full-scope, но без какой-то мелочи из нашего детализированного описания оценки?»
Планирование места для неожиданностей
«Я никогда не знал, что перемены могут наступать так внезапно и оставлять тебя без возможности подготовиться», — Чарли (из книги «Цветы для Элджернона», Дэниел Киз)
В оценках фичей или при планировании спринтов закладывание небольшого процента времени на неожиданные ситуации может сыграть положительную роль.
На практике случаи, когда появляется срочное «нужно было вчера», а команда уже загружена по максимуму, — не редкость. В таких условиях заранее предусмотренный буфер времени может стать спасением.
Например, если по расчетам команда может закрыть задачу за 45 человеко-дней, добавление хотя бы 5 дней на «сюрпризы» может позволить сохранить контроль над сроками и не перегрузить команду.
Важно помнить — это не время на всякий случай, а инструмент для управления рисками. Хотя формально такие резервы не всегда приветствуются, на практике они часто становятся тем, что позволяет довести спринт до конца без срывов и переработок.
Оперативное привлечение разработки к обсуждению при нестандартных хотелках
Порой проведение детального оценивания оказывается лишним, если на ранних этапах аналитики становится понятно, что доработка может поломать текущую логику и повлиять на стабильность системы. В подобных случаях может оказаться эффективным сразу подключать разработчиков к обсуждению, чтобы быстрее прояснить картину, оценить архитектурные риски и возможные последствия для сроков проекта.
Сломает ли эта хотелка старую логику? Затронет ли другие доработки?
Такой подход может помочь избежать ненужной работы: бизнес, получив информацию о возможных последствиях, может отказаться от изначальной идеи или предложить альтернативный вариант решения.
Из практики
В рамках работ по импортозамещению нам нужно было отказаться от сквозного использования CRM ID во всем процессе, на всех участниках. На нашей системе точек использования различных CRM ID (продукта, клиента и др.) было немало, отказ от них происходил постепенно. Так вот, когда однажды пришел запрос на снятие обязательности с очередного CRM ID, я вспомнила, что у нас была коварная логика, завязанная на этот атрибут, не описанная в документации, но когда-то реализованная на «костылях», потому что нужно было срочно. Я сразу привлекла разработчика к обсуждению. Он посмотрел код, и действительно — если бы мы просто отказались от атрибута (= сделали бы его необязательным), мы бы сломали большой пласт внутренней логики. Я передала данную информацию заказчику, и мы вместе сразу начали обсуждать другие варианты решения.
Умение слушать заказчиков, но говорить «нет» на фактах
«Я чувствую, что все, чего я хотел, больше не поддается контролю», — Чарли, осознавая спад (из книги «Цветы для Элджернона», Дэниел Киз).
Взаимодействие с заказчиком подразумевает уважительное отношение к его приоритетам и идеям. Однако бывают ситуации, когда новая доработка не вписывается в текущие сроки. В подобных случаях полезно опираться на объективные аргументы (ваши файлы с оценками, обдуманные потенциальные последствия и риски) и мягко обозначать границы возможного.
Формулировка «нет» может строиться не на запрете, а на выборе.
«Это можно реализовать, но потребуется 10 дней. Если берем, то от чего можем отказаться?»
«Какие риски готовы принять, если внесем это изменение?»
«Готовы ли вы сместить сроки релиза, если к нему доработка точно не будет готова?»
Эскалация противоречий — как способ прийти к решению
Бывают ситуации, когда изменения выходят за рамки зоны ответственности аналитика или между заинтересованными сторонами возникают противоречия в приоритетах. В таких случаях может оказаться полезным привлечение лида, владельца продукта (PO), руководителя направления или других лиц, принимающих решения.
Хорошей практикой может стать организация встречи с подготовленной фактурой:
текущие оценки и ограничения: «Объем планируемых доработок превышает рассчитанный “стакан”»;
информация о приоритетах и пожеланиях разных заказчиков;
возможные варианты: какие задачи можно перенести, сдвинуть, переоценить;
запрос «Для движения вперед нам нужна управленческая точка принятия решения».
Из практики
Я собрала прозрачную картину: оценки, список рисков, зависимости между фичами. И когда бизнес захотел добавить в релиз еще одну доработку «на этой неделе», я на фактах объяснила, что это добавляет дополнительно 12 дней, а значит сдвигает релиз. Заказчики все равно настаивали взять хотелку в релиз, не соглашаясь убирать что-то другое. Тогда я передала всю фактуру на уровень выше (лид и ПО) и именно там было принято решение, что доработку лучше все-таки перенести в следующий квартал.
Важно: даже если вы сделали все, что могли (собрали оценки, подсветили риски, аргументировали невозможность), а решения так и нет, то помните, что порой лучшая аналитическая работа — это своевременная эскалация.
Определение точки заморозки требований без боязни Agile
Помочь снизить риски может установление момента, после которого изменения в требованиях не принимаются без особого согласования.
Да, в Agile говорится: «Изменения требований приветствуются даже на поздних этапах разработки». Но реальность в крупных проектах такова, что бесконечные изменения без ограничений быстро приводят к хаосу.
Поэтому на практике может быть полезно применять такой подход:
при получении новой задачи «в этот релиз» на позднем этапе разработки не отказывать в ней, а предлагать включать ее в backlog и рассматривать в следующих спринтах или после текущего релиза;
при необходимости срочного внедрения — рассматривать возможность взять новую доработку, компенсируя это переносом или исключением других задач из плана на текущий релиз.
Фиксирование договоренностей с бизнесом в почте
«Я перечитываю свои записи, чтобы понять, где и когда началась путаница», — Чарли, в попытке зафиксировать свою деградацию (из книги «Цветы для Элджернона», Дэниел Киз).
Если требования мутируют, всплывает еще одна боль: «А мы это вообще согласовывали? А кто сказал, что это нужно? Почему сделали не то?»
Именно поэтому фиксирование договоренностей в письмах — не бюрократия, а инструмент защиты команды и продукта.
Преимущества такого подхода:
у заказчика появляется чувство контроля и уверенность: «Мы договорились именно об этом»;
у команды появляется ясная отправная точка: работа ведется строго по согласованным требованиям;
если вдруг хотелка превращается в «я такого не просил», всегда можно просто переслать письмо и напомнить о договоренностях.
Из практики
Порой у нас возникали ситуации, когда спустя время заказчики не совсем помнили, на чем же именно завершились наши обсуждения и какие решения в результате мы вместе зафиксировали. Из-за этого кто-то из бизнеса ожидал увидеть в реализации иной вариант. Резонно на показах мы получали вопрос: «А почему так? Мы же вроде решали, что будет иначе».
В таких ситуациях на помощь приходила переписка с подробным описанием принятых решений и согласований, которая помогала быстро прояснить ситуацию и избежать недоразумений.
А почему вообще «умнеющие» требования — это риск
Изначальные оценки перестают быть актуальными уже через несколько дней.
Фичи начинают зависеть от того, чего еще нет.
Команда теряет фокус, а бэклог превращается в лавину.
Разработчики и тестировщики не всегда понимают, что именно пилят.
Сложно отследить, что именно мы обещали заказчику.
В заключение я бы хотела сказать, что требования не всегда стабильны. Они развиваются, адаптируются, эволюционируют, как сам продукт и его пользователи.
Наша задача — не остановить развитие, а создать условия, в которых рост будет управляемым: с оценками, коммуникацией с заказчиком и, самое главное, уважением к бизнесу, команде и здравому смыслу.
Если у тебя были такие «умнеющие» требования — поделись своим опытом в комментариях, как ты справлялся с эволюцией хотелок.
А если пока с таким не сталкивался — пусть эти 10 приемов станут твоим навигатором на случай, когда фича вдруг решит стать доктором наук.
*Статья написана в рамках ХабраЧелленджа 4.0, который прошел в ЛАНИТ весной 2025 года. О том, что такое ХабраЧеллендж, читайте здесь.