Внешние и внутренние роли
Условно можно разделить функциональные/проектные/stakeholder роли на внешние и внутренние по отношению к команде инженеров, непосредственно создающих систему (с командами создателей по всему графу создания сложнее, там каждый раз надо разбираться, какой именно из проектов имеется в виду).
Внутренние роли --- это роли команды проекта (классические инженеры или не слишком классические --- врачи, преподаватели, разные специализации менеджеров, маркетологи и т.п.), а внешние --- это все остальные, которые в команду проекта не входят, но на которых влияет или которые влияют на проект. Типичная внешняя роль--- «пользователь», которого лучше бы называть по его роли в егопредметной области --- игрок, пациент, едок, а ещё плательщик, подрядчик, инспектор и т.п.
Хороший анализ видов внешних ролей в крупных продажах (например, инженерного оборудования --- в отличие от розничной продажи игрушечной машинки) дан в книге Neil Rackham «Стратегия работы с клиентами в больших продажах»[1]. В этой уже очень старой (1989) книге говорится, что в крупной организации за простым словом «клиент» могут скрываться самые разные роли --- и со всеми ними нужно работать по-разному. Так что «нашими клиентами являются поликлиники» уже больше тридцати лет лучше не говорить, это не лучшая практика. В реальной жизни внутри этой поликлиники обнаруживается много разных ролей --- и врач, и медсестра, и менеджер, и айтишник (да ещё несколько разных!), и лаборант, и пациент, и невидимый обычно инвестор-владелец. Когда вы говорили «нашими клиентами являются поликлиники», то кого из них вы имели в виду? Для каждого из них нужно уметь отвечать на разные вопросы, подавать материал на разном уровне детальности, хвалить систему за разное, по-разному отстраиваться от конкурентов, по-разному вести переговоры на разных стадиях продажи. Поэтому пытайтесь называть внешние роли не по отношению к команде (тут вырвется заведомо сверхобщее слово«клиент», как «все эти которые снаружи»), а как они называются у себя там в своих деятельностях, в своих командах.
Мы рекомендуем табуировать некоторые слова, которые очень любят использовать в подобных случаях, и которые скрывают за собой целые букеты ролей с самыми разными ролевыми предпочтениями в самых разных важных характеристиках систем:
- Пользователь --- называйте так, как они называют себя в проектных ролях их проектов. Если речь идёт об игре, то это «игрок». Если корпоративный софт, то там обычно много самых разных людей, играющих самые разные роли --- и для этих разных ролей придётся учитывать самые разные важные им характеристики, их нельзя объединять словом «пользователь». Ключевой ориентир тут --- роль называется по ключевому методу работы, которым занимается исполнитель роли. Если играет в компьютерную игру --- игрок, если врачует --- врач, если думает о финансах --- финансист. Простая проверка: есть ли в названии какая-то предметная область, специализация метода? Не просто «пользователь», ибо для «пользователя» предметная область непонятна, метод для «пользователя» не прикладной из какой-то предметной области, а просто «метод вообще», это слишком абстрактно для продуктивных рассуждений! Заземляйте! Должны звучать слова из какой-то предметной области, а не общеметодологический слова!
- Покупатель --- обычно там тоже отдельно бенефициар (тот, кто получает выгоды от купленного), приобретатель (юридическая сторона договора), плательщик, доверенное лицо (например, курьер, получающий покупку), эксперт (тот, кто выбирает товар) и т.д. И их всех нужно учитывать в разных ролях, учитывать их разный ролевой интерес к самым разным важным характеристикам.
- ... вы уже поняли идею. Слово «заказчик» или «клиент» также является подозрительным --- часто там есть люди с противоположными предпочтениями. Финансист-заказчик хочет минимальную цену и поэтому минимальные возможности, инженер-заказчик хочет максимальные возможности и поэтому максимальную цену --- и они там имеют противоположные предпочтения в цене и возможностях, в случае объединения их в «заказчика» мало что с этим можно будет сделать, это всё учитывать в проекте нужно отдельно.
Часто внешние люди-в-роли/стейкхолдеры недоступны. Например, у вас 10 тысяч игроков вашей игры на телефоне, у всех них одна роль «игрок». Но пока игровая программа ещё не написана и в эту игру никто не играет, то и игроков нет. Помним: если какой-нибудь «Вася Пупкин»::оргзвено/«конструктивный объект» не играет хоббита::роль/«функциональный объект», то никакого «хоббита» в этот момент в физическом мире нет! В таких случаях, когда «игроков роли нет, спросить некого, они будут когда-нибудь», внешние роли поручают представлять членам команды.
Четверть века назад для этого использовался метод персон, описанный в книге Алан Купера «Психбольница в руках пациентов»[2] в 1999 году. Там моделировались не роли, а исполнители ролей --- персонажи/персоны (persona). В этом методе предлагалось составить типовой портрет пользователя продукта, и кто-то из команды должен был играть его или её роль, как в театре. Например, «мать-одиночка, 32 года, живущая на окраине небольшого городка, пользующаяся своим планшетом для ведения домашних финансов». Но в последние годы прошла волна критики метода персон, ибо фокус его был направлен не на моделирование роли и методов работы роли, чтобы выявить интересы роли, но на моделирование несущественных характеристик агента-исполнителя роли, которые слабо связаны с сутью дела, то есть с предметами интереса персоны-в-роли. Это типичная ошибка: работа с агентом, а не выявление метода работы агента, его роли, интересов роли.
Это как если бы мы советовали представить в методе персон Принца Гамлета, предлагая точнее описать его вес, рост, пищевые привычки, предпочтения в одежде (тем самым описывая не роль, а агента, который мог бы играть Принца Гамлета) и надеясь при этом, что это даст нам более точный ответ о его деятельностных предпочтениях в моменты, когда он задаёт свой ролевой вопрос «быть или не быть». Понятно, что это психологически удобно команде. Крайне важно, чтобы команда проекта разрабатывала систему не как удобную «для себя», ибо это будет конфликт интересов--- им будет удобна та система, которую легче разработать, а как удобную «для других». И разрабатывать систему для «толстого Гамлета» много лучше, чем для «меня, хотя я ни разу не Гамлет, но готов его изобразить, уж как понимаю». А вот с точки зрения моделирования ролевых интересов персоны--- это тупик, хотя для успеха системы нужно удовлетворить именно ролевые интересы!
Лучше бы абстрагироваться от того, что «мать-одиночка живёт на окраине небольшого городка» и вместо «пользователя» назвать её «домашним финансистом» --- и это отсечёт в обсуждениях все области интереса матери-одиночки, все области интереса жителя небольшого городка, и это правильно, они будут только лишними, отвлекать внимание от важного. Если нужно учесть какие-то особенности исполнителя/актёра, то их учитывают как особенности другой роли этого актёра, а не самого агента-актёра. Так, для плохо видящих (важная характеристика: accessibility, доступность интерфейса) нужно предусмотреть крупный шрифт в интерфейсе (предпочтение). Но при этом мы понимаем, что роли «домашний финансист» и «плохо видящий» имеют разные важные характеристики, и эти характеристики будут отражены в функционале и конструкции системы по-разному.
Может даже быть выявлен конфликт интересов (разные предпочтения по одному предмету интереса/важной характеристике у одного исполнителя роли). Домашний финансист хочет увидеть сразу много на маленьком экране, а слабовидящий --- крупный шрифт, и пусть с этим шрифтом на экране поместится не всё, листать будет неудобно, зато всё видно! Какой в итоге будет размер шрифта --- как для слабовидящего, или как для домашнего финансиста? Кто победит в этом конфликте интересов? Теперь можно предлагать разные решения. Например, экранную лупу для шрифта (на экране всего много, но лупа даёт возможность посмотреть что-то из этого в нормальном для глаз размере), регулируемый размер шрифта (каждый исполнитель роли домашнего финансиста и плохо видящего настроит себе размер шрифта по-своему) и т.д.
Все современные методы моделирования внешних ролей в проекте (например, метод Jobs To Be Done[3]) пытаются одновременно как поднять точность содержательного моделирования роли и метода работы этой роли, чтобы точнее определить ролевые предметы интересов и предпочтения (нужен успех, поэтому удовлетворить эти предпочтения--- важно!), так и поднять психологическую достоверность этого представления для команды проекта, ибо «помочь человеку» психологически легче, чем «удовлетворить тому, что описывается моделью». Для этого в команду на личные встречи приглашают различных экспертов по предметной области, устраивают фокус-группы для потенциальных исполнителей нужной внешней роли, члены команды сами пробуют набрать необходимый опыт и сыграть за внешнюю роль.
Методы моделирования и «личного представления живыми людьми» разных внешних ролей в проекте обсуждают при разработке концепциииспользования системы (описание функциональности такой системы, которая приносит пользу в ходе её эксплуатации). Разработка концепции использования системы ведётся по методам разработки, которые задействуют разработчики::роль. Кроме концепции использования разработчики::роль разрабатывают также концепцию системы, выполняют проектирование/design с детальностью, достаточной для изготовления, изготавливают систему (задействуя внутреннюю производственную платформу, «завод», «конвейер», который строят инженеры этой платформы). Разработчики/developers::роль много ещё чего делают, и их обычно считают главными, кто озабочен удовлетворением интересов внешних проектных ролей, особенно пользовательских ролей (мы говорили уже, что этих ролей может быть множество, и называться они будут не «пользователь», а как-то более специфично для их предметной области).
Тем не менее, удовлетворением интересов внешних ролей будут озабочены не только разработчики, но и все командные роли, участвующие в проекте. Так, архитекторы::роль тоже моделируют внешние проектные роли, ибо они озабочены удовлетворить их интересы в части специфических архитектурных характеристик, которые могут не учесть разработчики. Скажем, разработчики серверной системы могут быть озабочены какими-то возможностями продукта, которые требуют слишком большой вычислительной мощности для одного «игрока», задача архитектора--- помнить, что этих игроков будет много. Поэтому архитектор идёт моделировать то, что ему расскажут люди из службы продвижения (ожидается этих «игроков» сто, сто тысяч, или сто миллионов одновременно). И далее архитектор и разработчики будут находиться в продуктивном конфликте, а у разработчиков, скорее всего появится технический (архитектурный) долг, то есть работы, которые они должны сделать, чтобы удовлетворить интересы игроков не только по функциональности, но и интересы игроков («игровой аудитории») по доступности и производительности серверов (эти «доступность» и «производительность» как раз будут архитектурными характеристиками), а представителем «игровой аудитории» (все игроки в целом, разница с одним игроком как разница клиентуры с одним клиентом) будет служба продвижения. Архитектора команда разработчиков может считать внешней проектной ролью, менеджер команды считает разработчиков и архитектора (или целую команду архитекторов) вполне себе членами команды.
Показателен пример одной из команд инженеров, которые вдруг попросили включить в состав команды местного юриста. Мотив: на переговорах агент, играющий роль юриста, вёл себя так, как будто работал против команды инженеров, а не был членом команды! Расчёт команды: после формального включения в члены команды исполнитель роли юриста будет учитывать прежде всего интересы инженеров, а не интересы каких-то там своих «надзоров» или кого ещё он там учитывает, представляя и продвигая интересы не инженеров по отношению к этим «надзорам», а интересы «надзоров», игнорируя интересы инженеров.
«-- Сколько будет дважды два?--- А мы покупаем или продаём?», это всегда надо помнить. В паутине организационных отношений легко запутаться без понимания (то есть акцент на моделировании,причём модели документированы) методов работы, ролей, предметов интересов и интересов, кто::агент чьи::роли интересы представляет.
Важны оказываются не столько «внешнесть» или «внутренность», сколько учёт (то есть акцент на документирование результатов моделирования) всех найденных предметов интересов и далее выполнение работ по согласованию и удовлетворению интересов на основе этого списка предметов интересов как чеклиста--- и при этом надо помнить, что интересы происходят от культурно-обусловленных ролей, а не конкретных агентов, исполняющих роли «носителей интересов», многие интересы не будут предъявлены публично, но могут появляться в частных переговорах (и это хорошо, ибо если все говорят со всеми, то это плохая архитектура, плохая модульность проекта, подробней об этом в курсе «Системная инженерия» и «Системный менеджмент»).
В любом случае, недостающие и внешние, и внутренние роли всегда нужно как-то отыгрывать в проекте, организовывать для этого каких-то компетентных, имеющих хоть какую-то квалификацию, а не случайных доступных исполнителей таких ролей, иначе успешность системы будет под вопросом. Помним, что успешность системы определяется согласием ролей (что-то про датское королевство понимает «принц Гамлет»), а не согласием исполнителей ролей (про датское королевство Вася Пупкин, которому поручили играть принца Гамлета ничего не знает)!
Если исполнителем роли ценителя музыки выступит глухой человек, то роль он исполнит плохо --- и его согласие с какой-то музыкой ничего значить не будет, успеха музыки это гарантировать не будет. Если исполнителем роли инженера-архитектора выступит профи в операционном менеджменте, то его согласие с конструкцией системы административно значит много, а вот в системной инженерии --- ничего не значит, ибо согласие нужно квалифицированного в системной инженерии актёра-исполнителя роли. Согласие опытного исполнителя роли операционного менеджера, самозванцем выступающего в роли инженера тут в зачёт не идёт.
Неудачи/неуспех многих и многих проектов объясняются тем, что решения принимают неопытные исполнители профессиональных ролей (зато полномочные принимать решения за любую роль, но это объясняет происходящее, но не оправдывает).
Если кому-то сложно представить абстрактного «Принца Гамлета» (но именно это и нужно делать!), то представляйте хотя бы персону: придумайте типичного исполнителя этой роли. В любом случае, избегайте считать, что все люди-в-ролях похожи на именно вас-в-роли. Все люди-в-ролях уникальны, а опытные исполнители этих ролей имеют большой опыт игры в соответствующей роли, плюс они часто имеют для выполнения своей роли в вашем проекте больше времени, чем вы --- если вы, конечно, не профессионал именно в этой роли. Но если вы разработчик, то ваш шанс хорошо исполнить чью-то чужую внешнюю роль близок к нулю («лучшая модель кошки --- это другая кошка, желательно та же самая», брать надо кого-то, кто имел похожее мастерство, а не кругозорное представление о мастерстве). Нужно предпринимать специальные усилия, чтобы представлять в проекте внешние роли: проводить фокус-группы, беседовать с позиционерами, изучать литературу и т.д.
О вас можно сказать то же самое: вы в ваших традиционных ролях, в которых у вас есть мастерство, будете иметь больше времени для их выполнения, и у вас больше опыта их отыгрывания, чем у исполнителей других ролей. Если это не так, и в вашем проекте «пироги печёт сапожник, сапоги тачает пирожник» про вас, то проект ваш в опасности, и эта опасность исходит от вас.
Начальник --- это не роль, это полномочия по принятию решений. Решение будет принято, но оно будет плохим, если у начальника нет мастерства в методе работ роли. Проверяйте мастерство начальников в выполнении какой-то деятельности, в занятии если не позиции, но хотя бы в мимолётном занятии роли и проявлении мастерства. Задавайте им простые вопросы для проверки (например, «каким методом вы получили этот результат? По какому учебнику я могу повторить рассуждение, приведшее вас к этому решению?»). Конечно, при этом вам придётся определиться: вы любите больше проект или начальника. Если начальника любите больше, то чёрт с ним, с проектом, заваленным из-за ролевой некомпетентности/недоквалификации агента-начальника (агента, занимающего организационное место начальника).