«Жизнь на грани»: как я работала на позиции тимлида

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

Это рассказ исключительно из личного опыта человека, которые не любит читать толстые и умные книжки. Только ИМХО, только то, что работало в моем опыте. А он был немалый, уже 10+ лет.

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

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

Итак:

1. Целеустремленность. Вот по моему мнению это одно из главных качеств лида. Вижу цель не вижу препятствий, почему да, а не почему нет. Вот правда, такие люди — это двигатель любого дела. Стадия принятия у человека должна сокращаться до секунд.
2. Стрессоустойчивость. Прод упал по неизвестной причине, задач внезапно стало больше, чем рук, план накрылся медным тазом, так как пришел заказчик со своими супер важными хотелками, багов навалило в разы больше, чем было вчера вечером, сделай то не знаю как завтра. То, с чем сталкивается лид каждый день, а может быть и час. Как он будет это переносить определит возможность достижения цели проекта. Запомните вы тут мама или папа, вы взрослый и ответственность за решение всех проблем на вас и только на вас. Поэтому не стрессуем, а решаем! Покажете стресс команде, получите 10 человек, которые не верят в победу.
3. Техническая экспертиза. И да, я сознательно не поставила на первое место. Вот 1000 раз видела успех лида, который не совсем прям глубоко знает технику (они всегда находили кого то в помощь в этом вопросе) и ни разу не видела выдающихся результатов при отсутствии первых 2х пунктов. Хотя лично я люблю работать с тем, что хорошо понимаю. И конечно это дает большой прирост и в оценке качества и скорости принятия решений, и возможности говорить о сроках плохо формализованных задач.
4. Справедливость. Вы работаете людьми, вы контролируете и оцениваете их работу. От вашего мнения зависит их зарплата. Вы будете когда то жестким, не всегда вас будут любить. И тем не менее, чтобы вы имели безоговорочную поддержку своей команды, вам необходимо видеть и слышать всех и честно выделять как успехи, так и ошибки каждого участника команды. Иначе рано или поздно вы точно окажетесь без своей команды и никуда не придете.

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

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

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

Вы обеспечиваете их временем (может быть даже сражаясь за него с ПМом на ринге), возможностями (изыскивая доступа, информацию, переговорами со смежными командами), являетесь щитом, который принимает на себя негатив со стороны заказчика, руководителя проектов и кого бы то ни было. Уважайте коллег, с которыми работаете, да вы — тягач, но механизм — это КОМАНДА. Это люди, которые делают мечты об успехе реальностью.

Плохая команда = плохой результат. Есть такой распространенный момент, когда мы стесняемся отказываться от услуг участников команды, так как мы тут все коллеги из одной компании.

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

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

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

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

1. Всегда составляй план. На день, на неделю, на месяц. Если земля уходит из под ног, под прессингом параллельных задач в секунду, смотри в план и отмечай все что сделано. Так ты увидишь, почему не достиг всего что запланировано и что не сидел без дела. Это очень сильно мотивирует.
2. Всегда держи список ошибок в легкодоступном месте. Я использую фильтр в джире. Первичный анализ всегда провожу сама, таким образом часть могу закрыть сразу, часть отдать своевременно другой команде (например, если ошибка не бэк), а также понимаю точный скоуп. Просматриваю список 1 раз в час
3. Не допускай разрастания ошибок. Только дашь ошибкам расти и уже трудно вернуться назад к приличным числам.
4. Один сильный разработчик должен вот-вот освободиться. Очень часто на горящих проектах возникают ситуации, когда непредвиденный функционал необходимо сделать срочно. Часто функционал сложный. И вот у вас всегда должна быть возможность подключить быстро сильного разработчика.
5. Один разработчик сидит плотно на ошибках.
6. Старайся не допускать чтобы в ту или иную часть функционала был погружен только один участник команды.
7. Смотри все мержи, даже если это немного тормозит процесс. Так ты будешь в курсе кода всего проекта, сможете оказать консалтинг по любому вопросу новым разработчикам, просто людям не знакомым с той или иной частью проекта, участвовать адекватно во встречах с заказчиком и быть в курсе всей разработки.
8. Поддерживай свою экспертизу. Без этого очень трудно вести за собой людей. Если вы не соображаете в текущем процессе, технологиях и не можете ответить на вопросы, ваш авторитет будет не очень высок.
9. Понятно, что для успешной работы нужно выполнять и всем понятные вещи, такие как качество кода, использование паттернов, современного стека и прочего. Эти пункты мне показались не тривиальными поэтому отдельно указала их.

Главная ошибка лида это невыполнение списка из предыдущего раздела, однако есть и другие ошибки, которые пагубно влияли на результат.

1. Не доводить до конца правильные начинания, полагаясь, что это сделает кто то другой. Речь о таких вещах как изменения в процессах команды проекта, поиск новых подходов и прочего, доведение задач до конца (часто это означало до прода)
2. Утверждение, что на проекте полный треш не принимать на свой счет. Вы тоже немаловажная часть проекта и у проекта проблемы, то вы тоже ОБЯЗАНЫ их решать.
3. Брать в команду временных разработчиков. Вот редко я видела хорошие результаты в таком подходе.
4. Пускать на самотек выполнение дополнительных задач. Все доработки должны быть в рамках системы учета задач. Никаких работ по договоренностям в месенджерах. Иначе потом трудно понять почему на скоуп ушло больше времени, чем рассчитывали.
5. Излишняя демократия в команде. Да, узурпатором власти быть не нужно, но и ключевые решения/работы должны проходить через вас. В моем опыте на это довольно негативно реагировали члены смежных проекте команд, однако это стоило того. Разработчики следовали плану, а я всегда знала, кто/чем/зачем занят. Почему важно на мой взгляд действовать через лида? Лиду дана задача, он же ставил сроки и у него был план как прийти к успеху. Если что то будет проходить в обход него, в чатиках, тут кто то отвлекся, там пошел на пол дня кому то помогать. Вот и все. Сроки сорваны.
6. Слишком сильно себя ассоциировать с проектом. Выгорите друзья!

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

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

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

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

Например, взять не супер срочную, но важную задачу и неспеша хорошо ее сделать. Вы можете наконец изучить что то новое! (на новом проекте вряд ли найдутся ресурсы для этого).

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

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

Вовремя уйти.

И все таки рано или поздно всем пора двигаться дальше. Если проект завершился, то тут можно сказать и повезло, а если он длится годами, этапы предыдущего пункта все пройдены, то пора двигаться дальше в сторону нового. Уйдите красиво, подготовив замену, приведя дела в порядок.

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

P.S. Спасибо всем, кто дочитал до конца! Еще раз это просто мой опыт и мои наработки не являющиеся истиной в последней инстанции. Всегда рада узнать ваши лайфхаки и ошибки и поучиться на Вашем опыте!