Заинтересованность инженеров: ресурс или блажь?
«Мэлоун, принимавший участие в облаве, воспользовался случаем и с особым тщанием исследовал каждую деталь интерьера».
«Мэлоун обрадовался возможности пойти по старому следу и с готовностью принял участие в облаве».
«Ему, совмещающему в себе пылкое воображение со строгим научным подходом, как никому другому было ясно…». Что именно ему было ясно? Это уже детали рассказа «Кошмар в Ред Хуке».
Детектив Томас Мэлоун — один из героев произведений Говарда Лавкрафта, наряду с другими: Рэндольфом Картером, профессором Уорреном Райсом или Генри Армитажем. Всех их объединяет несколько черт. Во-первых, в мирах Лавкрафта они умудрились выжить и почти не сойти с ума. А во-вторых, они все время двигались вперед, решая сложные задачи и принимая непростые решения.
Может показаться, что у Лавкрафта все рассказы про обреченность и безысходность. На самом деле встречаются и другие сюжеты: в них героям удается победить, спастись от Древних и уберечь себя от полусумасшедшего образа жизни обитателей Инсмута.
Эти герои достигали своих целей благодаря разной мотивации: у кого-то это было честолюбие, кто-то выполнял свой долг, другие вставали на защиту своего дома или даже мира. Важно то, что у всех них было очень сильное желание решать проблемы, перебирать варианты, обучаться. Хотя бы ради того, чтобы выжить.
Чем отличается хороший инженер от детектива Мэлоуна? Наверное, тем, что он не живет в мире ужасов Лавкрафта. Хотя наш мир может похвастаться другими кошмарами.
Что-то неизвестное и бросающее вызов
(Чума) пандемия на пороге: теперь все по-другому
У инженеров, FE, Desktop, BE, Mobile, QA и абсолютно всех остальных тоже есть свои краткосрочные и долгосрочные цели, которые поддерживают их интерес к текущему проекту. Везет, если все идет своим чередом: проект классный, стек актуальный, задачи находятся на том уровне компетенции, когда не просто, не сложно и интересно. Это идеальный мир. Наш таким никогда не был.
2020-ый — год пандемии. Вот тогда мы поняли, что теперь все будет по-другому. В начале весны мы отправились на удаленку и вживую встречались буквально три или пять раз за весь год, причем разными составами.
Рассуждения о плюсах и минусах удаленки выходят за рамки этого размышления. Есть много аргументов за и против, но я точно знаю, что не всем это дается легко. Кто-то адаптируется, кто-то начинает смотреть на рынок и изучать, что происходит вокруг, кто-то немного грустит, но продолжает работать. Если этот период совпадает с не самым ярким эпизодом разработки проекта, то разработчики начинают на 1–1 говорить менеджеру о том, что «задачки однообразные», «добавлять кнопочки и колонки это не рокет сайнс», «у нас там вообще перспективы на что-то интересное?».
Настроение команды такие отзывы передают хорошо, но этого недостаточно, чтобы убедить вышестоящих менеджеров в том, что проблема существует и ее нужно решать. Есть простой инструмент, который поможет превратить отзывы в данные, а с конкретными данными уже можно пойти выше.
Четыре квадранта, где по оси Х мы измеряем интерес, а по оси Y — компетенцию. На встречах с инженером можно попытаться раскидать задачи по этим квадрантами. Этот инструмент еще полезен тем, что может подсказать направления для роста инженера: если ему что-то очень интересно, но не хватает компетенции, то это отличный повод обсудить карьерный план.
Компетентность vs Интерес
Мы столкнулись с ситуацией, в которой все задачи инженеров одной команды оказались в области «компетентен и не интересно». В краткосрочной перспективе это ничего, ведь даже в самых интересных проектах всегда есть доля рутины, и невозможно каждый день выжимать только то, что нравится и хочется. Но если такая картина наблюдается около полугода, то нужно уже обратить на это внимание.
Почему?
Почему стоит задуматься о заинтересованности инженеров
Среднее время пребывания инженера в компании — около 2.5 лет. Этого времени обычно хватает, чтобы понять, что можно и что нельзя делать в компании на уровне принятия технических, продуктовых и других решений. И если статус-кво, который нельзя пошатнуть, не устроит инженера, то он пойдет искать другое место. В новом месте, скорее всего, все начнется сначала, но это уже не будет нас касаться.
Чтобы нанять нового инженера, необходимо потратить невероятное количество сил, времени и денег. Если замену не нашли заранее, то до выхода нового сотрудника производительность команды перестанет расти или начнет падать.
Поиск нового сотрудника — отдельный сложный процесс. На этом этапе включаются в работу разные структуры HR: сорсеры, рекрутеры, travel-координаторы. Сколько стоит их работа сказать не могу, но она однозначно не бесплатная.
На собеседованиях будет участвовать кто-то из команды, а значит его/её время работы над проектом уменьшается. А потом начинается процесс онбординга и адаптации в команде — это тоже время и силы ее членов.
Сколько месяцев пройдет с момента ухода инженера до момента, когда новый заменит его на все 100%? Два месяца? Три? Или может целых 6? А это все время пониженной эффективности команды. Поэтому, если вы или ваш менеджер говорит: «Да плевать, вместо Васи найдем Жору», то стоит подумать об этих цифрах.
Есть исследование, в котором были подсчитаны средние расходы на поиск нового разработчика в американских компаниях. Без деталей: у них получилось что-то около 30000$ до момента подписания офера. И это еще без учета снижения эффективности команды.
Это нужно компании, это нужно команде, это нужно менеджеру. Или нет?
Прежде чем бросаться в пасть шоггота с криками «За интересные задачи всем инженерам!» и кольтом на перевес нужно четко убедиться в том, что это нужно вашей компании, это нужно вашей команде, это нужно вам.
Аааааааа…
Это нужно компании? Если решаемые задачи действительно не потеряют в качестве после ухода Васи, навыков Жоры хватит еще на полгода, а текучка в компании — дело обыкновенное, то изменить положение дел вряд ли получится. Бизнес не заинтересован в этом. Если продукт сложный и требует большой экспертизы, которую дорого терять, тогда уже есть смысл обсудить эту проблему.
Это нужно команде? Страдает ли команда от этой проблемы? Есть ли у нее запрос на новые задачи и неизвестные области? Если нет, то нам предстоит решать другие вопросы, которые тоже выходят за рамки этой статьи. Если да, то переходим к последнему вопросу.
Это нужно вам? Если вы впишетесь в изменение статуса-кво, то откатиться назад уже будет непросто.
Чтобы что-то получилось, ответы нужны «да-да-да!».
Разговариваем к командой
Теперь пойдем в обратном направлении. Если с собственной заинтересованностью вы разобрались и убедились в правильности выбранного решения, то нужно обратиться к команде. Хорошему менеджеру стоит знать свою команду, иначе можно лечить там, где не болит, или пройти мимо неочевидной, но глубокой проблемы.
Для начала нужно узнать, как именно хотят развиваться инженеры и хотят ли вообще. Mожет, кто-то чувствует себя комфортно с текущими задачами и отлично с ними справляется. Если это и правда так, то не стоит лечить здорового.
В команде могут оказаться и другие инженеры. Кто-то наверняка скучает по зубодробильным алгоритмическим задачам, а кто-то пытается оптимизировать уже существующие фичи. Кто-то ненавидит рутину и готов автоматизировать часть задач. Кто-то хочет делиться знаниями, участвовать в хакатонах и писать статьи. Не зная своих коллег по команде, невозможно предложить им то, что будет интересно.
Знай свою команду
Да, на этом этапе подготовки ничего предлагать не нужно, достаточно просто знать, что МОЖНО предложить.
Разговариваем с «бизнесом»
Даже если менеджеры понимают ценность инженера с его экспертизой и реально оценивают затраты на замену, вряд ли они согласятся тратить половину рабочего (а значит оплачиваемого) времени на портирование Doom на пейджер из начала нулевых.
На этом этапе начинается самая интересная часть — переговоры, а менеджер команды в них — парламентер. В компании наверняка есть стейкхолдеры: VP, CTO, главы инженерных департаментов. Вот с кем-то из них придется обсуждать видение жизни инженера в компании. По моему опыту такие переговоры могут занять не одну неделю, потому что собрать нужных людей в одно время и в одном месте (зуме) бывает очень непросто.
На встречах, скорее всего, будут обсуждения: зачем вообще пытаться удержать людей в компании, как это они не будут работать над фичами, что делать с пробуждением Ньярлатхотепа и что значит будут, но меньше?
Какие аргументы можно использовать для защиты своей позиции:
Уход инженера из команды скажется на выполнении текущих задач. Если такой риск действительно существует, то это первый и самый весомый аргумент.
Уход инженера из команды скажется на всей команде. Есть риски, что остальные инженеры тоже потеряют в продуктивности и начнут искать другое место работы.
Поиск нового человека — это расходы на найм и все, что связано с ним.
Выход новичка потребует времени команды на онбординг и выстраивание новых связей. А это тоже расходы, пусть и не такие очевидные.
С этими четырьмя позициями уже можно начинать разговор.
Если же все аргументы не услышаны или опровергнуты, то дальнейшее решение остается за вами. На первый вопрос — «Нужно ли это компании?» — вы получили ответ «нет». Предложить что-то стоящее в этом случае я не могу. В этой ситуации может быть множество нюансов: от готовности работать в компании несмотря ни на что до попыток изменить что-то в обход вышестоящего руководства.
Если переговоры продуктивны, то можно ожидать, что через несколько встреч и недель может получится документ, который выражает намерение, но еще не является чем-то принятым.
Мы в итоге пришли к пяти последовательным шагам, которые можно применять по порядку: если первый пункт не сработал, то переходим ко второму и так далее.
Пять шагов на пути к повышению заинтересованности
Шаг 1: выбирать и создавать амбициозные задачи из скоупа команды. Если, например, нужно сделать одностраничный визард для создания отчетов и разработка со стороны FE не требует гениальности, то можно обсудить с продактом будущее этой функциональности. Если есть шанс, что она будет развиваться в будущем, можно попробовать заложить хорошую архитектуру с возможностью быстрого расширения и изменения. Это займет больше времени, но позволит инженеру отработать другой подход к разработке.
Шаг 2: развивать T-shape инженеров: FE-BE, BE-QAA, BE-FE. Вполне возможно, что кто-то из инженеров FE хотел бы писать BE или попробовать себя в автотестах. Это тоже можно наладить: простые задачи и ревью со стороны опытных коллег могут разбавить рутину. К тому же такой подход может помочь в том случае, если загрузка инженеров из других специализаций не позволяет им взять в работу какую-то из задач. Тогда наш T-shape инженер сможет взять весь цикл разработки на себя. Разумеется, нужно соблюдать баланс между сложностью и критичностью задачи.
Например, у нас был случай, когда было необходимо предоставить прототип новой функциональности. Для прототипа требовалась разработка фронтенда и бекенда, но ресурсов бекенд инженеров не было. В итоге фронтенд разработчик сделал обе части задачи, а бекендную половину ревьюили более опытные инженеры.
Шаг 3: выделять время на персонально значимые для инженера задачи. Под эту категорию попадает большое количество задач, которые так или иначе выбиваются из текущей продуктовой разработки. Может быть, это рефакторинг какой-то фичи, которая просто как заноза беспокоит инженера. Почему бы не дать ему время, чтобы справиться с этим? Или это может быть какое-нибудь приложение для проведения митапов в компании или статья на какой-нибудь ресурс.
Например, однажды мы столкнулись со странным поведением библиотеки для тестирования, которая должна была симулировать асинхронные запросы. В итоге родилась идея написать пару статей про асинхронность в Dart Angular.
Шаг 4: организовывать кратковременную внутреннюю ротацию — «внутренние командировки». Если ничего из предыдущих вариантов не подходит, то можно договориться с другой командой о «командировке», во время которой инженер поработает на другим скоупом, пообщается с другими людьми и посмотрит на другие процессы.
Шаг 5: давать инженерам возможность работать над задачами из публичного скоупа других команд. Чем это шаг отличается от предыдущего? В этом случае инженер все еще находится в своей команде, но делает задачи других команд. Это один из самых сложных вариантов, потому что нужно найти публичный бэклог, договориться с другой командой, выяснить, какой у задачи Definition of Done, кто отвечает за тестирование.
Принятие решения по пунктам 2–5 принимаются в индивидуальном порядке с каждым членом команды на 1–1. Если в команде, например, шесть инженеров, то это вполне реально: встретиться на час и обсудить, по какому пути человек хочет идти и как мы можем постараться совместить его личные цели, цели команды и компании.
Если сотрудник выбрал что-то из пунктов 2–5, то стоит согласовать время и цель со стейкхолдерами и продактами. Это нужно для того, чтобы все участники процесса понимали, чем инженер занимается сейчас и почему не фиксит вон ту мелкую багу.
Например, можно договориться о пяти рабочих днях в квартал для работы над такими задачами. В нашем мире это половина спринта. Важно, чтобы такие задачи попадали в спринт вместе с продуктовыми и техническими, и инженер на дейли рассказывал о прогрессе.
Задача должна быть достижима: если цель — переписать часть продукта на новый стек технологий, то, наверное, стоит выбрать другую задачу в этот личный лимит. Такой большой трек имеет смысл продавать уже на глобальном уровне и закладывать на него больше времени.
Ну и, конечно, через некоторое время вас спросят: «Ну что, как там твой план по поддержанию заинтересованности? Есть какой-то эффект?». Стоит сразу договориться, как вы будете отслеживать влияние этого изменения. Древним богам (стейкхолдерам) важно знать, что все не напрасно.
Самый простой способ — опрос команды о том, насколько им интересно работать в компании/команде/проекте. Можно отметить вещи, которые были созданы в рамках этих изменений: статьи, улучшения производительности, рефакторинг, сторонние, но важные для компании продукты. Ну и, конечно, слухи. Они не такие осязаемые, как цифры и фичи, но если о вашей команде говорят в компании, из нее не уходят инженеры, а другие команды хотят быть похожими на вашу — это тоже признание.
Немного про SPACE
Интересно, что в период пандемии компании стали активнее искать возможности понять и оценить производительность инженеров. В 2021-ом году очень много ссылок ведут на новый-кленовый фреймворк по таким оценкам. Он называется SPACE и, как многие крутые абревиатуры типа SMART, KISS, DRY, пришел прямиком из самой аббревиатурной страны — USA (я ничего не имею против, просто это показалось мне забавным).
Расшифровывается SPACE как satisfaction, performance, activity, communication, efficiency. Его применимость и эффективность отдельная тема, но мне хочется отметить, что первым пунктом идет как раз удовлетворение. В SPACE оно описано очень широко: туда входит и то, чем занимается инженер, и рабочее место, инструменты и все-все-все.
Та часть, которая интересна мне — заинтересованность человека в работе — как раз попадает в букву S. А учитывая, что так или иначе об этой теме писали на многих ресурсах и даже говорили в больших компаниях, таких как Microsoft, мне хочется верить, что каждому инженеру достанется задачка по вкусу.
Все это касалось продуктовых компаний, где проект может длится годами. Но как обстоят дела в непродуктовой разработке? У меня не очень большой опыт работы в таких компаниях, но чаще всего там естественным образом настроена ротация инженеров среди доменных областей и технологий. Завершился один проект для страховых компаний на Angular, следующим идет медицинский стартап на Vue. Это все условно, но в общих чертах вполне возможно. А если у компании есть роскошь держать инженеров в межпроектье в ожидании новых целей, то есть отличный шанс пройти какой-то курс и познакомиться с новыми технологиями или процессами.
Выводы или TL; DR
В пучине безумия
Заинтересованность инженеров может быть ресурсом для вашей компании, а может им и не быть — это зависит от многих факторов.
Если заинтересованность — ресурc, то без его восполнения инженеры могут угаснуть, как герои миров Лавкрафта, которым не повезло.
Но если это для них не критично, то не стоит лечить то, что не болит.
Чтобы поддерживать ресурс, не впадайте в безумие сами. Ведите переговоры с бизнесом, аргументируйте, показывайте цифры. Разработайте план, который будет подходить именно вашей команде. Пускай в нем будет несколько уровней: если не подходит первый, переходите ко второму.
Чтобы продемонстрировать стейкхолдерам, что все это стоит того, запустите опрос о том, насколько интересно работать в команде/компании/проекте до и после введения плана (каждый месяц), покажите, какие крутые штуки сделала команда за это время.
Ну и оставьте место для возможной ошибки: быть может, болит действительно не тут, а гипотеза оказалась не верна.
Надеюсь, нам когда-нибудь удастся достичь солнцеликих и блестящих покоев неведомого Кадата.
Неведомый Кадат
Кое-что из описанного здесь мне помогла сформулировать книга менеджера со стажем Уилла Ларсона «An elegant puzzle» — интересная книга для тех, кто стал менеджером в разработке и планирует развиваться в этой роли.
