Содержание
Его работа связана с более глубоким осознанием проблем, что уменьшает зависимость от всей системы. Если Delivery Manager хорошо знает, что ему нужен определенный эксперт, то коммуникация с ним пойдет быстрее, потому что оба человека в курсе проблемы. Delivery Manager контролирует проделанную работу и убеждается, что она приближает команду к цели. Сначала DM ждет много разговоров о проблемах заказчика и о том, как их решить. Это ближе к бизнес-требованиям, продакт-менеджменту и архитектуре решений.
Это разные подходы — жесткая иерархия, строгое планирование, четкое разделение ответственности. И — гибкая разработка, роли, не привязанные к конкретным людям, роли могут брать разные люди в зависимости от нагрузки и, не знаю, фазы Луны. Хотя может в этом и проблема — в уверенности, что если назвать «ведущего программиста» senior-ом, руководителя отдела — teamlead-ом, а гендира — СЕО — то в команде сразу все наладится.
Прогнуть, но не сломать и показать правильную лесенку к миддлу. А вот синьоров надо именно вдохновлять и мотивировать, тогда команда имеет много шансов на успех. Конечно же, не забывать и о многих-многих других технических сторонах роли. Это совсем не просто, если по-честному, а не «за выслугу лет». И именно поэтому тим-лиды получают лучше «чистых» менеджеров аналогичного ранга. Нужно быть готовым к большей нагрузке, дополнительным затратам нервных клеток, разорванному рабочему дню и необходимостью постоянно переключаться между задачами.
Если говорить о классификации, я склоняюсь к тому, чтобы определить атомарные роли, и потом уже говорить о том, кто какие роли на себя берет. Также статье не хватает диаграммы, в которой была бы отражена вся команда, место Team Lead-а в ней и связи (или их отсутствие) с каждым из тим мемберов. Но не зависимо от метода выбора — назначение сверху или самоорганизация — название должности ни на что не влияет.
Техлид должен оставаться в форме и совершенствовать свои навыки и знания, чтобы быть непререкаемым авторитетом для остальных сотрудников. Желательно искренне любить технологии – так работа и помощь остальным будут в радость. Именно техлид подает пример постоянного развития – он участвует в профильных конференциях и призывает к этому других. Эти роли решают совершенно разные задачи, и некоторые из них выходят далеко за рамки построения софта прикладного уровня. Кого-то можно встретить в сервисной компании, кого-то — в продуктовой, а кого-то вообще только на стыке настоящего Research & Development. Руководство начинает требовать метрики эффективности каждого инженера.
Помимо технических навыков это всё-таки про ответственность и работу с людьми. Например, многим техническим специалистам не нравится проводить one-to-one https://deveducation.com/ встречи. А это необходимая практика для «здоровой команды». Необходимо брать на себя ответственность, иметь технические навыки, быть лидером.
Поскольку команда состоит из людей, которые подвержены ошибкам из-за человеческой натуры, команда также уязвима перед хаосом и несовершенством. Техническому руководителю не нужно лишаться мотивации, вместо этого воспринимайте ошибки как мотивацию для постоянного улучшения. Еще работодатель проверит основы знаний об артефактах, идеологии и структуре проектного управления согласно определенной методологии.
В большинстве случаев в его трудовой прописана та же должность, что и у коллег из его сферы. Однако за выстраивание технических процессов и решение связанных с этим задач он получает ежемесячную премию, которая может быть больше зарплаты, иногда даже в несколько раз. В противоположном случае будет сложно вовремя заметить ошибки и сделать глубокий code review. При этом тим лидеру важно параллельно изучать новые технологии. Тимлидам также часто поручают дополнительные таски. Например, если в небольших компаниях в штате нет проджекта, вести коммуникацию с заказчиком приходится тимлиду.
Компания нанимает инженера с глубокой технической экспертизой, и после просмотра кодовой базы и общения со стейкхолдерами он видит недостатки текущей архитектуры ПО на системном уровне. При таком типе лидерства инженер не руководит командой, а использует свою репутацию, чтобы сформировать видение продукта. Тимлидами становятся те, кто предлагает изменения в процессах, растет в техническом плане, ходит на конференции и стремится применять новые знания на практике.
Опыт в разработке, английский, умение договариваться и желание работать не только с кодом, но и с людьми. Есть ситуации, где ищут лида именно для работы с командой, есть, где ищут на % работы с командой. Что сложнее — работать с людьми или технологиями — понятие относительное. Технарю сложнее с людьми, менеджеру — с кодом и технологиями. Все отличается, в зависимости от проекта и конкретного человека. В зависимости от фазы проекта рабочий день может быть разным.
Мне кажется, что ответ на вопрос в чем отличие от технического ПМа, кроется не в «как появилась эта роль», а в «зачем появилась эта роль». Уже есть люди, которые воспринимают Delivery Management как хайп и начинают судорожно искать возможности стать его частью. Но формирование такой тенденции тоже занимает время, и даже таких людей на рынке немного. Лучшая среда для роста — если у вас будет наставник с большим опытом, который будет выполнять роль «первого пилота». Роль и распределение обязанностей Delivery Manager зависит от стадии проекта.
Самое смешное — если человек не выполняет роль тимлида, то навешивание ярлыка «тимлид» моментально ситуацию не исправит. Кроме того, тактические вопросы управления командой тимлиду, который находится рядом, в «окопах», решать гораздо эффективнее, чем ПМу, который более сконцентрирован на стратегических показателях проекта. Это уже другой вариант — гомогенная команда, все делают все, кто-то добровольно берет на себя какие-то обязанности и тп. Чтобы стать тимлидом, необходимо проявлять инициативу в работе, накапливать разнообразный технический опыт, развивать коммуникативные навыки, зарабатывать авторитет в коллективе.
На основании чего было решено, якобы это таки «лиды»? Пример действительно очень распространенный и не уникальный рамками постсоветского общества. Особенно смешон такой «тип лидирования» в проектах типа «типа у нас агиле скрам». Если говорить о конкретных цифрах, то среди 1822 бывших украинских тимлидов база данных LinkedIn находит 852 проектных менеджеров и 346 системных архитекторов.
Это значит, есть место для специалистов с амбициями! Напротив, некоторые новоназначенные технические лидеры отказываются от кодирования. Как правило, разработчики программного обеспечения, которые могут быстро написать качественный код, получают техническую поддержку. Разработка программного обеспечения требует команды разработчиков по причине того, что это — сложный процесс. Следовательно, проект не может быть разработан одним человеком.
Например, когда начинали работать над проектом, то только собирали команду, а значит, очень много времени уходило на собеседования. Потом это проведение ежедневных митингов, общение с командой, решение проблем, которые у команды возникают, планирование и реализация новых фич в продукте. И, разумеется, это гораздо проще делать, имея технический бэкграунд, чем не имея его. Обычно новичкам на проекте такая должность не достается. Инженеры техподдержки третьего уровня имеют гораздо больше общего с сисадминами/devops, чем с коллегами из второго уровня.
Быть техническим лидером иногда чрезвычайно полезно, когда команда хорошо работает и наслаждается работой. Однако достичь и поддерживать tech lead обязанности такое состояние не так легко. Существует несколько вещей, о которых необходимо позаботиться, будучи техническим лидером.
В новых проектах на позицию Tech Lead часто выдвигают опытного сотрудника компании. Он за малое время сможет безошибочно определить объем ресурсов, который потребуется, и выстроить рабочие процессы. Затем, имея на руках эту информацию, тимлид займется формированием команды из сотрудников, способных справиться с предстоящей работой. Таким образом, техлид – довольно размытая роль и может встречаться в разных формах. Сотрудник, по факту выполняющий задачи техлида, может занимать разные должности. В любом случае он должен обладать развитым эмоциональным интеллектом для коммуникации с коллегами.