Шаблон сбора требований: 7 приёмов, которые я использую в проектах

Шаблон сбора требований оправдывает своё существование, только если заставляет вести трудные разговоры заранее: кто подписывает, кто может заблокировать, как выглядит успех и как быстро должна работать система. Это руководство для руководителей проектов, бизнес-аналитиков и лидеров SAP, которым нужен шаблон, переживающий первый управляющий комитет. Ниже полная структура, которую я использую, с владельцем у каждого раздела, пять разделов, которые я никогда не пропускаю, и семь приёмов для интервью, приоритизации и работы с изменениями. Скопируйте структуру в свой документ и заполните её до начала проектирования.

Однажды я наблюдал, как проект с шестизначным бюджетом рухнул, потому что никто как следует не собрал требования. Клиент ждал одного. Команда разработки построила другое. Виноватыми сделали всех, и вот тогда позвали меня.

Эта картина не редкость. Отчёт PMI Pulse of the Profession 2014 года об управлении требованиями показал, что 47 % неудачных проектов не достигли целей из-за плохого управления требованиями. Я видел, как это происходит, десятки раз.

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

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

Мой клиент из здравоохранения потратил 18 месяцев на внедрение EMR, которой врачи отказались пользоваться. Никто не спросил их, что им нужно в ежедневной работе. Проект закрыли и начали заново.

Позднее обнаружение обходится дорого. Исследование NASA о росте стоимости ошибок показало, что при ошибке в требованиях, обнаруженной при интеграции и тестировании, исправление стоило в 21-78 раз дороже, чем при обнаружении на этапе требований. При обнаружении в эксплуатации множитель составлял от 29 до более чем 1 500. На корпоративной программе это разница между воркшопом и запросом на изменение стоимостью в сотни тысяч.

1. ТребованияБазовая стоимость исправленияВыявлена, пока требования ещё пишутся
2. Интеграция и тестированиемножитель стоимости от 21 до 78Выявлена, когда система построена и проходит тесты
3. Эксплуатациямножитель стоимости от 29 до более чем 1,500Выявлена после запуска системы

Источник: Исследование NASA о росте стоимости ошибок

После того как я узнал это на собственном опыте, вот пять разделов, которые не должен пропускать ни один шаблон требований.

1. Резюме для руководства с блоком подписи

Занятые руководители не станут читать документ требований на 30 страниц. Однажды спонсор утвердил проект, не поняв, что подписывает, а потом вышел из себя, увидев результат. Уложитесь в одну страницу: влияние на бизнес, сроки, ресурсы, ожидаемая выгода и блок подписи на той же странице, чтобы утверждающие не могли сослаться на то, что пропустили важные детали.

2. Карта ролей и влияния

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

3. Бизнес-цели, а не технические требования

Какую проблему мы решаем и как будем измерять успех? Один производственный клиент внедрил систему управления запасами точно по спецификации, и она замедлила работу склада на 20 %. Шаблон должен заставлять заинтересованные стороны определять бизнес-успех через текущий базовый уровень, а не через перечень функций.

4. Функциональные требования, которыми могут пользоваться разработчики

Уберите жаргон. Делайте каждое требование конкретным и проверяемым. «Система должна улучшать клиентский опыт» бесполезно. А вот требование: «Пользователь должен иметь возможность оформить возврат и вернуть деньги менее чем за 3 минуты». Если вы не можете проверить, что оно выполнено, перепишите его.

5. Нефункциональные требования

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

Вот полная структура. Пять разделов выше входят в неё вместе с журналами, которые поддерживают её жизнь после подписания.

Раздел	Что в него входит	Владелец	Кто подписывает
1. Резюме для руководства	Проблема, влияние на бизнес, сроки, ресурсы, ожидаемая выгода. Одна страница с блоком подписи	Спонсор, черновик готовит ведущий бизнес-аналитик	Спонсор и финансы
2. Объём работ и базовая модель развёртывания	Что входит и не входит в объём, ограничения. Для SAP: public edition, private edition или on-premise	Директор программы	Управляющий комитет
3. Карта ролей и влияния	Подразделения, представители, уровень влияния, консультировать или информировать	Ведущий бизнес-аналитик	Спонсор
4. Бизнес-цели	Каждая цель с KPI, его текущим базовым уровнем и целевым значением	Владельцы процессов	Спонсор
5. Функциональные требования	ID (например, REQ-FUN-023), описание, источник, приоритет, критерии приёмки, решение fit-to-standard	Функциональные лидеры	Владельцы процессов
6. Нефункциональные требования	Производительность, безопасность, соответствие, доступность; для SAP подход к расширениям для каждого gap	Архитектор решения	ИТ, безопасность и комплаенс
7. «Парковка»	Отложенные запросы, кто просил, дата следующего пересмотра	Ведущий бизнес-аналитик	Никто, пока требование не переведено в активные
8. Журнал отклонённого	Что отклонено, почему, когда и кем	Ведущий бизнес-аналитик	Спонсор
9. Журнал изменений	Каждое изменение после подписания с влиянием на сроки и стоимость	PMO	Совет по изменениям

