Тимлидство

Преимущества и недостатки

Среди значимых плюсов работы тимлида можно выделить такие:

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

Недостатков у должности лидера команды немного, но о них нужно знать, прежде чем соглашаться занять этот пост:

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

Обязанности Team Lead-а

Следит за соблюдением стандартов качества при разработке.
Именно задачей тимлида является следить за тем, чтобы команда писала код, соответствующий стандартам компании, и выдавала качественный продукт.

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

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

Несет ответственность за все проблемы или сложности в коллективе

Именно тимлид несет ответственность за все проблемы в коллективе разработчиков, которые могут оказать влияние на качество финального продукта.

Подает пример профессионализма и соблюдения лучших практик в кодинге.
Еще одной довольно важной ролью тимлида является подавать другим членам команды пример соблюдения установленных принципов и лучших правил в кодинге.

Понимает и может внедрять разные процессы и методологии в кодинге.
Также Team Lead должен иметь представление и уметь внедрять с пользой для проекта различные методологии в команде программистов, такие, например, как Scrum, Kanban, XP, Lean и так далее.

Распределяет ответственность.
Задачей тимлида является организация нагрузки таким образом, чтобы никто из членов команды не был единственным способным реализовать ту или иную часть проекта. Чтобы команда была эффективной и продолжала работать, даже если кого-то из специалистов нет на месте.

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

Следит за дисциплиной в команде.
Ну и конечно, тимлид обязан следить за дисциплиной: тем как члены команды взаимодействуют друг с другом, посещают встречи, относятся к работе и т.д.

Шаг номер 0. Зачем?

Итак, вам предложили стать тимлидом или вы сами захотели им стать. Что надо сделать в первую очередь? Хорошенько подумать, а надо ли оно вам.

Я искренне убежден, что в тимлиды стоит идти, если только вы хорошенько порефлексировали и поняли, что сердечко вам подсказывает: это ваш путь. 

Я общался с многими состоявшимися специалистами в этой профессии и все они говорят примерно одно и то же: 

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

• Кто-то — потому что хочет больше влиять на процессы и результат. Лично я отношу себя к данному лагерю. В этом плане тоже всегда есть чем заняться. Хромающие процессы по всем фронтам. От начала формирования бизнес задач и требований, до уже конечных результатов разработки.

Ложные цели, на которые не надо вестись:

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

• Больше власти. Да, повлиять вы можете на что-то больше, чем рядовой разработчик, но спрос с вас будет тоже ощутимо выше. При этом зачастую реальной власти у тимлидов особо и нет. Очень часто бюджеты, найм, увольнения и прочие реальные административные рычаги в других руках. В итоге какую команду вам дали, такую и тащите, да при этом чтобы результаты были феерические.

• Повышение уровня ЧСВ. Ничего особо крутого в этой должности нет. Это просто очередная должность чуть выше рядовой. Как ефрейтор или сержант в армии. Вроде лычка есть, но хвалиться особо нечем, и вокруг куча таких же.

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

Где-то нужен полуменеджер-полуразработчик, где-то техлид/архитектор, где-то пипл менеджер и т.д

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

Советую заранее узнать, что же именно от вас требуется. 

Спойлер: 80-90% вакансий на российском рынке — полуменеджер-полуразработчик. Формально говорится, что 60-70% времени надо писать код, а 30-40% менеджерить. При небольших размерах команды и порядочном работодателе это может неплохо работать. Лично у меня где-то сейчас 40 на 60 получается делить код с менеджементом. Хотя я чувствую, как при разрастании команды код отодвигается от меня всё дальше и дальше. 

Однако при недобросовестном или просто непонимающем работодателе, от вас будут ожидать примерно 100% менеджмента и 100% написания кода. Постарайтесь узнать об этом как можно раньше, чтобы СБЕЖАТЬ.

Что надо понять

Вам платят деньги не за то, что вы пишите код

Умение писать код и понимать его — по-прежнему важно для TL, он оценивает и продумывает архитектуру и т.д. Но у вас всего две руки, а у команды их явно больше

