Когда требования — это ТЗ, а когда рабочая гипотеза
Степень неопределенности сильно зависит от формата разработки.
Например, в заказной разработке требования почти всегда стараются сформулировать и зафиксировать как можно раньше. Здесь техзадание — это своего рода смета, будущий акт приема-передачи. Всё потому, что у проекта есть конкретный заказчик, заранее согласованный бюджет, сроки и объем работ. Сами требования выступают основой для расчета стоимости и ответственности сторон. Именно поэтому любые изменения чувствительны для всех сторон. Если требования меняются, а сроки остаются прежними, команда оказывается в ситуации, где нужно срочно перекраивать бэклог, ускоряться и иногда жертвовать качеством, чтобы «успеть, как договаривались». Если же меняются и требования, и сроки, это уже болезненно для заказчика: проект дорожает, релиз сдвигается.
В продуктовой разработке изначально принимают тот факт, что «окончательной версии требований» может не быть довольно долго. Продукт живет в изменяющемся контексте: приходят новые данные, решения принимаются на основе метрик, экспериментов, результатов A/B-тестов, анализа, проверок гипотез, меняются цели бизнеса, появляются ограничения или, наоборот, новые возможности. Именно поэтому даже возможна ситуация, когда приоритеты внутри одного релиза могут меняться. Иногда доходит и до более радикальных сценариев: фича уже в разработке, и в какой-то момент ее отменяют. Причины могут быть разными: гипотеза не подтвердилась, сместился фокус продукта, появились более приоритетные задачи или изменились внешние условия. Здесь требования более динамические и живут версиями, а не единственно верной итоговой редакцией.
А кроме того, в продуктовой разработке, как правило, нет жесткой привязки к конкретному сроку сдачи фичи. Конечно, есть планы и сроки «крупными мазками» — например, зарелизиться в этом квартале или в этом году, но при наличии аргументов — данных, метрик, технических рисков — всегда есть пространство для диалога с внутренним бизнес-заказчиком. Сроки можно сдвигать, объем — пересматривать, а решения — откладывать или менять, если это обосновано и прозрачно для всех участников процесса. Неопределенность здесь не исчезает, но она становится частью управляемого процесса, а не источником постоянного конфликта.
Бизнес не знает, чего хочет: реальность проектов
Идеальная картинка, где заказчик приносит четкие, выверенные требования, получает ровно то, что ожидал, и остается полностью доволен, встречается крайне редко. Ситуация, когда требования недостаточно определены, — это не сбой, а особый вариант нормы.
Здесь важно сразу снять одну иллюзию: изменение требований со стороны заказчика — это не ошибка, которую можно один раз разобрать, сделать выводы и больше с ней не сталкиваться. Такая ситуация неизбежна: бизнес редко приходит с полностью сформированным пониманием будущего решения, а по мере работы ожидания, контекст и приоритеты почти всегда уточняются. Чем сложнее продукт и среда, в которой он развивается, тем чаще это происходит.
При этом дело не всегда в том, что требования были плохо собраны на старте, хотя и такое, безусловно, случается. Чаще проблема в другом: заказчик сам до конца не понимает, чего именно он хочет, пока не начинает видеть реальные ограничения, варианты реализации и промежуточный результат. И дело не в том, что заказчик «вредный», просто существует естественный процесс формирования ожиданий. Задача аналитика здесь не искать виноватых, а помочь бизнесу постепенно перевести размытые желания во внятные требования и одновременно показать, где проходят границы возможного.
Я поинтересовалась мнением участников разработки с разнообразными ролями о неопределенности требований и их отношении к этому — и, кажется, это тянет на отдельный материал.
Заказчик не профессионал (и это тоже нормально)
Чаще всего заказчик не понимает, чего именно хочет, не из вредности и не из желания анекдотичного «поиграться со шрифтами». Причина куда прозаичнее: отсутствие профессиональных навыков и вводных данных.
Бизнес может четко чувствовать потребность: нужно автоматизировать процесс, ускорить работу сотрудников, привлечь клиентов, выйти в онлайн или не отставать от рынка, но как именно это должно выглядеть в системе — неясно, четких вводных данных он не приносит.
Например, заказчик понимает, что какой-то участок работы пора автоматизировать, чтобы повысить эффективность процессов или снизить нагрузку на сотрудников. В таких случаях речь идет, например, о разработке АРМ или внутреннего сервиса. В других ситуациях мотивация связана с ростом бизнеса: привлечением клиентов, развитием онлайн-магазина, запуском нового канала продаж.
Бывает и иначе: иногда запрос формируется под влиянием внешних факторов и трендов, без четкого понимания, какую именно проблему нужно решить. Тогда появляются формулировки вроде «сделайте, чтобы работало», «сделайте красиво» или «сделайте, как у конкурентов». В последнее время к этому всё чаще добавляется универсальное пожелание «давайте подключим нейросеть», а для чего и какую реальную потребность должна решить эта фича, изначально не вполне ясно. За этими формулировками почти всегда стоит реальная боль, но не готовое решение. И важно не принять первый предложенный бизнесом вариант как истину, а попытаться разобраться, какую задачу вообще нужно решить.
Когда неопределенность рождается из-за сроков
Эта реальность чаще свойственна продуктовой разработке, где есть графики релизов, ставятся цели и отслеживаются результаты их выполнения. Коммититься на определенную цель — значит обещать выполнить определенный объем работы в оговоренные сроки. Именно горящие сроки часто влияют на то, что требования уже не формулируются, а преподносятся в размытых очертаниях: сделайте MVP, сделайте «примерно вот так». Не обозначены границы дозволенного или допустимое количество «бесплатных правок» и доработок. Или если заказчик настаивает на своем видении решения под давлением сроков, не до конца понимая технические последствия.
Типичный аргумент звучит примерно так: «Давайте сделаем вот так быстренько, это же несложно, потом переделаем». Причина появления таких идей — поверхностное представление о реальной трудоемкости задачи. Например, просит «просто вывести данные списком», не учитывая, что за этим стоит агрегация из нескольких источников, переработка схемы хранения, кеширование и обработка ошибок. С точки зрения заказчика, это выглядит как небольшой UI-штрих, а с технической стороны — как полноценная архитектурная доработка.
Если команда в такой ситуации идет на поводу у запроса «сделать побыстрее», решение почти неизбежно превращается во временный костыль. Оно действительно позволяет уложиться в текущий дедлайн, но закладывает технический долг: усложняет код, нарушает целостность архитектуры и делает последующие изменения значительно дороже и болезненнее. В итоге то, что «сэкономили» на этапе реализации, команда многократно оплачивает позже — при масштабировании, рефакторинге или попытке вернуться к изначально правильному решению.
В таких случаях размытость требований возникает не из-за спешки, а из-за отсутствия договоренностей о правилах игры и ответственности за изменения.
Как аналитик может начать наводить порядок
Если заказчик не понимает реальных ограничений и возможностей разработки, ключевая задача аналитика — снизить тревожность и помочь заказчику структурировать мысли, попытаться собрать максимум требований и конечных целей. Важно внимательно выслушать заказчика, но при этом не цепляться за предлагаемые им варианты решения. Заказчик может ошибаться, а аналитик или продакт-менеджер — незаметно принять это решение как единственно возможное и начать выстраивать вокруг него весь проект, так и не проверив, решает ли оно исходную задачу. Например, ранее я уже рассказывала о методиках сбора требований.
Важно задавать много вопросов и уходить от выбора конкретных решений к обсуждению целей и болей, выяснять на глубину, «что пользователь должен сделать и зачем». Чем больше вопросов задано на этом этапе, тем меньше сюрпризов будет дальше. Запрос на расстановку приоритетов — наше всё, нужно больше разговаривать, обсуждать, обозначать риски, попытаться взять управление в свои руки.
«Это вам обойдется в копеечку»
Часто помогает перевод абстрактных рисков в конкретику, в том числе в деньги и ресурсы. Когда заказчик слышит, что очередная правка означает плюс N человеко-часов или сдвиг релиза на две недели, требования внезапно становятся гораздо более взвешенными, после этого заказчики обычно начинают думать рациональнее. Это касается в особенности меняющихся на ходу требований и размытых приоритетов: нужно всё и сразу, и красиво, и чтобы работало — быстро.
Именно поэтому в заказной разработке железобетонно должны быть: договор, оговоренный бюджет, обозначены четкие сроки, и требования обязаны быть зафиксированы. Каждая новая хотелка превращается в Change Request (запрос на изменение) — формализованный способ зафиксировать, что именно в проекте предлагается поменять и по какой причине. Главное — с помощью него можно управлять изменениями: понять, что меняется, зачем это нужно и к каким последствиям это приведет. Благодаря CR команда может заранее оценить, как правки повлияют на сроки, стоимость и загрузку ресурсов, и принять решение не вслепую, а с пониманием общей картины и рисков.
Если проговорить, к чему приведет смена приоритетов и размытые требования, то это часто само по себе снижает количество новых правок. Когда заказчик понимает, что каждое изменение может привести к сдвигу сроков или пересмотру бюджета, к требованиям начинают относиться более осознанно.
Что делать, если заказчик всё равно настаивает на своем
Но бывают и более радикальные случаи, когда заказчику уже объясняли риски, сроки и последствия, а он всё равно оказывается настойчив и требователен. Что делать в таких случаях?
Помимо перечисления рисков и последствий, здесь важно умение вести переговоры, сохранять уверенность и выстраивать разговор так, чтобы решение принималось не на эмоциях, а с пониманием всех его последствий.
Если заказчик настаивает на том, чтобы «делать именно так», несмотря на то, что это рушит сроки, архитектуру (или здравый смысл), — лучше всего придерживаться тактики контрастных вариантов. Предложить несколько способов реализации, конечно же, с четким описанием стоимости и сроков: быстрый, надежный и дешевый — какой выбираем? Причем важно дать не иллюзию выбора, а реально возможные варианты. Например:
Мы можем сделать так, как вы хотите, но последствия будут следующими:
- Релиз придется сдвинуть на N недель.
- На переделку фронта нам нужен будет еще один разработчик, иначе придется отказаться от вот этих трех фич.
- Наша производительность снизится, потому что придется переделать план разработки и заново расставить приоритеты, а на это тоже нужно время.
- Стоимости разработки вырастет на XX тысяч.
То есть вместо спора или уговоров лучше продемонстрировать цену выбора. После этого появится шанс, что заказчики будут транслировать свою точку зрения взвешеннее, диалог получится более конструктивным.
А кроме того, полезно определить контрольные точки, зафиксировать моменты, после которых изменения будут особенно болезненны. Например, «После утверждения API вносить правки = менять контракт и архитектуру» или «После начала разработки UI изменения дизайна = двойная работа».
Еще можно продемонстрировать заказчику прототип, чтобы зафиксировать согласование. 80% изменений просто отпадают: заказчик наконец видит результат глазами, может «потрогать» интерфейс и точнее сформулировать свои ожидания.
Синхронизация и непрерывная валидация — рабочий вариант для заказчиков, которые могут вносить изменения и запросы на доработку в уже ранее несколько раз утвержденные и зафиксированные требования. Есть смысл буквально собираться на встречу, может быть даже офлайн, если это возможно, и проговаривать: «Мы реализуем именно вот это. Подтверждаете?» И, конечно же, фиксировать договоренность письменно или по почте. Это минимизирует абстракцию и возможные последствия а-ля «Погода меняется — мы переобуваемся».
О фиксации каждого изменения в заказной разработке я уже упоминала. В крупных же компаниях с постоянными короткими итерациями есть свои инструменты, которые помогают свести к минимуму доработки:
- Роадмап. Фиксируем, «что точно делаем», то есть на чём фокусироваться прямо сейчас, а всё остальное, менее приоритетное, — в бэклог.
- Версионирование требований. Каждую версию спецификации сопровождает отметка в истории: удобно возвращаться и откатываться, отслеживать изменения.
- Еженедельная синхронизация и утверждение изменений, чтобы не отклоняться от курса и поставленных целей.
Вредные советы, как работать с неопределенными требованиями
Если заказчик предлагает конкретное решение — сразу делайте именно так
Сказали «нужен вот такой экран» — значит, всё уже продумано, можно даже сразу сделать прототип: так будет наглядно и быстро.
Как правильно:
Сначала зафиксировать проблему и цель, а уже потом обсуждать варианты решения.
Не записывайте договоренности, чтобы не плодить бюрократию
Все и так всё обсудили много раз на встречах, желания заказчика понятны, зачем лишние документы.
Как правильно:
Фиксировать ключевые договоренности кратко и по делу, чтобы всегда можно было вернуться к контексту.
Не уточняйте, что значит «быстро», «просто» и «примерно»
Если заказчик говорит, что это просто, значит, так и есть: он явно больше разбирается в своей «кухне». Ну а про быстро и так всё понятно.
Как правильно:
Уточнять и конкретизировать как можно больше деталей. Сроки, объем работ и имеющиеся ограничения — это базовый минимум.
Если заказчик сказал «давайте пока так, потом переделаем» — соглашайтесь
Сейчас главное — запустить, а потом, когда будет время и ресурсы, переделаем нормально.
Как правильно:
Сразу проговаривать, что временное решение почти всегда становится постоянным. Фиксировать, какие именно компромиссы принимаются сейчас и что придется переделывать позже, если к этому вообще вернутся.
Если заказчик настаивает и требования меняются — просто подстраивайтесь (или нет)
Зачем спорить, если можно тихо переделать, тем самым сохранив отношения с заказчиком. Или сделать, как он хочет, а дальше пусть сам разбирается.
Как правильно:
Каждое изменение приоритизировать, обсуждать последствия, четко проговаривать сроки.
Вместо заключения: как сохранить и заказчика, и команду
В идеале нужно найти баланс, то есть не спорить и не пытаться «продавливать» какое-то решение, а удерживать общую картину и переводить хаотичные желания в понятный и рабочий процесс. В правильном сценарии должна быть выстроена такая структура, в которой бизнес получает ожидаемый результат, а команда не выгорает и не работает в режиме постоянных переделок. А чтобы реальность совпала с ожиданиями, их нужно четко фиксировать.
Важно суметь настроить открытую коммуникацию, найти компромисс, расставить приоритеты: что для нас сейчас важнее — скорость выхода или устойчивость решения? Всегда лучше предложить зафиксировать текущую версию, а правки вынести в следующий релиз: так и качество не потеряем, и сроки выдержим.
Именно в таких формулировках появляется рабочий диалог, где изменения перестают быть хаосом и становятся управляемым процессом.
