Прежде чем перейти к статье, хочу вам представить, экономическую онлайн игру Brave Knights, в которой вы можете играть и зарабатывать. Регистируйтесь, играйте и зарабатывайте!
В недавнем выпуске подкаста DotNet & More мы обсуждали полезные материалы для тимлидов и всплыла классическая проблема: как совмещать управление командой и написание кода. Этой осенью я рассказывал о лайвхаках, которые помогают мне продолжать программировать на позиции лида и мне показалось полезным, в этом контексте, выложить текстовую расшифровку доклада.
Хочу сказать отдельное спасибо Алисе Мироненко за подготовку транскрипта. Видео версия доклада:
Небольшой дисклеймер: то, что я буду говорить, может для вас не работать. Ваша ситуация может быть совсем другой. Если честно, не люблю, когда идет менеджерский доклад и говорят: «Вот это точно вам подойдет». Но я надеюсь, будет полезно тем, чей кейс соответствует тому, о чём я буду говорить.
Мне часто встречаются люди с такой карьерной историей: в новую компанию приходит разработчик с десятилетним опытом работы. В 2010 году он пришел в компанию Х, быстро развился до синьора, он талантливый, крутой. Так как он талантливый, ему дали тимлида.
Потом ему надоело, он на этой позиции выгорел и снова хочет быть девелопером. Человек приходит к нам, мы у него спрашиваем: «Скажите, какой была ваша рабочая нагрузка на каждой из этих позиций?»
В среднем по больнице рабочая нагрузка распределяется так: пока ты джуниор, мидл, ты в основном пишешь код. Как только становишься синьором, количество менеджерских задач резко возрастает. А будучи тимлидом, ты вообще почти не программируешь.
Потом человек с таким опытом приходит к нам на позицию разработчика.
Получается интересная история: опыт в резюме – десять лет, а реальный опыт разработки – два-три года.
Когда мы говорим про ожидание-реальность работы тимлидом, у нас возникает диссонанс. Что мы ожидаем от тимлидской работы? Мы идем, мы модные, нас все слушают, выполняют работу. На деле я бы сказал, что тимлид сидит на горячей сковородке, в которой варится кипящее масло. Потому что множество задач, коммуникации, переключений, зачастую нет времени выдохнуть.
Нам кажется: сначала мы были джуном, мидлом, потом синьором, потом ведущим разработчиком. Еще небольшой шаг – и можно идти в менеджеры и управлять людьми.
Но расстояние между лидом и менеджером такое же, как между джуном и лидом.
У нас нет времени учиться на менеджеров – это главная проблема.
Чтобы стать полноценным менеджером, необходимо получить образование. Я имею в виду не корочку, а менеджерские знания, опыт, связи. Нужно сделать мощнейший скачок, чтобы прыгнуть в менеджеры.
Но есть и другие варианты роста. Есть возможность быть тимлидом, который развивается в первую очередь как инженер. Я специально говорю романтизированное «инженер». Не просто человек, который умеет крутить гайки/писать код, а который умеет решать сложные задачи, в том числе привлекая других людей.
У нас есть такой вариант – идти в тимлиды, сохраняя инженерную рабочую нагрузку.
Раз мы решили пойти в менеджмент, давайте получать соответствующие навыки, знания. А то есть менеджеры, которые не знают основ – как делегировать и прочее.
Если мы решили углубиться в разработку, у нас должна быть инженерная нагрузка, хотя бы 30%. Возникает вопрос: «А разве эти 30% нас спасут?» Да, об этом сегодня и поговорим – как добиться этих 30% эффективной работы, чтобы мы продолжали развиваться как настоящие инженеры.
Давайте начнем с того, когда тимлиду стоит заниматься разработкой. Я сделал небольшой чеклист.
Возможно, у вас есть время на разработку, если:
Вы занимаетесь микроменеджментом.
Пишете много документации «в стол».
Вы единая точка коммуникации на проекте.
Ваша команда только пишет код.
У вас много тет-а-тет митингов.
Вы инициатор большинства этих митингов.
В таком случае вам нужно подумать над тем, чтобы совмещать управление с разработкой. Потому что, скорее всего, у вас много времени тратится достаточно неэффективно.
В целом я считаю, что совмещение ролей управленца и инженера зависит от трех вещей:
1) Стадии развития вашей команды
Если посмотреть на стадии развития группы по Такмену, все команды проходят несколько этапов: сначала идет этап формирования команды, в процессе люди начинают конфликтовать и начинается так называемый этап шторминга, конфликтная стадия – наиболее критичный этап.
Потом, когда люди поняли, кто есть кто, они начинают притираться друг к другу и наступает длительный этап норминга, на котором производительность медленно растет, доходит до пика на этапе перформинга и потихоньку падает.
Если вы тимлид в команде, которая только формируется или проходит конфликтную стадию, помните, что эти этапы нужно проскочить как можно быстрее, и вместо разработки стоит потратить время на то, что вы будете отслеживать конфликтные ситуации заранее и, если что, мирить сотрудников, много коммуницировать.
Как только вы перейдете в режим норминга и перформинга, у вас освободится гораздо больше времени на программирование.
2) Уровня квалификации и мотивации ваших сотрудников
Если у нас команда высоко мотивирована, но не очень квалифицирована, как будто там много активных джунов, то ваше время гораздо эффективнее вкладывать в менторинг команды, чтобы они быстро доросли до того уровня задач, которые им нужно выполнять.
Обратная ситуация – у вас в команде толпа «выгоревших синьоров». Тогда время и энергию стоит вложить в поддержку ребят, чтобы они выскочили из ямы демотивации.
Если у вас команда немотивированных и неквалифицированных сотрудников, то, наверное, вы всё время будете заняты микроменеджментом и больше ничем.
Есть классическая табличка на эту тему:
Единственный возможный вариант освободить себе время на разработку – делегировать задачи достаточно мотивированной и квалифицированной команде.
3) Уровня коммуникации на проекте
Возможности тратить времени на разработку не будет, если есть проблемы в коммуникации на проекте.
Например, mushroom management (управление по принципу «меньше знаешь – крепче спишь), когда вы являетесь единой точкой коммуникации и никто больше не знает, что происходит.
Очевидно, что в таком случае у вас не будет времени на инженерную деятельность.
Как настроить коммуникацию?
Вариант: если я единая точка коммуникации, я возьму и самоустранюсь.
Главная проблема будет в том, что появится неформальный лидер. Понятие «неформальный лидер» неприятное, потому что часто неформальные и формальные лидеры – не одно лицо. Это становится проблемой для формального лидера.
В идеале нам нужно соблюдать баланс в коммуникации: вы управляете командой, но не всё не завязано на вас – команда тоже общается с заказчиком и может решать проблемы.
Как перестать быть единой точкой коммуникации?
Если «всех всё устраивает», один из самых приятных вариантов – натравить на команду SCRUM-мастера, чтобы контролировать и оптимизировать рабочий процесс. К сожалению, это не всегда срабатывает.
Тогда можно пойти по классическому пути: уходите в отпуск – оставляете своего заместителя. Никакой заказчик не будет против, чтобы временно пообщаться с вашим сотрудником (кроме редких исключений). Но это не помогает познакомить заказчика со всей командой. Поэтому я бы хотел рассмотреть более общий способ того, как «подружить» заказчика с командой:
• Познакомьте заказчика с командой через task manager.
• Организуйте встречу с командой в привычном для заказчика месте и времени. Не приводите сразу всех.
• Ведите первые митинги как обычно, тет-а-тет с заказчиком, но с командой «на фоне».
• Передавайте часть инициативы коллегам, например: «Вот Евгений знает эту систему лучше всех, пусть расскажет».
• Поднимайте на встречах вопросы, которые можно адресовать команде. Пусть на них отвечают, не ожидая вас.
• Позвольте вашим коллегам вести митинги и переписки напрямую с заказчиком, но в первое время будьте рядом.
• Всегда будьте в копии и на связи с заказчиком.
Это было про коммуникацию, теперь про то, как делегировать.
Делегирование – процесс передачи функции руководителя. Но наши функции не всегда очевидны другим. Например, наша обязанность – деплой на продакшен в рамках фичи деплоя. Для нас может быть очевидно, что нужно прогнать тесты, кто ж не знает? Никто не знает, эта информация в вашей голове. Необходимо донести её до человека, который будет выполнять задачу.
Делегирование – это отдельная тема, сейчас я остановлюсь только на нескольких моментах.
Не забывать, что ваши функции не очевидны другим.
Давать задачи тем сотрудникам, которые способны с ними справиться. Если есть задача вести коммуникацию с кучей разных людей из разных стран, вряд ли стоит давать ее скромному интроверту с уровнем английского А1.
Делегирование должно развивать сотрудников. Помните, что чем больше вы делегируете человеку, тем лучше он справляется со своими полномочиями. Поэтому, если первый раз произошло полное фиаско и человек не справился с функциями, которые вы делегировали, лучше дать ему возможность еще раз попробовать эту задачу, возможно, он чему-то научился. Как это понять? Важная часть делегирования – контроль. Еженедельный контроль, ежедневные митинги и прочее.
Не забывайте, что делегирование – это не безучастность. Вы должны быть в курсе событий, слушать митинги.
Мы поняли, когда можно браться за разработку: команда не находится на этапе шторминга, мы умеем делегировать.
Давайте теперь подумаем, как бороться с отвлечением и управлять вниманием.
В чем проблема борьбы с отвлечением для тимлидов? В том, что классические подходы к тайм-менеджменту – focus time, помидорка, скалирование времени и другие – не работают, если сотрудники не уважают ваше время.
Но что делать с вопросами коллег? Важно отвечать на них хотя бы в течение получаса.
Я предпочитаю способ переноса времени: если вам написали, а вы программируете, то вы отвечаете через пятнадцать минут. Крайне важно не забывать ответить.
Для тимлидов отметим важный момент: пишем «через 15 минут» правильно.
Так вы сохраните хорошие взаимоотношения с коллегой, сможете уменьшить негатив. Впоследствии у человека не будет проблем, чтобы задавать вопросы – он не будет вас бояться.
Рассмотрим еще одну проблему – возврат в контекст.
Вы программируете, у вас в голове: «Задача-метод-класс». Вас отвлекли, контекст пропал. Вы ответили сотруднику, нужно вернуться в контекст.
Одно из самых эффективных решений – микродекомпозиция. Это когда вы берете листочек/one note, где можно сделать древовидную структуру и декомпозировать свою задачу вплоть до псевдокода или формулировки «сделай вот это».
Мультитаскинг – большая проблема тимлида, и здесь могут помочь виртуальные рабочие столы.
На виртуальном рабочем столе программирования у вас может быть открыт IDE, браузер, требования.
На виртуальном столе, где у вас релиз в продакшен, Jenkins/TeamCity, Splunk/Kibana, чат с DevOps. То же самое с обсуждением требований: Skype/Teams, Jira, Confluence.
Легче перескакивать между виртуальными рабочими столами, чтобы менять контекст.
Пора программировать.
Мы настроили время, коммуникацию, справились с отвлекающими факторами, налили чаёк… И мы парализованы.
У нас антипаттерн – аналитики-паралитики.
Представим ситуацию: мы архитекторы нефтекомплекса. Мы в голове держим весь этот нефтекомплекс: как он работает, почему он все еще не взорвался. Допустим, все рабочие ушли в отпуск и надо починить трубу. Мы единственные, кто может это сделать.
Как вы думаете, о чём будет думать архитектор нефтекомплекса, когда ему надо чинить трубу? «Пройдет ли этот биметалл эконормы? А как на давление повлияет в сжигателе?» В данном случае архитектор просто не сможет починить эту трубу, потому что не справится с такой когнитивной нагрузкой.
У нас то же самое. Разработка ПО – это комплексная задача. Бизнес-контекст, архитектура, код и прочее. От нас как от тимлидов требуют думать глобально.
Чтобы решить задачу, я использую подход вокализации действия. У меня над рабочим столом висят карточки, где написаны разные роли – архитектор, аналитик, программист. И я себе говорю, например: «Сейчас я аналитик, мой фокус внимания – не код, а бизнес-контекст» или «Сейчас я программист, я не думаю, как перекрутить требования». Упрощаем себе жизнь, переключаем фокусы внимания.
Напоследок хотелось бы поговорить про выбор «программерской роли», когда вы тимлид.
Давайте рассмотрим основные роли:
Ключевой разработчик, который делает основную бизнес-логику, разрабатывает ядро продукта.
Если ваша большая команда, времени на это может не быть. Стоит вовремя отдать эту роль, когда команда растет, иначе вы можете превратиться в прототипщика (человек, который пилит протопипы, а доведение проекта до ума оставляет на откуп команде).
«Затыкатель дыр» – человек, который приходит, когда нам чего-то не хватает для полного счастья.
Это человек с широким кругозором, который может компенсировать слабые стороны команды. В современном мире тимлид работает на компенсацию слабых сторон команды, а не наоборот. Такая роль идеальна в небольшой команде. Важно не только «затыкать дыры», но и заполнять пробелы новыми сотрудниками.
«Еще одни руки» – еще один программист, который просто еще что-то делает – фиксит баги, например.
Этот подход работает, потому что тимлид с такой ролью хорошо знает систему. Тут важно не стать кодерским балластом.
И мое любимое – кодерский балласт. Человек, которого лучше бы не было.
Кодерский балласт – менеджер, который когда-то был разработчиком, но навык программирования уже утерян. Использует устаревшие подходы, но он начальник, поэтому неостановим. Важно признать свою низкую квалификацию и не быть кодерским балластом.
Резюмируя: как быть тимлидом и продолжать программировать.
Когда?
• Когда команда на стадии норминга или перформинга.
• Когда люди квалифицированы и мотивированы.Когда настроена коммуникация.
Как?
• Прямая коммуникация.
• Делегирование.
Рекомендации
• Управлять отвлекающими факторами.
• Микродекомпозировать задачи.
• Облегчить переключение фокуса внимания.
• Трезво выбирать роль.
В заключении хочу сказать: коллеги, когда вы становитесь тимлидами, пусть мир приобретает либо активно обучающихся менеджеров, либо опытных инженеров.
