Введение

Всем привет, меня зовут Сергей Прощаев. Я Tech Lead и руководитель направления Java | Kotlin разработки в FinTech, а ещё преподаю на курсах по разработке и архитектуре в OTUS. Сегодня хочу поговорить о теме, которая, казалось бы, лежит на поверхности, но именно в ней чаще всего тонут проекты и страдает разработка. О работе с требованиями. Точнее — о том, почему их нельзя «собрать» раз и навсегда и почему Agile‑требования ничем принципиально не отличаются от любых других, как бы их ни называли.

Мне не раз приходилось видеть, как команды упираются в глухую стену именно из‑за иллюзий вокруг работы с требованиями. Кто‑то уверен, что в начале проекта можно всё предусмотреть и зафиксировать. Кто‑то, наоборот, считает, что в Agile можно вообще ничего не писать, достаточно устных договорённостей. И те и другие потом переписывают код по ночам. Давайте разберёмся, где тут правда, а где опасные заблуждения.

Почему «сбор требований» — это вредный миф?

Фраза «сбор требований» создаёт ложное ощущение, что они уже где‑то лежат готовенькие, как грибы в лесу, — только наклоняйся и складывай в корзину. На деле всё иначе. В большинстве случаев пользователи сами не знают, что им нужно, пока не увидят работающий прототип. Бизнес‑цели могут меняться. Регулятор выпускает новое постановление. Рынок переворачивается. Ждать, что в начале пути у вас будет полная и неизменная спецификация, — это утопия.

Когда я только начинал программировать, я часто попадал в одну и ту же ситуацию. Садился писать код, плохо понимая задачу. Через пару часов начинал «буксовать»: переписывал, правил, но почти не продвигался. Проблема всегда была одной и той же: я не потратил время на то, чтобы по‑настоящему понять, что именно должен сделать. Это не значит, что нужно впадать в аналитический паралич и месяцами рисовать диаграммы. Это значит, что нужно принять как факт: требования никогда не будут полными с первой итерации. И это нормально.

Разработка требований — это итеративный процесс

Представьте, что вы собираете пазл, но коробку с картинкой вам не дали, а часть деталей ещё не напечатали. Примерно так выглядит попытка зафиксировать все требования до начала разработки. Поэтому правильный подход — постепенное уточнение.

Как это работает на практике? Сначала вы определяете бизнес‑цель (зачем вообще делаем продукт). Затем выделяете крупные пользовательские сценарии или задачи. После этого приоритизируете: что пойдёт в ближайший релиз или спринт, а что может подождать. И только те требования, которые попали в ближайший цикл, детализируете до уровня, понятного разработчику и тестировщику. Потом цикл повторяется.

Такой подход решает сразу несколько проблем:

• Вы не тратите время на детальное описание функций, которые, возможно, вообще не понадобятся или изменятся.

• У команды всегда есть достаточно информации для старта, но она не перегружена документацией.

• Пользователи и стейкхолдеры видят промежуточные результаты и могут вовремя скорректировать курс.

В своей практике я много раз убеждался: если пытаться написать «идеальное ТЗ» на старте, то через пару месяцев оно превращается в тыкву. Реальность уходит вперёд, документ устаревает, и его перестают открывать. Гораздо эффективнее — вести «живой» артефакт (будь то список пользовательских историй в Jira, набор сценариев в Confluence или даже Miro‑доска), который постоянно актуализируется по мере получения новых знаний.

Ниже — схема (рис. 1), которая хорошо иллюстрирует итеративный процесс работы с требованиями. Обратите внимание: мы не просто движемся по кругу, а каждый раз уточняем и углубляем понимание.

На старте любого проекта я всегда начинаю с бизнес‑целей и видения — отвечаю на главный вопрос: «Зачем мы вообще это делаем?». Без этого фундамента любая приоритизация превращается в гадание на кофейной гуще, поэтому именно с него и начинается путь.

От целей мы плавно переходим к выявлению общих пользовательских задач. Здесь команда вместе определяет ключевые сценарии работы с продуктом, пока не углубляясь в детали. Этот этап даёт нам общую картинку, но не больше.

Дальше наступает самый важный момент — приоритизация и выбор задач на ближайший цикл. Из всего вороха идей нужно честно отобрать то, что принесёт максимальную пользу прямо сейчас и попадёт в следующий спринт или релиз.

В работу берём только этот сфокусированный набор. Его мы детализируем до уровня, понятного разработчикам. Здесь я (или бизнес‑аналитик, если он есть) прорабатываю критерии приёмки, краевые сценарии и нефункциональные требования ровно настолько, чтобы разработчики и тестировщики могли стартовать без лишних вопросов.

После этого начинается сам производственный цикл — разработка и тестирование. Команда воплощает требования в коде, проверяет их и готовит рабочий инкремент продукта.

Ключевой момент наступает на демонстрации и получении обратной связи. Именно здесь стейкхолдеры видят живой результат, а не сухие описания. И именно здесь рождаются два вида сигналов.

Первый — прямые замечания и уточнения по уже сделанному. Они могут отправить нас назад к этапу выявления пользовательских задач, если выяснится, что какой‑то сценарий мы поняли неправильно или упустили полностью.

