Как быть тимлидом и продолжать программировать

Продолжаем делиться полезными материалами с нетехнической конференции для IT-специалистов ESCAPE.

 

Ведущий разработчик EPAM Александр Кугушев рассказал о своём опыте, как находить время на программирование, когда управляешь командой разработки. К слову, успевать на 100% и то, и другое стоит не всегда – но об этом тоже поговорим.

 

Запись выступления есть на YouTube, а ниже – расшифровка доклада.

 


 

Сразу хочу сделать небольшой дисклеймер: то, что я буду говорить, может для вас не работать. Ваша ситуация может быть совсем другой. Если честно, не люблю, когда идет менеджерский доклад и говорят: «Вот это точно вам подойдет». Но я надеюсь, будет полезно тем, чей кейс соответствует тому, о чём я буду говорить.

 

Мне часто встречаются люди с такой карьерной историей: в новую компанию приходит разработчик с десятилетним опытом работы. В 2010 году он пришел в компанию Х, быстро развился до синьора, он талантливый, крутой. Так как он талантливый, ему дали тимлида.

 

Потом ему надоело, он на этой позиции выгорел и снова хочет быть девелопером. Человек приходит к нам, мы у него спрашиваем: «Скажите, какой была ваша рабочая нагрузка на каждой из этих позиций?»

 

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

 

Потом человек с таким опытом приходит к нам на позицию разработчика.

 

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

 

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

 

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

 

 

Но расстояние между лидом и менеджером такое же, как между джуном и лидом.

 

У нас нет времени учиться на менеджеров – это главная проблема.

 

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

 

 

Но есть и другие варианты роста. Есть возможность быть тимлидом, который развивается в первую очередь как инженер. Я специально говорю романтизированное «инженер». Не просто человек, который умеет крутить гайки/писать код, а который умеет решать сложные задачи, в том числе привлекая других людей.

 

У нас есть такой вариант – идти в тимлиды, сохраняя инженерную рабочую нагрузку.

 

Раз мы решили пойти в менеджмент, давайте получать соответствующие навыки, знания. А то есть менеджеры, которые не знают основ – как делегировать и прочее.

 

Если мы решили углубиться в разработку, у нас должна быть инженерная нагрузка, хотя бы 30%. Возникает вопрос: «А разве эти 30% нас спасут?» Да, об этом сегодня и поговорим – как добиться этих 30% эффективной работы, чтобы мы продолжали развиваться как настоящие инженеры.

 


 

Давайте начнем с того, когда тимлиду стоит заниматься разработкой. Я сделал небольшой чеклист.

 

Возможно, у вас есть время на разработку, если:

  1. Вы занимаетесь микроменеджментом.
  2. Пишете много документации «в стол».
  3. Вы единая точка коммуникации на проекте.
  4. Ваша команда только пишет код.
  5. У вас много тет-а-тет митингов.
  6. Вы инициатор большинства этих митингов.

 

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

 

В целом я считаю, что совмещение ролей управленца и инженера зависит от трех вещей:

 

1) Стадии развития вашей команды  

 

Если посмотреть на стадии развития группы по Такмену, все команды проходят несколько этапов: сначала идет этап формирования команды, в процессе люди начинают конфликтовать и начинается так называемый этап шторминга, конфликтная стадия – наиболее критичный этап.

 

Потом, когда люди поняли, кто есть кто, они начинают притираться друг к другу и наступает длительный этап норминга, на котором производительность медленно растет, доходит до пика на этапе перформинга и потихоньку падает.

 

Если вы тимлид в команде, которая только формируется или проходит конфликтную стадию, помните, что эти этапы нужно проскочить как можно быстрее, и вместо разработки стоит потратить время на то, что вы будете отслеживать конфликтные ситуации заранее и, если что, мирить сотрудников, много коммуницировать.

 

 

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

 

2) Уровня квалификации и мотивации ваших сотрудников  

 

Если у нас команда высоко мотивирована, но не очень квалифицирована, как будто там много активных джунов, то ваше время гораздо эффективнее вкладывать в менторинг команды, чтобы они быстро доросли до того уровня задач, которые им нужно выполнять.

 

Обратная ситуация – у вас в команде толпа «выгоревших синьоров». Тогда время и энергию стоит вложить в поддержку  ребят, чтобы они выскочили из ямы демотивации.

 

