Выявление ролей

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


Проект сдачи баланса

Роли по разным классификациям предприниматель инженер менеджер
Директор Мы должны соблюдать законодательство РФ    
Главный Бухгалтер     Согласно положения о бухгалтерском учете баланс должен быть сдан до 31 марта
Программист 1С   Обеспечение регламентной работы 1С, необходимой для формирования баланса  
Проект сдачи баланса

В данном случае получается, что непосредственно баланс создает программа 1 С, а бухгалтер контролирует только сроки и факт сдачи в налоговую.
 

Пост заставил задуматься. Но при этом соглашаться не хочется. Бухгалтер может быть и менеджером (контролировать выполнение задачи), и инженером (делать задачу), и даже предпринимателем (реже, конечно, но искать новые пути работы с балансом). Нужно ли бухгалтеру в проекте задумываться о том, какую роль он играет? Думать, как мы знаем, не всем необходимо, но в целом полезно.

Олег, спасибо за пост!
Тут дело в том, что с одной стороны, в любом проекте мы можем выделить предпринимательскую, инженерную и менеджерскую области интересов – и всеми тремя необходимо заниматься в любом проекте, чтобы он окончился успешно. Отсюда и эти крупные роли “предприниматель”, “инженер”, “менеджер”, которые универсальны даже для проектов вроде постановки танцев.
Но при этом проекты разные, деятельности в проектах разные, и только трех ролей для проекта будет очень, очень мало. В зависимости от деятельности там будут появляться свои специфичные роли: например, в образовательном проекте у вас появятся роли вроде “преподаватель-предметник”, “преподаватель-лидер”, “методолог”, “методист” и прочие – которых не будет в компании, которая строит мосты. Так что выделение ролей в проекте зависит от деятельности, которую рассматриваем.
Но и это еще не все. В главах 7-8 указано, что современный системный подход 2.0 основан на субъективизме: система выделяется не “объективно”, по факту ее наличия в физическом мире, а субъективно в зависимости от того, что вам вообще от системы нужно. Почему это важно, описано в моем комментарии к другому посту (заодно и приведен пример с проблемами “объективного” выделения). Роли выделяются точно так же: по преследуемым исполнителем роли интересам и выполняемым практикам. Никаких детальных универсальных классификаций (“волшебных таблеток”) тут нет, как и нет универсальных классификаций неудовлетворенностей/психологических потребностей, универсальных алгоритмов проведения системного разбиения. Все эти штуки очень контекстозависимы.

Должности – это не то же самое, что и роли! Должности определяются по полномочиям по распоряжению ресурсами, фиксируются в документах предприятия. Роли обычно не фиксируются, роли люди играют в ходе исполнения практик, в коммуникации, и в коммуникации же могут динамично их менять. Если Васю Иванова интересует “срок разработки фичи”, то вне зависимости от должности Вася Иванов сейчас играет роль “операционного менеджера”. Если дальше Вася Иванов переключится на “требования к системе” и будет их обсуждать в течение 10 минут, то в ходе этих 10 минут Вася Иванов будет играть роль “инженера по требованиям”, и разговаривать с ним надо будет как с инженером, иначе коммуникация провалится. При этом должность у Васи может быть как “директор департамента”, так и “программист”, “архитектор” или еще кто-нибудь. Должности могут совпадать с играемой человеком ролью (сейчас или бОльшую часть времени проекта), а могут и не совпадать.

“Бухгалтер” может быть как и должностью, так и ролью. Если мы говорим об интересах, практиках, рабочих продуктах (например, бухгалтерском балансе), то мы имеем в виду роль, у которой есть практики составления бухгалтерского баланса (и эти практики надо обсуждать, если хотим повысить качество рабочего продукта). Если произносятся слова вроде “должностная инструкция”, то речь уже не о роли, а о должности. Как правильно указала Маргарита, человек на должности бухгалтера может выполнять и не бухгалтерские практики, а, например, менеджерские. Тогда в этот момент у него роль менеджера (а должность по-прежнему бухгалтер).

По поводу примера с проектом сдачи баланса:

  • "директор" тут больше похоже на название должности. Если выделен интерес "законодательство РФ", то роль будет скорее называться "юрист".
  • главбух (должность): интерес "срок сдачи отчета" – менеджерский, тут все ок.
  • у программиста интерес выделен нечетко. "обеспечение работы" надо расшифровать: он делает модуль для сдачи отчетности и должен успеть до 25 марта? или он чинит баг, который мешает сдать отчет? еще что-нибудь?
  • мы рассматриваем как исполнителя роли не просто человека, а человека вместе с его экзокортексом. Точно так же оргзвеном в организации будет не просто "Вася Пупкин, исполняющий роль бухгалтера", но "Вася Пупкин в роли бухгалтера + бухгалтерский экзокортекс". Программа 1С сама не принимает решения по формированию отчета, не проверяет его, не несет ответственность за решения, она только помогает бухгалтеру. Так что исполнитель роли все равно бухгалтер.