Второй — новые инсайты и требования, которые не ломают текущие планы. Они спокойно уходят в общий бэклог, где потом пройдут приоритизацию и будут честно конкурировать с другими задачами за место в следующих циклах.

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

Agile‑требования: та же суть, другая упаковка

Второе распространённое заблуждение звучит так: «В Agile мы не пишем требования, у нас User Stories». Или наоборот: «У нас серьёзный проект, нам нужны Use Cases и функциональные спецификации, а не эти ваши стикеры». На самом деле, с точки зрения конечной цели — дать разработчику достаточно информации для создания работающего решения — разницы нет.

Разработчику всё равно, как называется документ, из которого он берёт информацию. Ему нужно понимать:

• Что именно должно быть сделано (функциональность).

• Для кого и с какой целью.

• Какие есть ограничения и краевые случаи.

• Как проверить, что всё работает правильно.

Эту информацию можно упаковать в Use Case, в User Story с критериями приёмки, в функциональное требование с тест‑кейсами. Суть не меняется. Меняется только способ подачи и момент, когда эта информация становится доступна.

В традиционном подходе часто пытаются описать всё заранее. В Agile требования детализируются «точно вовремя» — непосредственно перед тем, как команда берёт задачу в разработку. Это не отменяет необходимости в документации, но делает её более компактной и живой. Как говорится, «работающий продукт важнее исчерпывающей документации», но это не значит «документация не нужна».

На схеме ниже (рис. 2) показано, как роли в Agile‑команде взаимодействуют при работе с требованиями. Владелец продукта отвечает за видение и приоритеты, а бизнес‑аналитик (если он есть) помогает формализовать и детализировать запросы до уровня, понятного разработчикам.

На этой схеме показано, как информация о требованиях циркулирует между бизнесом и командой разработки.

Начнём с левой части. Стейкхолдеры — это представители бизнеса, пользователи и другие заинтересованные лица, которые формируют исходные запросы. Именно от них исходит поток, помеченный как «Видение, потребности, обратная связь».

Они не пишут технические задания, а делятся проблемами, ожиданиями и реакцией на уже сделанное. Этот поток направлен к Владельцу продукта — ключевой фигуре, отвечающей за ценность того, что создаёт команда.

Владелец продукта фильтрует входящие запросы, сопоставляет их с бизнес‑целями и формирует «Приоритеты, цели продукта», которые передаются дальше.

Следующий узел — Бизнес‑аналитик. В некоторых командах эта роль совмещена с владельцем продукта, но на схеме они разделены, чтобы подчеркнуть разницу функций.

Аналитик получает приоритеты и цели, после чего превращает их в «Уточнённые истории, критерии приёмки». Это уже не абстрактное «хотим админку», а конкретное описание с чёткими границами и проверяемыми условиями, которое передаётся Разработчикам.

Разработчики на основе историй и критериев создают «Рабочий инкремент» — ту часть продукта, которую можно протестировать и показать. Инкремент поступает Тестировщикам, которые проверяют его на соответствие критериям приёмки и возвращают «Результаты тестирования» обратно бизнес‑аналитику.

Это критически важная обратная связь внутри команды: если что‑то работает не так, как задумано, информация не уходит сразу к стейкхолдерам, а сначала проходит внутреннюю валидацию.

Когда инкремент стабилен, бизнес‑аналитик сообщает владельцу продукта о «Готовности фичи». Владелец продукта, в свою очередь, организует «Демонстрацию» стейкхолдерам, замыкая внешний цикл обратной связи. Именно здесь рождаются новые идеи и уточнения, которые снова поступают на вход процесса в виде потребностей и обратной связи.

Таким образом, схема наглядно показывает разделение труда: стейкхолдеры отвечают за «что ценно», владелец продукта — за «что и когда делать», бизнес‑аналитик — за «как именно описать», разработчики и тестировщики — за «как сделать и проверить». А петли обратной связи — внутренняя и внешняя — гарантируют, что продукт не уходит в сторону от реальных потребностей бизнеса.

Что в итоге?

Разработка требований — это не одноразовый этап, а непрерывный процесс уточнения и адаптации. Не важно, называете вы это User Stories, Use Cases или функциональными спецификациями. Важно, чтобы команда и заказчик имели общее понимание того, что будет сделано в ближайшей итерации, и могли быстро реагировать на новую информацию.

Итеративный подход позволяет снизить риски, не плодить ненужную функциональность и доставлять ценность бизнесу быстрее. А грамотная документация (ровно в том объёме, который нужен команде) страхует от потери знаний и упрощает онбординг новых участников.

Если вы хотите научиться делать это системно — задавать правильные вопросы, выявлять скрытые риски, проектировать интеграции без ночных хаток и писать документацию, которая действительно работает, — приглашаю вас на курсы по аналитике в OTUS.

Если вы узнали в статье свои проекты — скорее всего, проблема не в разработке, а в формулировке требований. Эту тему подробнее рассмотрим на открытом уроке «Как не допустить ошибок при написании пользовательских историй (User Story)?» — с примерами и разбором типичных провалов. Встреча пройдет 5 мая в 20:00. ☛ [Записаться на открытый урок]