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

Исследование The Standish Group показало, что неполные требования и спецификации, а также изменение требований входят в ТОП-3 причин провала IT-проектов. И, наоборот, ясное изложение требований называют третьей самой важной причиной успеха IT-проектов.

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

“Я имел в виду другое”
Недостаток информации
На картинке все выглядело иначе
Как избегать неоднозначностей: несколько проверенных техник

“Я имел в виду другое”

При общении со стейкхолдерами начинайте с простого: понимайте, какие именно проблемы решает ваш проект, и просите примеры из реальной жизни.

Одной записи требований на бумаге — недостаточно. К счастью, современные инструменты позволяют создать визуализации и даже работающие прототипы, не задействуя труд разработчиков.

Критически важные союзники: почему надо знать о стейкхолдерах

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

Недостаток информации

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

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

При наличии достаточного времени можно применить прием “работа в поле”. В этом случае бизнес-аналитик направляется в саму компанию и документирует процессы “изнутри”. В процессе наблюдения можно задать уточняющие вопросы и выявить пути оптимизации бизнес-процессов. Альтернативным вариантом может быть прикомандирование представителя заказчика в команду разработки. Это позволяет получать своевременную оценку прогресса разработки и корректности реализации. Однако такой способ тоже достаточно трудозатратен и требует траты времени на адаптацию сотрудника.

Пропущенные требования, в их число нередко входят функциональные, относящиеся к качеству работы системы и ее архитектуре, очень дорого добавлять после начала процесса разработки. Единственный способ избежать ситуации, когда в системе несколько тысяч пользователей и нужно выкатить критически важное обновление — проявлять проактивность. Представитель Software Engineering Institute Дональд Фаерсмит советует заранее предусмотреть сценарии “дождливого дня” (когда что-то идет не по плану) и, помимо диаграммы использования (что делают люди и системы) создавать для каждого сценария диаграммы с бизнес-процессами (как они это делают) и даже диаграммы последовательностей (на них указаны технические подробности и функции). 

На картинке все выглядело иначе

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

Бизнес-консультант Breadcrumb Digital Юлия Корниенко советует убедиться, что в документации существует четкое разграничение между дизайном и функциональными требованиями. Чтобы сосредоточиться на функциональных аспектах, лучше использовать более абстрактные инструменты, такие как диаграммы, пользовательские истории и низкоуровневые прототипы, а не дизайн-макеты.

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

Магия пиктограмм: что такое BPMN?

Как избегать неоднозначностей: несколько проверенных техник

Ничто не мешает проекту так, как неправильно понятые требования. Чтобы избежать неоднозначностей, важно научиться применять техники уточнения и валидации требований. Это может включать создание сценариев использования, создание прототипов или макетов, а также постоянное подтверждение полученной информации у заказчика.

• Если позволяют условия проекта, можно применить технику Event storming. В ней команда участников, которая состоит из разноплановых специалистов (разработчики, эксперты доменной области и так далее) визуализирует бизнес-процессы. Для этого используется доска и разноцветные стикеры. В процессе мозгового штурма команда может не только получить черновую модель для разработчиков, но и обменяться знаниями и улучшить взаимодействие.
• Никогда не забывайте про человеческий фактор. Так автор книги «Психбольница в руках пациентов» Алан Купер советует быть педантичным при сборе требований.
  «Клиенты часто говорили о каких-то новых вещах, которые они хотели бы видеть, но не упоминали функции, которые уже имелись в их существующем программном обеспечении (софте, которым они пользовались раньше — Прим. ред) или браузерах и которые они воспринимали как должное. Поскольку они об этих функциях не говорили, их никогда не добавляли в техническое задание, и они так и не были реализованы», — пишет он.

• Личные встречи лучше всего подходят для достижения консенсуса и приоритизации требований. Если подготовиться и заранее использовать технику MoSCoW, то на встреча можно будет сразу провалидировать все приоритеты.

• Убедитесь, что ваш документ не только понятен заказчику, но и команде разработчиков, тестировщиков и менеджеров. Записывайте и нумеруйте собранные требования, а также указывайте источники их поступления. Это очень поможет спустя время, когда возникнут вопросы к реализации фичи на этапе разработки.
• Аргументируйте собранные требования — разработчикам необходимо представить рациональную и обоснованную причину для внесения изменений.

10 советов для развития критического мышления

“Процесс проектирования архитектуры, разработки, реализации и тестирования становится более сложным, дорогим и требующим больше времени” — говорит о возможных последствиях представитель Software Engineering Institute Дональд Фаерсмит.

Он советует использовать удобный для пользователя инструмент, чтобы фиксировать сами требования, дату их поступления, изменения и их источники. Этот процесс должен происходить на всех стадиях проекта.

Казахстанская ERP-платформа Darlean позволяет фиксировать и расставлять приоритеты для требований в проектном модуле. Помимо этого, система обладает более чем 30-ю инструментами, необходимыми для ведения собственного бизнеса, включая функционал обучения сотрудников, документооборот и управления процессами.