В этой заметке мне бы хотелось рассказать об общении со стейкхолдерами как людьми, вовлеченными в проект и являющимися изначальным источником требований. Основная часть этого общения приходится на область Requirement Elicitation (неспроста BABOK даже в названии объединяет ее с Collaboration), но не ограничивается ею. Ведь при анализе требований, разработке дизайна, оценке решения обратная связь и взаимодействие со стейкхолдерами имеют огромное значение.
Напомним несколько определений, чтобы быть уверенными в общем понимании.
According to the IIBA, Requirement is:
1. A condition or capability needed by a stakeholder to solve a problem or achieve an objective.
2. A condition or capability that must be met or possessed by a solution or solution component to satisfy a contract, standard, specification, or other formally imposed documents.
3. A documented representation of a condition or capability, as in 1 or 2.
According to the IIBA, Stakeholders is:
A group or individual with a relationship to the charge, the need, or the solution.
А теперь немного пофантазируем и предположим, что анализ стейкхолдеров проведен и как его результат:
Нужные стейкхолдеры найдены и классифицированы
Выявлены области ответственности групп стейкхолдеров
И совсем фантастическое: Стейкхолдеры располагают неограниченным количеством времени и необходимых ресурсов, которые они готовы посвятить обсуждению требований
В таких "идеальных условиях" мы начинаем сотрудничество. И все-таки что-то идет не так: обсуждения "пробуксовывают", решения не принимаются, результаты анализа неудовлетворительны, невозможно перейти к реализации. Почему?
Обычно отношение к стейкхолдерам колеблется между двумя крайними точками зрения:
Stakeholders are golden source for requirements.
Все сказанной является непреложной истиной, которой необходимо следовать без всяких сомнений. Задача аналитика законспектировать пожелания близко к тексту и воплотить их с минимальными потерями.
VS.
'Что хочет заказчик решаем мы.'
Стейкхолдеры не понимают особенностей нашего окружения, не могут оценить достоинств нашего решения, не имеют времени вникнуть в проблему. Задача аналитика-следовать выбранному проектной командой решению и убедить в нем стейкхолдера.
Как правило, истина, как обычно, находится где-то между этими полюсами. При чем нет единого правила относительно ее расположения, в каждом случае оно уникально, зависит от проекта, обстоятельств, личности скейхолдера, в конце концов.
И все же заказчик, безусловно, знает, что он хочет. И не просто "чтобы все работало". Его знание вполне специфично. Но передача этого знания аналитику сталкивается с определенными препятствиями. "Канал связи" стейкхолдер – аналитик не настроен должным образом. Попробуем понять, почему это происходит, и найти пути к преодолению барьеров. Итак, причины:
Стейкхолдер знает, но не осознает
Стейкхолдер осознает, но не может сформулировать
Аналитик не понимает, что ему говорит заказчик.
Аналитик не воспринимает, что ему говорит заказчик
Давайте "начнем с себя" и рассмотрим трудности снизу вверх.
Пункт 4 Снимите шоры предубежденности. По последнему пункту давать советы легко, что, впрочем, не означает, что их легко выполнить. И все-таки попытаемся:
Забудьте об опыте, постарайтесь воспринять услышанное "с чистого листа" и проникнуться высказываемой идеей.
Помните, что каждая ситуация уникальна и откажитесь от шаблонов, которые каждый опытный аналитик имеет в распоряжении. Вы, безусловно, примените их позже.
Воспринимайте информацию не предвзято. Постарайтесь на какое-то время забыть "аналитический скепсис", откажитесь от поисков недостатков высказываемой идеи, сосредоточьтесь на достоинствах.
Знайте вашего стейкхолдера, уважайте его, примите то, что его бэкграунд, терминология, точка зрения могу не совпадать с Вашей.
Keep smile. Доброжелательное отношение будет хорошей альтернативой профессиональной холодности, когда речь идет о получении информации.
Пункт 3 Найдите общий язык. Этот пункт мне кажется наиболее понятным для аналитика, так как предполагает использование техник анализа, подробно освещенных в книгах и статьях по бизнес-анализу. И все же, позволю себе дать несколько советов.
Изучайте язык заказчика - его предметную область. Легко сказать, но не просто осуществить. Вам , конечно, не удастся овладеть знаниями о бизнесе или технических ограничениях в той степени, какой обладает ими человек, посвящающий этой деятельности все рабочее время, но предварительная подготовка к беседе, знакомство с терминологией просто необходимы. Впрочем, смотри следующий пункт.
Не надо стесняться задавать вопросы. Никому не хочется выглядеть непрофессионально, но ведь никто не ждет, что аналитик разбирается во всем и сразу. Не знать чего-то вполне нормально, хуже сохранять себя в неведении. Кроме того, объяснение проблемы человеку, не разбирающемуся в ее тонкостях, позволяет рассказчику самому взглянуть на нее свежим, "не замыленным" взглядом.
Обучайте заказчика языку аналитика. Помните, что выявление требований – это двусторонний процесс, в результате которого не только аналитик, но и стейкхолдер должен получить представление о том, что будет реализовано. При чем, желательно чтобы эти представления совпадали. Для достижения такого согласия послужат термины системы, такие как транзакция, документ, названия контролов, используемых в пользовательском интерфейсе.
Выберите нужный уровень абстракции. Рассуждения на слишком высоком уровне, так же как углубление в детали, когда не выработаны более высокоуровневые решения, приводят не только к потере времени, но и уводят от запланированного хода анализа. Коварство ситуации состоит в том, что аналитик должен обсуждать решение на разных уровнях, важно это делать в правильное время (на соответствующей стадии разработки) и с правильной аудиторией. Выбрать нужный "тон" разговора поможет знакомство с профилем собеседника.
Пункт 2 Помогите стейкхолдеру выразить себя. Опять-таки лучшие практики и методы анализа помогут Вам это сделать. Вспомним некоторые:
Используйте визуализацию
Используйте прототипирование
Используйте шаблоны описаний
Единственное предупреждение – не стоит излишне увлекаться формализмом. Используя техники документирования требований, помните, что у стейкхолдера может не быть достаточной подготовки для чтения формальных нотаций.
· Вспомните прежний опыт. Совет противоречащий тому, что говорилось выше, но вполне уместный в данном контексте. Приведенный к месту пример, удачная аналогия помогут Вашему собеседнику указать на сходства или подчеркнуть различия с обсуждаемой проблемой.
Пункт 1 Наконец, мы добрались первого пункта. Боюсь, что здесь мы сталкиваемся с ситуацией, когда техник анализа становится мало, так как проблема лежит в плоскости психоанализа и является своеобразной тайной для самого индивида – стейкхолдера. Избегая соблазна углубиться в дебри психоанализа примем гипотезу Фреда о том, что узнать бессознательное можно путем превращения его в сознательное. В этом могут помочь "эвристические" практики, как совокупность приемов и методов, облегчающих решение познавательных, конструктивных задач. Не будучи специалистом в этом вопросе, позволю себе все-же дать несколько "бытовых" подсказок, как привести собеседника к правильной мысли.
Используйте примеры
Пользуйтесь аналогиями
Просите подтверждения сказанному
Опирайтесь на факты
Проверяйте предположения
Заключение.
Я безусловно заметила, что советы носят некоторый хаотический характер и даже противоречат друг другу. Но в этом проявляется особенность нашей профессии. Бизнес-анализ – деятельность, которую нельзя описать формальной инструкцией, это набор практик и методов, а также навык, возможно, даже искусство, их комбинирования. Не бойтесь пробовать, следуйте своей интуиции и получайте удовольствие от работы.
Тренинги от "Art of Business Analysis":