Требования к бизнесу, а не только к ПО

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

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

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

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

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

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

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

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

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

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