Ваша основная задача — создать такие условия, чтобы команда была наиболее эффективна. Программист должен писать код, а всё остальное — ваши заботы.

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

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

Ваши главные показатели эффективности — качество всего проекта и время разработки. Здесь, пожалуй, главную роль играют ваши навыки коммуникабельности. Что-то надо делать качественно и долго, а иной раз целесообразнее быстрое решение. Сложность состоит в том, что вы должны донести это до программиста и убедить его сделать, как нужно в этот момент. А не через 2 дня обнаружить, что он только на середине, а готовое решение нужно сейчас.

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

Вам нужно нанимать людей. Хорошо, если у вас есть отдел кадров, который умеет нанимать IT-специалистов. Если нет — у вас появились дополнительные обязанности. Учитесь составлять вакансии, отбирать специалистов, проводить собеседования, увольнять. И если у вас не стартап с космическими инвестициями, готовьтесь находить людей в бюджете ниже рынка. Возможно даже придётся самому обзванивать кандидатов.

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

Вы не можете выбирать технологии, какие хотите. Обычный разработчик может предлагать новые технологии, а задача TL — поддерживать баланс стека технологий проекта. Помните, стабильность проекта и процесса разработки — ваша обязанность. Что делать, если из команды уходит единственный хранитель какой-то особенной технологии? Кроме того, использование каждой технологии должно быть обосновано. Я периодически наблюдал как полтора земплекопа в крохотном проекте всё пилят на микросервисах. Они не догадывались, что компания не была готова к этому. Конечно, ни к чему хорошему такие эксперименты не приводили.

Вы палочка-выручалочка в любом аврале. В любых нештатных ситуациях вы не можете просто рявкнуть на команду: «Всё должно быть сделано!» и уйти. Сидеть до ночи должны именно вы. Нельзя бросать разработчиков с проблемой один на один. Это плохой пример для них, ответственность в таких случаях лежит именно на TL. Но и держать всю команду на аварийных работах тоже нет смысла. Я сам несколько раз возвращался домой в 5 утра, а на следующий день приезжал к 9 утра на совещание. Вообще, ваша работа в том, чтобы до такого не доводить.

Вы должны уметь подменять любого члена команды. Если кто-то заболел, ушёл в отпуск или уволился, и процесс разработки остановился, вся ответственность ложится на вас. Будьте готовы к этому всегда.

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

Растить замену ещё полезнее

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

На мой взгляд, полезная мысль. Если размеры команды и желания людей позволяют, то лучше растить сразу 2 или 3, тогда лучше начнёшь замечать свои собственные проблемы, на которые раньше не обращал внимания

Для удалённой работы это очень важно, потому что получить фидбек для самого себя намного сложнее, чем при работе всем вместе, ведь мой начальник тоже сидит за 1000км от меня и тоже сталкивается с похожими проблемами, когда хочет поговорить со мной

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

В каком вузе Нижнего Новгорода можно получить профессию Тимлида, технического лидера

• от 65 000 / год
  Информация о стоимости года обучения предоставлена за 2021 год

  Нижний НовгородГосударственный

  экономика; программная инженерия; юриспруденция и еще 7 направлений

  Ср. балл ЕГЭ бюджет 2020от 81.8 бал.бюджет

  Ср. балл ЕГЭ платно 2020от 55.3 бал.платно

  Бюджетных мест 2021 429 мест бюджет

  Платных мест 2021 480 мест платно

  Средний балл ЕГЭ на бюджет в 2020 году от 81.8

  Средний балл ЕГЭ на платные места в 2020 году от 55.3

  Количество бюджетных мест в 2021 году 429

  Количество платных мест в 2021 году 480

  Что такое средний проходной балл

  Бакалавриат, специалитетМагистратура

  5 подразделений

