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

Роли

Роль определяет задачи, за которые отвечает заинтересованная сторона внутри организации. Бывает, что по формальному названию должности эти задачи не вполне очевидны. Что далеко ходить? Например, где‑то аналитик может отвечать и за задачи архитектуры, и за дизайн, и за пользовательскую документацию, а где‑то он отвечает за составление требований и немного за тестирование.

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

Отношения

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

Например, когда аналитик выбирается «в поля» пообщаться с конечными пользователями, то часто видит очень высокую заинтересованность. Это те, кто каждый день спотыкается о наши поля и кнопки! У них много идей и требований. Вернувшись на рабочее место, аналитик обнаруживает, что лица, принимающие решения иначе видят приоритеты.

Отношение к задаче может меняться со временем и это тоже приходится отслеживать. Например, если функция не внедряется вовремя, то и заинтересованность может снизиться.

Полномочия

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

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

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

Уровень власти или влияния

Эта характеристика не обязательно совпадает с ролью или должностью заинтересованной стороны.

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

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