Привет! Меня зовут Артем Валевич, последние три года я тимлид в AGIMA. За это время я составил для себя что-то вроде тимлидского кодекса — список небольших правил и принципов, которые помогают мне в работе. Правила эти я вывел разными способами: что-то установил опытным путем, что-то подсказали старшие коллеги, что-то вычитал в статьях и книгах.

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

1. Микроменеджмент: «Я всё сделаю сам»

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

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

Всё почему? Потому что микроменеджмент — это про отсутствие доверия в команде.

Антипример 1. Разработчик закончил разрабатывать фичу и отдал ее на ревью. Тимлид видит недочет и сам исправляет код. При этом он не поясняет, почему он решил его исправить, что было не так. Как видит тимлид: «Проще самому». Как видит разраб: «Я сделал плохо». Если такое повторяется из раза в раз, то рано или поздно приведет к тотальной демотивации.

Антипример 2. Тимлид требует ежедневные отчеты, они должны быть подробными, лучше текстом, лучше со всеми деталями, а еще лучше созвониться, давайте утром, а потом еще вечером, два раза… В общем, вы поняли. В итоге разработчики тратят больше времени на бюрократию, а не на код. Очевидно, что это безумно раздражает, поскольку как бы говорит: «Если я не буду следить за тобой, ты будешь филонить».

Исправить эту ошибку одновременно легко и сложно. Легко — потому что, по сути, не требует особых усилий, а сложно — потому что менять нужно в первую очередь себя (а это всегда нелегко):

• научиться доверять команде и позволить ей принимать решения;

• давать советы и рекомендации к работе, а не исправлять самому;

• фокусироваться на результате, а не на процессе;

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

2. Отсутствие четких задач: «Разберутся по ходу»

Это база. Постановка задач — ответственное дело, подходить к нему спустя рукава просто нельзя. Но иногда эта прописная истина вылетает из головы: дедлайны грозно висят над головой, заказчик пингует каждые полчаса, впереди важный-преважный созвон, а тут еще эта задача. У кого в такой ситуации не возникнет желания взять и передать ее без дополнительных пояснений?

Да, такое случается, но надо приучить раз и навсегда себя и свою команду: нет четкого технического задания — задачу можно не делать. В противном случае ее, скорее всего, придется переделывать. Тимлид получит не то, чего ожидал. Разработчик получит плохой фидбек. Заказчик и вовсе пока не получит ничего, придется подождать. 

Антипример. Техзадание: «Сделать авторизацию на сайте». Разработчик пошел и реализовал OAuth. Формально задача как бы выполнена, но есть одно «но»: заказчику нужна была обычная форма логина. Итог — потерянное время, потраченные деньги. И срочная переработка всей задачи.

Инструменты, которые помогают ставить четкие задачи, давно известны:

• ставить задачу по SMART;

• добавлять примеры, кейсы, ожидаемый результат и критерии оценки (DoD);

• каждый раз проверять, насколько хорошо исполнитель понял задачу — переспрашивать и уточнять.

3. Неумение делегировать: «Быстрее сделаю сам»

«Я дольше буду объяснять, чем делать», «Сам сделаю лучше, чем кто-то другой», «Кто, если не я» — всё это ловушка. В нее попадают почти все начинающие тимлиды. Чем быстрее вы осознаете проблему и начнете с ней бороться, тем лучше для вас, для команды и для бизнеса. Причины примерно те же, что и в первом пункте. Когда тимлид выполняет всю работу собственными руками, он перестает управлять проектом.

Антипример. На проекте нужно настроить CI/CD на проекте. Тимлид долго размышляет, кому передать задачу, а потом просто берет и делает ее сам. Принимает такое решение, потому что не хочет всё подробно расписывать, объяснять, разжевывать (см. пункт 2). Итог: на время разработки тимлид перестал выполнять свои основные обязанности по управлению проектом, проект буксует, а в команде никто не получил новые компетенции.

В этом случае способы решения понятны:

• делегировать всё, что можно делегировать;

• описывать не решение, а ожидаемый результат

• развивать не только себя, но и команду.

Без делегирования тимлид становится бутылочным горлышком процесса. К тому же он не обязан быть самым сильным техническим специалистом в команде. И точно не должен замыкать всё на себе.

4. Игнорирование технического долга: «Фичи важнее»

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

Как с этим бороться:

• наладить процесс по работе с техдолгом;

• если техдолг можно закрыть сразу — нужно закрывать его сразу;

• объяснить бизнесу важность работы с техдолгом.

5. Отсутствие обратной связи: «Разработчик сам разберется»

Одна из важных задач тимлида — обратная связь для команды: честная, объективная, полезная. Если что-то идет не так — просить исправить, если всё круто — хвалить. Когда человек не получает фидбэк, он как бы идет на ощупь: «Правильно ли я делаю? Довольны ли мной?» Так уж повелось, что любое наше действие требует какой-то реакции. Нет реакции — нет мотивации.

Вот несколько простых советов:

• проводить регулярные встречи 1–2–1;

• хвалить даже за небольшие заслуги;

• не ругать и поменьше критиковать;

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

6. Нерациональное распределение задач: «Кому-то всё, кому-то ничего»

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

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

Как исправлять:

• визуализировать нагрузку специалистов;

• давать задачи по уровню, но с возможностью роста;

• доверять всем членам команды и давать задачи «на вырост».

7. Игнорирование командной культуры: «Важен только код»

Главный элемент любого бизнеса — люди, а людям иногда хочется посмеяться или отдохнуть. Намного приятнее работать в дружной и принимающей команде, где люди помогут, поймут, поддержат. А значит, в коллективе нужно создавать атмосферу доверия и взаимопонимания. 

Антипример. Специалисты стесняются задавать вопросы или озвучивать идеи, потому что боятся выглядеть глупо. Это вызывает ошибки, недопонимания, в целом тяжелое чувство, и работа такого чувства вызывать в идеале не должна.

Как исправлять:

• регулярно проводить командные ретро и встречи;

• поддерживать культуру помощи и взаимоуважения;

• давать пространство для неформального общения;

• создавать неформальные традиции в общении.

Зачем всё это

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

Поэтому считаю важным делиться опытом, инструментами и выводами. В этой статье вы увидели мой универсальный набор тимлида: то, без чего не обойтись. Теперь расскажите, какой у вас. Каких правил придерживаетесь? С какими согласны, а с какими не очень? Какие инструменты применяете?

Больше о работе тимлида я и мои коллеги рассказываем в телеграме.

Что еще почитать

• Почему мы охотно нанимаем джунов и советуем всем делать то же самое

• Как не сжечь команду дотла, или Почему Work-life balance — задача руководителя

• Стоит ли идти в тимлиды? История о том, как меня повысили и что я теперь об этом думаю