Бум в ИТ-индустрии требует организации новых команд, а опытные мидлы и сеньоры оказываются перед сложным выбором: продолжать совершенствовать собственные технические навыки или переходить в управление разработкой программного обеспечения. Сайт proglib.io опубликовал статью, в которой взвешиваются плюсы и минусы разных вариантов развития карьеры разработчика.
Можно ли управлять командой, оставаясь крутым программистом?
Первое озарение новоиспеченного тимлида:
Успех достигается не в одиночку, а потому остро встает вопрос: что важнее – научиться управлять людьми и растить из них крутых специалистов или продолжать развивать собственные навыки?
Ускользает то, ради чего лидер пришел в профессию – программирование. Вдобавок, не очевидно, как тимлида оценивает руководство, и какие у него теперь KPI. Еще непонятно, получится ли найти работу в другой компании, если потребуется. После нескольких лет управления лидер уже не ответит на вопросы, которые сам задает кандидатам на собеседованиях.
Работа тимлида
Основные задачи тимлида: построить процесс разработки и наладить отношения с командой.
С построением процесса все понятно: можно перенять опыт коллег, воспользоваться принятыми в компании стандартами и подходами, или пройти обучение по организации разработки программного обеспечения.
Сложность управления командой на первый взгляд неочевидна. Процессы кажутся происходящими автоматически. Что сложного – нарежь техзадание на задачи и раздай программистам.
Быстро приходит понимание, что директивные методы не работают на сеньорах, а микроменеджмент джуниоров отнимает слишком много времени. То, что раньше казалось работающим “само по себе”, требует усилий – чтобы не потерять время и не завалить проект, нужно развивать навыки управления людьми.
Психология кажется бабушкиными сказками до первого случая выгорания в коллективе. Возможно, вашего собственного выгорания.
Лидерство, эмоциональный интеллект, ведение переговоров и управление конфликтами – вот софтскильные навыки тимлида. Для технаря эти слова звучат слишком пафосно, а на деле без них далеко не уедешь:
- Лидерство. Это слово растиражировано диванными коучами и вызывает неприятие, но смысл навыка – иметь позицию, собирать вокруг себя команду, принимать решения за себя и других и нести за них ответственность.
- Эмоциональный интеллект. За этим названием кроется умение понимать, что хотят люди. Эмоциональный интеллект позволяет предсказать реакцию команды на слова лида, учит выбирать эти слова для каждого конкретного сотрудника.
Для новых лидов становится полной неожиданностью, когда они невольно погружаются в личную жизнь членов команды. Поначалу кажется, что этого можно избежать, но чем дольше команда работает вместе, тем больше тимлид знает о личных проблемах сотрудников.
Это происходит незаметно. Отпрашиваясь на утро вторника, Николай скажет, что ему надо сгонять в банк по поводу ипотеки, а в пятницу Валентин везет ребенка в больницу. Люди чувствуют потребность сообщить, почему их не будет на работе, а тимлиду придется это слушать. В следующий раз лидер команды принимает решение уже зная ситуацию в семьях коллег и психологические особенности этих людей.
Собственный эмоциональный интеллект лида дает инструменты психологической самозащиты в условиях стресса:
- Руководитель проекта выставляет жесткие сроки и дает неподъемное количество задач.
- Члены команды хотят делать только креативные задачи, рефакторить код и использовать модные библиотеки.
- А еще у тимлида есть личная жизнь. Должна быть в теории.
Тимлид работает под двойным давлением: изнутри – от членов команды и снаружи – от руководства. Развитие софтскильных навыков помогает это давление уменьшать:
- Управление временем. Тимлиду требуется управлять собственным временем и временем членов команды, причем не только рабочим. Повышенные нагрузки требуют качественного отдыха. Отдых нужно организовывать, чтобы не потратить выходные на ремонт в квартире под видом смены деятельности.
- Навык переговоров. Кажется, что переговоры – это для крутых боссов в пиджаках и галстуках, а на деле это важная часть новой работы.
«Все в жизни — переговоры. Когда вы переходите улицу – это переговоры. Захватить кофе в Старбаксе – это переговоры. Возможно вы участвуете в 3-7 переговорах в день. И ваша жизнь может быть совсем другой, если вы улучшите свой навык переговоров».
Крис Восс
Попросите коллегу поовертаймить в субботу или подключиться к звонку из отпуска. Откажитесь брать в спринт новую пачку задач у руководителя проекта и останьтесь друзьями. Объясните клиенту, как лучше реализовать нужную функцию.
Переговоры – это важно и энергозатратно, но особенно энергозатратны манипуляции. Нужно правильно распознать попытки манипуляций от сотрудников, которые не хотят делать порученные задачи или не успевают справиться с ними в срок.
Как следствие, руководителю пригодится навык урегулирования конфликтов. Например, для решения постоянного спора красных с белыми: программистов и тестировщиков.
Вечный сеньор
Не погружаться в менеджерские дебри, а просто любить свою профессию — тоже нормально. Постоянно совершенствовать навыки программирования и стремиться стать лучшим в своем деле – это отличный вариант.
Слово “мастерство” действительно звучит приятнее слова “менеджмент”.
Выбирая путь совершенствования технических навыков, нужно учесть две неочевидные проблемы: наступление стагнации и изменение требований отрасли.
Стагнация
С позиции мидла достижение потолка кажется невозможным. Слишком много открытий еще впереди, а информация слишком необъятна. Однако для выхода на уровень сеньора нужно сосредоточиться на одном конкретном навыке и оттачивать его.
Через несколько лет навык становится изученным. С каждым годом процент неизвестного все ниже, все больше становится повторяющихся задач. Ученые считают, что монотонная работа опасна для эмоционального здоровья. Выгорание наступает не только от высоких нагрузок, но и от однообразия.
Возможное развитие сеньора – стать архитектором. Для этого нужно не так уж много: научиться смотреть на разрабатываемые системы сверху, а не изнутри, и погрузиться в задачи заказчиков конкретной бизнес-области.
Еще один вариант развития – заняться менторством, подготовкой новых специалистов. Если не позволяют условия внутри компании, можно рассмотреть внешние возможности или даже заняться индивидуальным предпринимательством.
Изменение требований отрасли
ИТ – быстро меняющаяся сфера, и сеньору придется учиться. Сменилась версия Java или Python – нужно обновить знания. Старый код без лямбд уже неинтересен, а организация многопоточности может стать неэффективной. Однако, это — мелочи по сравнению с глобальными изменениями.
Не так давно весь мир перешел от монолитов к микросервисам, и программисты обновили знания, познакомившись с облачными решениями. Без знания нового стека линейное руководство со временем не найдет программистам новых проектов. Даже “латынь” программирования – язык SQL – претерпевает серьезные изменения, образуя новый диалект при переходе на трендовые базы данных.
Сеньор не сразу бросается учиться новому из-за недоверия к очередной архитектурной идее. Требуется проверка временем – это логично. Однако при существенной смене стека, чем дольше сеньор тянет с обновлением знаний, тем меньше проектов готовы пригласить его в команду.
Работая с определенным языком и направлением, следует держать руку на пульсе новых веяний в отрасли и своевременно учить свежие фреймворки, чтобы внезапно не оказаться джуном с двадцатилетним опытом программирования на мертвых языках.
Сеньору также нужны софтскиллы. Ситуация на рынке труда в ИТ такая, что вместо запланированных 10 человек в команде работает в лучшем случае 6. Переработки уже никого не удивляют.
В условиях, когда ресурсов нет и не будет, важно правильно оценивать силы и сохранять хорошие отношения с коллегами. На первый план выходят навыки общения с командой и планирования собственной нагрузки.
Работать после работы
Это единственный способ поддерживать технические навыки, развивая управленческие.
Чем больше человек в команде тимлида, тем больше времени занимает управление. Этот менеджерский аспект нарастает снежным комом.
Сначала – ежедневный синкап на 30 минут и проверка задач стрима (час в неделю), потом – верификация дизайна с аналитиками перед запуском задачи в работу, а дальше тимлид начинает решать проблемы, с которыми приходят тестировщики. Еще надо позвонить джуниору и проверить, правильно ли он понял задачу, или устроить брейнсторминг с архитектором по поводу новой фичи.
И вот уже 5-7 часов чистого времени в день занимает управление. Когда же кодить?
Согласно Scrum Guide, команда разработки должна состоять из 3 – 9 человек, но опыт показывает, что с командой от 5 человек программировать удается все меньше, а магическое число 7 практически полностью блокируют эту активность. Срабатывает эффект “нехватки мыслетоплива”, описанный Максимом Дорофеевым:
Время у нас есть, у нас ума не хватает.
Между встречами не удается сосредоточиться, а после обсуждений уже нет сил. Если тимлид принял, что его ценность и задача не в программировании, а в организации процесса, его рабочее время выглядит так:
Коммуникации занимают львиную долю, но все еще удается программировать и учиться новому.
Если любовь к программированию не отпускает, то оно замещает личные дела и рабочая неделя становится восьмидесятичасовой.
Работая после работы и программируя в выходные, удается сохранять и развивать технические навыки, но долго в таком режиме работать сложно. Чтобы не перегружаться, приходится меньше развивать или управление, или программирование.
Взвешиваем за и против
Как узнать, что вам нужно на самом деле? Основной вопрос при принятии решения: кому нужно, чтобы вы стали лидом?
Это нужно лично вам, это вам интересно, или это установки общества и других людей? Так положено, так круче, все делают в этом возрасте, это нужно компании – выполнять желание других людей долгое время не получится. Вы возьмете работу, и в итоге она будет вас бесить.
Делать через силу — «воспитывать» сотрудников и терпеть запросы руководства — тяжело психологически. Другое дело, если вам нравится направлять людей, задавать темп и радоваться результатам вместе.
Если управление вас драйвит, но вы не готовы принимать на себя ошибку конкретного программиста, стоит хорошенько подумать. Вы разделяете результат команды (нет никакого “я вывел эту систему в прод”, только “мы вывели”), но вы разделяете и неудачи.
Не Петр забыл конфигурационный файл в сборке, а вы, команда, подготовили ее некорректно (и может быть завалили продакшн). Это разумная плата за те вершины, куда вас может вынести команда в случае успеха.
Вопреки распространенному мнению, “интроверсия” не является блокирующим фактором для работы тимлидом: постепенно члены команды становятся “своими”, и говорить с ними получается легко и приятно. Нарабатывается привычка защищать “своих” от дополнительной работы, которую подкидывает руководитель проекта, и обучать “своих” новому.
А вот формализм является опасным фактором. Лидера, который любит, чтобы все было обезличенным, безэмоциональным и правильным, команда перестает слышать и начинает игнорировать.
За разрешением своих проблем, как следствие, команда ходит к неформальному лидеру группы. И со временем назначенный лидер получает жесткий конфликт с самопровозглашенным. Об аспектах командной работы можно узнать из материалов и тренингов по командообразованию.
Перспективы
Логичным развитием тимлида будет позиция технического менеджера, технического руководителя проекта. Позиция имеет много названий, но суть одна: технический менеджер – это сеньорный тимлид или лид лидов.
В команде сеньорного тимлида работает лид разработки, лид аналитиков и лид тестирования. Технический руководитель выполняет задачи по подготовке проекта к старту, управляет разработкой и поставкой готового программного обеспечения заказчику. Сеньорный лид может принимать архитектурные решения, выбирать средства и методы программирования.
Чтобы дорасти до технического менеджера, нужно постоянно совершенствовать софтскиллы и навыки коммуникации, в том числе на иностранном языке, если компания работает с зарубежными заказчиками.
Технический руководитель более погружен в бизнес заказчиков. Одно из основных занятий менеджера — выбрать и разъяснить заказчику стратегию разработки, услышать его нужды и приоритеты и запланировать выдаваемые функции.
Вывод решения в продакшен также задача технического менеджера.
Не стоит путать технического менеджера и проектного менеджера. Технический менеджер не занимается расчетом бюджета, но выполняет оценку трудоемкости в человеко-днях. Проектный менеджер не обладает знаниями для технических разговоров с командами заказчика.
Позиция технического менеджера, как правило, представлена у крупных разработчиков программного обеспечения, а у небольших компаний совмещается с архитектором или отсутствует.
Сеньорный программист при повышении квалификации становится архитектором. Архитектор должен видеть проект комплексно и систему в целом, а также знать типовые паттерны решения разного рода задач.
Есть несколько типов архитекторов – от проектирующих конкретную часть проекта или платформы (хранилище данных, состав облака) до разрабатывающих полную архитектуру системы.
Чтобы стать архитектором, нужно постепенно расширять круг технических интересов и соотносить технические решения с нуждами бизнес-среды, в которых они применяются.
Для бизнес-сфер существуют промышленные, отраслевые стандарты интеграции. Архитектор выполняет проектирование системы в соответствии с этими стандартами.
Помимо индустриальных стандартов, есть паттерны проектирования информационных систем и методологии построения архитектуры. Изучение фреймворков проектирования, таких как TOGAF, заодно выполняет форматирование мозга, упорядочивает деятельность.
Архитектор уменьшает вероятность изобретения велосипедов на проектах, поскольку знает варианты решений для типовых проблем.
В конечном итоге и сеньорная, и тимлидская позиции дают возможности профессионального роста. Поэтому для принятия решения достаточно быть честным с собой и осознавать последствия смены деятельности.
[customscript]techrocks_custom_after_post_html[/customscript]
[customscript]techrocks_custom_script[/customscript]