Как я задумал этот пост - вступление, которое отчасти дублирует и немного раскрывает текст до ката
Я работаю тимлидом и лидом лидов на разных уровнях в разных по масштабу командах уже более пяти лет. За это время я поработал на лидовских позициях в трех компаниях, работа в каждой из которых соответствовала своему этапу получения опыта:
Уверенность в том, что тимлид - это в первую очередь самый опытный разработчик;
Осознание того, что в средних(3-10 человек) и больших командах тимлид - это в первую очередь организатор и лидер;
Закрепление и передача опыта из пункта 2.
На третьем пункте я хочу остановиться подробнее. Дело в том, что после реорганизации технического направления компании у нас появилось несколько новых команд. Возглавить эти команды мы предложили разработчикам, которые на наш взгляд являются не только хорошими техническими специалистами, но и демонстрируют навыки и желание брать на себя ответственность за команду и расти внутри компании.
Учитывая что некоторые из разработчиков не имеют опыта работы в лидовской позиции или имеют минимальный опыт, я решил организовать серию мастер-классов для начинающих тимлидов.
Фидбэк от команды оказался позитивным, поэтому я решил поделиться знаниями и с сообществом - для того, чтобы:
Обменяться опытом и получить обратную связь от опытных коллег,
Поделиться опытом с начинающими коллегами и помочь им понять стоит ли выбирать менеджерскую карьерную ветку
В первом посте я начну с самых основ - поделюсь как я выстраиваю коммуникацию с каждым отдельным участником команды. Если пост получит хороший отклик - постараюсь раскрыть и другие темы - на внутреннюю аудиторию у меня запланировано более 10 мастер-классов на такие темы как построение процессов и планирования внутри фичекоманды, взаимодействие с бизнес заказчиками и другими командами(не разработки) внутри бизнеса, проведение собеседований по софт и хард скилам, построение грейдов как основы для персональных планов роста и проведения перформанс ревью, предотвращение стресса и выгорания, и тд.
Основы работы тимлида: работа с командой
«Тимлид - это человек, который ставит задачи» - так звучит одна из самых популярных ассоциаций с ролью тимлида у тех, кто на этой позиции самостоятельно не работал. Постановка задач - действительно большая часть работы на позиции лида, поэтому с нее я и начну свое повествование.
Делегирование и постановка задач
Как формулировать задачу
Для формулирования крупных задач (от недели самостоятельной работы) я использую широко известную методику SMART. В соответствии с методикой задача должна быть:
Specific / Конкретной
Measurable / С измеримым результатом
Achievable / Достижимой
Realistic and relevant / Реалистичной и релевантной
Time-bound / ограниченной по времени
Думаю, это методика достаточно известная, поэтому на теории останавливаться подробно не буду. При этом как показывает практика - именно при переходе к реальным задачам у начинающих лидов возникают трудности, поэтому пример из своей практики добавлю.
Пример постановки задачи
Контекст
У нас есть несколько фичевых кросс-функциональных команд, которые работают над продуктом - мобильным приложением. Мобильное приложение релизится заданное количество раз в месяц по расписанию по заранее описанному процессу. Процесс релиза включает довольно стандартный для таких случаев набор действий:
отвести релизные ветки,
создать релизы в джире,
проверить что все задачи, попавшие в релиз, находятся в корректных статусах,
создать тест-раны для регресса
и так далее.
На проекте есть CI, который умеет собирать новую сборку по пушу в ветку, больше автоматизаций нет. На все эти ручные действия релиз менеджер тратит 1-2 часа времени каждый релиз, в месяц это получается 2 часа * 2 мобильные платформы * кол-во релизов в месяц - получается достаточно значительно. Задача состоит в том чтобы этот процесс максимально автоматизировать и сэкономить дорогое время релиз менеджера. И эту задачу мне нужно поставить разработчику из мобильной платформенной команды.
Постановка задачи
У нас есть проблема - ответственные за релиз разработчики тратят по 1-2 часа времени на релиз на монотонные задачи, которые можно автоматизировать (релевантность).
Нужно сделать интеграцию со слаком, которая по заданной команде запускает релизный процесс и делает следующие шаги - {описание шагов}. После каждого шага, а так же по готовности нового билда автоматизация пишет сообщение в тред к релизу (конкретность).
Таким образом мы сможем облегчить жизнь релиз-менеджеров и планировать им в спринт на час больше интересных задач вместо монотонных (измеримость результата).
Реализовать автоматизацию можно при помощи API слака, джиры и CI - в письменной постановке задачи я описал подробнее какие API на мой взгляд нужно использовать, но если у тебя есть более оптимальные предложения, давай обсудим. Работать автоматизация будет в инфраструктуре нашей компании, которую мы с девопс командой уже обсудили (достижимость).
Декомпозируй до завтра эпик на подзадачи и сделай оценку, обсудим сколько задача займет времени (ограниченность по времени - в данном примере она только для первого шага, но после обсуждения оценки будет установлена для всей задачи).
Насколько подробно формулировать задачу
В примере из прошлого пункта задача описана достаточно подробно, хотя задача ставится эксперту в области мобильной разработки из платформенной команды. Этот момент тоже хочется объяснить.
Вообще у меня есть примерная зависимость подробности постановки задачи от опытности специалиста:
Новичку - дать цель, ожидаемый измеримый результат и пошаговое руководство;
Опытному сотруднику - дать цель и ожидаемый измеримый результат;
Эксперту - дать цель и позволить предлагать решения.
Исходя из описания казалось бы задачу стоить формулировать от цели и давать самостоятельность в подготовке решения. Но задача сформулирована в некоторых пунктах даже с пошаговым описанием достижения цели.
Дело тут в том, что на мой взгляд степень подробности постановки задачи зависит от опытности специалиста в той области, в которой поставлена задача. В данном случае я ставлю задачу опытному мобильному разработчику, но в то же время человеку без большого опыта в инфраструктурных задачах и опыта подобного рода автоматизаций.
Как закрепить ответственность
После того как задача поставлена, нужно закрепить ответственность за решение задачи. В случае стандартных задач это обычно происходит на планировании, когда специалист соглашается с оценкой задач, данной им или командой на общем планировании, а затем назначенной на него в спринт. Но бывают такие ситуации, когда специалист по той или иной причине не хочет брать определенную задачу - например, сомневается в своих силах или не любит решать такой тип задач. Для таких случаев есть несколько форм:
Требование - «Сделай это потому что ты должен это сделать в соответствии с должностными обязанностями»;
Убеждение - «Сделай это, и бизнес получит такую-то пользу, которая отразится и на твоей премии»;
Просьба - «Пожалуйста, сделай это для меня - ты меня очень выручишь»;
Приказ - «Просто сделай это, это приказ». Без объяснения, обоснования и тд.
По моему опыту начинающим тимлидам в основном следует прибегать к первой и второй форме, потому что просьба - это форма обычно манипулятивная, которой нужно уметь пользоваться и даже в случае умения не использовать слишком часто, а для использования приказа нужно обладать достаточным авторитетом, которого у начинающих лидов может не хватить.
Фидбэк
После того как человек задачу сделал, ему нужно дать фидбэк. Тут на мой взгляд тоже есть важные моменты:
Фидбэк должен быть своевременным;
Фидбэк должен быть привязан к конкретной задаче, результату или действию;
Фидбэк должен быть основан на фактах, а не на эмоциях;
Фидбэк должен подчеркивать важность обсуждаемого результата как для человека, так и для команды/компании;
Хороший фидбэк не менее важен, чем плохой;
Хороший фидбэк можно продублировать в публичном пространстве - например, объявить о хороших результатах на стендапе или отметить вклад членов команды при анонсе результатов работы. Это не только поможет членам команды почувствовать свою значимость, но и улучшит атмосферу в команде, а так же поможет на примере показать что лид и компания считают большим вкладом в работу;
Будьте искренними когда хвалите. Тут сложно дать общий рецепт, но в то же время это очень важно для построения личных отношений и атмосферы в команде. Для начала просто улыбнитесь при даче позитивного фидбэка 🙂
Давайте разберем на примере. В качестве примера давайте представим себе ситуацию, когда разработчик автоматизировал часть релизного процесса мобильного приложения из примера с постановкой задачи. После первого использования автоматизации я приглашаю его пообщаться и строю разговор в таком ключе:
«Спасибо за разработку бота. Я думаю, что тебе, как человеку, который регулярно выполняет роль релиз-менеджера, самому будет удобнее, когда значительная часть рутиной работы будет выполняться автоматически. И не только тебе - я помню немало просьб автоматизировать эти действия. Это нововведение важно и для бизнеса, потому что это экономит часы релиз-менеджеров, а это дорогое время на фоне других специалистов. Также отмечу, что решение такой задачи такой сложности подходит под требование следующего грейда, так что ещё 1-2 примера задач такой сложности - и на следующем ревью мы сможем обсуждать повышение».
Выявление мотивации и работа с ней
Бывают такие моменты, когда члены команды не хотят брать ту или иную задачу. Причины могут быть совершенно разные - например, человек боится, что не справится, или считает что задача не относится к его прямому кругу обязанностей, а выходить за него он не готов. При этом лид уверен в том, что задача важная и нужная команде, и человек с задачей справится. В таком случае работа лида - это убедить человека задачу взять. Существуют разные способы это сделать. Самые банальные - это обещание премии или угроза увольнением. Но есть способ более мягкий и безболезненный - это определение мотивации человека и убеждение его в том, что решение этой задачи поможет достичь того, что мотивирует человека.
Начнем с определения мотивации члена команды. Существует несколько разных классификаций мотивации, среди которых я предпочитаю такую:
Признание: сюда могут относится звания «Сотрудник месяца», «Герой спринта» и так далее. Карьерный рост также здесь, если его основная цель - получить новое формальное звание, например лычку сеньора. Сюда же можно отнести и желание работать в престижной компании;
Психологический комфорт: хороший коллектив, четкие правила компании и комфортное общение;
Удобство: хороший офис или удаленная работа, понятный и комфортный рабочий процесс;
Профессиональный рост: возможность изучить новые инструменты в профессиональной сфере, например, технологию или построение процессов работы команды;
Безопасность: быть уверенным, что вовремя придет зарплата, человек не попадет под сокращения, компания не закроется и так далее;
Деньги.
Важный комментарий по поводу денег: они не зря на последнем месте в моем списке. Многие начинающие менеджеры считают, что для того чтобы мотивировать людей, нужно просто все больше и больше накидывать им денег. Моя практика и практика общения с более опытными товарищами показывают, что это не всегда так. Деньги являются мотивацией для большинства людей до того момента, пока человек получает меньше некого комфортного ему минимума. Для каждого этот минимум свой - кому-то достаточно чтобы хватало снимать квартиру и хорошо кушать, кому-то хочется свою большую квартиру и менять машину раз в пару лет. Но общее тут то, что по достижению этого комфортного уровня мотивация более, чем у 90% людей не в деньгах.
Кстати, я могу подтвердить это утверждение и на своем примере. Когда я услышал это утверждение от более опытных товарищей - я этому не поверил. Спустя некоторое время оказалось, что когда мы это обсуждали, я ещё не достиг своего комофортного уровня. А спустя ещё некоторое время оказалось, что этот самый уровень комфорта не постоянный - при некоторых жизненных обстоятельствах он имеет свойство меняться.
После этого осознания я стараюсь учитывать это ещё и с точки зрения управления командой.
Так как же определить мотивацию? - Тут ответ очень простой. Нужно просто слушать человека, особенно обращая внимание на причины поступков человека в той или иной ситуации. Самым банальным примером будет обсудить со коллегами кто по какой причине выбрал работу в текущей компании.
Как же полученным знанием воспользоваться? - В первую очередь показать, что выполнение задачи поможет достич той цели, которая мотивирует человека. Например, в случае, если человека мотивирует профессиональный рост, можно сказать, что задача - отличный повод попробовать новую технологию. Компания может ему помочь, оплатив курсы по новой технологии, или отправить его на конференцию.
Стоит отметить, что понимание мотивации помогает не только в описанном примере с задачей, но и, например, в случае если ценный специалист в компании думает об уходе в другую компанию. В этом случае следует сравнить текущую компанию и конкурентов в первую очередь с точки зрения того, как работа в текущей компании поможет достичь мотивирующих его целей.
Где всем этим заниматься
Я считаю что для установки доверительного отношения с членами команды следует регулярно общаться с ними один на один. Во время таких встреч можно подробно обсуждать постановку и текущее положение дел по задачам, персональные планы роста и развития, давать фидбэк и просить фидбэк на свою работу, иногда даже просто общаться за жизнь.
Тут хочется оставить отдельный комментарий по поводу простого общения за жизнь. В начале своей карьеры в роли лида я недооценивал это аспект. Казалось, что тратить время на разговоры о личных вещах - это потеря времени, которое можно было бы использовать на более продуктивные задачи, такие как написание кода или тестирование задач. Однако, со временем я осознал, что такие разговоры способствуют построению доверительных отношений в команде. Они позволяют лучше понять мотивацию сотрудников, получить обратную связь, которую они могли бы не выразить в формальных анкетах на перформанс ревью, и узнать много другой полезной информации.
Благодаря доверительным отношениям в команде, мне удалось удержать нескольких членов, которые рассматривали возможность ухода, а также своевременно подготовить замену для тех, кого удержать не удалось, потому что они ставили себе цель перейти работать в иностранную компанию.
Однако тут важно не уйти в крайность, когда общение на 1-1 сводится просто к разговорам за жизнь и в большинстве случаев не имеет другой цели со стороны лида. В таких случаях лиду следует более точно сформулировать цель таких встреч для себя и при подготовке ко встречам про эти цели не забывать.
На мой взгляд, частота таких встреч должна составлять раз в 1-2 недели. Редкие встречи могут привести к потере контекста в общении, особенно если члены команды не работают над общими задачами каждый день.
Как понять что я не зря трачу силы на выстраивание отношений
Оглядываясь назад на свой опыт, я могу вспомнить более 10 случаев когда хорошо налаженный контакт помогал мне удержать человека в команде, быстро найти человека в новой компании или заранее узнать что человек собирается уходить и найти замену без остановки работы. Данное утверждение может показаться излишне оптимистичным, но я посчитал только те случаи, когда текущие или бывшие члены команды упоминали об этом явно или сами писали мне о том что ищут новое место и спрашивали нет ли у меня чего-то интересного на примете.
Но это если оглядываться на несколько лет опыта назад. А что же делать начинающему тимлиду, если большая статистика ещё не собрана, опыта мало, а синдром самозванца периодически навещает?
Для себя я вывел такие признаки того, что коммуникация с членами команды налажена хорошо:
Первый признак хорошей коммуникации - это то, что ваши разговоры 1-1 больше похожи на неформальную коммуникацию, чем на регулярный отчет перед боссом. Вы обсуждаете общие темы, в которых заинтересованы все стороны дискуссии, обе стороны задают вопросы, аргументируют свою точку зрения, могут не соглашаться друг с другом. Тут есть важный момент - это совершенно не значит, что члены команды могут спокойно отказаться делать задачу, которую вы им ставите, и свалить ее на вас. Но на мой взгляд даже в этом случае убеждение за счет накопленного авторитета и неформального лидерства вместо подхода "нужно делать это потому что я начальник и я так сказал" - это признак хорошей работы лида.
Второй признак отчасти является продолжением первого. Он заключается в том, что общение с членами команды построено не только вокруг рабочих задач. Если члены команды делятся с вами личными проблемами - это признак доверия, которое, скорее всего будет проявляться и в работе.
Третий признак - это то, что лид получает от общения 1-1 полезную информацию. Например, ту, которая позволяет выявить мотивацию или скрытый конфликт между членами команды до того, как он привел к неприятным последствиям вроде увольнения одного из участников конфликта.
Лайфхаки 1-1
За время работы на разных лидовских позициях я собрал несколько полезных лайфхаков, которые сейчас мне - как и скорее всего многим опытным лидам - кажутся очевидными, но в начале таковыми не казались. Вот примерный список:
Общение 1-1 может быть более или менее формальным. Более формальное - это когда вы раз в неделю строго по расписанию собираетесь в переговорке и что-то обсуждаете. Менее формальное - это совместный поход на обед, за чашкой кофе или даже в бар после работы. Хороший лид использует комбинацию этих подходов.
При общении важно установить контакт с собеседником. Если мы говорим про личное взаимодействие - даже формальный его варинат из прошлого пункта - это складывается из таких мелочей, как то, что вы смотрите человеку в глаза, а не сидите напротив него, отгородившись ноутбуком.
Если речь идет про взаимодействие онлайн - включайте камеру.
Кстати, при общении онлайн тоже есть возможность "отгородиться ноутбуком" - например, если вы используете дополнительный монитор и все время смотрите на него, а не в камеру. Для таких случаев спасает маковская фича сплит скрин или просто два окна если речь идет о другой операционно системе. В одном окне собеседник, в другом - заметки со встречи.
Не планируйте несколько встреч подряд без перерыва или встречи в конце дня. После большинства регулярных 1-1 остаются заметки, которые нужно проработать, сами встречи могут затягиваться или на них может быть тяжелое обсуждение, после которого не будет сил внимательно слушать следующего собеседника и вникать в его проблемы.
Если человек поделился какой-то своей проблемой, не обязательно рабочей, по которой не нужна помощь - поинтересуйтесь в следующий раз как обстоят дела с этой проблемой. Это помогает выстраивать доверительное отношение.
Когда членов команды и встреч много, бывает такое что какие-то результаты забываются, не говоря уже о личных проблемах из предыдущего пункта. Для того, чтобы их не забывать, я веду заметки со встреч с каждым из членов команды, куда записываю и в том числе и личные моменты, которыми делятся члены команды - чтобы не забыть что у человека происходит что-то важное и как минимум узнать как дела с важной для него проблемой.
Помогайте решать рабочие проблемы, о которых услышали при общении и подсвечивайте ход решения этих проблем, так члены команды не будут думать что их проблемы просто игнорируются и будут понимать, что рассказывать о них вам полезно.
Если члены команды рассказали вам о проблемах, которые вы самостоятельно решить не можете - подсветите их перед теми, кто может решить и не забудьте рассказать о результатах обсуждения членам команды. Члены команды должны явно понимать, что при общении с высшим руководством вы представляете их интересы, а не являетесь просто звеном в цепочке передачи задач.
Заключение
Спасибо за внимание. Буду рад обсудить тему поста и послушать про ваш опыт. Как я уже писал в начале - если пост вызовет большой и хороший отклик, я планирую регулярно писать ещё - так что, если тема тебя заинтересовала, но добавить нечего, поставьте плюсик - это будет для меня означать, что тема интересная.
P.S. Я понимаю, что хороший пост, особенно длинный, читается легче, если у него есть иллюстрации - но сам умею рисовать разве что схемы взаимодействия сервисов и орг. структуры, художественным талантом к сожалению не обладаю. Так что если кто-то будет готов помочь с иллюстрациями к этому посту или следующим - я буду очень рад :)