Если у вас команда немотивированных и неквалифицированных сотрудников, то, наверное, вы всё время будете заняты микроменеджментом и больше ничем.

 

Есть классическая табличка на эту тему:

 

 

Единственный возможный вариант освободить себе время на разработку – делегировать задачи достаточно мотивированной и квалифицированной команде.

 

3) Уровня коммуникации на проекте 

 

Возможности тратить времени на разработку не будет, если есть проблемы в коммуникации на проекте.

 

Например, mushroom management (управление по принципу «меньше знаешь – крепче спишь), когда вы являетесь единой точкой коммуникации и никто больше не знает, что происходит.

 

Очевидно, что в таком случае у вас не будет времени на инженерную деятельность.

 

Как настроить коммуникацию?

 

Вариант: если я единая точка коммуникации, я возьму и самоустранюсь.

 

 

Главная проблема будет в том, что появится неформальный лидер. Понятие «неформальный лидер» неприятное, потому что часто неформальные и формальные лидеры – не одно лицо. Это становится проблемой для формального лидера.

 

В идеале нам нужно соблюдать баланс в коммуникации: вы управляете командой, но не всё не завязано на вас – команда тоже общается с заказчиком и может решать проблемы.

 

Как перестать быть единой точкой коммуникации? 

 

Если «всех всё устраивает», один из самых приятных вариантов – натравить на команду SCRUM-мастера, чтобы контролировать и оптимизировать рабочий процесс. К сожалению, это не всегда срабатывает.

 

Тогда можно пойти по классическому пути: уходите в отпуск – оставляете своего заместителя. Никакой заказчик не будет против, чтобы временно пообщаться с вашим сотрудником (кроме редких исключений). Но это не помогает познакомить заказчика со всей командой. Поэтому я бы хотел рассмотреть более общий способ того, как «подружить» заказчика с командой:

 

• Познакомьте заказчика с командой через task manager.

 

• Организуйте встречу с командой в привычном для заказчика месте и времени. Не приводите сразу всех.

 

• Ведите первые митинги как обычно, тет-а-тет с заказчиком, но с командой «на фоне».

 

• Передавайте часть инициативы коллегам, например: «Вот Евгений знает эту систему лучше всех, пусть расскажет».

 

• Поднимайте на встречах вопросы, которые можно адресовать команде. Пусть на них отвечают, не ожидая вас.

 

• Позвольте вашим коллегам вести митинги и переписки напрямую с заказчиком, но в первое время будьте рядом.

 

• Всегда будьте в копии и на связи с заказчиком.

 


 

Это было про коммуникацию, теперь про то, как делегировать.

 

Делегирование – процесс передачи функции руководителя. Но наши функции не всегда очевидны другим. Например, наша обязанность – деплой на продакшен в рамках фичи деплоя. Для нас может быть очевидно, что нужно прогнать тесты, кто ж не знает? Никто не знает, эта информация в вашей голове. Необходимо донести её до человека, который будет выполнять задачу.

 

Делегирование – это отдельная тема, сейчас я остановлюсь только на нескольких моментах.

 

Не забывать, что ваши функции не очевидны другим.

 

Давать задачи тем сотрудникам, которые способны с ними справиться. Если есть задача вести коммуникацию с кучей разных людей из разных стран, вряд ли стоит давать ее скромному интроверту с уровнем английского А1.

 

Делегирование должно развивать сотрудников. Помните, что чем больше вы делегируете человеку, тем лучше он справляется со своими полномочиями. Поэтому, если первый раз произошло полное фиаско и человек не справился с функциями, которые вы делегировали, лучше дать ему возможность еще раз попробовать эту задачу, возможно, он чему-то научился. Как это понять? Важная часть делегирования – контроль. Еженедельный контроль, ежедневные митинги и прочее.

 

Не забывайте, что делегирование – это не безучастность. Вы должны быть в курсе событий, слушать митинги.

 


 

Мы поняли, когда можно браться за разработку: команда не находится на этапе шторминга, мы умеем делегировать.

 

Давайте теперь подумаем, как бороться с отвлечением и управлять вниманием.

 

В чем проблема борьбы с отвлечением для тимлидов? В том, что классические подходы к тайм-менеджменту – focus time, помидорка, скалирование времени и другие – не работают, если сотрудники не уважают ваше время.

 