1. Используйте «Пять почему» в интервью с заинтересованными сторонами

Спросите «что вам нужно?», и получите список желаний. Спросите о боли: «Что вызывает у вас желание выбросить компьютер в окно?» Затем спросите «почему», и ещё раз «почему», пять раз. Настоящее требование обычно отличается от первой просьбы.

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

2. Создайте «парковку» требований

Значительная часть того, что просят заинтересованные стороны, так и не будет использована. Когда кто-то настаивает на сомнительном, я не спорю. Я кладу это на парковку и раз в месяц отправляю напоминание с вопросом, не перевести ли это в активные требования. Большинство остаётся на парковке навсегда.

3. Используйте правило трёх для тех, кто постоянно меняет решение

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

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

Дайте каждому участнику 100 виртуальных долларов, которые нужно распределить между всеми требованиями. Получить всё нельзя, поэтому деньги идут туда, где важнее. Я делал так с клиентом из финансовых услуг, у которого было более 200 «критических» требований. За час у нас появился реальный топ-20.

5. Нумеруйте каждое требование

Используйте единый формат, например REQ-FUN-023. Он прекращает путаницу «о каком требовании мы говорим?», которая съедает время совещаний. Фиксируйте источник: кто просил и зачем, чтобы знать, кому звонить, когда пункты придётся сокращать.

6. Пересказывайте требования на языке заинтересованной стороны

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

7. Документируйте то, что отклонено

Кто-нибудь вернёт отклонённое требование на пятом месяце. «Мы обсуждали это в апреле, и вот почему решили против» быстро закрывает такой разговор. Без журнала вы получаете тот же спор заново.

Семь приёмов работают на любом проекте. В шаблон для программ SAP нужно добавить ещё три вещи.

Модель развёртывания входит в базовую часть

Зафиксируйте модель развёртывания до сбора функциональных требований: S/4HANA Cloud Public Edition (через GROW with SAP или RISE), Private Edition (обычно через RISE) или on-premise. Она определяет, что возможно. Public edition не допускает модификации ядра, поэтому требования, которые зависят от нестандартных процессов, нужно переформулировать или отклонить. Private edition и on-premise допускают больше, но ценой трудозатрат на обновления.

Соберёте требования до этого решения, и многие из них придётся переписывать, когда оно будет принято.

Решение по расширению для каждого gap

Подход Clean Core от SAP означает, что для каждого gap нужно записанное решение: настроить, расширить через выпущенные API (on-stack с ABAP Cloud или side-by-side на SAP BTP) или отклонить. В public edition это обеспечивает сам продукт. В private edition и on-premise это настоятельная рекомендация SAP, и каждая допущенная вами модификация позднее превращается в работу по обновлению. Внесите решение в раздел 6 шаблона, рядом с производительностью и безопасностью, и дайте одному архитектору право его утверждать. Мой гайд по Clean Core объясняет уровни.

ИИ делает черновики, решают люди

ИИ теперь помогает с бумажной работой. В SAP Cloud ALM есть функция генерации требований: она готовит черновики требований по расшифровкам воркшопов fit-to-standard в рамках шаблона, а оплачивается через AI units. Универсальные ассистенты вроде Microsoft Copilot готовят резюме и протоколы по заметкам совещаний.

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

Разработка программного обеспечения. Добавьте технические ограничения, точки интеграции, пользовательские сценарии (реальные шаги пользователей, а не только функции) и критерии приёмки «прошёл/не прошёл». Мы упустили это в проекте клиентского портала и три месяца спорили, «правильно ли работают» функции.

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

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

