Не разработчик и не менеджер. Что означает быть лидом
Я уже полгода как мало пишу код, не вылезаю из митинг-румов и очень хочу в отпуск. Иными словами, уже полгода я лид в небольшой аутсорс-команде. В этой статье я хочу поделиться некоторыми мыслями, возникшими за этот период, а точнее, попытаться ответить на следующие вопросы:
- кто такой лид;
- в чем заключается его работа;
- как делать ее хорошо (ну как минимум не очень хреново).
Кто такой лид
Простой вопрос со сложным ответом. Ведь кто-то видит лида как топового технаря в команде, кто-то — как организатора и дирижера рабочего процесса, кто-то — как прокси между бизнесом и разработчиками. В принципе, все это правда. Но то, каковы конкретно будут твои задачи, из чего будет состоять твоя рутина и сколько кода ты будешь писать, уникально почти для каждой команды и проекта.
Причиной является сама природа этой позиции, а именно: ты нужен для того, чтобы затыкать дыры. Твоя задача — решать проблемы, будь они с кодом или с людьми. А на каждом проекте свои проблемы. Поэтому будь готов к абсолютно разным ожиданиям на разных проектах — и, идя на эту позицию, старайся максимально детально прояснить этот вопрос со своим менеджментом. Иначе есть риск получить совсем не ту работу, которую хотелось бы выполнять.
Мой текущий проект — это миграция более чем
Если бы я четко не знал, на что шел, такой большой акцент на коммуникации и планировании мог бы стать неприятным сюрпризом. Поэтому честный и детальный менеджмент ожиданий при найме лида (и вообще кого угодно) — must have.
Также чрезвычайно важно понимать, что ты уже не исполнитель. Ну почти. Скорее всего, писать код ты будешь, но не тот, который хочешь, а тот, который надо: баг срочно пофиксить, скрипт сборки поправить, модуль отрефакторить. Но основное ожидание от тебя — это не закрывать задачи, а построить масштабируемый процесс и команду, способную с этим процессом работать, — в идеале такие, чтобы тебя оттуда через некоторое время вынуть и ничего сильно не сломалось. Честно говоря, у меня пока так не получается.
В любом случае это сильно отличается от того, что ты делал раньше, будучи программистом. Тогда у тебя была роскошь полагаться только на свои знания, опыт и навыки и отвечать только за себя. Теперь, как лид, ты должен полагаться на свою команду и отвечать за работу в целом. А там, где начинается работа с людьми, всегда есть проблемы. Об основных — в разделе ниже.
Лид курильщика
Исходя из своего опыта, я могу поделить плохих лидов на две общие категории, или архетипа. Это босс и отличник. Немного карикатурные персонажи, которые редко встречаются в жизни именно такими, но они позволяют продемонстрировать те черты характера или ошибочные подходы, которые, по моему мнению, наиболее вредны на этой позиции.
Босс
Он много «делегирует». Очень много. В каких-то книгах пишут, что так и надо, но получается так, что своей работы у него просто не остается: все уходит его подчиненным.
Обычно выбираются один-два хороших технаря, на которых вешается все, что связано с кодом: архитектура, инструментарий, написание, ревью, инфраструктура.
Ответственность за сроки, качество и объемы тоже сбрасывается: или на кого-то, или на всю команду. Основной критерий оценки сотрудника — много ли он делает из того, что не должен, и часто ли об этом напоминает.
Единственное, что босс любит делать сам, — это митинги. На них он с важным видом вещает о единстве команды, важности совместных усилий и синергии коллектива. Часто хвалит тех, кто делает его работу, чтобы они продолжали ее делать. Тех, кто мешает идиллии, старается убрать. Разными способами.
На самом деле не худший вариант. Есть много проектов, где такие лиды вполне смогли построить самодостаточный процесс, а это признак неплохого менеджера (в кого они действительно могут вырасти). Для бизнеса они до определенной поры не особо вредны, если команда вытягивает объемы работы, а босс не мешает. Плюс они могут красиво побеседовать с заказчиком, что на многих проектах довольно важно.
Почему тогда я называю таких лидов плохими? Потому что исходов их работы может быть два.
Вариант 1. Появляется неформальный лид, который перенимает большую часть обязанностей. Обычно это кончается конфликтами и уходом одного из них, что всегда стресс для проекта и минус много денег для компании.
Вариант 2. Команда потихоньку стонет от нагрузки и уходит, а продукт загибается от техдолга и текучки. Может длиться от полугода до года, в результате проект закрывается или перезапускается.
Отличник
Обычно это самый старательный разработчик, которого в качестве поощрения назначили лидом. Также часто это очень ответственный человек, который по-настоящему болеет за проект и хочет сделать как можно лучше.
К сожалению, у таких людей при всех их положительных качествах есть один изъян — абсолютная уверенность в собственной правоте и превосходстве над коллегами.
Именно сочетание всех перечисленных характеристик знакомит нас с отличником. Если такие люди есть на проекте, их легко узнать: ровный, глубокий синий цвет мешков под глазами, легкий тремор конечностей и неразлучность с ноутбуком в любой ситуации.
Обычно после становления лидом для них ничего не меняется: как они писали много кода (сначала даже хорошего), так и пишут. Только вот теперь надо еще на звонки с заказчиком подключаться, митинги с командой проводить, задачи раздавать, апрайзалы заполнять... Отличник старается успевать все, просто экстенсивно наращивая количество рабочих часов в день. Со временем психика начинает отказывать, начинаются истерики («Я один здесь работаю, все остальные ничего не делают»), качество работы падает, сроки горят, что только усугубляет положение. Выйти из этого замкнутого круга без внешней помощи он не может, ведь искренне считает, что все делает правильно и жертвует собой ради проекта.
При этом сотрудники, которые в большинстве случаев дописывают и переписывают впопыхах созданное отличником, справедливо недовольны и начинают уходить. Либо, наоборот, расслабляются и вообще перестают работать, ведь за них и так все сделают.
Вред от таких лидов примерно такой же, как и от босса: иногда все просто работает. Отличник потихоньку выгорает, сотрудники листают социалки, заказчик видит прогресс. Правда, иногда отличник психует, берет отпуск на полгода или на такой же период попадает в больницу, а команда начинает вспоминать, как собирать проект и искать ссылку на прод. Тогда это потенциально минус проект и точно минус много денег для компании.
В итоге
Большинство людей, в том числе и плохих лидов, индивидуальны. Позволю себе немного перефразировать Толстого: «Все хорошие лиды похожи, а все херовые — херовы по-своему». Веду я к тому, что это лишь собирательные образы. Описание всех негативных качеств всех людей на этой позиции потянет на отдельную статью.
К сожалению, во мне отличника иногда многовато. На прошлом проекте мы писали healthcare-приложение, в котором часто встречались определенные формы. У меня появилась идея, как можно генерировать их через JSON-конфиг, таким образом ускорив разработку. Там должны были поддерживаться формы с несколькими шагами, двухсторонняя валидация, кастомные контролы и логика — иными словами, задача была непростой.
Хоть я и работал над приложением с коллегой, всю эту фичу я решил вытянуть сам. Менеджер предлагал поделить нагрузку, чтобы отдать ее раньше и облегчить работу, но я просто не хотел доверять свое «детище» кому-либо еще. Я дизайнил, писал, переписывал, заново дизайнил... На 70% работы я почувствовал, что с трудом заставляю себя открыть редактор, чтобы закончить начатое... В итоге фича получилась очень похожей на знаменитый рисунок коня.
Также яростное нежелание делиться работой явно не добавило мне плюсов ни в глазах менеджера, ни в глазах коллеги. Это стало хорошей прививкой от «синдрома отличника» и поводом подумать над эффективным рабочим процессом в команде.
Главное — понимать, что плохими эти персонажи становятся лишь в абсолюте, ведь, если присмотреться, в каждом из нас можно найти что-то похожее. В хорошем лиде, может, и должно быть немного отличника, немного босса, а самое главное — желания делать свою работу так, чтобы не было стыдно.
Лид здорового человека
Для начала обозначу мои критерии хорошего лида:
- его команда отдает нужный функционал в нужное время с нужным качеством;
- люди в его команде довольны своей работой, текучка низкая;
- процесс разработки нормально масштабируется при увеличении команды.
Можно было бы написать и больше, но даже если эти три пункта воплотятся в реальность, то ты уже молодец. Итак, как это сделать?
Нанимай нормальных людей
Как бы ты ни старался, ты не сможешь построить хорошую команду без правильных людей. Главное — без перфекционизма. Абсолютно бесплатно шарю чек-лист по найму таких людей на любую позицию.
Человека надо брать, если:
- Человек может (скоро сможет) делать работу.*
- Человек хочет делать работу.*
- Ты хочешь вместе с этим человеком делать работу.
* Первые два пункта являются интеллектуальной собственностью Владимира Кожаева. Надеюсь, он не против цитирования.
По своему опыту могу сказать, что третьим пунктом часто пренебрегают. Человек может уметь то, что нужно, хотеть этим заниматься, но, если ты считаешь, что тебе или большей части коллектива с ним будет некомфортно, не бери его. Поверь, он от этого только выиграет (рынком сейчас правят кандидаты), а ты — тем более. Иначе каждый день, потраченный на обучение и интеграцию этого человека в ваши процессы, будет потерянным. В итоге вы все равно разойдетесь, но сумма ущерба от такого найма будет на порядок больше потраченного на других кандидатов, так что... Нанимай тех, с кем хочешь работать. Если, конечно, тебе с ними работать.
Не требуй от людей лишнего
Все просто: если человек делает свою работу с надлежащим качеством и в оговоренные сроки, пусть работает, как хочет. У всех бывают неудачные дни, плохая продуктивность, семейные обстоятельства... Относись к этому спокойно, и, если это не мешает работе, не надо это «чинить».
Не стану говорить за всех, скажу за себя: бывает, хочется что-то запретить. Чтобы и кофе на кухне не пили, и ленты в соцсетях не крутили, и в туалет пореже ходили. Такие мысли надо пресекать простыми вопросами: «На проекте все нормально? Задачи закрываются? Релизы релизятся?» Если да, тогда отстань ты от людей и делай свою работу.
Если серьезно, то в случае, когда реально нужно мобилизовать ресурсы, так и скажи: «Дедлайн такого-то числа, надо успеть то и это. Давайте поработаем максимально продуктивно». По своему скромному опыту могу сказать, что работает нормально. А если кто-то этого не понимает, то вопрос уже не в твоих формулировках и частоте кофе-брейков, а в отношении этого человека к своим обязанностям. Но это уже совсем другая история...
Делегируй, но не эксплуатируй
Сколько копий сломано на теме делегирования... Вряд ли я буду оригинальным, но не сказать об этом не могу. С ростом численности команды, количества работы и ответственности ты перестаешь это все вытягивать. Просто физически. Какое-то время еще получается, но начинаешь замечать провалы в памяти и клоки волос в руках.
Как лид, ты обязан знать сильные стороны своих сотрудников. И согласно им решать, что можно предложить тем или иным людям. Часто это взаимовыгодная ситуация: люди получают возможность попробовать делать что-то посложнее, получить опыт и в перспективе повышение, ты получаешь больше времени на более приоритетные или сложные задачи и прокачавшегося сотрудника.
В 99% случаев быстрее сделать самому. Быстрее в первый раз, второй, третий... Всегда по-разному, но если человек был выбран правильно, то инвестиции начинают окупаться. И тут наблюдается целый ряд положительных эффектов:
- ты больше не тратишь столько времени на эту задачу;
- человек получил новый навык;
- человек получил подтверждение, что ты ему доверяешь;
- вы с человеком поработали вместе, и ваша коммуникация улучшилась.
Внимательные читатели могут спросить: ведь босс из плохих лидов тоже делегировал, почему здесь это хорошо? Предметно и компактно отвечу на это таблицей:
| Делегирование | Эксплуатация |
| Добровольное | Принудительная |
| Проходит под четким контролем | Отдается на самотек |
| Ответственность возлагается на тебя | Ответственность вешается на человека |
Как-то, в начале своего карьерного пути я получил в личку ссылку на дизайн и просьбу от менеджера сверстать то, что там было. Лид хоть формально и числился у нас на проекте, но вовлечен был минимально: в лучшем случае несколько часов в неделю. «Что ж, — подумал я, — это мой шанс проявить себя».
Я набросал структуру компонентов, прикинул эстимейты, выделил реюзабельные блоки и отписал менеджеру (важный нюанс: менеджер была просто прокси между лидом, командой и заказчиком). Мы созвонились, завели таски по моим описаниям (некоторые из них относились к back-end), и я приступил к работе.
Через некоторое время мне пишет лид: «Кто дал тебе право создавать задачи, особенно для back-end?» Я ответил, что он сам просил не работать без заведенных задач (по ним биллились заказчики), а предварительно созданы они не были. Он покритиковал описания и суть моих задач и попросил больше так не делать. Страницы я в итоге сверстал, но осадок остался.
В этой истории так или иначе неправы все стороны, но я бы хотел рассмотреть ее с точки зрения именно неправильного делегирования. Доверяя кому-то работу, ты обязан дать исчерпывающую информацию и оказать хоть какую-то помощь в процессе выполнения, иначе либо ничего не будет сделано, либо будет сделано не так, как ты хотел. И в таком случае критиковать стоит в первую очередь себя.
Подводя итог по этому пункту, хочу отметить, что все начинается с доверия. Если ты нанял этого человека, дай ему шанс проявить себя. Рано или поздно ты ошибешься, но даже несколько правильных людей, в которых ты поверил и вложился, компенсируют это с лихвой.
Расти вместе с командой
Допустим, ты нанял хороших специалистов, построил адекватный процесс и все вроде бы работает. А люди, поработав в твоей dream team, все равно уходят. Почему это происходит?
Люди растут. Они хотят больше денег, больше власти, больше ответственности, больше монитор. Если ты им этого не дашь, они найдут это у других. Ты можешь удивиться, ведь ни с чем таким к тебе не приходили. Варианта тут два: либо приходили, а ты не понял, либо посчитали, что легче получить это не через просьбы, а просто приняв оффер в соседней конторе.
Как удержать таких людей? В первую очередь не допускать ситуации, в которой цели твоих сотрудников тебе неизвестны. Для этого есть множество инструментов: one-to-one-митинги, апрайзалы, прозрачная система повышений и т. д. Твоя цель — как можно раньше понять, в каком направлении и в каком темпе сотрудник видит свой рост, и учитывать это в дальнейшей работе.
К примеру, недавно на 1-to-1 митингах некоторые разработчики из моей команды поделились заинтересованностью в роли лида и большей ответственности. Я подумал, как это можно реализовать с пользой для проекта и решил применить идею module ownership: каждый в команде получает возможность отвечать за определенный модуль или часть процесса. Это включает технические решения, поддержку, интеграцию, масштабирование — во все это они вовлекаются больше других, когда речь идет об их зоне ответственности.
Пока результат положительный: ребята получили возможность прокачать скилы, необходимые для роли лида, мне стало легче работать, ведь теперь я четко знаю, к кому идти по тем или иным вопросам, а продукт стал стабильней и качественней, так как «серые зоны» получили ответственных за них людей.
Важно понять: я не говорю о том, чтобы подстраивать весь рабочий процесс под работников и превращать компанию в начальную школу. Но часто есть возможность выбора: кому какую задачу дать, кого на каком проекте вовлечь, кому дать попробовать новую технологию. Это показывает человеку, что тебе не все равно и что в компании ему есть куда расти.
Таким образом, ты получаешь лояльных специалистов, мотивированных держаться за это место и расти вместе с остальными. А с такой командой можно и ракеты запускать.
Блиц-советы
- Не расслабляйся, если кажется, что все хорошо.
- Не пытайся сделать все идеально.
- Если чувствуешь, что кого-то надо уволить, увольняй.
- Если чувствуешь, что кого-то надо нанять, нанимай.
- Не забывай писать код.
- Признавай свои ошибки (в том числе публично).
Кушай жидкое как минимум раз в неделю и не мочи манту.
Заключение
Быть лидом сложно. Хорошим — еще сложнее. Но если, прочитав эту статью, ты увидел вызов, а не стоп-сигнал, то тебе понравится. Впереди много нервов, сорванных сроков, крашей на демо и деплоев в пятницу вечером. Много людей, много проектов, много критики, сомнений и неправильных решений. И много кайфа. Я честно скажу, что, попробовав, не хочу снова становиться разработчиком. И при этом понимаю тех, кто захотел.
Каждому, кто сомневается, просто хочу посоветовать попробовать и, если будет трудно, не сдаваться. Наверное, я говорю это и себе. Будет интересно прочитать эту статью через несколько лет.
А пока жду вас в комментариях. Расскажите, что, по-вашему, должен делать лид, поделитесь историями о плохих лидах и расскажите о хороших.
