Почему сотрудники делают не то, что нужно

В статье Почему подчиненные делают не то, что нужно я писал о четырех типах заданий, которые может поставить руководитель: алгоритм, задача, проблема, возможность и, соответственно, о четырех типах вопросов, один из которых встанет перед исполнителем, когда он будет выполнять задание:

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

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

Еще один пример. Для наемного менеджера внутри бизнеса создание стратегии - это проблемная область, т.е. поиск и последующий выбор проблем, которые нужно решать, а для серийного предпринимателя или инвестора - это всего лишь задача, которая в свою очередь сводится к поиску соответствующего специалиста. Для того чтобы привести этот пример, мне пришлось уйти от абстрактных A, B, C, P, G в описании, т.е. пришлось добавить контекст. И теперь можно говорить не о неопределенности знания, а о сложности динамической системы, в рамках которой мы реализуем алгоритмы, ставим цели и решаем проблемы. А это в свою очередь означает, что классификация заданий превращается в известную многим айтишникам модель сложности Кеневин.

Например, упомянутые в примерах выше домены технологий, управления продуктом, бизнесом и активами можно изобразить в виде спирали на модели Кеневина. На каждом новом витке мы возвращаемся к старому контексту, но на новом уровне. Модель Кеневина часто используют для обоснования отказа от использования “старомодного” регулярного менеджмента и “тяжелых” методов проектного управления. Дескать, мы делаем новые продукты, значит система запутанная, значит только scrum, только аджайл. Но “запутанность” при этом может иметь место не на всех уровнях. Так, даже при создании принципиально новых продуктов на разработку отдельно взятой фичи, вы вполне можете смотреть как на проект, а на процесс запуска А/Б-тестов вообще как на операционку, если, конечно, зрелость ваших процессов позволяет. Проще говоря, сложность системы - это не абсолютная характеристика системы, это ваша оценка системы, которая включает и ваш опыт, и ваш угол зрения на эту систему.

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

Как правило, люди видят только конец и начало соседних витков, выпрямляя спираль в одну прямую. Например, вот так могут выглядеть уровни сложности принятия решений некого наемного менеджера среднего звена:

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

И что со всем этим делать, как находить общий язык, какие софтскиллы нужны? Это отдельный большой разговор. Отмечу только, что софтскиллы - это всегда про уважение. Стоит помнить, что твой коллега говорит то, что он говорит, и делает то, что он делает, не потому, что он идиот, а потому, что находится в другом контексте или по-другому формулирует вопросы в нем.

Вот перед нами некий профессионал своего дела. Менеджер, разработчик, серийный предприниматель - не важно. Важно, что он прошел путь по всем вопросам своего витка спирали и дошел до последнего вопроса “почему”, возможно прыгнул на новый виток и снова дошел до следующего “почему”. И теперь он свое дело делает ну очень хорошо. Чувствуете? Он делает… а зачем он это делает? Какая у него цель? Почему он занимается технологиями или зачем он делает бизнес? Поздравляю, мы снова на первом уровне.

Статья и так получилась затянутой, поэтому ответы на эти вопросы писать не буду, но подскажу, где можно поискать возможные варианты для ответов.

Типовой ответ на вопрос “какая цель?” можете узнать у любого HR, они наверняка знают, зря что ли всех спрашивают “кем вы видите себя через Х лет?”.

Варианты ответов на вопрос “зачем?” можно подсмотреть в миссиях крупных ИТ-компаний: “сделать мир лучше”, “помогать людям становиться лучше”, “дарить людям радость” и бла-бла.

Ну а с главным вопросом “почему?” вообще все просто, ответ на него давно уже дал один очень мощный компьютер. Формулировка ответа записана в книге Дугласа Адамса “Автостопом по галактике”.

Регулярно пишу в Telegram-канал Токсичный манагер про управление и все, что с ним связано. Заходите.