• от 40 000 / год
  Информация о стоимости года обучения предоставлена за 2021 год

  Нижний НовгородГосударственный

  прикладная информатика; фундаментальная информатика и информационные технологии; программная инженерия и еще 52 направления

  Ср. балл ЕГЭ бюджет 2020от 38.8 бал.бюджет

  Ср. балл ЕГЭ платно 2020от 39.3 бал.платно

  Бюджетных мест 2021 2 033 места бюджет

  Платных мест 2021 8 660 мест платно

  Средний балл ЕГЭ на бюджет в 2020 году от 38.8

  Средний балл ЕГЭ на платные места в 2020 году от 39.3

  Количество бюджетных мест в 2021 году 2 033

  Количество платных мест в 2021 году 8 660

  Что такое средний проходной балл

  Бакалавриат, специалитетМагистратура

  13 подразделений

• от 46 900 / год
  Информация о стоимости года обучения предоставлена за 2021 год

  Нижний НовгородГосударственный

  электроэнергетика и электротехника; информатика и вычислительная техника; информационные системы и технологии и еще 40 направлений

  Ср. балл ЕГЭ бюджет 2020от 46.3 бал.бюджет

  Ср. балл ЕГЭ платно 2020от 36.7 бал.платно

  Бюджетных мест 2021 1 592 место бюджет

  Платных мест 2021 1 420 место платно

  Средний балл ЕГЭ на бюджет в 2020 году от 46.3

  Средний балл ЕГЭ на платные места в 2020 году от 36.7

  Количество бюджетных мест в 2021 году 1 592

  Количество платных мест в 2021 году 1 420

  Что такое средний проходной балл

  Бакалавриат, специалитет

  9 подразделений

Проф.ориентация

Выбрать обучение

Моя ли это профессия

Описание должности

Кто такой тимлид и чем он занимается? Само название имеет английское происхождение (team leader – «лидер команды»). Этот человек – координатор команды разработчиков. Он определяет сферы ответственности своим подчиненным и контролирует их работу, организовывает обучение и обеспечивает возможности профессионального роста для специалистов, а также ведет переговоры с заказчиком.

Тимлид – не профессия, а должность. Лидером команды, как правило, становится программист-разработчик. Соответственно, программист – это профессия, а тимлидер – занимаемая им должность.

Кроме непосредственно профессиональных, на тимлида возложены функции менеджера:

• заключать договоры с заказчиками;
• вести документацию, касающуюся проекта;
• оценивать объемы и планировать сроки работы;
• рассчитывать бюджет;
• определять приоритеты задач и разбивать их на более мелкие задания;
• грамотно делегировать полномочия внутри команды, чтобы достичь максимума продуктивности;
• создавать и выпускать релизы;
• быть продюсером проекта (контролировать разработку, дизайн и маркетинг);
• давать каждому члену команды возможность развития.

Ключевой момент в работе тимлида – мощная мотивация команды и умение вдохновлять ее на успех. Разумеется делать это нужно личным примером.

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

Технические задачи тимлида:

• трансформировать абстрактные бизнес-задачи в конкретные задания, понятные для разработчиков;
• следить за технологией и качеством выполнения проекта;
• рецензировать код;
• разрабатывать, тестировать и создавать дизайн проекта;
• вовремя замечать проблемы, выяснять их происхождение и находить оптимальные решения.

Team leader может устроиться на работу в крупную брокерскую или финансовую компанию, бизнес-корпорацию, банк либо в IT-фирму. Интересно, что официальная должность тимлида есть не во всех айти-компаниях. И все же в любой команде должен быть главный. Занять этот пост обычно предлагают самому опытному разработчику или руководителю отдела, в небольшом стартапе – техническому директору или начальнику SEO-отдела. В крупной компании разработчики могут сформировать сразу несколько команд, каждая из которых получит своего формального тимлидера. В таком случае для руководства лидерами команд учреждается дополнительная должность – тимлид тимлидов.

Где научиться специальности?

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

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

Курс «TeamLead» от SkillBox

SkillBox – онлайн-университет современных профессий в области маркетинга, дизайна, программирования и менеджмента. Участник проекта Skolkovo, обладатель премии Рунета за 2018 и 2021 годы.

