Сел тут выписывать категории стейкхолдеров. В проекте положено делать анализ стейкхолдеров, да? Обычно его либо не делают, либо с умным видом рассказывают про "луковичную диаграмму" (и иногда даже рисуют её).
Луковичная диаграмма делит стейкхолдеров на круги, или слои. Конкретные названия слоев варьируются.
Йэн Александер (собственно, автор методики и книг «Writing Better Requirements» и «Discovering Requirements: How to Specify Products and Services» — кстати, не вижу, чтобы они переводились на русский, а это вам не Вигерс, это конкретное руководство про выявлению и написанию требований) предлагает следующие:
0 слой: сам продукт
1 слой: "наша" система: продукт + операторы + инструкции/правила по работе с системой
2 слой: объемлющая (содержащая) система: наша система + бенефициары нашей системы (кто получает пользу от её функционирования, но сами могут не пользоваться ей)
3 слой: широкое окружение: объемлющая система + все остальные стейкхолдеры
Раскладывает стейкхолдеров по типам так:
1 слой ("наша система"):
* Нормальный оператор: вводит данные, отдает команды и получает результат от работы продукта. Главные требования: наличие необходимых функций, удобный и понятный пользовательский интерфейс, скорость работы, отсутствие ошибок/потерь данных, безопасность.
* Оператор технического обслуживания: обеспечивает и следит за работоспособностью системы. Требования: наблюдаемость (время поиска неисправности), ремонтопригодность (возможность и время на ремонт).
* Операционная поддержка: так как система включает технику и людей, должно быть две роли — поддерживающая технику и поддерживающая людей. Это может быть служба поддержки и люди, занимающиеся обучением.
2 слой ("содержащая система"):
* Функциональный бенефициар. Получает пользу от нашей системы, возможно не напрямую, а от операторов. Это немного старомодное деление, когда умение работать с компьютерами было отдельным скиллом. Хотя встречается и сейчас, в любом взаимодействии, когда вы смотрите на экран компьютера с обратной стороны: на кассах, в банках, МФЦ и т.п. Функциональный бенефициар в данном случае мы, мы взаимодействуем с оператором, а не с системой напрямую.
* Владелец смежной системы. Александер называет их "Ответственными за интерфейсы". С кем вы будете говорить, когда речь пойдет об интеграциях.
* Приобретатель. Может быть один (в организации) или миллионы (в массовом продукте, тогда их представляет Продакт). Кто выкладывает денежки. Кто отвечает за то, чтобы продукт был сделан.
* Спонсор или чемпион продукта. По-русски мы так не говорим, но это тот, кто вообще пробивает создание нашего продукта. Причем не только находит деньги но и решает политические вопросы. Исполнительный продюсер.
3 слой ("широкое окружение"):
* Негативный стейкхолдер. Тот, кто может пострадать от внедрения системы: физически, финансово или иным способом, за который вы будете отвечать перед регуляторами или судом. Требования регуляторов на самом деле — формализованные и обобщенные требования негативных стейкхолдеров (или ограничения). Александер добавляет сюда же стейкхолдеров, которые могут пытаться вредить работе продукта.
Он даже предлагает выделять специальную роль:
* Враждебный агент. Те, кто совершенно точно станут активно вредить или использовать продукт не по назначению. С определенным уровнем хитрости и креативности. Например, вопросы для любого открытого продукта с хостингом пользовательского видео: как вы будете бороться с порно-контентом, а для продуктов с комментариями или отзывами: как бороться с размещением спамерских ссылок.
* Политический бенефициар. Кто получит выигрыш с точки зрения власти, влияния или престижа от создания вашей системы? Мой любимый тип стейкхолдеров. Пользоваться системой они не будут, может быть даже функциональными бенефициарами не будут, а вот власть и влияние их очень интересуют. В государственных организациях (и некоторых крупных бизнесовых) это чуть ли не основной смысл существования некоторых систем, а за контроль над ними ведутся жестокие битвы. Политические бенефициары могут быть и негативными — активно противодействовать созданию систем, или создавать свою альтернативную, или запрещать/затруднять интеграцию. Чем выше вы заходите в управление корпоративными продуктами, тем больше там политики.
* Финансовый бенефициар. Получит прибыль от создания системы. По-честному, редко берется в расчет, если вы не делаете коммерческий продукт.
* Регулятор. Тот, кто задает правила игры — обычно в виде ограничений или навязанных функций.
* Разработчик. Есть мнение, что они вообще не должны быть в этой модели, они перпендикулярны.
* Консультант (западная практика, бывает ли в РФ?)
* Поставщик (обычно очень далекая роль, но для некоторых систем бывает крайне важен)
Вот такая классификация. У меня из головы получилась похожая, напишу следующим постом.
25
5
2August 29, 2026 901 4 30
