Недавно на Хабре вышла статья Сергея Прощаева «Требования в Agile: полный гайд с работающими практиками». Тема требований остаётся одной из самых конфликтных в разработке. Автор верно подмечает, что команды часто впадают в две крайности. Одни пытаются предусмотреть всё в самом начале и пишут исчерпывающее техническое задание. Другие считают, что в Agile можно вообще ничего не фиксировать и достаточно устных договорённостей. И те и другие потом переписывают код по ночам. И те и другие потом переписывают код по ночам. Решение, которое предлагает Сергей, звучит разумно: итеративное уточнение, пользовательские истории, критерии приёмки, демонстрации и обратная связь.
Проблема в том, что это решение подано как универсальное. И в этом кроется системная ошибка, которая может дорого обойтись командам, работающим над софтом для производственных предприятий, строительных организаций или финансовых департаментов. Я хочу разобрать несколько ключевых тезисов статьи и показать, где они перестают работать, а также предложить альтернативный взгляд, который не отрицает Agile, но существенно его дорабатывает для определённого класса задач.
Тезис первый: «Сбор требований — вредный миф»
Сергей пишет, что фраза «сбор требований» создаёт ложное ощущение, будто требования уже где-то лежат готовенькие. В стартапе или при разработке пользовательского приложения это действительно так. Но когда мы автоматизируем расчёт налога на прибыль или проверку наличия оснастки перед запуском станка, требования в самом прямом смысле уже лежат готовенькие. Они зафиксированы в Налоговом кодексе, в технологических регламентах. Их не нужно итеративно выявлять на демонстрациях. Их нужно извлечь из нормативных документов, правильно интерпретировать и зафиксировать. Пропустить этот этап и заменить его короткой пользовательской историей значит гарантированно упустить критические детали.
Тезис второй: «Разработчику всё равно, как называется документ»
В статье утверждается, что форму можно менять, суть остаётся той же. С этим нельзя согласиться. Формат пользовательской истории с критериями приёмки хорош для функциональности, которая может меняться от итерации к итерации. Для требования, основанного на нормативе, который не изменится ни через неделю, ни через год, нужен другой формат. Нужно описание алгоритма, формулы, учёт всех возможных состояний и негативных сценариев. Короткая история в Jira этого не вмещает.
Второе и более важное предположение спрятано в словах Сергея «превращает их в уточнённые истории, критерии приёмки». В мире стартапов история и критерии приёмки это действительно достаточный артефакт для разработчика. Там цена ошибки невелика. Но в мире, где ошибка в расчёте налога ведёт к штрафу, а ошибка в управлении станком к поломке оборудования, критериев приёмки недостаточно. Нужен алгоритм. Нужна формула. Нужно описание того, как именно система должна себя вести в разных ситуациях, причём не просто «должна проверять наличие оснастки», а точная последовательность шагов с учётом всех возможных состояний склада. Формат User Story с критериями приёмки просто не вмещает в себя эту сложность. Он хорош для функциональности типа «пользователь хочет видеть список заказов». Он плох для функциональности «расчёт налога на прибыль с учётом временных разниц».
Автор статьи говорит, что аналитик создаёт «конкретное описание с чёткими границами и проверяемыми условиями». Но он умалчивает, в каком именно формате это описание существует. В стартапе это может быть пара абзацев в Jira. В банке это будет отдельный документ на несколько страниц, который потом пройдёт несколько итераций согласования с тестировщиком и бизнесом. И этот документ будет называться не «уточнённая история», а «техническое задание» или «функциональная спецификация». Разница не просто в названии, а в глубине проработки и в уровне ответственности.
Более того, в регулируемых отраслях документация выполняет ещё одну функцию: она фиксирует ответственность. Если через год налоговая спросит, почему программа посчитала налог именно так, ответ «мы так договорились на груминге» не подойдёт. Нужен утверждённый и подписанный документ.
Тезис третий: роль аналитика как посредника
В статье поток информации проходит через цепочку от заказчика к владельцу продукта, затем к аналитику и только потом к разработчику. В гибких методологиях такую цепочку часто критикуют как лишнее звено, замедляющее процесс. Считается, что разработчик должен общаться с бизнесом напрямую. Однако в сложных предметных областях прямой диалог между программистом и, скажем, начальником цеха или главным бухгалтером редко бывает продуктивным. Они говорят на разных языках. Начальник цеха оперирует понятиями оснастки, переналадки, технологических карт. Разработчик мыслит структурами данных, алгоритмами и интерфейсами. Без промежуточного звена, способного перевести производственную задачу на язык технических требований, велик риск упустить критические детали. Аналитик в данной ситуации выступает не секретарём, а адаптером, который выясняет нюансы, фиксирует негативные сценарии и готовит документ, понятный обеим сторонам.
Тезис четвёртый: роль тестировщика на этапе требований
В схеме Сергея тестировщик появляется после того, как код написан. В реальных проектах с высокой ценой ошибки тестировщик подключается на этапе создания требований. Он проверяет техническое задание на полноту, ищет логические недочёты и пропущенные негативные сценарии. Исправить неточность в документе стоит час работы аналитика. Переписывать из-за неё готовый код придётся несколько дней. Это не бюрократия, а банальная экономия ресурсов.
Тезис пятый: бесконечный цикл демонстраций
Автор описывает цикл обратной связи как безусловное благо: заказчик видит инкремент, рождаются новые идеи, они попадают в бэклог. Но он не упоминает, кто и как этот цикл останавливает. Без жёстких критериев готовности и воли владельца продукта говорить «нет» или «да, но отдельной задачей» команда может месяцами дорабатывать одну и ту же функцию. Аппетит приходит во время еды, и это нормально. Ненормально, когда это превращается в бесконечный дрейф требований и потерю темпа поставки.
Где же правда
Правда в том, что не существует единого подхода к работе с требованиями, одинаково пригодного для всех проектов. Есть требования, которые можно и нужно уточнять итерациями. Для них отлично подходят пользовательские истории и демонстрации. А есть требования, зафиксированные в нормативах и стандартах. Для них нужен другой процесс: детальная проработка, формальное техническое задание, проверка тестировщиком до передачи в разработку, подпись ответственного лица.
Эти два потока могут и должны сосуществовать в рамках одного проекта. Для наглядности представим этот гибридный подход словесно.
Представьте воронку, в которую поступают все запросы от бизнеса. На входе они сразу разделяются на два рукава. Первый рукав предназначен для нормативных требований, которые жёстко зафиксированы и не подлежат изменению в ходе разработки. Здесь аналитик изучает нормативные документы, пишет подробное техническое задание, затем тестировщик проверяет его на полноту и ищет логические недочёты. После этого документ согласовывается с бизнесом и утверждается подписью. Только после подписания техническое задание попадает разработчику, и тот пишет код строго по документу.
Второй рукав предназначен для пользовательских сценариев, которые могут уточняться по мере получения обратной связи. Здесь аналитик оформляет короткую историю с критериями приёмки, она попадает в бэклог, команда включает её в ближайший спринт, разработчик создаёт работающий фрагмент, и команда демонстрирует его бизнесу. После демонстрации собирается обратная связь, и при необходимости история уточняется и возвращается в бэклог для следующей итерации.
Важно, что эти два потока не смешиваются. Нормативные требования не превращаются в бесконечные итерации, а гибкие истории не требуют многомесячного согласования. Такой подход позволяет сохранить скорость разработки там, где это возможно, и обеспечить надёжность там, где это необходимо.
Пример из практики: как два подхода уживаются в одной задаче
Рассмотрим сквозной пример, который наглядно показывает, как в рамках одной и той же функциональности могут применяться оба подхода. Представьте, что разрабатывается система управления заданиями для цеха. От начальника цеха приходит задача: перед запуском партии деталей на станок система должна проверять наличие необходимой оснастки.
Первая часть этой задачи содержит жёсткое нормативное требование. Оснастка это не просто строчка в справочнике. На заводе она учитывается как группа номенклатуры, внутри которой находятся конкретные позиции: фрезы, резцы, свёрла и другой инструмент. У каждой позиции есть собственное состояние, зафиксированное в технологических регламентах предприятия. Она может находиться на складе и быть готовой к использованию. Может быть отправлена на переточку и временно недоступна. Может быть зарезервирована под другой срочный заказ. Может числиться в базе, но по факту быть списанной по акту износа. Система должна проверять доступность конкретной позиции, а не просто факт наличия чего-то в группе. Если система пропустит задание на станок, а нужной позиции в доступном состоянии не окажется, производство встанет. Цена простоя значительная. Эти правила не меняются от спринта к спринту и не зависят от того, понравился ли начальнику цеха интерфейс. Поэтому данная часть требования оформляется как полноценный раздел технического задания. Аналитик выясняет все возможные состояния оснастки, описывает алгоритм проверки для каждого случая, затем тестировщик проверяет документ на пропущенные сценарии. После согласования и подписи техническое задание уходит разработчику, и тот реализует логику строго по документу.
Вторая часть той же задачи касается пользовательского интерфейса и оповещений. Как именно система должна сообщать оператору о недоступности оснастки? Достаточно ли красной иконки в интерфейсе или нужно отправлять уведомление мастеру смены? Должна ли система предлагать альтернативную оснастку, если основная недоступна? Эти вопросы невозможно решить заранее, потому что они зависят от того, как операторы реально работают с системой. Здесь как раз и пригождается гибкий подход. Команда оформляет пользовательскую историю с критериями приёмки, реализует простой вариант оповещения, показывает начальнику цеха, собирает обратную связь. На демонстрации выясняется, что операторы часто не замечают красную иконку, потому что работают с другим монитором. Тогда в следующей итерации добавляется звуковой сигнал или уведомление на почту мастеру. Эти доработки не затрагивают нормативную логику проверки состояний оснастки и не несут риска остановки производства.
Таким образом, в одной задаче мирно уживаются два подхода. Нормативная часть фиксируется в техническом задании с подписью и проверкой тестировщика до написания кода. Пользовательская часть уточняется итерациями через демонстрации и обратную связь. Граница между ними проходит там, где заканчиваются жёсткие регламенты и начинается удобство работы.
Опасность бесконечных демонстраций на том же примере
Предположим, команда разработала проверку доступности оснастки и показала её начальнику цеха. Тот видит работающий функционал и говорит: «Отлично, а теперь добавьте сюда ещё проверку исправности самой оснастки по данным последнего технического осмотра». Это полезное дополнение, но оно не входило в исходный объём. Если владелец продукта не скажет твёрдое «нет» или «да, но отдельной задачей», команда начнёт расширять текущую функцию. Спринт за спринтом будут добавляться новые проверки, а другие важные задачи останутся без движения. В итоге продукт не получит вовремя нужную функциональность, а команда потеряет темп. Поэтому критерии готовности должны быть жёсткими. Как только они выполнены, задача закрывается. Новые идеи фиксируются отдельно и проходят обычный цикл приоритизации.
Вывод
Статья Сергея Прощаева правильно указывает на две вредные крайности в работе с требованиями. Но предлагаемое им решение, при всей его разумности для одних проектов, не подходит для других. Правда не в Agile и не в Waterfall. Правда в умении различать природу требований и выстраивать под них разные процессы в рамках одного проекта. Убеждение, что можно написать полное ТЗ на старте, вредно. Убеждение, что всё можно упаковать в истории с критериями приёмки, вредно не меньше. Главное умение аналитика — вовремя понять, где нужна гибкая история, а где жёсткий документ с подписью. Только такой баланс позволяет команде не переписывать код по ночам. Не потому, что они угадали все требования заранее. И не потому, что они обходятся устными договорённостями. А потому, что они зафиксировали ровно то, что необходимо зафиксировать, и оставили пространство для манёвра там, где это уместно.