- Я стал тимлидом - мои первые шаги
- Введение
- Новая команда
- Знакомая команда
- Общие советы
- Итого
- Полезные ссылки
Кому будет интересно/полезно прочесть данный текст? Людям, кто только начинает свой путь и вступает в новую роль тимлида.
Здесь мы обсудить первые шаги, с чего начать и что делать в самом начале.
Все ниже сказанное и описанное - это компиляция как моего опыта и мнения, видения, так и статей, видеороликов и конференций, книг. Все источники, которые повлияли на написание этого текста вы сможете найти в конце.
При этом, есть большая разница в том как вы стали тимлидом: в уже знакомой команде (например, прошлый тимлид ушел на повышение или в другую компанию), либо же вы пришли в абсолютно незнакомую для себя команду.
Рассмотрим оба этих варианта.
Представим ситуацию, что вы пришли в абсолютно новую команду, где практически никто вам не знаком (либо вовсе никто не знаком).
В таком случае, что я бы советовал сделать и с чего начать.
Здесь я хочу выделить прекрасную статью С чего начинать на новом месте (памятка для Руководителя проектов), на которую частично буду опираться, так как с многими пунктами согласен и они так или иначе пересекаются с ролью тимлида. По сути РП (Руководитель Проекта) тесно связан с Тимлидом (иногда даже эти роли могут совмещаться, но редко), отсюда и первые пункты, на мой взгляд, одинаковы.
Во-первых, постарайтесь в начале, первое время, не давать никому никаких обещаний. Здесь ровно те же причины, что и в статье по ссылке выше.
Почему это важно?
Ваша работа - это стык разработки, бизнес-целей и команды. По сути это три составляющие, три направления работы. И по каждому из этих направлений вы сейчас не знаете ничего.
Перед вами:
-
Неизвестный проект и риски (которые были заложены)
В отличии от РП вы должны больше понимать именно технические риски, за вами по сути последнее слово-апрув по коммитам сроков и так далее.
Сейчас нет понимания ни эксплуатации, ни процесса разработки, ни рисков, на которые, так или иначе, пошли еще до вашего прихода, ни предметной области и влияния каких-то действий на нее. Также вы не чувствуете и не знаете силы своей команды, не понимаете накопленных проблем - что вы можете, а что нет в рамках каких-то сроков и условий.
В моей практике были проекты, где накоплен такой техдолг, что даже поменять минорный параметр в конфигурации - это путешествие на несколько недель. И представьте, что вы видите задачу на подобное изменение и обещаете руководителю или представителям бизнеса срок в пару дней. Стоит ли говорить, что окончится все сдвигами сроков и некоторым негативным опытом у всех участников.
-
Неизвестный руководитель
Пока вы не знаете этого человека и как он реагирует на различные ситуации (в том числе и негативные).
Есть разные типы руководителей, в моей практике были случаи, когда человек пытался надавить, чтобы посмотреть как я буду вести себя в стрессе и насколько можно под давлением уговорить меня на какие-то обещания и коммиты (это был его способ проверки).
В то же время, у меня был опыт, когда мой руководитель вообще ничего не просил и не требовал, считая, что я сам разберусь в том, что надо делать.
-
Неизвестная команда
В отличие от РП, команда и ее производительность, настрой и эмоциональный фон - это ваша непосредственная обязанность.
Новая команда - это новые люди со своей мотивацией, со своим характером и реакцией на различные события и слова. Это своя культура, возможно, присутствующая только внутри этой команды, возможно, сформированная в отделе или на уровне организации. Ко всему этому надо привыкать и во всем разбираться.
Надо понимать, что новая команда также присматриватся к вам и формирует о вас свое мнение, привыкает и по началу, возможно, недоверяет. А значит и к словам/обещаниям будет относиться настороженно.
При этом надо помнить, что люди бывают разные и кто-то может преждевременные обещания использовать в свою пользу - бывает всякое.
Также, не понимая свою команду очень опасно давать какие-то прогнозы по разработке. Кто-то может уже думает об увольнении, кто-то демотивирован, кто-то наоборот готов перформить на 140%, где-то человек одной ногой в отпуске.
-
Неизвестные процессы
Вы, как тимлид, должны достаточно хорошо понимать процессы в компании, так как это влияет как на разработку, или, например, релизный цикл, эксплуатацию, так и на мотивацию сотрудников (пересмотры, повышения).
Также вы должны понимать и как устроен процесс согласований каких-то действий, чтобы что-то обещать. То, что занимает в одной компании несколько часов, в другой может занять не один день.
Например, в Сбере как-то был момент (это было давно и не правда), что те правки, что мы внесли в код, доехали до продакшена только через несколько месяцев, пройдя череду согласований и заявок. В свою очередь, во время моей работы в e-commerce компании мы могли выкатить что-то хоть день-в-день.
-
Непонятный заказчик (для нас это скорее всего продуктовая команда)
Здесь все примерно то же, что и в пункте с руководителем и процессами, только взаимодействие более тесное. Не понимая всего вышеперечисленного не стоит обещать бизнесу свершений и побед.
Мне понравилась аналогия (с той же статьи):
Выглядит так, что РП, выходящий на новую работу, как пассажир, который пытается запрыгнуть в поезд на ходу, чтобы потом добраться до головы состава и начать им управлять. И чем быстрее летит поезд – тем сложнее в него запрыгнуть
На мой взгляд, очень тонкая аналогия. Для тимлида это также актуально.
Это сделать надо чем быстрее - тем лучше.
Вспомните, что один из минусов роли тимлида - это 'размытость' области ответственности и возможностей.
Поэтому чем раньше вы поговорите с руководителем и очертите себе вашу зону ответственности, поймете на что можно влиять и как - тем лучше.
Для начала выясните, на что, по мнению вашего нового руководителя, надо обратить внимание сейчас. Спросите его по команде, нет ли уже известных проблем/конфликтов? Например, руководитель сразу может сказать, что в команде есть, например, Петя и он очень любит 'закапываться' в технические детали, забывая о сроках и самой задаче, а есть Вася, который уже приносил оффер из другой компании и сейчас думает о продолжении своей карьеры в другом месте.
Обязательно выпишите то, что от вас ждет ваш руководитель. И лучше зафиксировать это текстом, это важно, так как по ним как вас будут оценивать на испытательном сроке, так и вы сформируете свое представление о руководителе и проекте. В случае каких-то недопониманий можно будет всегда ссылаться на это, по сути это вектор, который вам задает руководитель и вектор лучше не на словах этот иметь.
Попросите внутренние регламенты, спросите заранее про доступы и как их получать, соберите ссылки на материалы для изучения (например, Confluence). Также попросите добавить на необходимые встречи вас.
Договоритесь о регулярных one-to-one встречах с руководителем. Здесь я бы советовал встречаться где-то раз в неделю: чаще нет смысла, а реже будет скорее всего неудобно из-за того, что вы сейчас будете собирать и анализировать информацию и нужно будет так или иначе консультироваться, обмениватсья общими впечатлениями.
Узнайте о встрече с заказчиком (продуктовая команда) и спросите как она обычно проходит: это будет общая встреча, пойдете ли вы вместе или это от вас ожидают инициативу?
Это не значит, что надо соглашаться на все, но займите пока нейтральную, обозревающую позицию.
После этого пункта у вас на руках должны быть:
- Ожидания от руководителя (в идеале - зафиксированные)
- Базовое понимание по команде и ее составу (как грейдовому, так и численному)
- Представление о церемониях команды (дейли, one-to-one, ретро)
- Базовое понимание по процессам в компании (доступы, документация)
Основные метрики для вас:
- Насколько по вашему мнению вы согласны с ожиданиями
- Насколько ваш руководитель понимает силу команды
- Насколько бюрократичны процессы
Обязательно надо поговорить с представителем от заказчика (для вас скорее всего это продакт или лид продактов).
В чем смысл этой встречи?
Хочется базово собрать информацию о планах, ожиданиях, о проблемах и векторе движения проекта. Тут вы можете задать вопросы по предметной области, попросить что-то показать (какое-то демо проекта), посмотреть бэклог на ближайшие фичи и планы.
Узнайте что беспокоит заказчика, в чем его боль - это также надо зафиксировать где-то у себя.
Эту встречу также лучше сделать регулярной с необходимой и удобной для вас периодичностью. Периодичность зависит от специфики и предметной области, по сути надо ориентироваться на скорость изменений и движения. Чем выше скорость - тем чаще встречи. В среднестатическом случае я бы ставил встречу раз в неделю.
После этого пункта у вас на руках должны быть:
- Ожидания от заказчика
- Базовое понимание вектора развития проекта
- Доступы до планов, задач
Основные метрики для вас:
- Насколько ваш продакт понимает предметную область
- Скорость наполнения бэклога, глубина проработки задач
- Аккуратность и понятность в описании задач
Важно понимать точки входа в соседние команды, если они влияют на вас.
Точно также назначьте встречи с представителями команд (тимлидами или тимлидами + продактами). Здесь цель - это познакомиться, узнать нет ли у них каких то договоренностей, ожиданий, возможно недавних инцидентов.
Почему это важно?
При любых проблемах во взаимодействиях проще и легче будет, если вы уже знакомы, нежели когда абсолютно незнакомый человек вам пишет в стрессе и негативе про инцидент.
После этого пункта у вас на руках должны быть:
- Точки входа в интеграции
- Дополонительная информация о возможных проблемах или потерянных договоренностях
Скорее всего вы придете на первый дейлик уже в первый (может второй) рабочий день, поэтому понимание как проходят дейлики начнет складываться сразу.
В начале я бы не советовал вмешиваться и один-два дейли митинга, лучше дать провести их 'по старому', понаблюдайте как он проходит, как ведут себя люди, какие тайминги, насколько хаотично он проходит. И только после этих наблюдений подхватывайте его в свои руки.
Почему лучше немного обождать (те самые один-два дейли)? Для того, чтобы понять как проходили дейли без вас и к чему привыкла команда.
Даже если вам что-то серьезно не нравится, в первые недели не стоит ничего менять. Так как резкие изменения могут негативно повлиять как на рабочий процесс, так и на внутренний климат.
Важно понимать, что если модель управления разработкой вам не знакома (например, вы не работали по спринтам) не бойтесь, у вас есть время на то, чтобы посмотреть как это происходит в текущей команде, а также чтобы восполнить этот пробел. При этом не стоит слишком сильно сейчас погружаться в чтение/изучение нюансов, вам необходимо ознакомиться с базовыми механизмами и этого будет достаточно.
Основные метрики для вас:
- Как долго и насколько полезно проходит митинг
- Присутствует ли хаос в решениях
- Как люди общаются между собой и насколько слаженна команда
Надо понять какие еще есть церемонии у команды (если они есть): это может быть ретро, командное время, предпланирование и так далее.
Попросите добавить вас на эти мероприятия, там также займите наблюдательную позицию.
В вашем случае, скорее всего, бэклог будет как продуктовый, так и для разработки. Чаще всего их разделяют на две изолированные части (например, ведут на разных досках), но иногда смешивают (такое редко случается).
Продуктовый бэклог вы должны были посмотреть с заказчиком (продактом), а вот бэклог разработки надо посмотреть и узнать кто за него ответственный, как происходит его наполнение. С этим человеком (или людьми) лучше назначить встречи для более глубокого погружения. Узнайте как происходит работа с техдолгом, сколько времени уделяется на это.
Основные метрики для вас:
- Наполненность бэклога и его аккуратность его ведения
- Аккуратность в описании задач
- Декомпозиция задач (epic/story/task)
- Работа с приоритетами
- Размер техдолга
Здесь основной совет - это в первое планирование минимально вмешиваться, наблюдать и анализировать как происходит планирование, насколько команда умеет работать с прогнозированием и сроками, сама оценивает свои силы.
Основные метрики для вас:
- Насколько гладко и прозрачно происходит планирование
- Работа со сроками
Параллельно с изучением процессов, начинайте знакомство с командой. Для этого поставьте one-to-one с каждым членом вашей команды.
Учтите, что это энерго и эмоционально затратный процесс, поэтому обычно не стоит ставить несколько встреч в день.
Советы и мысли по проведению one-to-one мы обсудим в другом месте, но пока, для начала, я бы мог посоветовать присмотреться к такому формату.
Перед встречей постарайтесь накидать мини-план, чтобы разговор не был совсем уж хаотичным.
Мини-план может иметь следующий вид:
-
Расскажите о себе и своем опыте
Начав первым обычно можно задать тон беседе, 'сломать' невидимый барьер стеснения (если он есть). Рассказать можно как об увлечениях, так и об опыте, что вам нравится в работе, а что - нет, про прошлые места труда.
Так вы покажете, что вы вполне такой же человек, что к вам можно обращаться за помощью и решением проблем.
-
Попросите рассказать о себе коллегу
Спросите как он пришел к текущей роли, чем занимался до текущего проекта и как долго он на находится на проекте текущем. Спросите об увлечениях, по сути, разговор будет примено о том же, что и в прошлом пункте.
Так вы узнаете о коллеге чуть больше, возможно, уже начнете понимать его мотивацию и характер, что его привлекает в работе и что наоборот демотивирует.
Плавно можно перейти к следующему пункту.
-
Поговорите о проекте
Спросите нравится ли ему проект, предметная область. Понимает ли он его ценность, как он видит его развитие, есть ли по его мнению у проекта проблемы или может быть есть что-то, что лично ему не нравится?
Так вы можете получить как информацию о мотивации сотрудника, так и насколько он хорошо разбирается в предметной области. Возможно получится вскрыть первые проблемы или раздражающие места, что впоследствии, при их устранении, добавит как открытости, так и авторитета.
-
Спросите остались ли какие-то вопросы
-
Запланируйте следующую встречу
Можно просто спросить человека как часто он бы хотел встречаться на one-to-one, можно самому предложить удобную периодичность.
Здесь важно не переборщить, так как встречаясь слишком часто будет сложно показать, что вы работаете над проблемами, многие новые моменты для обсуждения еще могут не созреть и встречи будут 'натянутыми' или пустыми. В свою очередь, если сделать встречи слишком редкими - это также будет не продуктивно.
Я бы советовал ставить встречи раз в 2-3 недели, не чаще.
Крайне важно НЕ забывать о проблемах: если просто послушаете и это отправится в /dev/null, то все доверие между вами и командой рухнет, не начавшись. Нет ничего более разрушительного, чем выслушать человека и не показать какой-то результат. Даже если не получилось исправить, то надо поднять снова эту тему и проговорить ее, возможно получится как-то купировать проблему другим способом.
Каждая такая встреча - это по сути документ, в который вы фиксируете настроение, мотивацию и проблемы человека.
После этого пункта у вас на руках должны быть:
- Выписанные боли и проблемы людей
- Впечатление о настроении и замотивированности
- Первое впечатление о человеке
Основные метрики для вас:
- Эмоциональный фон
- Готовность делиться проблемами (здесь нет такого, что чем больше тем - лучше или чем меньше - тем лучше. Здесь важно, что они есть)
Необходимо иметь четкое представление того, как осуществляется релиз и кто за это ответственный.
Также сразу попросите ссылки или доступы до мониторинга, дабы ознакомиться с теми метриками, что уже есть.
Следующим шагом будет попросить показать или ознакомиться через документацию с тем, как организован процесс обеспечения качества продукта (или попросту говоря - тестирование). Где хранятся тест-кейсы, процент тестового покрытия, бэклог по улучшению и техдолгу.
На данном этапе не требуется полного погружения и разбор вплоть до деталей. Вам важно собрать материалы для составления общего представления: во-первых, если возникнут вопросы на планировании или дейли, то вы уже хотя бы как-то, но ориентируетесь, во-вторых, покажете, что хотите разобраться во всех аспектах цикла разработки, в-третьих, проверите готовность команды идти вам на встречу и открытости (а то всякое бывает).
После этого пункта у вас на руках должны быть:
- Понимание процесса релиза
- Понимание процесса тестирования
- Понимание списка метрик, где смотреть их и так далее
Основные метрики для вас:
- Количество проблемных релизов
- Количество проблем после релиза и как о них узнают: от пользователей, от алертинга и мониторинга, дополнительным тестированием каким-то или инструментами.
- Как часто задачи возвращаются на доработку из тестирования
По каждому члену команды попробуйте выписать эмоциональный настрой. Для этого лучше заранее для каждого завести свой документ или карточку, где будете фиксировать one-to-one и свои мысли.
Постарайтесь сформулировать свои предположения о замотивированности человека, его погружению в проект и предметную область.
Возможно, получится сгруппировать проблемы, которые вам на one-to-one рассказали сотрудники. Их лучше выделить в отдельный блок, так как эти проблемы надо будет стараться решить или смягчить их негативное воздействие.
Также обязательно постарайтесь сгруппировать плюсы и положительные стороны, которые также вы должны были обсудить на one-to-one.
После этого пункта у вас на руках должны быть:
- Карточки или заметки по каждому члену команды
- Сгруппированные минусы и проблемы по проекту
- Сгруппированные плюсы и что нравится в проекте
- Предположения о настроении и мотивации в команде
Основные метрики для вас:
- Эмоциональный фон
- Количество общих проблем (сгруппированных) - то, что часто подсвечивали на one-to-one разные
- Ваш эмоциональный фон
Здесь нужно составить представление о соответствии сроков в плане (от продактов или руководителя) и задач в бэклоге, насколько понятно расписано и аккуратно составлено.
Проанализировать насколько удачно прошли прошлые рабочие итерации (возможно, спринты), насколько планы и ожидания сошлись в этих итерациях. Сейчас почти все таск-трекеры позволяют составить отчеты, посмотреть историчность действий - в общем, изучите (если еще нет) этот фунционал, он вам поможет.
Если были серьезные расхождения или 'сносы' задач, то лучше сразу спросить причину, а также узнать последствия (как у своего руководителя, так и у продуктовой команды).
На этом этапе важно попробовать сопоставить те цели, что вы фиксировали с вашим непосредственным руководителем, с реальным положением дел и проблемами, пожеланиями от сотрудников и заказчика (продуктовой команды).
Это, кстати, еще одна из причин, почему хорошо бы зафиксировать ожидания, а не оставить на словах - для упрощения синхронизации.
После этого пункта у вас на руках должны быть:
- Отчет или представление о прошлых итерациях
- Больше понимания о силе команды и умению планировать
- Больше понимания о проблемах и их корнях
Основные метрики для вас:
- Расхождения в сроках
- Плохо или не прозрачно составленная карта развития проекта
- Хаос в планах и задачах
Постарайтесь сгруппировать собранные материалы по приоритетам. Всегда что-то необходимо изучить в первую очередь, а что-то пригодится еще не скоро. Например, материалы по корпоративному обучению скорее всего можно отложить на потом, а информация по получению доступов вам понадобится уже в ближайшее время.
Не стесняйтесь попросить помощи как у руководителя, так и у ребят из вашей команды, чтобы вам помогли вникнуть или показали наглядно какие-то вещи. Возможно, ребята с команды также помогут с приоритетами материалов.
Основные метрики для вас:
- Насколько запутанны и сложны процессы
- Отзывается ли устройство управления и разработка у вас
Часто бывает, что вы выросли именно в новую роль в рамках одной команды. В таком случае все проще, так как большая часть всего, что надо собрать и понять вам уже знакома.
В этом случае первые шаги будут проще. Но!
Несмотря на то, что может казаться будто вы уже знакомы, но все же: никаких обещаний и коммитов первую неделю.
Перед вами:
-
Известный проект, но не все известные риски (которые были заложены)
Да, проект вам знаком, но не все риски по нему вы знаете. Для начала надо составить полную картину, а у вас, несмотря на то, что есть большая часть, она все же не до конца составлена.
-
Неизвестный руководитель
Неважно, знакомый у вас руководитель или нет, но вы в новой роли и в этой роли другая ответственность, другие требования и другая реакция на негативные события. Сначала узнайте и посмотрите на то, изменилось ли отношение, что от вас ждут и так далее.
-
Неизвестная команда
Кажется, что команда известна и знакома, но то может быть обманчивое впечатление.
Например, команда может быть не знакома по грейдовому составу и зарплатным ожиданиям. Возможно, вы не думали о мотивации ваших коллег (одно дело ругать в курилке начальников и другое - уже самому относится к ним).
-
Неизвестные процессы
Скорее всего во многих процессах вы либо уже разбираетесь, либо слышали. Но общей картины вы все еще можете не иметь, не забывайте, что сейчас вам придется знакомиться с разными областями, на которые вы ранее могли не обращать внимания или не фокусироваться (то же тестирование или эксплуатация).
Добавляются также и неизвестные ранее процессы по пересмотрам/повышениям, найму, премиям, у кого-то будет возможность управлять финансами (бюджет на команду).
-
Непонятный заказчик (для нас это скорее всего продуктовая команда)
Тут для вас просто открывается новая область взаимодействия с заказчиком, которая ранее вас касалось уже на этапе планирования разработки или даже декомпозированных задач. Теперь вы должны будете подключаться заранее, участвовать в декомпозиции, возможно отстаивать какие-то сроки, выторговывать (или объяснять) время на техдолг и так далее.
Как видите, все очень похоже, хоть и немного проще. Но не стоит обольщаться, так как при переходе в новую роль многие люди раскроются перед вами иначе, многие процессы и сама разработка будет выглядеть иначе.
Возвращаясь к аналогии:
Выглядит так, что РП, выходящий на новую работу, как пассажир, который пытается запрыгнуть в поезд на ходу, чтобы потом добраться до головы состава и начать им управлять. И чем быстрее летит поезд – тем сложнее в него запрыгнуть
Только здесь вы не запрыгиваете в поезд, а уже некоторое время едете пассажиром!
Почти все советы и действия будут идентичны прошлым, но более просты и более понятны ответы, меньше материалов и непонятного будет для вас.
Во-первых, помните, что тимлид - это в первую очередь про умение сплотить людей, достичь результата командной работой. А значит, надо уметь (или учиться) делегировать.
Делегирование - это в том числе и про доверие.
Ваши сотрудники не дети, они получают зарплату, подписывают контракты, платят по счетам квартиры, в общем, они умеют работать с обязательствами.
Тут важно отметить, что делегирование - это не просто 'назначить' тикет на исполнителя и все, считай готово. Здесь важно понимать кому вы делегируете задачу, что это за задача и так далее.
Согласитесь, что делегирование джуну критически важной задачи с сложной логикой - это не делегирование, это перекладывание ответственности.
Какие-то задачи вы можете делегировать частично, где-то больше вмешиваться или попросить вмешиваться/контролировать опытного коллегу, есть договоренность о том, как будет осуществлен контроль выполнения и когда человек сделает пару таких итераций над подобными задачами, то можно утверждать, что вы можете делегировать ему полностью еще одну такую задачу.
Здесь:
- Человек подготовлен к подобным задачам
- У него есть к кому обратиться
- Вы уверены в нем
Плохим примером делегирования может быть еще 'коллективная' ответственность: когда вы просто делегируете какую-то задачу всей команде и может быть кто-то ее сделает. Такое можно делать только с очень 'взрослыми' командами.
Микроменеджмент же - это в первую очередь то, что будет отнимать ваше время, во-вторую, то, что будет тормозить или расхолаживать вашу команду.
Микроменеджмент - это 'ручное' управление, а вы, как тимлид, стремитесь к автоматизации выполнения процессов, без вашего участия. Представьте, что вы едете на машине и не можете доверять ей, потому каждую минуту проверяете все приборы, метрики, делаете через каждые 100 метров остановку на проверку двигателя и колес. Мало того, что вы далеко так не доедете, так еще и удовольствие от такой езды - сомнительное.
Микроменеджмент имеет смысл только в серьезно запущенных случаях, где и команда, и проект в плачевном состоянии. Когда, грубо говоря, машина почти не едет и вы ее 'толкаете'.
При этом, делегировать и 'не микроменеджерить' - это не значит полностью отпустить все в свободное плавание. Вы же не смотрите 24/7 на метрики вашего продакшена? Вы аккуратно выставляете метрики и алертинг, реагируя уже либо на инциденты, либо явно понимая по статистике, что может быть проблема и вмешиваетесь заранее. Тут примерно то же самое, вы должны не спрашивать каждую минуту 'ну как там?', не расписывать до запятой что делать, а давать работать, но смотря при этом на метрики. Как человеческие (эмоциональный фон, вовлеченность, профессиональный рост и т.д.), так и технические (количество багов, размер техдолга, как часто задачи возвращаются с тестирования в разработку и т.д.).
Одна из основных ваших задач - это решение проблем и 'затыков' там, где они произошли и кого-то заблокировали.
И не всегда, а главное не все, проблемы должны решаться именно вами, вариантов решений их почти всегда несколько: ваша компетенция, призыв других людей (возможно даже из смежных команд), административный ресурс, поиск экспертизы в других местах и т.д.
Как пример:
На дейли один из сотрудников описывает проблему и просит помочь, так как время идет, а результата нет - затык.
Вы подключаетесь к проблеме, разбираетесь вместе (привлекаете свою экспертизу), в какой-то момент понимаете, что это уже выходит за рамки ответственности кодовой базы вашей команды, но понимаете к кому обратиться (у вас больше кругозор, вы понимаете какие интеграции есть, например, и к кому обратиться можно с той смежной команды).
В этотм момент вы уже вполне можете попробовать подключить к проблеме человека с той команды (подключение внешней экспертизы), собрать встречу. Иногда бывает такое, что можно подключить даже знакомого вам человека с соседнего, не связанного отдела, просто потому, что вы знаете или слышали, что они делали подобное.
И такими вот горизонтальными связями вы вполне можете решить проблему, порешав все. При этом и сотрудник ваш будет на подъеме (дело сдвинулось с мертвой точки), и прокопать удалось все (возможно, даже вскрыв проблемы у смежников), и времени потратили вы не так много на все.
И здесь важно для себя отметить: проблемы иногда можно решать не только своей экспертизой. И не бояться, не стесняться этим пользоваться.
Многие забывают это правило и зря.
Понятно, что есть коллективы, в которых публичная критика является абсолютно нормальной историей, но я не сторонник такого.
Во-первых, даже если текущая команда относится к этому нормально, то при появлении новых членов (как усиление, стажировка, просто рост команды) - вам придется работать с возросшими рисками. Пользы же эта ругань особой не дает.
Во-вторых, это всегда общение 'на грани', оно зависит от многих факторов, да даже от настроения. Сегодня все смеются, завтра такое заденет и будет конфликт.
В-третьих, в разработке хватает стресса и не следует его без необходимости увеличивать, пусть и потенциально.
Это не значит, что вы не можете на встречах быть недовольным или всегда улыбаться (и рукой махать), но выделять кого-то в негативном свете скорее всего не стоит. А вот хвалить - да.
При этом тут также нужна мера и аккуратность, если вы из раза в раз будете хвалить одного, а про других вообще забывать, то а) упадет вес у вашей похвалы, б) снова будет легкий конфликт (любимчика нашел!) и в) некоторые могут просто не стараться - все равно хвалят всегда Васю! Другие люди тоже стараются и если их старания не так заметны, как у другого - это вопрос уже к вам. Похвала - это тоже инструмент и пользоваться им надо с умом.
Регулярно старайтесь проводить ревизию процессов, ставьте себя на место исполнителя. Думайте над тем, насколько та или иная вещь будет полезна для вашей команды и проекта.
Например, у меня был случай, когда менеджер говорил: "Саша, ты вот после своих финтехов не достаточно гибкий. Смотри Agile Manifesto, там написано: Отношения важнее документации! Главное - это люди! А у нас никто не любит писать документацию! Нам она не нужна в таком количестве.". И был именно конфликт, в котором пришлось отстаивать время на документацию.
Однако, после увольнения пары сотрудников и необходимости прохождения оценки по ОУД-4 именно документация спасла нас.
Отличная статья про это Agile умер: из-за своего сострадания к product- и project-менеджерам (с) Фридрих Ницше
Был и обратный случай, когда я приходил в команду и спрашивал, а какая у нас есть документация по проекту? И мне говорили - только читать код. К чему это привело? К хаосу. На проектирование фич нужно было по несколько часов сидеть и собирать разных людей, так как по крупицам приходилось понимать как должно работать и ничего ли из старых процессов и систем не сломается.
Да, разные люди всегда что-то предлагают и изобретают в любой сфере, однако это может быть как полезно, так и вредно. Особенно, если это можно неоднозначно интерпретировать. Я не утверждаю, что необходимо досконально все документировать, но везде нужен баланс и надо думать не только 'как мы сейчас', а и 'как мы будем потом'.
Если какой-то инструмент не приносит вам результата, то задумайтесь - а нужен ли он вам?
Все эти оценки задач в попугаях, диаграммы сгорания задач, отчеты, спринты — всё это зачастую стандарт де-факто и есть везде, но это хорошо, пока это полезно. Если вы видите, что инструмент не приносит пользу, то попробуте посмотреть в сторону отказа от инструмента, даже если 'везде же так'.
Чаще рефлексируйте над своими действиями, для этого я рекомендую раз в некоторое время проводить ретро самому себе.
Выделяйте время на стратегическое планирование и проработку рисков.
Раз в месяц-другой (в зависимости от проекта и рисков) выделяйте время на то, чтобы остановиться и абстрагироваться от бесконечной беготни, посмотреть на проект со стороны (лучше сверху). Посмотреть на как текущие, так и потенциальные риски.
В рисках может быть какой-то техдолг, потенциальные боттл-неки, потеря компетенций с возможным уходом сотрудников, зависимости от вендора, да даже геополитическая обстановка - что угодно, что может негативно повлиять на проект.
В идеале это также фиксировать, но для себя.
Несмотря на то, что потеря сотрудника - это всегда отрицательная метрика, но увольнять надо тоже уметь и не бояться этого.
Увольнение - это в том числе инструмент, но более болезненный для команды и острый, это последний аргумент. Разумеется, лучше обойтись без крайностей, так как уход сотрудника зачастую негативно влияет вообще на всю команду.
Однако, бывают ситуации, когда это неизбежно.
Люди могут меняться, у них меняется мотивация, отношение к работе и даже к компании. Иногда не уволить во время - это потратить большое количество денег, времени и сил, а возможно и развалить команду.
Например, вы нанимаете разработчика, оцененного уровнем Senior, но в процессе работы все чаще возникают проблемы: отношение к коду, к тестам, документации на достаточно 'легком' уровне, может где-то присутствует элемент даже лени (да если что на тестировании баги найдут - вернут в работу). В таком случае, у вас может быть две развилки - это попрощаться с человеком или перестраивать его под ваши требования.
И тот, и другой вариант - это сложности, это потеря в деньгах, времени и прочем.
Обычно в таких случаях я выступаю за то, чтобы дать человеку обратную связь и шанс ее исправть (хотя я встречал компании, которые просто сразу увольняли). Но вот вы даете шанс раз, потом другой и человек не исправляется. В таком случае, на мой взгляд, не нужно тянуть и лучше начать процесс вывода из команды.
Почему? Почему не спасать до последнего?
Во-первых, проекту нужен результат. И пока вы 'спасаете' одного - страдают другие. Кто-то эти баги ищет и тратит на это свое время, копится негатив (можно было свой код и лучше тестировать!), кто-то может начать копировать код и подходы, кто-то банально может задуматься над вопросом 'Почему я (Миддл) исправляю код за сеньором?'.
Во-вторых, эта ситуация банально будет отнимать и ваше время, силы на контроль - а ваш ресурс тоже ценен. И если человек не воспринимает обратную связь или не готов меняться - возможно, вам просто не по пути?
В-третьих, иногда такие ситуации просто не совпадение ожиданий и культур. Человек во время таких ситуаций тоже стрессует и переживает, при этом команд много, компаний тоже не мало и в другой команде он, возможно, будет сразу более подходяще себя чувствовать.
Здесь, разумеется, надо держать руку на пульсе и чувствовать баланс: шанс всегда надо давать. И если итог - это расставание, то эту негативную метрику вы, как тимлид, обязаны обработать.
Оптимизм - это хорошо. Он может помочь придать мотивации, привнести новые идеи да и вообще руководитель чаще должен поддерживать, с оптимизмом смотреть в будущее и не вешать нос, ведь на то вы и лидер?
Но везде нужен баланс и если вы настолько оптимистично смотрите уже на все, что не замечаете ничего вокруг, то это уже уже начинает вредить делу. Иногда такой 'чрезмерный' оптимизм называют 'токсичным' (хоть я и не люблю слово 'токсичный').
Что я вкладываю в это?
Я лично вкладываю в 'токсичный оптимизм' ситуации, когда человек доносит до вас проблемы, но вы реагируете на эти проблемы в формате: 'Да мы справимся!' или 'Это вызов!'. При этом вы никак не помогаете, нчего не советуете, вы просто подбадриваете. И постоянная такая политика может вызвать у человека ощущение неуслышанности, что чтобы вам не сказали - вы просто подбодрите, скажете дежурное 'все молодцы, мы справимся', улыбнетесь, может по плечу похлопаете и на этом все.
Регулярное такое отношение - это путь к тому, что сотрудники перестанут вам доверять и делиться опасенями, потому что зачем? Чтобы снова вам сказали, что это вызов?
Второй вариант проявления - это вообще избегание критиков и навешване ярлыков на таких сотрудников. Из разряда 'Да это Саша, он вечно о чем-то переживает и жалуется'.
В моей практике у меня был руководитель, который вел себя подобным образом. Причем было проявление обоих вариантов, что привело к тому, что сначала я, потом еще пара лидов, а в конце уже и весь 'офицерский' состав перестал доверять и отзеркалил отношене в формате 'Да это же Ваня, что ты хотел от него?' или 'Ну как? Все также сказал, что все хорошо? Стабильно!'.
При этом я не говорю, что надо посыпать голову пеплом и видеть мир в серых тонах, но главное — научиться слушать и оказывать поддержку, а не улыбаться со словами 'Все будет хорошо' на проблему номер 1035012.
Еще одним советом может быть: следите за качеством документации.
Документация, как и другие вещи, должна приносить пользу - если открывая ее вы утопаете в воде, то надо что-то менять.
Хорошая документируемость - это повышение качество и ускорения онбординга, масштабируемость команды и в каком-то роде отказоустойчивость.
Зачастую отношение к ней достаточно легкомысленное, что является ошибкой.
Банальный совет, но на эти грабли наступают все: не забывайте о спорте и физических нагрузках. Стресс хорошо вымещается в спорте.
Не забывайте о технической составляющей и старайтесь писать код, не забрасывать хард-скиллы свои. Помните о том, что это одна из больших проблем тимлидства.
Обязательно ставьте в календаре фейк-встречу на обед!
При переходе в новую роль тимлида ваша жизнь изменится и достаточно стремительным образом.
Старайтесь соблюдать баланс и не терять здравый смысл, чаще думайте над инструментами и их полезностью, обдумывайте риски.
Не бойтесь действовать, но при этом помните, что людям нужно время для адаптации к изминениям, первая стадия принятия - это отрицание.
Помните, что ваша основная сила и ваш основной инструмент - это команда.
В конце хотелось бы закончить аналогией: в разработке программисты стараются сделать свои сервисы максимально отказоустойчивыми, чтобы даже при проблемах сервис был доступен, выдерживал потери нод и большую часть действий умел произвести автоматически или с минимальным воздействием извне. Никто не смотрит нон-стоп за сервисом, нажимая F5 и обновляя старницу, для детектирования проблем используются свои механизмы: метрики, алертинг, накопление статистики и стратегическое видение (например, перед 'черной пятницей' увеличивается количество нод сервисов).
В тимлидстве - ровно то же самое, но отказоустойчивой надо сделать команду и проект. Для этого точно также существует большое количество метрик и процессов. Точно также нужно стратегически мыслить и 'подкладывать соломку' в потенциально опасные места.
В качестве верхнеуровневой карты, по которой можно делать следующие шаги, можно использовать Teamlead Roadmap.