1 лайк

Анна, большое спасибо за развернутый комментарий!
Объяснение должно позволять делать предсказания.
Первая часть действительно даёт предсказание - если вошёл в проект, то ищи менеджера- инженера- предпринимателя. Называться они могут по разному смотри какие вопросы задают, смотри на их интересы, намерения, предпочтения. Если какую-то роль не нашел, то, наверно, проект будет неуспешным.
Но добавление в качестве ролей многообразия всяческих бухгалтеров, маркетологов, аналитиков и т.п. вообще никак не позволяет мне извлечь из этого никакой практической пользы, либо вывод будет тривиальным - бухгалтерским учетом занимается бухгалтер.

Поняла проблему)))
Смотрите, тут такая штука. Далее в текстах глав 7-8 и 11 будет определение успешной системы. Успешной называем систему, в которой учтены интересы внешних (в первую очередь) ролей, определенных командой как важные. Соответственно, чтобы все эти интересы были удовлетворены, нужно, чтобы были внутренние роли, которые на эти интересы “отвечают”.

“В проекте должен быть предприниматель, инженер, менеджер” – это необходимое, но не достаточное условие для успешности системы. Достаточные условия каждый раз придется определять в зависимости от вашего проекта и вашей роли в нем.

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

Сама концепция ролей не привязана к доменной области, позволяет в одинаковом ключе обсуждать самые разные роли (например, перечисленные выше) с использованием понятий “интересы”, “предпочтения”, “намерения”, “практики”, “рабочие продукты”. Но чтобы рассмотреть какой-то проект, потребуется вот этот вот большой концепт приземлить на какой-то домен. Знание, какие могут быть вообще роли в проектах вашего типа – это деятельностный кругозор в модели человека-платформы) и да, для проекта он тоже потребуется (хотя бы на уровне “в принципе понимаю, какие роли могут быть в проекте такого типа”).

1 лайк

Анна, большое спасибо за разъяснение!

Пожалуйста)

Доброго дня. Спасибо за пост - интересен опыт других людей по назначению ролей и совмещению с участниками проекта. Полностью согласен с Анной - невозможно постоянно придерживаться только 3-х позиций, поскольку в жизненном цикле проекта один и тот же человек может выполнять эти роли в зависимости от решаемой задачи.
Пока что мы пришли к следующему алгоритму выявления ролей: четкое формирование конечного продукта (понимание того, что у нас получится в итоге); выявление необходимых действий для получения конечного продукта, определение должности, ответственной за выполнение действия и назначение ответственных.
Маргарита правильно расписала роли, которые выполняет бухгалтер. Не соглашусь с ней только в том, что бухгалтеру не нужно задумываться какую роль он выполняет в проекте - это просто необходимо, поскольку он влияет на целевой продукт. По личному опыту могу сказать, что люди, задумывающиеся о своей роли в проекте, гораздо более эффективны, чем простые исполнители, поскольку они заинтересованы в конечном продукте, а не в процессе.

Добрый день! Спасибо за Ваш комментарий. Исходный импульс написания поста возник после прочтения главы 6 курса Введение в системное мышление. В первой части говориться что универсальные роли предпринимателя, инженера, менеджера могут в зависимости от проекта называться по разному, например парикмахер это инженер в контексте парикмахерской. А во второй части есть положение, что роль можно выявить по практике или рабочему продукту и приводится пример бухгалтера, рабочим продуктом, которого является бухгалтерский баланс. При появлении роли следующим должны появляться интерес, предпочтение, намерение. У меня возникло следующее сомнение, что при появлении роли бухгалтер не появляется определенных вне контекста конкретного проекта интересов -предпочтений - намерений. Все равно я должен определить что за целевая система, какая надсистема, кто является интересантами системы, какие у них интересы и предпочтения и роль бухгалтер здесь никак не помогает. В целом Анна объяснила, что такие роли необходимы для приземления универсальной модели на конкретный проект. Получается чтобы не писать в документации инженер, который сделает бухгалтерский баланс, а просто обозначить бухгалтер.
В вашем высказывании, что означает - “задумываться о том какую роль выполняет” при условии, что специалист знает, какая конкретно его целевая система (рабочий продукт). Какую дополнительную ценность принесет думание?