Для небольших проектов: Trello, чтобы проводить требования по стадиям утверждения, Google Docs с комментариями для рецензирования и Miro для картирования процессов на воркшопах.

Для корпоративных программ: Jira с дополнением для управления требованиями, Confluence для живых документов (его функции ИИ теперь работают под брендом Atlassian Rovo) и Modern Requirements, если вы работаете в Azure DevOps. В программах SAP система SAP Cloud ALM хранит требования, пользовательские истории и тест-кейсы в одном месте, связанными с дорожной картой SAP Activate.

Инструмент важен меньше, чем связность. Связывайте требования с планом проекта и тест-кейсами и отправляйте автоматические уведомления, когда требование меняется. «Я не знал, что это изменилось» убивает больше проектов, чем плохие инструменты. Когда требования подписаны, как удержать их в таком виде, описано в моём руководстве по предотвращению расползания объёма работ при внедрении SAP, а контрольные точки качества SAP показывают, где подписание требований вписывается в цикл управления.

Шаблон, который никто не открывает после подписания, превращается в театр. Работающие шаблоны короткие, у каждого раздела есть владелец, и их обновляют каждый раз, когда кто-то меняет решение, а в любой программе, которую стоит вести, это происходит каждую неделю.

Каковы 5 этапов сбора требований?

1. Выявление: сбор информации через интервью, воркшопы и наблюдение
2. Анализ: упорядочивание, приоритизация и разрешение конфликтов между требованиями
3. Документирование: составление спецификации (BRD, FRD или пользовательские истории, в зависимости от метода)
4. Валидация: подтверждение, что требования отражают реальные потребности и их можно протестировать
5. Управление: отслеживание изменений до конца проекта

Каждый этап опирается на предыдущий. Спешка на выявлении, а большинство команд спешит именно там, создаёт проблемы на каждом последующем этапе.

В чём разница между BRD и FRD?

Документ бизнес-требований (Business Requirements Document, BRD) охватывает потребности бизнеса: предысторию, цели, заинтересованные стороны, ограничения и высокоуровневые требования. Он отвечает на вопрос «что нужно бизнесу?»

Документ функциональных требований (Functional Requirements Document, FRD) охватывает то, как будет вести себя система: пользовательские истории, поведение системы, интерфейсы и критерии приёмки. Он отвечает на вопрос «что должна делать система?»

Я всегда начинаю с BRD, чтобы добиться согласия бизнеса, прежде чем переходить к FRD. Команды, которые сразу прыгают к FRD, часто строят технически правильную систему, решающую не ту проблему.

Каковы 3 типа требований?

1. Бизнес-требования: зачем существует проект, его цели и показатели успеха
2. Функциональные требования: что система должна делать
3. Нефункциональные требования: насколько хорошо она должна это делать (производительность, безопасность, масштабируемость, соответствие требованиям)

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

Как модель развёртывания SAP меняет сбор требований?

Зафиксируйте её первой. S/4HANA Cloud Public Edition не допускает модификации ядра, поэтому требования, основанные на нестандартных процессах, нужно переформулировать или отклонить. Private Edition и on-premise дают больше гибкости, но каждая модификация добавляет трудозатраты на обновления.

Соберёте функциональные требования до этого решения, и многие придётся переделывать. Добавьте для каждого gap записанное решение о расширении (настроить, расширить через выпущенные API или отклонить).

Что делает требование проверяемым?

Чёткое, измеримое условие «прошёл/не прошёл». Требование «Система должна быть быстрой» проверить нельзя. А «Результаты поиска должны возвращаться менее чем за 2 секунды для 95 % запросов при стандартной нагрузке» можно.

Мой тест: можете ли вы прямо сейчас написать тест-кейс с чёткими критериями «прошёл/не прошёл»? Если нет, перепишите требование. Непроверяемые требования вызывают больше споров при go-live, чем что-либо другое из того, что я вижу.

Как не дать требованиям постоянно меняться?

1. Управление изменениями: любое изменение после подписания документирует влияние на сроки, бюджет и ресурсы до того, как кто-либо его утвердит. Сделайте стоимость изменения видимой.
2. «Парковка»: новые запросы идут на парковку, а не сразу в объём. Пересматривайте раз в месяц. Большинство запросов, которые кажутся срочными, ожидания не переживают.
3. Контрольные точки качества: определите, что значит «требования завершены», и не начинайте проектирование, пока это не достигнуто.

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