• Чему научитесь: освоите навыки управления командой разработчиков, принципы подбора персонала; изучите методологии Agile, Scrum и Kanban; сможете эффективно решать бизнес-задачи; узнаете системы мотивации работников.
• Формат обучения: практические видеоуроки, самостоятельные домашние задания с проверкой преподавателем и исправлением ошибок, защита дипломного проекта; всего 82 урока, сгруппированные в 28 тематических модулей.
• Преимущества: доступ к материалам курса навсегда с учетом всех обновлений; преподаватели-практики; разбор реальных кейсов; диплом о прохождении подготовки; отсрочка платежа до 12 месяцев.
• Длительность курса: 6 месяцев.
• Кому подойдет: начинающим специалистам, middle и senior-программистам.
• Стоимость: около 39 000 рублей, возможна рассрочка по 6 900 рублей в месяц.

Посмотреть курс

Интенсив «Тимлид разработки» от SkillFactory

SkillFactory – онлайн-школа по работе с данными, лидер в сегменте Data Scientist, участник проекта Skolkovo. На рынке онлайн-образования с 2021 года.

• Чему научитесь: прокачивать навыки эффективного управления командой разработчиков; настраивать командные процессы; грамотно разрешать конфликтные ситуации; превращать бизнес-задачи в технические задания; планировать архитектуру будущего проекта.
• Формат обучения: вебинары, Q&A сессии, индивидуальные и групповые практикумы.
• Преимущества: формирование команды в процессе обучения; ментор на протяжении всего цикла обучения; работа в компактных группах.
• Длительность курса: 4 месяца.
• Кому подойдет: middle и senior-разработчикам.
• Стоимость: около 95 000 рублей за весь курс, или в рассрочку по 7 91 рублей на 12 месяцев без процентов.

Посмотреть курс

3. Онлайн-интенсив «Бизнес и управление» от Нетологии

Нетология – одна из лучших образовательных онлайн-платформ в России с 2011 года, участник проекта Skolkovo. Является обладателем премии Рунета в области онлайн-образования на протяжении трех лет, с 2021 по 2021 годы.

• Чему научитесь: финансовому моделированию; проверять гипотезы и определять направление развития проекта; управлять конфликтами; собирать команду; использовать подход бережливого производства; приоритизировать задачи и контролировать их исполнение.
• Формат обучения: 14 тематических мини-интенсивов, каждый из которых состоит из 8 видео по 10-20 минут, 2-х промежуточных и одного итогового теста.
• Преимущества: практика и тренировка; помощь в подборе мини-интенсива.
• Длительность курса: в свободном графике, в зависимости от выбора интенсива.
• Кому подойдет: начинающим специалистам.
• Стоимость: каждый модуль стоит около 15 000 рублей.

Посмотреть курс

Предыстория. Как и где я вообще стал тимлидом

Это первая фирма, куда я пришёл сразу тимлидом. Для меня это был качественный скачок в плане карьерного роста. На прошлую работу (1,5 года) я пришёл миддлом и вырос там до сеньора. Но градации разработчиков слишком субъективны и часто зависят лишь от компании, где они работают. Какое-то время я много изучал вопрос оценки программистов и по сути всё свелось к тому, что если “взяли миддлом/сеньором/старшим — стал миддлом/сеньором/старшим”. Когда я начал искать работу, мне бы хватило и позиции сеньора (и её я искал), но предложение тимлидства меня перекупило и немного польстило.

Собственно при самом поиске вакансий уже на второй день меня сманили в столичную фирму, которая занимается разработкой сайтов на Битриксе (так что дальше всё происходит на фоне разработке сайтов на Битриксе). Я же наоборот давно мечтал уйти от Битрикса, но возможность самореализоваться в новом качестве и хорошая зарплата не оставили мне шансов отказаться.

Забавный факт: единственным условием при приёме меня на работе было то, что я могу сам выбирать технологических стек, но нельзя ни в коем случае отказываться от Битрикса, если на нём настаивает клиент.

