Тут в фейсбуке натолкнулся на откровение от одного из Agile коучей, которое звучит примерно так: «Если у вас в Scrum-команде есть бизнес-аналитик, который во время спринта готовит требования на следующий спринт, то, с большой вероятностью, Scrum у вас ненастоящий». У меня пригорело и появился отличный повод высказаться на эту тему.
У меня складывается ощущение, что чем меньше люди работают в режиме hands-on с командами, тем более они верят в реалистичность абстракций. Например, проще всего возложить всю работу с требованиями на роль PO и утверждать, что присутствие аналитиков попахивает «зрадой». Я постараюсь в деталях описать свой опыт и видение в данной области. Поэтому будет несколько последовательных постов.
В первой части я бы хотел поднять вопрос необходимости в бизнес-аналитике в современной разработке. Где есть вовлеченный PO и полноценная feature-команда для работы над самыми приоритетными требованиями в инкрементально-итерационном режиме. Казалось бы, ну зачем тут аналитик?
Оказывается, не все работают в простом бизнес-домене. Хватает бизнес-доменов, в которых за простой формулировкой User Story могут скрываться недели анализа и проработки бизнес-требований. Например, в медицинском домене «я, как врач общей практики, хочу иметь возможность выписать рецепт пациенту, чтобы назначить полноценное лечение» до планирования превращается в целую мини-спеку с кучей очень важных деталей, без которых системой невозможно будет пользоваться или она будет противоречить законам. И PO явно не имеет времени на погружение во все эти детали, так как он занят видением продукта, приоритезацией, работой с внешними стейкхолдерами и другой важной работой. Примеров масса: финансы, логистика, медицина...
Второй пример жизненной необходимости в бизнес-аналитиках заключается в роли SME для команды как по бизнес-процессам так и по самой системе. Все знают, что можно в любой момент обратиться с уточняющим вопросом и получить оперативный и точный ответ, при этом не отвлекая PO, если вопрос не касается приоритетов или изменения взятых в работу требований.
Также, бизнес-аналитики оказывают большую помощь QA инженерам в проработке всех тестовых сценариев и обеспечении корректного покрытия реализуемой функциональности. На это у подавляющего большинства PO нет времени от слова совсем.
Ну и наконец, есть кейсы, когда PO просто никогда не работал с IT и является человеком из бизнеса. Ему чужды все эти User Story и прочие «приседания», он хочет простыми словами описать требования и чтобы команда их сделала. При этом, он четко понимает приоритеты и готов помогать команде во всем. Команде же не хватает доменного и аналитического опыта, чтобы привести эти «бытовые требования» к готовому для разработки варианту. И тут участие бизнес-аналитика помогает соединить воедино PO и команду.
Я могу перечислять ещё много сценариев, но думаю, у вас есть и свои примеры из реального опыта. В следующих частях я расскажу о негативных примерах, откуда они берутся, а также почему обычно не получается команде забрать эти активности на себя.
#аналитики #требования
