Что такое важное
Работа внимания позволяет выделить важное для проведения работ агента. Но что такое «важное» и как мы его выделяем?
Внимание агента субъективно, и выделение важного – тоже. Определение важного зависит в первую очередь от того, с какой целью агент начинает что-то делать. Допустим, компания планирует запустить новый продукт. Команде поручили исследовать, какой именно продукт компании выгоднее всего производить и продавать. Тогда команда посчитает важным «рынок», «конкурентов на рынке», «методы исследования рынка», но не будет выделять «методы начисления зарплаты в компании» – ей это никак не поможет достичь цели. Нерелевантные цели объекты (те, которые не связаны с целью) будут отфильтрованы вниманием.
Далее выделение важного зависит от **угла зрения/точки зрения или способа описания/**viewpoint. Команде сейчас важно посмотреть на свое поведение (связанное с достижением цели) функционально или конструктивно? То есть, нужно смотреть на свое поведение как на метод или как на работу? Если важен метод, то команде нужно будет выделить как «важные» объекты выбранного метода из нужной предметной области, в данном случае – методы исследования рынка из маркетинга, определить, каким из множества возможных методов исследования рынка (или каким набором методов) будет пользоваться команда. Например, будет проводить расчеты доступной емкости рынка, опросы потенциальных клиентов, чтобы извлечь пользу – оценить, какие продукты по итогу можно запустить на данном рынке и почему.
Потом команде нужно будет организовать работу по выбранному методу(ам), а значит, переключиться на конструктивное рассмотрение. Продумать, кто именно какие методы применяет, сколько времени это займет, как будет организована коммуникация по поводу проведенных работ (как будет координироваться работа команды) и как передаются результаты. Например, Людмила проводит опросы (или нанимает подрядчиков и координирует их работу), Иван рассчитывает емкость рынка, все это делается в течение недели, потом обмениваются результатами.
Обязательно нужно будет заземлиться и оценить, насколько возможно выполнение работ по данному проекту в нужный срок. Здесь команда столкнется с многопроектностью: скорее всего, у нее не один проект, и надо будет как-то выбирать, какие работы по какому проекту приоритизировать, а какие – отложить. То есть, команде надо будет определиться с приоритетами. И вот здесь часто возникают конфликты.
Дело в том, что «важное» выделяется по-разному не только разными агентами, но и на разных системных уровнях. Системными уровнями мы пока будем называть масштабы крупности физических объектов, позже в руководстве «Системное мышление» понятие уточнится. Как уже говорили в разделе 1, в рамках организации можно выделить следующие «системные уровни»/«масштабы крупности»:
- Компания;
- Подразделение;
- Команда;
- Сотрудник.
С точки зрения команды важным/приоритетным может оказаться порученный проект по исследованию рынка. А может – текущая работа («текучка»), которую выполняет команда (или даже «у каждого члена команды своя текучка», если команда кроссфункциональная и собрана из работающих в разных отделах сотрудников), а порученный проект команда воспринимает как «дополнительную нагрузку», от которой лучше бы побыстрее избавиться, потому что она не влияет на оценку работы команды и ее членов (а вот «текучка» влияет). Сотрудники – члены команды тоже могут по-разному оценивать важность/приоритетность проекта и по-разному распределять работы, что может привести к задержке отдачи результатов команде и задержке работы всей команды. А с точки зрения подразделения проект важен, и на команду будут давить, чтобы они поскорее предоставили результат!
Как разрешаются подобные конфликты в реальности? Чаще всего благодаря неявному и почти случайному выделению важного, а не благодаря рациональному выбору. Из всех конкурирующих за ресурс сотрудников проектов победит не тот, который действительно важен для компании, а тот, у которого окажутся лучшие лоббисты, например, руководители с луженой глоткой, которым реализация именно этого проекта поможет достичь своих личных целей, например, получить повышение или бонус. Проект такого лоббиста будет выделен как «важный», ресурсы будут направляться на его реализацию в первую очередь, о нем будут спрашивать чаще всего, ради него будут откладываться работы по другим проектам – все это признаки, что проект на самом деле важен, что бы ни заявляли о «наших приоритетах» окружающие. Важность показывают реальные данные, а не нормативные описания и не наши хотелки. Проект лоббиста размечен как «важный» во внимании тех, кто будет выполнять работу и выделять на нее ресурсы, даже если это не проговаривается вслух. Распределенное представление команды уже содержит определение важного, даже если вы всячески избегаете того, чтобы выразить его символами (например, в устной или письменной речи).
Что делать, чтобы минимизировать подобные ситуации и выбирать рационально? Договариваться! Когда договариваетесь, вам надо будет исходить из следующего: важность работы не задается на том же системном уровне, на котором будет выполняться, она задается как минимум на уровне +1! А если мы говорим о компании, то важность в идеале должна задаваться на максимально доступном уровне – уровне компании. Только в этом случае можно оптимально выстроить работу компании в целом. Выбор на более низких системных уровнях может привести к локальной субоптимизации: когда компания свою цель не выполняет, зато руководитель, пролоббировавший свой проект, свои цели реализовал успешно (за счет всех остальных).
В случае с командой, которой поручили исследовать возможность запустить новый продукт на рынок, это означает следующее. Чтобы назвать сроки выполнения проекта, команде нужно понять, как приоритизировать работы по этому проекту относительно работ по другим проектам. Значит, задаем вопросы: каковы цели компании? как именно этот проект способствует их достижению? важен ли этот проект настолько, что мы должны отложить какие-то другие проекты и даже меньше заниматься текучкой, чтобы реализовать его? Задавая вопросы, мы исходим из того, что ресурсы ограничены, и количество проектов, которые команда сможет качественно реализовать за какой-то период времени – тоже. Работать 24/7 не вариант (да и не особо поможет в случае самых сложных проектов).
Прояснить эти вопросы можно на уровне подразделения. Руководители подразделений должны смочь ответить на эти вопросы – а если не могут, то поднимаемся на уровни выше. **Понимание важного должно быть общим/**shared, иначе все будут выбирать так, как им будет удобно на своем уровне и исходя из своих личных целей.
Допустим, оказалось, что проект приоритетный для компании, и нужно отодвинуть другие проекты ради его реализации. Тогда важность/приоритетность проекта должна отразиться в методах/способах приоритизации работ по проекту и на уровне подразделения (увеличиваем сроки по остальным проектам, откладываем какие-то из них), и на уровне команды (команда приоритизирует работы по этому проекту), и на уровне отдельных сотрудников. А еще приоритеты должны отобразиться в методах оценки работы сотрудников. Например, если компания применяет метод Objectives and Key Results (OKR) для постановки целей и оценки работы сотрудников, то проект исследования рынка должен попасть в OKR команды (и, соответственно, сотрудников). Изменение в выставленных приоритетах должно привести к изменению в методах оценки, иначе будет выполняться не то, что нужно, а то, за что оценивают. Кроме того, если в рамках проекта потребуется привлечь сотрудников других подразделений, включить их в команду проекта, даже если на старте их не было (допустим, подключить инженеров для создания минимального продукта/MVP), то методы оценки работы новых членов команды тоже должны быть изменены! В их OKR тоже должен появиться проект запуска продукта на рынке. Иначе они тоже будут воспринимать время, выделяемое на проект, как «лишнее» в своих расчетах личной мощности/при аудите времени. Хотя оно ни разу не «лишнее», а очень даже «продуктивное»!
В некоторых компаниях обсуждение приоритетов заглохнет, не успев начать. Например, команда пытается начать разговор с руководителем подразделения как с операционным менеджером о приоритетах, но руководитель слышать ничего не хочет, считает, что все должны успеть. Возможные причины:
- Агент считает, что работать в режиме многозадачности – это оптимально. Возможные причины:
- отсутствие расчетов реального времени выполнения проектов (который показывает неоптимальность),
- недостаток квалификации в операционном менеджменте (нет знания о методах и умения их применять);
- Агент, который должен исполнять роль операционного менеджера и применить методы операционного менеджмента, уклоняется от их применения. Возможные причины:
- это непривычно агенту,
- он не хочет выполнять и считает, что может позволить себе уклониться от применения методов;
- агенту очень неприятно заземляться и признавать, что сделать все сразу нельзя, поэтому он предпочитает вообще не углубляться в расчеты, надеяться на чудо и возможность свалить ответственность на команду;
- у агента недостаток квалификации в операционном менеджменте.
В случае если приоритеты команде не хотят выставлять и требуют реализации всего и сразу, можно попробовать это обойти, обратившись на уровень выше в иерархии компании (к начальнику начальника) для обсуждения приоритетов. Если это по какой-то причине не получается сделать, можно попробовать извлечь реальные приоритеты из распределенных представлений руководства. Для этого надо будет навести внимание на признаки важности проекта, которые видны из поведения руководства, то есть, обратить внимание на:
- частоту, с которой спрашивают о том или ином проекте;
- какой проект выбирается, в случае если дедлайны по двум проектам совпадают;
- то, сколько ресурсов выделяется на проект;
- то, какой именно агент, наделенный полномочиями повлиять на приоритеты, интересуется проектом в какой роли,
- и другие признаки важности, которые вы обнаружите.
Даже если мы не желаем признавать, что у нас есть приоритеты, они все равно существуют. Достаточно обратить внимание на реальные ситуации выбора: что оказалось важнее, когда нехватка ресурсов стала очевидна? Если вы хотите уточнить собственные приоритеты, ответьте себе на вопрос: если завтра вам придется экстренно ехать к врачу на полдня, какие работы вы за оставшееся время выполните, а какие отложите? Что если ресурсов станет в 5-10 раз меньше, какие проекты вы все-таки запустите и/или доведете до конца, а какие отложите? Вопрос о проектах можно задавать и на уровне команды, и на уровне подразделения.
Определение важного будет регулярно меняться/эволюционировать. Например, в проекте исследования рынка обнаружат, что новый продукт запускать бессмысленно. Тогда на уровне компании могут принять решение закрыть проект, что повлияет на приоритеты (а они повлияют на методы оценки работы сотрудников).
В целом, методы выделения важного на разных системных уровнях применять не слишком сложно. Проблемы обычно не в сложности метода, а в том, что работа по приоритизации проектов и работ выбранным методом вообще не ведется. Внимание S2 не наводится на рациональный выбор проектов, работ и проблем для решения.
Работа по приоритизации не ведется, потому что нет понимания ее важности и того, как она экономит время. Или потому, что команды и отдельные сотрудники стесняются задавать вопросы о приоритетах. Или потому, что срабатывает внимание S1, которое «задает» приоритеты совсем иначе.
Внимание S1 (а также мышление S1) сработает автоматически, из-за него мы выделим и посчитаем более важными объектами, которые:
- Часто встречаются, привычны и знакомы, легко выделяются агентом;
- Ассоциируются с объектами, которые видели до этого;
- Соответствуют фону;
- Связаны с нами;
- Имеют приоритет с точки зрения биологии (угрожающие, сексуальные стимулы).
Мы выделим как важное то, что привыкли выделять. Типовая проблема инженера, который стал менеджером: он привык выделять как важное «метод», но не привык думать о «работе». Ему придется научиться методам организации работ других агентов, придется думать не о том, как выполнить работу самому, а как организовать работу команды и отдельных членов команды. Но учиться придется с включением внимания S2. Из-за внимания S1, направленного на привычное, он будет пытаться тащить работу в одиночку. Чтобы научиться исполнять новую для себя роль менеджера, придется менять рабочие привычки и выделять в качестве важных объекты, которыми обычно интересуются менеджеры[1]. Узнать о том, что должно быть важно для менеджеров, чтобы качественно выполнять работу, вы сможете из руководства «Системный менеджмент». В руководстве по рациональной работе будут приведены лишь некоторые методы операционного менеджмента.
Мы также будем выделять как более «важное» те объекты, которые связаны с «новыми вводными». Например, мы будем стремиться бросить старую работу и начать новую только потому, что она только что прилетела и кажется более важной, чем другие задачи в списке, над которыми тоже нужно работать. Обходим это за счет записи всех задач (или проектов, или проблем, те work items/предметов работ) в очередь и приоритизации сразу по всей очереди.
Кроме того, мы автоматически будем выделять как «важную» работу, которая даст возможность лично нам добиться каких-то своих целей или просто получить одобрение. Поэтому и необходимо приводить в соответствие методы выбора проектов и методы оценивания работ, менять/обновлять их синхронно: иначе сотрудники просто начнут выбирать то, что оптимально для них. Нужно устранять конфликт и делать оптимальной для них выполнение именно той работы, которая важна компании.
Вопросы, которые можно задавать для рационального выбора важного:
- Какой цели пытаемся достичь?
- На каком системном уровне делаем выбор (реально и на каком должны бы выбирать)?
- Какое рассмотрение нас интересует?
- С точки зрения какой роли смотрим?
- Как конкретный агент делает выбор в ситуациях конфликта?