🔥 РАЦУХА #187: Используйте CBOK, чтобы говорить с бизнес-аналитиками на одном языке и получать нужные требования

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

Как это работает: требования расходятся с ожиданиями не потому, что аналитики плохо пишут. Чаще их пишут без опоры, когда никто не зафиксировал, зачем компании это изменение и как понять, что оно удалось. Документ бизнес-требований (BRD) даёт эту опору. До любых функций в нём записывают цель изменения, показатели успеха и явную границу: что входит в решение и что не входит. Когда цель и граница записаны и согласованы, спорить приходится с документом, а не с памятью участников. Разработчик видит, ради чего делается каждая функция, а бизнес заранее подтверждает рамки и не может «вспомнить» о новых желаниях в конце. Структура документа опирается на BABOK, Вигерса и ISO/IEC/IEEE 29148, поэтому вы получаете общий язык с аналитиками, а не очередной самодельный шаблон.

Как это выглядит процессом

Схема живая: её можно открыть на весь экран, а в OrgDevTools — скопировать себе и адаптировать под свою компанию. Фиолетовые шаги может взять на себя ИИ-агент.

Простое действие с мгновенным эффектом (до 30 минут): выберите задачу, которую сейчас делает разработка. Попросите заказчика с бизнес-стороны и разработчика по отдельности, не сговариваясь, написать одной фразой, какой результат должна дать эта задача и как понять, что она удалась. Сравните ответы. Если фразы заметно расходятся, проблема не в конкретном аналитике, а в том, что общей цели нигде не записано.

Что делать дальше:

1. Возьмите один-два текущих проекта и прогоните их требования через структуру BRD: есть ли записанная цель, показатели успеха и граница «входит / не входит». Отметьте, чего не хватает.

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

3. Назначьте ответственных: ведущий аналитик отвечает за шаблон и качество документа, владелец бизнес-задачи — за согласование цели и показателей.

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

5. Опишите функциональные требования через Сценарии использования (Use Cases), от целей пользователя, и проверьте, что у каждого требования есть источник и способ проверки.

6. Перед оценкой сроков проведите разбор с разработчиками: каждый сценарий должен вести к цели из BRD, а всё, что ни к какой цели не ведёт, обсудите отдельно.

7. Через месяц разберите пилотный проект: какие изменения требований появились, сколько из них упирается в незаписанную цель или размытую границу и что поправить в шаблоне.

8. Закрепите правило в регламенте проектов: без подписанного BRD и сценариев с проверками задача не берётся в разработку.

Такие планы обычно гибнут на второй неделе, когда горящие задачи вытесняют всё, что не горит прямо сейчас. В OrgDevTools.ru для этого есть Рабочая тетрадь — цифровой инструмент сервиса, который превращает такой план в отдельные задачи с прогрессом и живым интерактивным фреймом по каждой методике. Попробуйте бесплатно на OrgDevTools.ru →

#Рацуха #BRD #UseCases #БизнесАнализ #Требования