Про бизнес-требования и онтологию требований

Канал о системном и бизнес-анализе, продуктовом мышлении и архитектуре. Как выявлять реальные проблемы, строить работающие решения и не терять здравый смысл в IT. Все вопросы - @innokentyB

требованиябизнес-требованияаналитика

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

Посмотрел тут доклад горячо мною любимого Дениса Бескова 😆 про онтологию требований по Вигерсу. И в целом я с ним согласен — в том, что не стоит слепо доверять авторитетам, даже если они пишут умные книги. Best practices хороши тогда, когда их можно адаптировать. И то, что было актуально 20 лет назад — сейчас может быть банально непригодно.

Но есть нюансы.

Доклад Дениса строится в первую очередь на позиции проектной разработки, где требования — это про софт. Что для меня в целом немного странно, так как Денис не столько аналитик, сколько продакт и предприниматель, я ожидал от него взгляда больше направленного на ценность, а не на ПО.
Вигерс действительно писал про software requirements. Но даже у него есть важная ремарка — мы решаем не технические задачи, а бизнес-проблемы.

И вот тут начинается расхождение.
В моем понимании, требования — это не про «что ПО должно делать». Это про что должно измениться в бизнесе. И вот эти business requirements, user requirements, stakeholder requirements — как ни называй — это то, что аналитик должен понимать и уметь формулировать. Не «система должна», а «людям нужно». И тут я с одной стороны согласен с докладчиком, что требования будут К бизнесу и к пользователям, как они должны поменять свое поведение, чтобы достигнуть целей, но ведь и они могут требовать каких то возможностей и инструментов, так что тут взгляд кажется немного узким.

Я категорически не согласен с идеей, что пользователь в команде представлен только продактом. Простите, но если команда делает продукт, вся команда должна понимать, кто пользователь, что у него болит и зачем вообще мы делаем фичу. Аналитик не должен зарываться в ТЗ и «функциональные требования» — он должен держать в голове, кого и зачем мы спасаем.

Я искренне считаю, что в 2025 году ограничиваться только требованиями к ПО не только странно, но и уже опасно. Требования должны быть к решению, ПО может быть частью решения, инструментом, а может и не быть. И важно это помнить, что мы всегда должны решить боль бизнеса и\или проблему пользователя.

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

P.S. Я сделал краткий конспект его выступления — ссылочку прикрепляю под постом.

Дискуссия

Denis Beskov
2. про «решения» да, надо идти дальше и критиковать BABOK, где действительно на 3-м уровне стоит уже Solution, а не Software но поскольку Solution может в общем случае иметь любой состав — и ПО и железо и людей и процессы и подразделения и компании, то эту «систему» сложно считать подсистемой бизнеса, нужно как-то отдельно их разносить, тк чистой иерархии не получается но это я попробую отдельно сделать и видимо уже сразу на английском
Denis Beskov
это вообще не было частью моего доклада мне тут пока сложно решить, что делать, тк вопросы распределения работ по ролям я не считаю существенными, важнее то, какую работу и как делать но поскольку не хочется людям грубить и обламывать отказом, я отвечаю наиболее коротко, тк на объяснения в формате QnA нет места фразы «пользователь представлен в команде только продактом» я не помню. я стою только на позиции, что в продукте право заказывать способности для пользователя с определённым качеством имеет продакт, это общая позиция и Scrum и культуры продакт-менеджмента. команда может сколько угодно понимать пользователя и сколько угодно придумывать классные идеи, но право ТРЕБОВАТЬ есть только у того, кто отвечает головой за успех продукта. иногда бывают команды с коллективной ответственностью, но они слишком редки для короткого ответа в формате QnA
PRO анализ в ИТ
Denis Beskov
это вообще не было частью моего доклада мне тут пока сложно решить, что делать, тк вопросы распределения работ по ролям я не считаю существенными, важнее то, какую работу и как делать но поскольку не хочется людям грубить и обламывать отказом, я отвечаю…
Вообще в Scrum требования могут добавлять все. А вот приоритезировать их имеет право только продакт. Так что получается немного софистики. Требовать могут все, решать какие требования реализовывать - продакт и частично команда.Кроме того, многие требования рождаются по результатам интервью, анализа данных и так далее и продакт их вообще видит только в момент, когда они сформулированы и попали в хвост бэклога
Denis Beskov
PRO анализ в ИТ
Вообще в Scrum требования могут добавлять все.
так там вообще не требования, а просто идеи) причём часто идеи о решении) я поясню, что мне не нравятся многозначные определения «требований», которые устоялись в ISO, типа «формы выражения потребностей». мне ближе требования, которые являются безусловно необходимыми и нужными — в силу каких-либо обязательств.
PRO анализ в ИТ
Denis Beskov
так там вообще не требования, а просто идеи) причём часто идеи о решении) я поясню, что мне не нравятся многозначные определения «требований», которые устоялись в ISO, типа «формы выражения потребностей». мне ближе требования, которые являются безусловно…
Ну то есть в продуктовой разработке требования практически не нужны? ну только регуляторные?
Denis Beskov
PRO анализ в ИТ
Ну то есть в продуктовой разработке требования практически не нужны? ну только регуляторные?
в продуктовой да (но Scrum != продуктовая разработка, скорее это пересекающиеся области). и то они subject to change в том смысле, что стартап их может игнорировать, если штрафы и риски приемлемы. а корпорация может лоббировать их изменение.
PRO анализ в ИТ
Denis Beskov
в продуктовой да (но Scrum != продуктовая разработка, скорее это пересекающиеся области). и то они subject to change в том смысле, что стартап их может игнорировать, если штрафы и риски приемлемы. а корпорация может лоббировать их изменение.
получается, что вся котовасия с требованиями вообще только для заказной\проектной разработки нужна?
Denis Beskov
PRO анализ в ИТ
получается, что вся котовасия с требованиями вообще только для заказной\проектной разработки нужна?
так она была для неё придумана потом продуктовый мир пытался её копировать через слова MRD, PRD, пока не пришёл Scrum, CustDev, Design Thinking, культура гипотез, HADI-циклов и проч. и оказалось, что можно и нужно без формальных требований, по крайней мере в B2C, довольно часто в B2B и иногда в B2G (см UK Digital Government Services) правда некоторым компаниям, типа Контура, приходится несладко, тк предмет их работы включает как продукт, так и внутренние системы и сервисы. поэтому возникают головоломки, где у нас требования, а где продуктовые идеи
PRO анализ в ИТ
Denis Beskov
так она была для неё придумана потом продуктовый мир пытался её копировать через слова MRD, PRD, пока не пришёл Scrum, CustDev, Design Thinking, культура гипотез, HADI-циклов и проч. и оказалось, что можно и нужно без формальных требований, по крайней мере…
Вот только многие до сих пор пытаются натянуть сову на глобус и в продукте делать требования
Denis Beskov
PRO анализ в ИТ
Вот только многие до сих пор пытаются натянуть сову на глобус и в продукте делать требования
«дурное дело нехитрое» :)
Присоединиться к обсуждению →

Читайте так же