[.NET, Управление разработкой, Управление персоналом] Как быть тимлидом и продолжать программировать
Автор
Сообщение
news_bot ®
Стаж: 6 лет 4 месяца
Сообщений: 27286
В недавнем выпуске подкаста 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.Легче перескакивать между виртуальными рабочими столами, чтобы менять контекст.Пора программировать.Мы настроили время, коммуникацию, справились с отвлекающими факторами, налили чаёк… И мы парализованы.У нас антипаттерн – аналитики-паралитики.Представим ситуацию: мы архитекторы нефтекомплекса. Мы в голове держим весь этот нефтекомплекс: как он работает, почему он все еще не взорвался. Допустим, все рабочие ушли в отпуск и надо починить трубу. Мы единственные, кто может это сделать. Как вы думаете, о чём будет думать архитектор нефтекомплекса, когда ему надо чинить трубу? «Пройдет ли этот биметалл эконормы? А как на давление повлияет в сжигателе?» В данном случае архитектор просто не сможет починить эту трубу, потому что не справится с такой когнитивной нагрузкой.У нас то же самое. Разработка ПО – это комплексная задача. Бизнес-контекст, архитектура, код и прочее. От нас как от тимлидов требуют думать глобально. Чтобы решить задачу, я использую подход вокализации действия. У меня над рабочим столом висят карточки, где написаны разные роли – архитектор, аналитик, программист. И я себе говорю, например: «Сейчас я аналитик, мой фокус внимания – не код, а бизнес-контекст» или «Сейчас я программист, я не думаю, как перекрутить требования». Упрощаем себе жизнь, переключаем фокусы внимания. Напоследок хотелось бы поговорить про выбор «программерской роли», когда вы тимлид. Давайте рассмотрим основные роли:Ключевой разработчик, который делает основную бизнес-логику, разрабатывает ядро продукта.Если ваша большая команда, времени на это может не быть. Стоит вовремя отдать эту роль, когда команда растет, иначе вы можете превратиться в прототипщика (человек, который пилит протопипы, а доведение проекта до ума оставляет на откуп команде). «Затыкатель дыр» – человек, который приходит, когда нам чего-то не хватает для полного счастья.Это человек с широким кругозором, который может компенсировать слабые стороны команды. В современном мире тимлид работает на компенсацию слабых сторон команды, а не наоборот. Такая роль идеальна в небольшой команде. Важно не только «затыкать дыры», но и заполнять пробелы новыми сотрудниками. «Еще одни руки» – еще один программист, который просто еще что-то делает – фиксит баги, например.Этот подход работает, потому что тимлид с такой ролью хорошо знает систему. Тут важно не стать кодерским балластом. И мое любимое – кодерский балласт. Человек, которого лучше бы не было. Кодерский балласт – менеджер, который когда-то был разработчиком, но навык программирования уже утерян. Использует устаревшие подходы, но он начальник, поэтому неостановим. Важно признать свою низкую квалификацию и не быть кодерским балластом.Резюмируя: как быть тимлидом и продолжать программировать.Когда? • Когда команда на стадии норминга или перформинга.• Когда люди квалифицированы и мотивированы.Когда настроена коммуникация.Как?• Прямая коммуникация.• Делегирование.Рекомендации• Управлять отвлекающими факторами.• Микродекомпозировать задачи.• Облегчить переключение фокуса внимания.• Трезво выбирать роль. В заключении хочу сказать: коллеги, когда вы становитесь тимлидами, пусть мир приобретает либо активно обучающихся менеджеров, либо опытных инженеров.
===========
Источник:
habr.com
===========
Похожие новости:
- [.NET, Системы сборки] Подход к интеграции .NET в TeamCity
- [Управление разработкой, Управление проектами, Управление персоналом, Карьера в IT-индустрии] 5 мифов о тимлидах. Как стать тимлидом и избежать ошибок
- [Управление персоналом, Карьера в IT-индустрии] Где работать в ИТ в 2020: Тинькофф
- [IT-эмиграция, Управление персоналом, Карьера в IT-индустрии, IT-компании] Пишите зарплаты, траты и чего вы хотите. Или не пишите ничего
- [PostgreSQL, Управление разработкой, DevOps] Patroni cluster (with Zookeeper) in a docker swarm on a local machine
- [.NET, Промышленное программирование, Разработка робототехники, Управление проектами, Робототехника] Роботы. Часть два. Крылатые качели
- [Программирование, .NET, ASP, C#] Разбираемся с middleware в ASP.NET Core (перевод)
- [Управление разработкой, Управление персоналом] Заметки тимлида
- [Управление разработкой, Управление персоналом, Удалённая работа] Три проблемы удаленной работы: личный опыт от разработчика до менеджера
- [Исследования и прогнозы в IT, Управление персоналом, Карьера в IT-индустрии] Смотрим, сколько зарабатывают в Glassdoor
Теги для поиска: #_.net, #_upravlenie_razrabotkoj (Управление разработкой), #_upravlenie_personalom (Управление персоналом), #_teamlead, #_coding, #_timlidy (тимлиды), #_timlidy_i_razrabotchiki (тимлиды и разработчики), #_blog_kompanii_epam (
Блог компании EPAM
), #_.net, #_upravlenie_razrabotkoj (
Управление разработкой
), #_upravlenie_personalom (
Управление персоналом
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 02-Июл 19:51
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 4 месяца |
|
|
В недавнем выпуске подкаста DotNet & Moreмы обсуждали полезные материалы для тимлидов и всплыла классическая проблема: как совмещать управление командой и написание кода. Этой осенью я рассказывал о лайвхаках, которые помогают мне продолжать программировать на позиции лида и мне показалось полезным, в этом контексте, выложить текстовую расшифровку доклада. Хочу сказать отдельное спасибо Алисе Мироненко за подготовку транскрипта. Видео версия доклада:Извините, данный ресурс не поддреживается. :( Небольшой дисклеймер: то, что я буду говорить, может для вас не работать. Ваша ситуация может быть совсем другой. Если честно, не люблю, когда идет менеджерский доклад и говорят: «Вот это точно вам подойдет». Но я надеюсь, будет полезно тем, чей кейс соответствует тому, о чём я буду говорить.Мне часто встречаются люди с такой карьерной историей: в новую компанию приходит разработчик с десятилетним опытом работы. В 2010 году он пришел в компанию Х, быстро развился до синьора, он талантливый, крутой. Так как он талантливый, ему дали тимлида.Потом ему надоело, он на этой позиции выгорел и снова хочет быть девелопером. Человек приходит к нам, мы у него спрашиваем: «Скажите, какой была ваша рабочая нагрузка на каждой из этих позиций?»В среднем по больнице рабочая нагрузка распределяется так: пока ты джуниор, мидл, ты в основном пишешь код. Как только становишься синьором, количество менеджерских задач резко возрастает. А будучи тимлидом, ты вообще почти не программируешь.Потом человек с таким опытом приходит к нам на позицию разработчика.Получается интересная история: опыт в резюме – десять лет, а реальный опыт разработки – два-три года.Когда мы говорим про ожидание-реальность работы тимлидом, у нас возникает диссонанс. Что мы ожидаем от тимлидской работы? Мы идем, мы модные, нас все слушают, выполняют работу. На деле я бы сказал, что тимлид сидит на горячей сковородке, в которой варится кипящее масло. Потому что множество задач, коммуникации, переключений, зачастую нет времени выдохнуть.Нам кажется: сначала мы были джуном, мидлом, потом синьором, потом ведущим разработчиком. Еще небольшой шаг – и можно идти в менеджеры и управлять людьми.  Но расстояние между лидом и менеджером такое же, как между джуном и лидом.У нас нет времени учиться на менеджеров – это главная проблема.Чтобы стать полноценным менеджером, необходимо получить образование. Я имею в виду не корочку, а менеджерские знания, опыт, связи. Нужно сделать мощнейший скачок, чтобы прыгнуть в менеджеры.  Но есть и другие варианты роста. Есть возможность быть тимлидом, который развивается в первую очередь как инженер. Я специально говорю романтизированное «инженер». Не просто человек, который умеет крутить гайки/писать код, а который умеет решать сложные задачи, в том числе привлекая других людей.У нас есть такой вариант – идти в тимлиды, сохраняя инженерную рабочую нагрузку.Раз мы решили пойти в менеджмент, давайте получать соответствующие навыки, знания. А то есть менеджеры, которые не знают основ – как делегировать и прочее.Если мы решили углубиться в разработку, у нас должна быть инженерная нагрузка, хотя бы 30%. Возникает вопрос: «А разве эти 30% нас спасут?» Да, об этом сегодня и поговорим – как добиться этих 30% эффективной работы, чтобы мы продолжали развиваться как настоящие инженеры. Давайте начнем с того, когда тимлиду стоит заниматься разработкой. Я сделал небольшой чеклист. Возможно, у вас есть время на разработку, если:
 Как только вы перейдете в режим норминга и перформинга, у вас освободится гораздо больше времени на программирование.2) Уровня квалификации и мотивации ваших сотрудников Если у нас команда высоко мотивирована, но не очень квалифицирована, как будто там много активных джунов, то ваше время гораздо эффективнее вкладывать в менторинг команды, чтобы они быстро доросли до того уровня задач, которые им нужно выполнять.Обратная ситуация – у вас в команде толпа «выгоревших синьоров». Тогда время и энергию стоит вложить в поддержку ребят, чтобы они выскочили из ямы демотивации.Если у вас команда немотивированных и неквалифицированных сотрудников, то, наверное, вы всё время будете заняты микроменеджментом и больше ничем.Есть классическая табличка на эту тему:  Единственный возможный вариант освободить себе время на разработку – делегировать задачи достаточно мотивированной и квалифицированной команде.3) Уровня коммуникации на проекте Возможности тратить времени на разработку не будет, если есть проблемы в коммуникации на проекте.Например, mushroom management (управление по принципу «меньше знаешь – крепче спишь), когда вы являетесь единой точкой коммуникации и никто больше не знает, что происходит.Очевидно, что в таком случае у вас не будет времени на инженерную деятельность.Как настроить коммуникацию?Вариант: если я единая точка коммуникации, я возьму и самоустранюсь.  Главная проблема будет в том, что появится неформальный лидер. Понятие «неформальный лидер» неприятное, потому что часто неформальные и формальные лидеры – не одно лицо. Это становится проблемой для формального лидера.В идеале нам нужно соблюдать баланс в коммуникации: вы управляете командой, но не всё не завязано на вас – команда тоже общается с заказчиком и может решать проблемы. Как перестать быть единой точкой коммуникации? Если «всех всё устраивает», один из самых приятных вариантов – натравить на команду SCRUM-мастера, чтобы контролировать и оптимизировать рабочий процесс. К сожалению, это не всегда срабатывает.Тогда можно пойти по классическому пути: уходите в отпуск – оставляете своего заместителя. Никакой заказчик не будет против, чтобы временно пообщаться с вашим сотрудником (кроме редких исключений). Но это не помогает познакомить заказчика со всей командой. Поэтому я бы хотел рассмотреть более общий способ того, как «подружить» заказчика с командой:• Познакомьте заказчика с командой через task manager.• Организуйте встречу с командой в привычном для заказчика месте и времени. Не приводите сразу всех.• Ведите первые митинги как обычно, тет-а-тет с заказчиком, но с командой «на фоне».• Передавайте часть инициативы коллегам, например: «Вот Евгений знает эту систему лучше всех, пусть расскажет».• Поднимайте на встречах вопросы, которые можно адресовать команде. Пусть на них отвечают, не ожидая вас.• Позвольте вашим коллегам вести митинги и переписки напрямую с заказчиком, но в первое время будьте рядом.• Всегда будьте в копии и на связи с заказчиком. Это было про коммуникацию, теперь про то, как делегировать.Делегирование – процесс передачи функции руководителя. Но наши функции не всегда очевидны другим. Например, наша обязанность – деплой на продакшен в рамках фичи деплоя. Для нас может быть очевидно, что нужно прогнать тесты, кто ж не знает? Никто не знает, эта информация в вашей голове. Необходимо донести её до человека, который будет выполнять задачу.Делегирование – это отдельная тема, сейчас я остановлюсь только на нескольких моментах.Не забывать, что ваши функции не очевидны другим. Давать задачи тем сотрудникам, которые способны с ними справиться. Если есть задача вести коммуникацию с кучей разных людей из разных стран, вряд ли стоит давать ее скромному интроверту с уровнем английского А1.Делегирование должно развивать сотрудников. Помните, что чем больше вы делегируете человеку, тем лучше он справляется со своими полномочиями. Поэтому, если первый раз произошло полное фиаско и человек не справился с функциями, которые вы делегировали, лучше дать ему возможность еще раз попробовать эту задачу, возможно, он чему-то научился. Как это понять? Важная часть делегирования – контроль. Еженедельный контроль, ежедневные митинги и прочее.Не забывайте, что делегирование – это не безучастность. Вы должны быть в курсе событий, слушать митинги.Мы поняли, когда можно браться за разработку: команда не находится на этапе шторминга, мы умеем делегировать.Давайте теперь подумаем, как бороться с отвлечением и управлять вниманием.В чем проблема борьбы с отвлечением для тимлидов? В том, что классические подходы к тайм-менеджменту – focus time, помидорка, скалирование времени и другие – не работают, если сотрудники не уважают ваше время.Но что делать с вопросами коллег? Важно отвечать на них хотя бы в течение получаса.Я предпочитаю способ переноса времени: если вам написали, а вы программируете, то вы отвечаете через пятнадцать минут. Крайне важно не забывать ответить.Для тимлидов отметим важный момент: пишем «через 15 минут» правильно.  Так вы сохраните хорошие взаимоотношения с коллегой, сможете уменьшить негатив. Впоследствии у человека не будет проблем, чтобы задавать вопросы – он не будет вас бояться.Рассмотрим еще одну проблему – возврат в контекст.Вы программируете, у вас в голове: «Задача-метод-класс». Вас отвлекли, контекст пропал. Вы ответили сотруднику, нужно вернуться в контекст.Одно из самых эффективных решений – микродекомпозиция. Это когда вы берете листочек/one note, где можно сделать древовидную структуру и декомпозировать свою задачу вплоть до псевдокода или формулировки «сделай вот это».  Мультитаскинг – большая проблема тимлида, и здесь могут помочь виртуальные рабочие столы.На виртуальном рабочем столе программирования у вас может быть открыт IDE, браузер, требования.На виртуальном столе, где у вас релиз в продакшен, Jenkins/TeamCity, Splunk/Kibana, чат с DevOps. То же самое с обсуждением требований: Skype/Teams, Jira, Confluence.Легче перескакивать между виртуальными рабочими столами, чтобы менять контекст.Пора программировать.Мы настроили время, коммуникацию, справились с отвлекающими факторами, налили чаёк… И мы парализованы.У нас антипаттерн – аналитики-паралитики.Представим ситуацию: мы архитекторы нефтекомплекса. Мы в голове держим весь этот нефтекомплекс: как он работает, почему он все еще не взорвался. Допустим, все рабочие ушли в отпуск и надо починить трубу. Мы единственные, кто может это сделать. Как вы думаете, о чём будет думать архитектор нефтекомплекса, когда ему надо чинить трубу? «Пройдет ли этот биметалл эконормы? А как на давление повлияет в сжигателе?» В данном случае архитектор просто не сможет починить эту трубу, потому что не справится с такой когнитивной нагрузкой.У нас то же самое. Разработка ПО – это комплексная задача. Бизнес-контекст, архитектура, код и прочее. От нас как от тимлидов требуют думать глобально. Чтобы решить задачу, я использую подход вокализации действия. У меня над рабочим столом висят карточки, где написаны разные роли – архитектор, аналитик, программист. И я себе говорю, например: «Сейчас я аналитик, мой фокус внимания – не код, а бизнес-контекст» или «Сейчас я программист, я не думаю, как перекрутить требования». Упрощаем себе жизнь, переключаем фокусы внимания. Напоследок хотелось бы поговорить про выбор «программерской роли», когда вы тимлид. Давайте рассмотрим основные роли:Ключевой разработчик, который делает основную бизнес-логику, разрабатывает ядро продукта.Если ваша большая команда, времени на это может не быть. Стоит вовремя отдать эту роль, когда команда растет, иначе вы можете превратиться в прототипщика (человек, который пилит протопипы, а доведение проекта до ума оставляет на откуп команде). «Затыкатель дыр» – человек, который приходит, когда нам чего-то не хватает для полного счастья.Это человек с широким кругозором, который может компенсировать слабые стороны команды. В современном мире тимлид работает на компенсацию слабых сторон команды, а не наоборот. Такая роль идеальна в небольшой команде. Важно не только «затыкать дыры», но и заполнять пробелы новыми сотрудниками. «Еще одни руки» – еще один программист, который просто еще что-то делает – фиксит баги, например.Этот подход работает, потому что тимлид с такой ролью хорошо знает систему. Тут важно не стать кодерским балластом. И мое любимое – кодерский балласт. Человек, которого лучше бы не было. Кодерский балласт – менеджер, который когда-то был разработчиком, но навык программирования уже утерян. Использует устаревшие подходы, но он начальник, поэтому неостановим. Важно признать свою низкую квалификацию и не быть кодерским балластом.Резюмируя: как быть тимлидом и продолжать программировать.Когда? • Когда команда на стадии норминга или перформинга.• Когда люди квалифицированы и мотивированы.Когда настроена коммуникация.Как?• Прямая коммуникация.• Делегирование.Рекомендации• Управлять отвлекающими факторами.• Микродекомпозировать задачи.• Облегчить переключение фокуса внимания.• Трезво выбирать роль. В заключении хочу сказать: коллеги, когда вы становитесь тимлидами, пусть мир приобретает либо активно обучающихся менеджеров, либо опытных инженеров. =========== Источник: habr.com =========== Похожие новости:
Блог компании EPAM ), #_.net, #_upravlenie_razrabotkoj ( Управление разработкой ), #_upravlenie_personalom ( Управление персоналом ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 02-Июл 19:51
Часовой пояс: UTC + 5