Почему важно собрать требования и как в этом поможет аналитик
Если вас попросят объяснить роль системного аналитика на проекте, самым частым описанием будет «мостик между бизнес-заказчиком и командой разработки». На старте заказчик может иметь представление о целевой картинке или просто обозначить проблему, которую необходимо решить. Например, упростить работу или автоматизировать процесс, но он может не предусмотреть все сценарии использования системы. Аналитику нужно расспросить заказчика, понять, «где болит». Для этого придется слушать и разобраться с истинными причинами, но не пытаться сразу предлагать возможные решения.
От успешного сбора требований зависит совпадение реальности и ожиданий заказчика, а также сроки реализации и качество продукта.
«Время, затраченное на выяснение потребностей пользователей, представляет собой эффективное инвестирование в успех проекта». К. Вигерс
Бывает, что у заказчика есть четкие требования к конкретной функциональности, но нет полного понимания, чего необходимо достичь. Любое действие должно иметь смысл, поэтому аналитику так важно выявить ценность продукта или разработки конкретной фичи.
Например, клиент пришел и уверенно поставил задачу: нужно организовать миграцию базы данных. Требования есть, задача поставлена, разработчики приступают к выполнению, а в базе данных — сплошное legacy, и никто толком не помнит, что, как и зачем там сделано. На решение задачи уходят ресурсы, которые можно было использовать более разумно.
Избежать ситуации можно было, если бы на этапе обсуждения аналитик задал вопрос: «А зачем вам это?» Оказывается, что миграция данных не нужна, а чтобы сохранить пользователей, можно выяснить, какие именно данные из старой системы они используют, и перенаправлять запросы по необходимости. Дешево и сердито. А потом, может, и вовсе старую базу уничтожить за ненадобностью.
Итак, еще на этапе сбора требований можно наперед продумать дальнейшие шаги и снизить вероятность того, что требования придется дособирать и переутверждать.
Пять вопросов «Зачем?»
Правильно собрать требования аналитику поможет техника «Пять почему» или «Пять зачем», которую изобрел в 30-х годах предыдущего столетия основатель компании Toyota Сакити Тоеда. Ее суть — последовательно задавать вопросы, постепенно углубляясь в суть проблемы. В бизнес-аналитике даже выделяют отдельный метод анализа первопричин — Root Cause Analysis — как эффективный способ превентивного предотвращения багов. Подход не всегда работает для сложных и многосторонних проблем, но метод «Пять почему» остается эффективным в большинстве случаев.
Конечно, на практике опрос заказчика не должен выглядеть заклинившей пластинкой: повторение одного и того же вопроса вызовет недоумение у собеседника. В каждой итерации нужно уточнять, перефразировать сказанное раньше, «зачем» и «почему» можно комбинировать.
Например, заказчику нужно настроить систему уведомлений для сотрудников о том, что появился новый подписанный документ, который следует оформить и отправить в корреспонденцию. Задаем вопросы:
- Зачем это нужно? Чтобы сотрудники не пропускали новые документы. Когда бумаги уже подписаны, их надо быстро передать дальше, иначе процесс заказа тормозится, из-за этого клиенты недовольны скоростью работы.
- Почему так происходит? Потому что при создании документа его регистрирует в системе отдел B, а потом сотрудники отдела A вручную нажимают кнопку «Отправить руководителю».
Уже на этом этапе можно сделать вывод, что процесс можно автоматизировать и отправлять документы на подпись после регистрации черновика. То есть техника помогла выявить истинную проблему: нужно не уведомлять сотрудников о новых бумагах, а изменить процесс, чтобы работать эффективнее.
Популярные техники сбора требований
Существует множество описанных методик и инструментов сбора требований аналитиком, не все из них используются в реальной жизни. Но я считаю, что знать базовые концепции важно, поскольку общая насмотренность позволяет выводить собственные гибриды и применять комплексные методики.
Чаще всего аналитики используют такие методы сбора требований:
- опрос (интервью) заинтересованных лиц;
- сбор обратной связи от пользователей;
- изучение существующих процессов и анализ конкурентов;
- мозговой штурм.
Опрос
Прежде чем приступить к опросу, необходимо определить заинтересованных лиц (стейкхолдеров) и среди них — основных пользователей системы. Например, это владельцы других систем при межсервисном взаимодействии.
Я выделяю пользователей как особую группу стейкхолдеров, поскольку их интересы желательно знать. Не всегда условия позволяют учесть мнение большинства, но в идеале стоит к этому стремиться. Многие проблемы или особенности пользования выявляются при первом релизе, при обкатке системы и работе над новыми версиями.
Основными же целевыми источниками информации при сборе требований выступают бизнес-заказчики. Они рассказывают, какие бизнес-задачи или проблемы необходимо решить, что нужно оптимизировать с помощью продукта, каких целей достичь. Также они обозначают основные ограничения по бюджету, времени и ресурсам. Опрос можно провести в формате анкеты или интервью с заранее подготовленными вопросами.
Сформулированные требования важно записать, согласовать и утвердить с заказчиком в техническом задании или договоре — это залог того, что все участники понимают договоренности одинаково. Кроме того, зафиксированные требования могут стать решающим аргументом, если у заказчика и исполнителя возникнут разногласия на этапе приемки и тестирования проекта.
Обратная связь
К сожалению, сбор требований не всегда предполагает общение с конечными пользователями продукта. Бывает сложно найти инициативных активных пользователей, готовых идти на контакт, но даже когда они есть, не всегда получается объективная оценка.
Чаще всего комментарии и пожелания пользователей удается получить уже после релиза в формате обратной связи или при исправлении возможных багов. Такие сведения с точки зрения user experience самые ценные: они позволяют понять, какие функции в действующей системе нужно сделать удобнее, переместить в другой раздел, добавить или убрать, какие процессы надо оптимизировать.
Изучение процессов и анализ конкурентов
Еще к методикам сбора требований можно отнести изучение существующих процессов: в документации (если она есть и актуальна) или путем самостоятельного тестирования.
Часто бывает, что заказчик приходит с видением того, как разработанная система должна функционировать, а аналитику нужно продумать детали реализации и проработать требования. В этой ситуации может быть полезно изучить практику конкурентов, проанализировать уже существующие решения. Так можно собрать базу референсов, которые наиболее точно отражают идею заказчика, или найти готовые проверенные решения, которые потребуют минимальной адаптации.
Брейншторм
Brainstorm — это техника группового творчества, которая помогает выявить различные, в том числе нестандартные, подходы к решению поставленной задачи. Она полезна, когда у заказчика нет внятных идей: нужно «что-то вот такое». Тогда можно устроить мозговой штурм, чтобы помочь представителям заказчика сформулировать боли и пожелания. А вместе с командой разработки можно сгенерировать более «приземленные» идеи и подходы, которые точно можно реализовать.
Участники штурма могут накидывать идеи, напрямую или косвенно связанные с задачей, иногда странные или на первый взгляд глупые. Аналитику нужно приоритизировать требования, отфильтровать ненужные и выстроить план предстоящей разработки, а главное — сформулировать MVP.
Я часто использую методику расстановки приоритетов, описанную всё у того же Вигерса, под названием MoSCoW. Требования формируются по группам:
- Must have (обязательно);
- Should have (нужно);
- Could have (желательно);
- Won’t have (можно перенести).
Работа «в поле»
Из собственного опыта не могу не упомянуть методику, которую используют несколько реже других, но при этом она довольно эффективна: работа «в поле». Под полем можно понимать и офис, где работают сотрудники, и складские помещения. Аналитик наблюдает, как работают потенциальные пользователи системы, изучает их процессы «в прямом эфире».
Важно при этом не засмущать пользователей, стать незримой тенью, поскольку многие люди пытаются сделать «как правильно», а не пользуются системой в обычном режиме. Другие, наоборот, волнуются и ошибаются: пропускают некоторые шаги, неправильно заполняют поля. Кстати, все эти ошибки как раз и могут быть следствием непродуманного, неудобного дизайна, сделанного без учета особенностей реальных процессов.
Очевидный плюс работы «в поле» — возможность задать любые вопросы сразу, в контексте рабочего процесса.
Вместо заключения
В мире IT ничего не застывает, и методики сбора требований не являются исключением. Есть масса разных подходов, от классических до довольно экзотических. Аналитик должен знать о них всё и непременно следить за новыми трендами. Это не только поможет на собеседованиях, но и принесет пользу на практике.
Но тут важно помнить, что, помимо «хотелок» заказчика, аналитик должен учитывать и другие факторы, например ограниченные ресурсы, а также не забывать про нормы закона или запрет на использование определенных технологий. Хорошая работа аналитика — это не просто записать пожелания клиента, а создать полную картину будущей системы, учитывающую все ее аспекты.
