Ошибки в определении ролей

«Если на клетке слона прочтёшь надпись «буйвол», не верь глазам своим»[1]. Этот афоризм Козьмы Пруткова полностью применим к проектным ролям: мы должны выявлять их по словам и действиям, а не ориентироваться на официальные титулы должностей. Иногда титулы, конечно, совпадают с проектными ролями. Но часто --- не совпадают. Агент с должностью «программист», например, может оказаться техническим писателем пользовательских инструкций, вовсе не уметь программировать. То же самое--- с самоназваниями, от них тоже можно ждать подвоха. Только дела, только обсуждение предметной области какого-то метода работы (деятельности, культуры, практики --- синонимов тут огромное количество) в разговоре.

Если Принц Гамлет вдруг начинает спрашивать «Молилась ли ты на ночь, Дездемона?», это уже не Принц Гамлет! Это Василий Пупкин, который переключился на другую роль (какую? В этот момент важен кругозор! Вы можете пропустить момент, когда вам ясно говорят, что сейчас кого-то задушат!).

В момент неожиданного для вас переключения ролей у исполнителя роли/актёра полезно задать вопрос, почему это он::актёр поменял обсуждаемый «предмет интереса»/тему и стал другой ролью: вы можете узнать много интересных подробностей. Скорее всего это означает, что всплыл какой-то новый интерес: актёр вашей команды Вася Пупкин, исполняющий предыдущую роль, припомнил что-то важное, поэтому и переключил роли, тем самым проявил интерес другой роли. Не забывайте задавать вопрос о причине смены темы/«предмета интереса«/«важной обсуждаемой характеристики», когда «люди или AI»::агенты будут вдруг неожиданно менять роли в ходе разговора. Должности этих агентов неважны, разве что они будут свидетельствовать об административных полномочиях участников разговора. Должность важна только при отдаче распоряжений и определении ставки, на мышление и деятельность должность не влияет!

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

Напомним основные ошибки, которые делают люди, определяя внешние для проекта и внутренние (командные) роли. Если студент будет делать эти ошибки (они ведь тут явно прописаны), он смело может рассчитывать на два балла на экзамене. Если эти ошибки будет делать не студент, то эти два балла поставит ему жизнь:

  • Вместо роли указывают исполнителя --- конкретного человека или конкретное подразделение (ФИО или название подразделения/оргзвена), или даже AI.
  • Вместо роли указывают «ответственного» (должность, оргзвено, позиция в штатном расписании), чаще всего «начальника» (ошибка типа «Директор театра» в списке действующих лиц «Сна в карнавальную ночь». Легко узнаётся и по квалификаторам «ведущий», «главный», «менеджер»: эти слова в названии роли должны сильно настораживать).
  • Указывают звание (учёную степень, воинское звание) вместо роли, попытки указать степень мастерства, но не сам вид мастерства.
  • Указывают тип организации, в которой много различных ролей (клиника, завод). Указать для медицинского проекта «поликлиника» --- какими методами работы занимается поликлиника, какие у этой «сверхроли» важные характеристики и предпочтения в их значениях? Там внутри много людей, они исполнители самых разных методов работ в самых разных ролях, и там среди них наверняка будут разные предпочтения по одним и тем же характеристикам одной и той же системы, их нельзя замешивать в одно целое! Указывайте роли в больших организациях подробно, чем ближе к узким профессиональным ролям, тем лучше!
  • Считают, что один агент-исполнитель роли --- это одна роль. Нет, один исполнитель/актёр может исполнить десяток ролей, идёт ли речь о человеке, AI или целой организации. Впрочем, и одну роль может исполнить большое подразделение, или даже многие тысячи человек (скажем, роль «игрок» у игры с двумя миллионами игроков) или сложная сеть из множества AI-агентов.
  • Считают, что пять внешних ролей в проекте --- этого более чем достаточно. Нет, обычно счёт идёт от пятнадцати. Если выявлено всего пять внешних ролей, то это вы недостаточно подумали.
  • Забывают учитывать свои собственные роли и их интересы. Но ведь вы-агент тоже участник проекта! Что вы там делаете, чего добиваетесь (интересы), чему для этого учились, у вас высокая степень мастерства в выполнении работ каким методом?
  • Забывают про множество предметов интереса у проектной роли и множество проектных ролей, имеющих один предмет интереса. А вот предпочтения в одной важной характеристике/предмете интереса у этих ролей могут быть разными. И очень разные варианты реализации предпочтений: три актёра/исполнителя роли врача поинтересуются артериальным давлением и даже согласятся с тем, что его нужно срочно понизить, а потом предложат три абсолютно разных способа этого понижения! Поговорка про «два юриста, три мнения»--- как раз про это.
  • Не обращают внимания на проявляемый в текущей ситуации интерес, указывают предполагаемый интерес из каких-то прошлых или ожидаемых ситуаций. Нет двух одинаковых проектов, всегда уточняйте, что происходит в вашем проекте, и вот прямо сейчас (ибо ситуация в проекте обычно быстро меняется: люди деятельны!).
  • Не различают ролевых предметов интереса, самих интересов/предпочтений, не ожидают неминуемых действий агентов по реализации их намерений в достижении интересов их ролей.

