Специфика задач
Алексей работает с исследователями и техническими специалистами, которых можно назвать творческими, потому что они занимаются задачами, которые на старте не имеют понятного пути решения. Это называется R&D, или НИОКР — научно-исследовательская и опытно-конструкторская работа. Исследовательская работа должна состоять из самого исследования и из внедрения.
По словам Андрея Гулина, инженера, которого спикер считает одним из лучших руководителей, работа с творческой технической командой — это когда ты говоришь, что им делать, а они делают что хотят. Давайте разбираться, почему так происходит.
Уникальность. Вы ставите задачу, а вам говорят, что понятия не имеют, что это и никто такого не делал. Добавляют, что ушли думать и вернутся, когда появится идея.
Уникальность задачи — это классный челлендж. Вы не можете попросить повторить или переиспользовать существующую информацию.
Нет хорошо работающих аналогий. Вы ставите задачу исполнителям, а вам отвечают, что это не типовая история и они не могут повторить предыдущие решения. Это правда.
В R&D большая проблема с аналогиями, потому что чаще всего они ложные друзья ресёрчера. Как правило, нет универсального решения, любая аналогия — это попытка перепридумать что-то из существующей области в новой. Часто это не то, что хочется сделать.
Нет хорошего фреймворка работы со сроками. Вы ставите команде, казалось бы, не самую сложную задачу, но, когда уточняете, будет ли она готова через две недели, вам отвечают, что это непонятные и нереалистичные сроки. Во многом этот ответ лежит на стыке специфики исследовательских задач и человеческой психологии, потому что все люди немного по-разному воспринимают поставленные задачи.
Специфика людей
У людей, как и у задач, есть своя специфика. Особенности каждого человека влияют на восприятие поставленных ему задач.
- Отторжение чужой идеи. Вы приходите к команде и просите взять классное рабочее решение, которым все пользуются. Вам отвечают, что оно не очень понятное и его надо будет доработать. Добавляют, что решение писали не самые умные люди, его адаптировали под маленький масштаб и оно им не нравится. В целом люди отторгают готовые решения.
Похожая история случается, когда вы приходите к человеку и рассказываете об обалденной идее. Тот отвечает, что она очень интересная, но у него есть десяток идей, которые он уже два года холит, лелеет и будет работать с ними.
Вы не понимаете, как убедить человека поверить в предложенную идею. Единственный шанс — это сделать так, чтобы он считал её своей. Но это не так просто. - Любовь к своей идее. Обожание того, что человек придумал или хочет сделать. Он верит в свою идею и хочет доказать всем, что в нём зря сомневаются.
Появляется когнитивное искажение confirmational bias, когда человек в своих исследованиях и обсуждениях проблемы находит только те факты, которые подтверждают его точку зрения, и отвергает все, которые не подтверждают её. В процессе бесконечного обсуждения, что эта идея классная и все факты говорят за неё, попадаем в третью проблему. - Остановиться невозможно. R&D — это в каком-то смысле азартная игра. Человек думает, что сейчас получится и нужно ещё немного времени для решения проблемы. В R&D вы копаете и верите, что сейчас найдёте решение и получите желаемое.
Эти три когнитивных искажения вместе с особенностями исследовательских задач очень сильно влияют на то, что люди вместо поставленных вами задач решают другие.
Как с этим работать
Можно попросить не брать выбранные ими задачи и просто следовать вашим указаниям. Но вы всё-таки собираете исследовательскую команду, которая должна придумывать, ресёрчить, генерировать идеи. Именно поэтому можно использовать определённые механики.
Говорить не что делать, а как должен выглядеть результат. В противном случае человек продолжит следовать заданному руководителем пути, а если у него не получится — ответственность на руководителе. Так у сотрудника будет ощущение выученной беспомощности.
Если вы говорите ему, что нужно дойти до какого-то конкретного результата, у него сохранится желание придумывать и он будет перебирать варианты решений. Это исследовательская работа.
Не формулировать решения под видом задачи. Потому что иначе вам будут приносить проекцию решения. Люди внутри этой работы будут чувствовать себя руками для выполнения задачи.
Поставьте человеку задачу «прийти из точки А в точку Б», а как это сделать пусть решает сам исполнитель. Тогда он начинает ощущать свою ответственность за выбор из многих решений.
Договариваться о бюджете на ошибку. Если у вас нет права на ошибку, то вы не рискуете, не пробуете и не исследуете. В итоге получается максимально стабильная узкоработающая система, в которой все боятся что-то сделать.
В R&D так нельзя, потому что можно свалиться в изготовление понятных, но плохо работающих или вообще не решающих проблему прототипов, которые потом нельзя внедрить.
Поэтому договаривайтесь. Например, так: «Ребята, у вас две недели покопать в эту сторону, я вам даю пул GPU и ресурс на разметку». А спустя отведённое время вместе решаете, стоит ли инвестировать в следующий отрезок работы или нет.
Нанимать людей умнее себя. Мы выбираем людей со складом ума, похожим на наш собственный. В итоге получается команда, в которой все со всеми согласны. Для R&D это очень страшно и опасно.
В команду исследователей нужно нанимать людей непохожих мнений, разных специальностей и уровней крутости в разных направлениях. У них есть альтернативные точки зрения, и они готовы проявлять интересные навыки в области, в которой вы ничего не понимаете.
Не мешать людям работать. Это не значит, что нужно приходить только раз в три недели и спрашивать, как идёт работа. Никакого чайка-менеджмента.
Не мешать работать — это научиться мотивировать и развивать команду, при этом не отнимать у них ощущение свободы в принятии решений.
Как мотивировать и развивать
Необходимость правильно мотивировать и развивать команду открывает перед нами ещё один раздел необходимых для руководителя действий.
Не мешать им работать. Можно лишить их возможности сделать круче, чем им предлагали. Тогда вы отнимете у них то, ради чего они пошли в эту область.
Людям важно чувствовать, что вы в первую очередь видите их как исследовательскую команду, а не как группу людей, которые будут выполнять ваши указания.
Правильно хвалить. Есть классическая проблема снобизма, когда исследователи говорят, что делают крутую вещь, rocket science, а внедрить в продакшен — это что-то простое, написать какой-то код, и оно заработает. Есть снобизм в обратную сторону, когда говорят, что исследователи не занимаются ничем полезным, потому что исследования не принесли результат.
В команде одни неизбежно будут более склонны к R, а другие — к D. Нужно хвалить и за исследование, и за прототипы, и за внедрение в продакшен. И особенно надо хвалить тех, кто делает end-to-end. R&D — длительный процесс, иногда ресёрч — это полгода-год, а внедрение — ещё столько же.
Заранее договориться, за что не хвалить. Со всеми командами нужно с самого начала договариваться о том, что с какого-то грейда вы никогда не хвалите,например, если они говорят, что очень много всего сделано, но ничего не работает
Должно выполняться правило: если у вас не готов полностью результат, вы в этот условно отчётный период просто не хвалите, начиная с сеньорного грейда. Потому что сеньоры должны отвечать за конечный результат, а не за набор промежуточных.
Но верно и обратное. У вас всегда есть люди, которые никак не могут повлиять на скорость внедрения. Условно, младшие грейды, которые имеют атомарные изолированные задачи. Их можно хвалить за это.
У команды должно быть чёткое понимание, за что будут хвалить, а за что — нет, потому что это заранее выставляет понятное ожидание и мотивацию.
Не кешировать неудачи. Во многих компаниях, научно-исследовательских группах в университетах даже не пытаются повторно реализовать какую-то идею, если предыдущая попытка была неудачной.
Но никто не знает, как именно пробовали. В ML, например, если не хочется делать задачу, вы можете очень легко её похоронить — в тридцати местах сделать не очень хорошо, и оно в сумме не сойдётся. Если кто-то закеширует негативный ответ на то, что задача не решается этим способом, то всё — вы останетесь с этими знаниями и не сможете попробовать снова.
Именно поэтому у вас должна быть договорённость, если люди хотят сделать что-то похожее на предыдущее решение. Вы чётко формулируете отличия от прошлой попытки и определяете бюджет на ошибку.
Не искать под фонарём. Есть история про то, что мужчина ищет ключи под фонарём. У него спрашивают, почему он ищет здесь. А тот отвечает, что потерял в темноте, но там не видно, поэтому он будет искать здесь.
Это тот формат, в котором часто пытаются решать исследовательскую задачу. Например, предлагают обучать модель на готовых данных. Возможно, получится. Как правило, не очень хорошо.
Иногда можно рассмотреть сборку лёгкого прототипа на том, что есть, как один из вариантов. Но в команде должно быть базовое правило — не тратить ресурсы на то, что кажется лёгким, если почти все согласны, что туда нет смысла копать.
Дать человеку самому поставить дедлайн. Страшно, когда вы приходите и говорите: «Твоя идея может быть классной или нет, я не знаю. Копай две недели». У человека появляется выученная беспомощность, и он не способен сам оценить, сколько ему надо времени.
Диалог про «бюджет на попробовать» должен быть в формате:
— Сколько тебе нужно?
— Не знаю.
— Хорошо, давай подумаем, сколько ты можешь на это потратить.
Когда у вас есть договорённость о том, сколько времени вы будете на это тратить, у человека есть желание уложиться в этот срок.
Если скомбинировать все части при работе с командой, то получится микромечта руководителя. У команды появится ощущение ответственности за то, что они делают. Они захотят ставить перед собой задачи и договариваться о том, сколько будут инвестировать. У них не будет ощущения, что за них кто-то что-то решил. При этом у руководителя появится понимание процесса «торга». Появятся договорённости о том, сколько времени на что будет потрачено.
Что делать с собой
Вроде бы всё замечательно, но команда развивается не сама по себе, в ней есть ещё один человек — вы. Возникает главный вопрос — что делать с собой.
Стать высокоуровневым переводчиком. Сейчас есть проблема недостатка взаимопонимания между представителями технической, бизнесовой, коммерческой и продуктовой сферы. Чем дальше, тем сильнее мы уходим в то, что глубокая экспертиза в одной области замечательна, но всё классное начинает происходить где-то сбоку от неё. На некой линии, которая разделяет дисциплины.
Тимлид или технический руководитель, особенно в R&D, должен стать человеком, который переводит знания, образы и базисы с технического языка на бизнес-лингво и обратно.
Потому что вы понимаете, какой уровень технологий есть сейчас, какие решения возможны, как сформировать из этого продукт. Вы можете отсекать идеи, которые делать долго и сложно и которые вряд ли сойдутся, и предлагать идеи, которые смогут прямо сейчас выстрелить.
Стать операционной системой. В книге Эндрю Таненбаума «Современные операционные системы» написано, что операционная система занимается двумя вещами: управляет ресурсами и даёт уровень абстракции между железом и программами. Технолид — операционная система по Таненбауму, потому что у него есть две аналогичные задачи.
Первая — осуществлять менеджмент своей команды как человеческих ресурсов и возможности выполнения каких-то задач.
Вторая задача — предоставлять абстракции наружу и внутрь. Когда вы делаете абстракцию наружу, вы представляете свою команду как рабочую единицу и говорите, какие задачи она сможет решить, а какие — нет.
Есть ещё абстракция внутрь. Вы для своей команды должны быть тем самым интерфейсом, который представляет всех смежников: руководство компании и отделы, которые взаимодействуют с ней. Эти люди, как правило, говорят на других языках, не упорядочены и хотят ставить вам задачи не в ваших терминах. И для команды очень важно иметь понятный взгляд на внешний мир.
Синдром самозванца
Синдром самозванца — странное ощущение некомфортности, будто вы не умеете руководить и теряете технические навыки, а новые не приобретаете. Всё время кажется, что вы недостаточно хороши для своей задачи и что результаты команды никак не связаны с вашей работой.
Появляются новые метрики. Синдром самозванца появляется не потому, что вы стали хуже или недостаточно хороши. У вас были старые задачи и классные хард-скилы. Внезапно появляется новая позиция и новые задачи — ещё одна мензурка. Она совсем не так наполнена, как хард-скиловая часть.
В первые месяцы работы техническим руководителем вы наполняете софт-скиловую часть. В итоге через три-пять месяцев у вас размазывается фокус по обоим направлениям. Вы перестали читать статьи, интересоваться тем, что делают в соседних командах, у вас уменьшается технический навык.
Нужно найти баланс между инвестициями в хард- и софт-скилы. Очень плохая история, если вы вдруг решаете, что теперь как руководителю вам не нужны технические навыки. Через полтора года вы потеряете понимание, о чём именно с вами говорит команда.
Надо принять, что у вас теперь новые метрики оценки. Вы больше не человек, который должен выдавать максимум хард-скилов. Нужно инвестировать в обе части и балансировать время и ресурсы на своё развитие так, чтобы наполнялись обе мензурки. Новая метрика — баланс между хард- и софт-скилами, а вовсе не каждый из них по отдельности.
Научитесь делать снапшоты, то есть снимки. Раньше вы целый день писали код, верстали, создавали дизайны, занимались ресёрчем. У вас был осязаемый результат в конце дня или недели.
Теперь вы проводите двенадцать встреч, принимаете два-три решения за день и большую часть времени разговариваете. У вас больше нет осязаемого результата. Вам кажется, что все происходящие процессы замедлились. Вы впадаете в постоянное ощущение, что ничего не происходит, и вы на это никак не влияете.
Поставьте себе регулярную встречу, например раз в месяц и просто выписывайте снапшот: что случилось на сегодняшний день и через месяц. В этом случае вы чётко понимаете, какой именно дифф есть между двумя состояниями системы.
Нельзя совсем не рефлексировать и не думать о том, правда ли вы делаете то, что надо, правда ли что-то меняется, полезны ли вы.
Нужны правильно расставленные снапшоты, потому что многие вещи большого уровня действительно очень хорошо видятся только издалека
Итоги
Если научиться так жить с самим собой, научиться мотивировать, развивать команду и правильно ей управлять, можно достичь желаемого. Прийти в состояние, когда вы не говорите, что им делать, но при этом все, включая вас, делают то, что надо.