На новом месте

На новом месте оказался очень хороший начальник-технарь, плохой менеджер, джун, миддл и несколько действительно больших проектов на Битриксе. Довольно странная ситуация и я до сих пор не понимаю, как она сложилась и не схлопнулась сразу. Но возможно меня и пригласили как раз для того, чтобы всё наладить.

В первые же дни в глаза бросилось множество “детских” проблем:

• информация по проектам хранилась в головах у одного-двух человек и нигде более. Инструкций и документации тоже никаких не было, и чтобы узнать как работает тот или иной функционал, нужно было пытать того, кто его делал, если вообще мы его создавали
• каких-либо налаженных систем и процессов считай не было, всё делалось “как-то”, “по привычке”. Отсюда соответственно суета, неразбериха, срывы сроков, напряжение
• задачи ставились считай на словах. В трекерах были лишь названия задач, просто чтобы можно было залогировать время куда-то (нужно было набирать 40 часов в неделю)
• сама разработка тоже была не ахти:
  • где-то что-то разрабатывалось даже вне гита
  • где-то программисты по очереди правили файлы на одном сервере
  • где-то были тестовые площадки, а где-то их не было (но в любом случае они не сильно помогали)
  • вдобавок везде было очень, очень много говнокода. Предвосхищая комментарии, сам Битрикс тут, к сожалению, не причём
• Всё общение происходило в скайпе. Но к нему у меня просто личная неприязнь

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

Они правда ещё не считались, но из-за Парето, это пока и не важно

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

Теперь переходим непосредственно к статье и решению проблем. Первым делом в новой компании нужно было как-то сориентироваться.

Предыстория побед и поражений

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

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

Что делать? Добавлять новых героев в свой эпос, интересоваться не только решением задач, но и тем, как и какими эмоциями эти задачи были решены.

Варианты будущего роста

Раз у вас уже возник вопрос «а что дальше?» в бытность разработчиком, то он у вас возникнет и на этапе team lead. А здесь всё также можно следовать разобранной ранее схеме. Вопрос лишь в том, стоит ли развиваться как менеджер или всё-таки уйти еще глубже в сторону разработки в
роли архитектора. Попробуйте, и вы сможете четко ответить на этот вопрос. Но как я говорил ранее, не задавайте его себе в первые несколько месяцев. Потому что находясь вне привычной зоны комфорта человек по умолчанию склонен негативно реагировать на любые стимулы. Разберитесь хотя бы в базовых вещах, потом принимайте решение.

Общее в задачах тимлида и психолога

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

А в деятельности тимлида важно делегирование, разделение работы между членами команды. По сути и то, и другое – о том, как не брать на себя лишнего. 

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

А тимлид работает с вовлечённостью команды, с корпоративной культурой и выстраивает такие отношения, чтобы сотрудник мог с нами общаться открыто, мог делиться тем, что для него важно и интересно. 

Но важно и психологу, и тимлиду помнить про дистанцию. Если психолог на консультации начинает сливаться со своим клиентом, начинает строить дружбу или романтические отношения, то терапевтическая работа разрушается

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

Обесценивание и магия. Я называю это «творить магию». Бывает так: команда считает, что тимлид ничего не делает, сидит в своём компьютере, и всё происходит само по себе, без его участия. Творится магия. Такие комментарии можно найти и здесь, на Хабре, и в Фейсбуке. А то, что команда при этом эффективна, и задачи решаются в срок, команда об этом может забывать, и тимлиды, к сожалению, тоже порой об этом забывают. Из-за такой жёсткой оценки со стороны команды у тимлида может стираться самоощущение, что вообще-то это случилось благодаря грамотной постановке задач. То же самое можно услышать порой о работе психолога: «Как так, Анастасия, вы всего 3 вопросы мне задали, и мы до этой темы добрались?» 