Для того, чтобы разобраться с ролями в проекте, можно рекомендовать заполнять табличку примерно такого содержания. Тут приведён пример заполнения такой таблички для простейшего совещания на троих из отдела разработки:


Номер п/п Роль Метод роли Исполнитель роли Должность исполнителя роли Организация исполнителя роли Мастерство исполнителя в данной роли Предмет интереса Предпочтение/интерес Стратегия агента («что будет делать»::метод) 1 Разработчик концепции использования Jobs to be done Динара программист Отдел разработки новичок функциональность Максимизация числа фич Опрашивание всех, а что не удалось выяснить в опросе --- то придумывание 2 Визионер MVP Я программист Отдел разработки мастер функциональность Минимизация числа фич Продавливание MVP, остальное игнорируется 3 Операционный менеджер Оценка времени выполнения работы по функциональным точкам Тимур Начальник отдела Отдел разработки новичок Время разработки Минимизация времени разработки Обрезание функции даже в MVP


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

Кого нужно было ещё пригласить на совещание, чтобы полноценно обсудить эти предметы интереса? Для ответа на этот вопрос прежде всего нужно подумать, какие роли могут иметь другие предпочтения в этих важных характеристиках. Затем предположить, кто::агент может быть актёром/исполнителем этих ролей. Например, можно было бы пригласить актёра в роли разработчика, который бы дал оценку времени разработки каждой предлагаемой фичи/feature[2] системы: это помогло бы актёру в роли операционного менеджера разобраться со своим интересом. Можно улучшить результаты работы роли разработчика концепции использования, пригласив кого-то более опытного вместо текущего исполнителя (там ведь у текущего исполнителя мастерство «новичок»). Можно пригласить кого-то из службы продвижения продукта (маркетинга), чтобы лучше оценить MVP[3]. Главное, что эта простая табличка заполняется за три минуты, но она помогает спланироваться и лучше понять ситуацию. В сложных случаях такие таблички экономят месяцы бесплодных разговоров непричастных людей на неважные темы.

Особо в такой табличке нужно уделять внимание своим собственным ролям. Заявляли ли вы на этом совещании свои роли, ролевые интересы? Раскрывали ли свои намерения, планы по реализации ролевых интересов? Знали ли участники совещания, какие роли вы играете в ходе совещания, если вы явно не заявляли эти роли?

Знание должности и из какой вы организации тут совершенно неважно, равно как и какие роли вне совещания вы ещё можете играть. Главное: вы на совещании вели себя как кто (по роли)? Каким методом/способом работы пользовались в своей роли? «Никаким» и «здравым смыслом» --- это очень, очень плохой ответ. То есть вы не играли никакой роли, творили произвол, были не в культуре, не демонстрировали стиля, вели себя как «дикарь-на-производстве». Как вы помогли остальным участникам совещания лучше с вами коммуницировать? Скажем, в данном примере, рассказали ли вы явно, что будете пользоваться методом, задействующим понятие minimal viable product? Декларировали ли своё предпочтение в фичах с опорой на метод разработки с MVP и привели ли аргументы «из книжки по MVP» (то есть привели ролевое культурно-обусловленное, а не личное-без-роли мнение)?

Отвечали ли вы в своих выступлениях на интересы/предпочтения остальных присутствующих ролей, демонстрировали ли вы понимание их предметов интереса и учёт их планов по реализации их интересов в ваших планах? Или вы отвечали «просто людям» или должностям, а не актёрам-в-роли?

Вовсе необязательно строить такую табличку в письменном виде каждый раз в полном виде на каждом совещании (помним, что «поговорить в чате»--- это тоже совещание!). Но для начала вам будет более чем полезно «мыслить письмом», в данном случае выполнять моделирование ситуации с ролями с документированием в виде таблички. Сначала это будет трудно и требовать значительного времени на продумывание. Например, у каждого агента может оказаться по три роли, а совещание может быть целого десятка человек. Или возникнут трудности в выявлении роли AI. Как учитывать роль AI? Как роль, которую играет провайдер сервиса этого искусственного интеллекта (роль играет AI, или даже не создатель, а оператор этого AI, а сам AI его инструмент--- типа как «забивало» может играться плотником Васей или молотком плотника Васи), ибо ежели что пойдёт не так, договариваться придётся с провайдером сервиса AI, а не самим AI (с Васей, а не го молотком) --- и даже не с ролью «провайдер», а какой-то подролью, ибо «провайдер AI» может легко разбиться на множество самых разных ролей, и договариваться нужно будет только с какой-то одной из них, а все они будут играться разными людьми или даже целыми службами фирмы-провайдера AI.

Думать про роли и их методы будет всё легче и легче, затем вы будете это делать «на лету» и в уме. И, конечно, без какого-то методологического/трудового/деятельностного/практического/инженерного кругозора эту табличку заполнить невозможно, для людей без кругозора происходящее на совещании будет магическим действием по взаимным уговорам агентов-участников. С табличкой же становится совершенно понятно, в чём интрига, и что можно предпринять для улучшения качества принятия решений на подобных совещаниях.


  1. https://ru.wikipedia.org/wiki/Козьма_Прутков ↩︎

  2. https://en.wikipedia.org/wiki/Software_feature ↩︎

  3. https://en.wikipedia.org/wiki/Minimum_viable_product ↩︎