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

В таких условиях компании, как правило, обращаются к одному ИТ-подрядчику, который готов предоставить полный спектр услуг: от бизнес-анализа (извлечение, анализ и документирование требований) до непосредственной разработки и тестирования ИТ-решения.

И здесь возникает сразу несколько проблем.

Во-первых, ИТ-подрядчик всегда на первое место ставит собственные интересы. Это приводит к тому, что аналитики исполнителя при разработке и документировании требований в большей степени думают не об удовлетворении всех потребностей бизнес-пользователей, а о будущих трудозатратах, а также технической возможности платформы/технологии, применяемой его командой в работе.

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

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

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

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

Однако нередко, к сожалению, случается и обратное.

Как избежать дополнительных затрат и получить оптимальное ИТ-решение?

Одним из способов решения проблемы видится организация собственного штата бизнес-аналитиков и других ИТ-специалистов. Но это сопряжено с трудностями: поиск и найм персонала, затраты на содержание (часто при отсутствии постоянной загрузки задачами), необходимость мотивировать и удерживать персонал. Учитывая всё это, организация БА-отдела может являться не самым оптимальным выбором.

Есть и более простое решение проблемы — найм независимого бизнес-аналитика.

Функции независимого бизнес-аналитика

Статус независимого, или внешнего, говорит о том, что бизнес-аналитик будет привлечен не совместно с командой разработки (исполнителем), а как отдельный подрядчик.

Функции независимого бизнес-аналитика не отличаются от внутрикомандного. В процессе работы специалист выполнит следующие задачи:

  • определит цели и границы проекта по разработке ИТ-решения;
  • соберет и задокументирует бизнес- и пользовательские требования;
  • разработает и задокументирует функциональные и нефункциональные требования;
  • обеспечит сопровождение проекта на всех этапах;
  • возьмет на себя коммуникацию с командой разработки по всем вопросам, связанным с требованиями к ИТ-решению;
  • примет участие в тестировании разработанной функциональности ИТ-решения.

В чем преимущества найма независимого бизнес-аналитика?

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

Внешний бизнес-аналитик не заинтересован в разработке ненужных функций и модулей (эффект, получивший название «gold plating», или «озолочение продукта»), а также в отсечении пожеланий пользователей по причине их трудоемкости.

2. Бизнес-аналитик отвечает за коммуникацию с исполнителем по всем вопросам, касающимся требований. Независимый бизнес-аналитик становится своеобразным переводчиком между бизнес-пользователями и разработчиками. Именно он будет объяснять исполнителю требования и выяснять детали у бизнес-пользователей.

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

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

3. Бизнес-аналитик является профессионалом в ИТ. Соответственно в процессе тестирования и приемки функциональности ИТ-решения внешний бизнес-аналитик отслеживает не только сам факт реализации функции, но и UX, качество дизайна, соответствие разработанной функции изначальным требованиям пользователей.

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

Для внешнего бизнес-аналитика важнее опыт в доменной области заказчика, чем детальное знание различных ИТ-платформ. Поэтому, с точки зрения перспективы долгосрочного сотрудничества, независимый бизнес-аналитик с каждым проектом наращивает компетенции в специфике работы заказчика и может привлекаться для широкого круга ИТ-проектов в будущем, вне зависимости от того, какие технологии/платформы/языки программирования будут использоваться для разработки. Тогда как непосредственные исполнители часто не могут обеспечить заказчику разработку всех необходимых ИТ-решений в портфеле, поскольку просто не имеют соответствующего технического опыта.

От привлечения независимого аналитика выигрывают и разработчики

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

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

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

Исправление таких ошибок стоит очень дорого. Часто приходится кардинально менять бизнес-логику или архитектуру ИТ-решения, что невыгодно самому исполнителю.

Подводим итог

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

Автор статьи — директор практики консультирования A1QA в области качества программных продуктов.