Безопасность. И тимлиду, и психологу необходимо выстроить диалог, в котором человек может раскрываться, чувствовать себя безопасно, может двигаться вперёд. То есть задача тимлида – построить атмосферу в команде такую, чтобы сотрудник сам к нему пришёл. При этом сотрудник имеет право вам ничего не рассказывать, и вам нельзя нарушать его границы, копать на ту глубину, к которой он не готов. Помнить, что вас не касается то, что вам не сказали. Что каждый отвечает только за собственные чувства. 

Риск выгорания. У тех, кто работает с людьми, риск выгорания выше

И важно разобраться в причинах, почему мы идём в эти профессии. Может, всех спасти? Всех направить? Если у нас есть такая цель, и она не достигается, выгорание неизбежно. 

Зачем нужны тимлиды

Пред­ставь­те такую ситу­а­цию: в ком­па­нию про­грам­ми­стов при­хо­дит заказ­чик и про­сит раз­ра­бо­тать мобиль­ное при­ло­же­ние. Сеньор начи­на­ет пла­ни­ро­вать архи­тек­ту­ру, мид­лы пишут код, а джу­ни­о­ры при­кру­чи­ва­ют кноп­ки в интер­фей­сах.

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

Тим­ли­ды нуж­ны как раз для того, что­бы таких ситу­а­ций не воз­ни­ка­ло. Для это­го тим­лид дела­ет свою руко­во­ди­тель­скую рабо­ту:

• встре­ча­ет­ся с заказ­чи­ком и обсуж­да­ет все дета­ли про­ек­та;
• сам оце­ни­ва­ет ход и сро­ки каж­до­го эта­па работ;
• пони­ма­ет, что нуж­но сде­лать в первую оче­редь, а от чего пока мож­но отка­зать­ся;
• раз­би­ва­ет зада­чи на эта­пы, а эта­пы — на сприн­ты (про них мы рас­ска­жем подроб­нее в отдель­ной ста­тье);
• рас­пре­де­ля­ет нагруз­ку сре­ди про­грам­ми­стов;
• смот­рит за тем, как про­дви­га­ет­ся зада­ча;
• оце­ни­ва­ет код и даёт реко­мен­да­ции;
• что­бы не терять ква­ли­фи­ка­цию — тоже пишет часть кода, если у него есть на это вре­мя, но это необя­за­тель­но;
• согла­су­ет с заказ­чи­ком выпол­нен­ную рабо­ту;
• рабо­та­ет дипло­ма­том и сле­дит за настро­е­ни­ем в кол­лек­ти­ве.

Вытаскивание информации из голов сотрудников

Когда я пришёл, я совсем ничего не знал ни о проектах, ни о клиентах, и эта информация не храниласьнигде в текстовом виде. Поэтому первым делом, я начал вытаскивать информацию из голов коллег в тексты.

По сути в фирме, занимающееся разработкой, есть 2 больших подмножества важных и/или полезных текстов:

1. инструкции, регламенты, статьи, описания функционала, пользовательские истории,…
2. Задачи с их названием, описанием, комментариями, логами времени, подписи к коммитам, комментарии в коде, автотесты,…

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

Так же повезло, что в то же время фирма начала активно переезжать на scrum (просто совпадение), менялось рабочее ПО (тоже совпадение), соответственно с нуля создавались бизнес-процессы. И у меня почему-то изначально был большой авторитет в глазах коллег. Поэтому я просто начал писать регламенты самостоятельно (в рамках компетенции) и перестраивать на них ребят, то есть по сути просто диктовать правила и быть примером их исполнения.

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

На момент начала моей работы менеджер ставила задачи ужасно. Пример: название задачи — “Исправить баг на сайте” и всё: ни какого-либо описания, ни скринов, только название и отсылка к проекту

Были конечно попытки донести принципы SMART и важность описания задач до менеджера, но все начинания разбивались об “У меня нет времени расписывать задачи”

Одно время я пытался перенять часть ответственности за постановку задач, но тут иронично, что у меня на это тоже не хватало времени, так как практически всё время я писал код.

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