Но что делать с вопросами коллег? Важно отвечать на них хотя бы в течение получаса.

 

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

 

Для тимлидов отметим важный момент: пишем «через 15 минут» правильно.

 

Так вы сохраните хорошие взаимоотношения с коллегой, сможете уменьшить негатив. Впоследствии у человека не будет проблем, чтобы задавать вопросы – он не будет вас бояться.

 

Рассмотрим еще одну проблему – возврат в контекст.

 

Вы программируете, у вас в голове: «Задача-метод-класс». Вас отвлекли, контекст пропал. Вы ответили сотруднику, нужно вернуться в контекст.

 

Одно из самых эффективных решений – микродекомпозиция. Это когда вы берете листочек/one note, где можно сделать древовидную структуру и декомпозировать свою задачу вплоть до псевдокода или формулировки «сделай вот это».

 

 

Мультитаскинг – большая проблема тимлида, и здесь могут помочь виртуальные рабочие столы.

 

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

 

На виртуальном столе, где у вас релиз в продакшен, Jenkins/TeamCity, Splunk/Kibana, чат с DevOps. То же самое с обсуждением требований: Skype/Teams, Jira, Confluence.

 

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

 


 

Пора программировать.

 

Мы настроили время, коммуникацию, справились с отвлекающими факторами, налили чаёк… И мы парализованы.

 

У нас антипаттерн – аналитики-паралитики.

 

Представим ситуацию: мы архитекторы нефтекомплекса. Мы в голове держим весь этот нефтекомплекс: как он работает, почему он все еще не взорвался. Допустим, все рабочие ушли в отпуск и надо починить трубу. Мы единственные, кто может это сделать.

 

Как вы думаете, о чём будет думать архитектор нефтекомплекса, когда ему надо чинить трубу? «Пройдет ли этот биметалл эконормы? А как на давление повлияет в сжигателе?» В данном случае архитектор просто не сможет починить эту трубу, потому что не справится с такой когнитивной нагрузкой.

 

У нас то же самое. Разработка ПО – это комплексная задача. Бизнес-контекст, архитектура, код и прочее. От нас как от тимлидов требуют думать глобально.

 

Чтобы решить задачу, я использую подход вокализации действия. У меня над рабочим столом висят карточки, где написаны разные роли – архитектор, аналитик, программист. И я себе говорю, например: «Сейчас я аналитик, мой фокус внимания – не код, а бизнес-контекст» или «Сейчас я программист, я не думаю, как перекрутить требования». Упрощаем себе жизнь, переключаем фокусы внимания.

 


 

Напоследок хотелось бы поговорить про выбор «программерской роли», когда вы тимлид.

 

Давайте рассмотрим основные роли:

 

Ключевой разработчик, который делает основную бизнес-логику, разрабатывает ядро продукта.

 

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

 

«Затыкатель дыр» – человек, который приходит, когда нам чего-то не хватает для полного счастья.

 

Это человек с широким кругозором, который может компенсировать слабые стороны команды. В современном мире тимлид работает на компенсацию слабых сторон команды, а не наоборот. Такая роль идеальна в небольшой команде. Важно не только «затыкать дыры», но и заполнять пробелы новыми сотрудниками.

 

«Еще одни руки» – еще один программист, который просто еще что-то делает – фиксит баги, например.

 

Этот подход работает, потому что тимлид с такой ролью хорошо знает систему. Тут важно не стать кодерским балластом.

 

И мое любимое – кодерский балласт. Человек, которого лучше бы не было.

 

Кодерский балласт – менеджер, который когда-то был разработчиком, но навык программирования уже утерян. Использует устаревшие подходы, но он начальник, поэтому неостановим. Важно признать свою низкую квалификацию и не быть кодерским балластом.

 

Резюмируя: как быть тимлидом и продолжать программировать.

 

Когда? 

• Когда команда на стадии норминга или перформинга.

• Когда люди квалифицированы и мотивированы.Когда настроена коммуникация.

 

Как?

• Прямая коммуникация.

• Делегирование.

 

Рекомендации

• Управлять отвлекающими факторами.

• Микродекомпозировать задачи.

• Облегчить переключение фокуса внимания.

• Трезво выбирать роль.

 

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