Альфа внешних проектных ролей

Альфа внешних проектных ролей (stakeholders) говорит о ролях, для которых целевые системы их проекта — надсистемы нашей целевой системы, так что эта альфа в области интересов надсистем. И ещё мы относим её главным образом ко времени продвижения (работы маркетинга, рекламы, продажи), ибо важнейшие внешние проектные роли — это относящиеся к пользователям/бенефициарам, будущим владельцам, плательщикам и прочим ролям (иногда собирательно называемых «клиентом»), которые должны согласиться профинансировать создание и развитие целевой системы, а затем её использовать. Это очень условное отнесение, ибо внешние проектные роли могут быть самые разные (например, всевозможные надзоры — роли, проверяющие соответствие работ всех систем графа создателей, включая целевую систему, какому-то разделу законодательства).

Команда (внутренние проектные роли) представлена отдельной альфой. Термин «stakeholder» имеет два значения:

• собственно роль (функциональный объект, называется по методу работы)
• агент, играющий роль (конструктивный объект, оргзвено, называется по его имени).

Будьте осторожными, чтобы не перепутать роль и исполнителя роли: не надо путать потребности принца Гамлета с потребностями Васи Пупкина, который сегодня играет роль принца Гамлета (в речи они оба могут быть «стейкхолдер», поэтому лучше используйте «внешнюю проектную роль» для обсуждения потребностей).

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

Проектные роли (и внешние, и внутренние) могут играться группами исполнителей (например, 30 тыс. пользователей программного приложения, которые появились от 30 тыс. розничных продаж, или 1 тыс. зрителей спортивного поединка на каком-то стадионе), некоторые группы исполнителей ролей могут быть вообще недоступны (скажем, хакеры), поэтому каждая из групп может быть представлена**/**represented каким-то «образцом проектной роли», или даже членом команды (например, отвечающим за продвижение/маркетинг), ответственным за представление разнообразных интересов внешних ролей и отстаивание их удовлетворения как перед командой, так и перед другими внешними проектными ролями (ибо внешние проектные роли легко могут конфликтовать между собой в своих потребностях — клиент самоката, скажем, хочет «ездить побыстрее», а надзор для тех же самокатов хочет — «скорость должна быть ограничена»).

Хорошей практикой является сразу разделение альфы «внешние проектные роли» на отдельные подальфы индивидуальных проектных ролей и раздельный учёт состояния каждой из этих подальф. И обычно этих подальф сразу от пятнадцати, а не от трёх или пяти! Помним: в любой момент проекта число внешних проектных ролей на единицу больше числа выявленных проектных ролей— и вот эта единица будет неиссякаемым источником сюрпризов.

Вот состояния с контрольными вопросами для определения их достижения для внешних проектных ролей (и помним, что речь может идти или о свежесозданном MVP, или какой-то версии/инкременте системы, или даже об отдельной фиче в составе системы):

• Признаны (recognized): внешние проектные роли выявлены; ключевые из них представлены; ответственности представителей/исполнителей проектных ролей определены.
• Представлены (represented): исполнители внешних проектных ролей согласились с ответственностью; представители каких-то оргзвеньев получили полномочия; подход к сотрудничеству согласован; инженерный процесс поддерживается и уважается.
• Вовлечены (involved): представители/исполнители внешних проектных ролей помогают команде; реагирование представителей на запросы своевременно, и они предлагают решения; изменения сообщаются вовремя.
• В**согласии (inagreement*)😗 минимальные ожидания/предпочтения согласованы; представители/исполнители внешних проектных ролей довольны своим вовлечением; вклад внешних проектных ролей приносит пользу проекту; приоритеты ясны; перспективы команды и внешних проектных ролей сбалансированы.
• Удовлетворены для разворачивания (satisfiedfordeployment)**: имеется отклик/feedback от внешних проектных ролей; система готова для разворачивания в месте её эксплуатации.
• Удовлетворены в использовании (satisfiedinuse): отклик/feedback по использованию/эксплуатации системы доступен; система отвечает ожиданиям/предпочтениям.

Проектные роли в силу 4D экстенсионализма совпадают с актёрами (конкретными оргзвеньями, которые исполняют эти роли) в тот момент, когда они играются. Проектные роли не существуют, когда их никто не отыгрывает. Если какая-то проектная роль (в том числе внешняя) в проекте нужна, но отсутствует, то надо найти исполнителя этой роли. Продвижение именно этим и занято для клиентуры: находит исполнителей составной роли клиента (помним, что «клиент» или «заказчик» — это обычно большое обобщение, ибо платят одни, владеют другие, используют третьи, принимают решение о покупке четвёртые, и это ещё не весь список).

Люди-актёры могут играть в проекте несколько ролей, и несколько человек могут играть одну роль. Ведущая практика, которая катализирует сотрудничество актёров в ходе качественного отыгрывания ими своих ролей — лидерство. Люди в команде должнывыполнять лидерство не только для налаживания сотрудничества внутри команды (и команды из одного человека**—** себя, «организовывать себя», «быть лидером самого себя», «сотрудничать/дружить с собой», а ещё команды из многих людей, и даже команды из многих больших оргзвеньев-предприятий) но и с необходимыми представителями/исполнителями внешних проектных ролей**, чтобы играющие эти роли** внешние по отношению к команде люди были вовлечены в проект и оказывали содействие в продвижени****и всех альф проекта по их состояниям**.**

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

Номер п/п	Роль	Метод работы роли	Исполнитель роли	Должность исполнителя роли	Организация исполнителя роли	Степень мастерства исполнителя в данной роли	Предмет интереса	Предпочтение	Стратегия агента

А ещё внешние проектные роли берут не только по отношению к надсистемам целевой системы, но и по отношению к системам создателей в их графе, причём иногда они будут довольно далеки по этому графу от целевой системы. Команде в каком-то месте графа создателей всё равно, речь идёт о надсистеме целевой системы или любой другой команде любой другой системы в графе создателей: «не члены нашей команды, а взаимодействовать надо» — всё, эти роли попали во «внешние проектные роли», проектирование ведь обычно ведётся не абстрактное, а в рамках работы какой-то команды. И если CEO считает все 8 тысяч человек какого-то холдинга «нашей командой», то команда какого-то небольшого проекта на пять человек в этом холдинге посчитает роли этого CEO совсем внешними (если вообще учтёт).