Заметки для начинающего тимлида

 Публичный пост
22 декабря 2023  1327
Держи долор

Как я задумал этот пост

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

  1. Уверенность в том, что тимлид - это в первую очередь самый опытный разработчик;
  2. Осознание того, что в средних(3-10 человек) и больших командах тимлид - это в первую очередь организатор и лидер;
  3. Закрепление и передача опыта из пункта 2.

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

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

Фидбэк от команды оказался позитивным, поэтому я решил поделиться знаниями и с сообществом - для того, чтобы:

  1. Обменяться опытом и получить обратную связь от опытных коллег,
  2. Поделиться опытом с начинающими коллегами и помочь им понять стоит ли выбирать менеджерскую карьерную ветку

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

Основы работы тимлида: работа с командой

«Тимлид - это человек, который ставит задачи» - так звучит одна из самых популярных ассоциаций с ролью тимлида у тех, кто на этой позиции самостоятельно не работал. Постановка задач - действительно большая часть работы на позиции лида, поэтому с нее я и начну свое повествование.

Делегирование и постановка задач

Как формулировать задачу

Для формулирования крупных задач (от недели самостоятельной работы) я использую широко известную методику SMART. В соответствии с методикой задача должна быть:

  • Specific / Конкретной
  • Measurable / С измеримым результатом
  • Achievable / Достижимой
  • Realistic and relevant / Реалистичной и релевантной
  • Time-bound / ограниченной по времени

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

Пример постановки задачи

Контекст

У нас есть несколько фичевых кросс-функциональных команд, которые работают над продуктом - мобильным приложением. Мобильное приложение релизится заданное количество раз в месяц по расписанию по заранее описанному процессу. Процесс релиза включает довольно стандартный для таких случаев набор действий:

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

На проекте есть CI, который умеет собирать новую сборку по пушу в ветку, больше автоматизаций нет.
На все эти ручные действия релиз менеджер тратит 1-2 часа времени каждый релиз, в месяц это получается 2 часа * 2 мобильные платформы * кол-во релизов в месяц - получается достаточно значительно.
Задача состоит в том чтобы этот процесс максимально автоматизировать и сэкономить дорогое время релиз менеджера. И эту задачу мне нужно поставить разработчику из мобильной платформенной команды.

Постановка задачи

У нас есть проблема - ответственные за релиз разработчики тратят по 1-2 часа времени на релиз на монотонные задачи, которые можно автоматизировать (релевантность).

Нужно сделать интеграцию со слаком, которая по заданной команде запускает релизный процесс и делает следующие шаги - {описание шагов}. После каждого шага, а так же по готовности нового билда автоматизация пишет сообщение в тред к релизу (конкретность).

Таким образом мы сможем облегчить жизнь релиз-менеджеров и планировать им в спринт на час больше интересных задач вместо монотонных (измеримость результата).

Реализовать автоматизацию можно при помощи API слака, джиры и CI - в письменной постановке задачи я описал подробнее какие API на мой взгляд нужно использовать, но если у тебя есть более оптимальные предложения, давай обсудим. Работать автоматизация будет в инфраструктуре нашей компании, которую мы с девопс командой уже обсудили (достижимость).

Декомпозируй до завтра эпик на подзадачи и сделай оценку, обсудим сколько задача займет времени (ограниченность по времени - в данном примере она только для первого шага, но после обсуждения оценки будет установлена для всей задачи).

Насколько подробно формулировать задачу

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

Вообще у меня есть примерная зависимость подробности постановки задачи от опытности специалиста:

  1. Новичку - дать цель, ожидаемый измеримый результат и пошаговое руководство;
  2. Опытному сотруднику - дать цель и ожидаемый измеримый результат;
  3. Эксперту - дать цель и позволить предлагать решения.

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

Как закрепить ответственность

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

  1. Требование - «Сделай это потому что ты должен это сделать в соответствии с должностными обязанностями»;
  2. Убеждение - «Сделай это, и бизнес получит такую-то пользу, которая отразится и на твоей премии»;
  3. Просьба - «Пожалуйста, сделай это для меня - ты меня очень выручишь»;
  4. Приказ - «Просто сделай это, это приказ». Без объяснения, обоснования и тд.

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

Фидбэк

После того как человек задачу сделал, ему нужно дать фидбэк. Тут на мой взгляд тоже есть важные моменты:

  1. Фидбэк должен быть своевременным;
  2. Фидбэк должен быть привязан к конкретной задаче, результату или действию;
  3. Фидбэк должен быть основан на фактах, а не на эмоциях;
  4. Фидбэк должен подчеркивать важность обсуждаемого результата как для человека, так и для команды/компании;
  5. Хороший фидбэк не менее важен, чем плохой;
  6. Хороший фидбэк можно продублировать в публичном пространстве - например, объявить о хороших результатах на стендапе или отметить вклад членов команды при анонсе результатов работы. Это не только поможет членам команды почувствовать свою значимость, но и улучшит атмосферу в команде, а так же поможет на примере показать что ты и компания считаете большим вкладом в работу;
  7. Будь искренним когда хвалишь. Тут сложно дать общий рецепт, но в то же время это очень важно для построения личных отношений и атмосферы в команде. Для начала просто улыбнись при даче позитивного фидбэка 🙂

Давайте разберем на примере. В качестве примера давайте представим себе ситуацию, когда разработчик автоматизировал часть релизного процесса мобильного приложения из примера с постановкой задачи. После первого использования автоматизации я приглашаю его пообщаться и строю разговор в таком ключе:
«Спасибо за разработку бота. Я думаю, что тебе, как человеку, который регулярно выполняет роль релиз-менеджера, самому будет удобнее, когда значительная часть рутиной работы будет выполняться автоматически. И не только тебе - я помню немало просьб автоматизировать эти действия. Это нововведение важно и для бизнеса, потому что это экономит часы релиз-менеджеров, а это дорогое время на фоне других специалистов. Также отмечу, что решение такой задачи такой сложности подходит под требование следующего грейда, так что ещё 1-2 примера задач такой сложности - и на следующем ревью мы сможем обсуждать повышение».

Выявление мотивации и работа с ней

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

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

  1. Признание: сюда могут относится звания «Сотрудник месяца», «Герой спринта» и так далее. Карьерный рост также здесь, если его основная цель - получить новое формальное звание, например лычку сеньора. Сюда же можно отнести и желание работать в престижной компании;
  2. Психологический комфорт: хороший коллектив, четкие правила компании и комфортное общение;
  3. Удобство: хороший офис или удаленная работа, понятный и комфортный рабочий процесс;
  4. Профессиональный рост: возможность изучить новые инструменты в профессиональной сфере, например, технологию или построение процессов работы команды;
  5. Безопасность: быть уверенным, что вовремя придет зарплата, члеовек не попадет под сокращения, компания не закроется и так далее;
  6. Деньги.

Важный комментарий по поводу денег: они не зря на последнем месте в моем списке. Многие начинающие менеджеры считают, что для того чтобы мотивировать людей, нужно просто все больше и больше накидывать им денег. Моя практика и практика общения с более опытными товарищами показывают, что это не всегда так. Деньги являются мотивацией для большинства людей до того момента, пока человек получает меньше некого комфортного ему минимума. Для каждого этот минимум свой - кому-то достаточно чтобы хватало снимать квартиру и хорошо кушать, кому-то хочется свою большую квартиру и менять машину раз в пару лет. Но общее тут то, что по достижению этого комфортного уровня мотивация более, чем у 90% людей не в деньгах.
Кстати, я могу подтвердить это утверждение и на своем примере. Когда я услышал это утверждение от более опытных товарищей - я этому не поверил. Спустя некоторое время оказалось, что когда мы это обсуждали, я ещё не достиг своего комофортного уровня. А спустя ещё некоторое время оказалось, что этот самый уровень комфорта не постоянный - при некоторых жизненных обстоятельствах он имеет свойство меняться.
После этого осознания я стараюсь учитывать это ещё и с точки зрения управления командой.

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

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

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

Где всем этим заниматься

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

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

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

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

На мой взгляд, частота таких встреч должна составлять раз в 1-2 недели. Редкие встречи могут привести к потере контекста в общении, особенно если члены команды не работают над общими задачами каждый день.

Как понять что я не зря трачу силы на выстраивание отношений

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

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

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

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

Лайфхаки 1-1

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

  • Общение 1-1 может быть более или менее формальным. Более формальное - это когда вы раз в неделю строго по расписанию собираетесь в переговорке и что-то обсуждаете. Менее формальное - это совместный поход на обед, за чашкой кофе или даже в бар после работы. Хороший лид использует комбинацию этих подходов.
  • При общении важно установить контакт с собеседником. Если мы говорим про личное взаимодействие - даже формальный его вариант из прошлого пункта - это складывается из таких мелочей, как то, что ты смотришь человеку в глаза, а не сидишь напротив него, отгородившись ноутбуком.
  • Если речь идет про взаимодействие онлайн - включай камеру.
  • Кстати, при общении онлайн тоже есть возможность "отгородиться ноутбуком" - например, если ты используешь выносной монитор для ноутбука и все время смотришь на него, а не в камеру. Для таких случаев спасает маковская фича сплит скрин или просто два окна если речь идет о другой операционно системе. В одном окне собеседник, в другом - заметки со встречи.
  • Не планируй несколько встреч подряд без перерыва или встречи в конце дня. После большинства регулярных 1-1 остаются заметки, которые нужно проработать, сами встречи могут затягиваться или на них может быть тяжелое обсуждение, после которого не будет сил внимательно слушать следующего собеседника и вникать в его проблемы.
  • Если человек поделился какой-то своей проблемой, не обязательно рабочей, по которой не нужна помощь - поинтересуйся в следующий раз как обстоят дела с этой проблемой. Это помогает выстраивать доверительное отношение.
  • Когда членов команды и встреч много, бывает такое что какие-то результаты забываются, не говоря уже о личных проблемах из предыдушего пункта. Для того, чтобы их не забывать, я веду заметки со встреч с каждым из членов команды, куда записываю и в том числе и личные моменты, которыми делятся члены команды - чтобы не забыть что у человека происходит что-то важное и как минимум узнать как дела с важной для него проблемой.
  • Помогай решать рабочие проблемы, о которых услышал при общении и подсвечивай ход решения этих проблем, так члены команды не будут думать что их проблемы просто игнорируются и будут понимать, что рассказывать о них тебе полезно.
  • Если члены команды рассказали тебе о проблемах, которые ты самостоятельно решить не можешь - подсвети их перед теми, кто может решить и не забудь рассказать о результатах обсуждения членам команды. Члены команды должны явно понимать, что при общении с высшим руководством ты представляешь их интересы, а не являешься просто звеном в цепочке передачи задач.

Заключение

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

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

Связанные посты
19 комментариев 👇

Я бы добавил еще: не забывайте хвалить своих сотрудников. Об этом часто забывают. Заметка про похвалу из нашего хендбука в компании:

🔥 Хвали свою команду

Похвала это важно. Она как топливо для развития и роста. Похвала помогает ребятам в команде чувствовать свою значимость. Это особенно важно на удалёнке.

Я не могу дать тебе точные алгоритмы, кого, как и когда хвалить. Зато дам несколько универсальных советов, которые тебе в этом помогут.

😓 Хвалить это работа

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

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

Как только научишься делать это регулярно, ты «оздоровишь» не только себя, но и всю команду.

🤔 Когда и за что хвалить?

Самое простое — хвалить за результат.
Сделал — молодец. Сделал мега круто — похвали его при всех.

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

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

🤔 Как хвалить?

Одобрение — та же похвала, но менее выраженная. Одобрение может быть высказано мимоходом. Например, когда в чате кто-то поделился результатом работы или идеей, можно сказать коллеге «Круто!», «Красавчик», «Пацаны вообще ребята» или просто подметить «Хорошая идея».

Можно хвалить один-на-один. Тут уже можно быть более открытым, сказать: «Мужик, ты реально крут, афигенское решение нашел! И как ты его выдумал то.»

Ценнее всего — общее признание неких заслуг. Поэтому можно хвалить при коллегах, при всей команде на стендапах.

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

Не бойся перехвалить.
Особенно новичков в командах и особенно один-на-один. Хвали, пока это не начнёт получаться у тебя легко. После этого ты сможешь подобрать необходимый и достаточный объем похвалы в команде :)

Бойся перехвалить кого-то одного.
Иначе команда станет смотреть на него, как смотрят на отличника и выскочку в школе. Иногда лучше разделить успехи на всю команду: «Хорошо поработали, сделали все запланированные задачи. Молодцы!»

Будь искренним.
Добиться этого труднее всего. Хотя бы улыбнись перед началом разговора. Включи эмпатию.

🤬 Что не надо делать

  • Не сравнивай коллегу с кем-либо другим, это принижает остальных. («Сегодня Вася был лучше всех»)
  • Не отзывайся в третьем лице. («Я хотел бы поблагодарить Васю...»)
  • Не хвали по шаблону. Подбирай разные слова.
  • Избегай паттерна «Ты молодец, НО ...» (это всё обесценивает).
  Развернуть 1 комментарий

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

  Развернуть 1 комментарий

@artemy_l, да, без проблем

  Развернуть 1 комментарий

@cat, у нас project manager всех постоянно хвалит за вложенные усилий и проделанную работу. И это реально помогает поддерживать хорошую атмосферу в коллективе, даже если на самом деле работа была выполнена так себе.

  Развернуть 1 комментарий

Спасибо, статья очень дельная)

ещё 1-2 примера задач такой сложности - и на следующем ревью мы сможем обсуждать повышение

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

  • вы на 100% уверены, что можете повысить человека либо прямо сейчас, либо, если таков процесс, на ближайщем ревью, но железно что бы ни случилось
  • вы не боитесь единомоментно потерять свой авторитет руководителя и разрушить те самые доверительные отношения
  Развернуть 1 комментарий

@vlcmdc, разговоры про повышения - это вообще дело тонкое. Со своей стороны я бы сформулировал так - обсуждать можно и нужно, обещать без 100% уверенности не стоит.

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

  Развернуть 1 комментарий
Roman Kagan Punk, СТО, IT Project Manager 23 декабря 2023

Привет, хороший пост. Есть один момент, с которым не согласен

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

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

Единственным методом тут будет - как психолог, бережно и наводящими вопросами докопаться до сути. И решить проблему в режиме win-win. Если это страх, то страх чего? Осуждения? Неопределенности? Если человек не любит решать такой тип задач, то почему? Может он чувствует, что на него скидывают всякое дерьмо, или у мего и так куча задач, или может он и вовсе перегорел и раздражается от всего.

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

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

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

  Развернуть 1 комментарий

@roman09, я думаю тут стоит уточнить - начиная с того, что подразумевается под закреплением ответственности.

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

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

Единственным методом тут будет - как психолог, бережно и наводящими вопросами докопаться до сути. И решить проблему в режиме win-win.

И есть убеждение.

  Развернуть 1 комментарий

@roman09,

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

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

  1. Требование. При масштабировании одного из направлений разработки я обратил внимание на то, что большинство разработчиков в направлении не любят проводить технические собеседования. Никаких формальных требований к тому, что собеседования относятся к обязанностям разработчика не было, найм планировался большой, и если брать только одного разработчика, для которого участие в собеседованиях было нормой, то нагрузка по собеседованиям на него занимала бы значительные ресурсы в его фичекоманде, и это направление в его фичекоманде стало бы отставать, при этом другие фичекоманды своими ресурсами в этом бы не участвовали. Соответственно когда мы формализовывали требования к грейдам, мы прописали там что к обязанностям сеньор разработчиков относится в том числе и проведение технических собеседований когда в компании идет найм по направлению, и отказ от участия в собеседованиях стал отказом от выполнения своей работы, а задача провести техническое собеседование стала равносильна задаче реализовать определенную фичу. Естественно, при планировании собеседований мы учитываем нагрузку на команды и приглашаем проводить собеседования в первую очередь тех разработчиков, которым нравится в них участвовать, но проблему неравномерного распределения этой обязанности по командам мы решили.
  2. Убеждение. Тут подходит пример с автоматизацией релиза - разработчик из кор команды не был готов взять на себя ответственность за задачу, потому что никогда не работал с инфраструктурной частью и не был уверен что справится с задачей. Аргументов для убеждения у меня было 2 - во-первых, мы декомпозировали задачу сделали вывод, что со всем кроме инфраструктуры для хостинга бота он справится, а с хостингом помогу я и при необходимости привлеку девопса, во-вторых, как я уже писал в статье - задача в соответствии с нашими грейдами тянула но повышение по грейду, и, соответственно, зарплате.
  3. Просьба. У нас в компании мобильные приложения релизятся по расписанию, которое составляется заранее раз в квартал. Расписание включает дату релиза и ответственного релиз менеджера. Расписание учитывает отпсуска и нагрузку на команды, в случае если релиз менеджер не может отвечать за релиз, он может поменяться с кем-то другим предупредив заранее. И в какой-то момент релиз менеджер заранее не предупредил. У меня как у ответственного за мобильные релизы было 2 варианта - забрать обязанности релиз-менеджера себе или попросить кого-то из команды помочь, то есть сделать больше, чем есть в оговоренных обязанностях и запланированных задачах. И в этом случае я обратился к разработчику, объяснил ситуацию и попросил выручить.
  4. Приказ. Этот пример будет из опыта разрешения инцидентов на проде когда от скорости принятия решений зависит скорость восстановления работы сервися и размер потерь компании из-за простоя. Пример заключается в том, что я, как ответственный за всю систему могу отдавать приказы дежурным разработчикам, возможно, не знакомым с теми частями системы, над исправлением которых мы работаем, в случае когда решения проблемы не прописано в инструкциях или есть разные варианты - само собой принимая во внимания их возражения, так как и я могу совершить человеческую ошибку - но не тратя в моменте времени на убеждение в правильности своих решений или объяснение своих требований формальными правилами - как говорится, «под личную ответственность».
  Развернуть 1 комментарий

У нас есть проблема - ответственные за релиз разработчики тратят много времени на релиз.
Подготовь RFC как бы можно было решить эту проблему.

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

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

За статью спасибо <3

  Развернуть 1 комментарий

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

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

Что касается оверинжениринга - это скорее относится к вопросу о релевантности и контекста. Объясню на приведенном примере - одно дело если мы пишем свой CI/CD, который мы будем продавать как продукт и который должен уметь обрабатывать тысячи релизов одновременно, другое дело - мы делаем простой скрипт для себя. В первом примере я бы уделил много внимания как будет храниться информация о релизах чтобы нормально работали консистентность/доступность/масштабируемость, во втором случае можно поставить вопрос нужно ли вообще хранить где-то информацию о релизах и если нужно - как это сделать проще :)

  Развернуть 1 комментарий

Спасибо за интересный пост! Случайно не хочешь его сделать публичным? Очень хочется его показать паре людей снаружи

  Развернуть 1 комментарий

@khvostikovao, хочу и даже планирую опубликовать ещё на нескольких ресурсах после того как соберу обратную связь

  Развернуть 1 комментарий

@khvostikovao, к сожалению не вижу кнопки сделать публичным при редактировании поста, возможно, сейчас уже нельзя, поэтому оставлю ссылку на публикацию на хабр - https://habr.com/ru/articles/783096/

@moderator можно сделать пост публичным?

  Развернуть 1 комментарий

@artemy_l, готово

  Развернуть 1 комментарий

Недавно читал такое: https://razrabs.ru/post/0e4e0a21-7fab-4f7f-a5f8-250b460e4d21

  Развернуть 1 комментарий

@da4nik,

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

Сам через такое проходил, в том числе по следам этого опыта и решил для начинающих лидов в моей команде этот путь сделать проще 🙂

  Развернуть 1 комментарий

Спасибо! Отличный пост, всё коротко и по делу :)

Единственный "косметический" момент: часть "Как формулировать задачу", последние 2 абзаца. Может быть их переформатировать в 3-4 абзаца или добавить что-то вроде форматированных списков действий, формул на новой строке, внутрь? Я, честно говоря, при первом прочтении их проскочила, потом вернулась и перечитала 😄

  Развернуть 1 комментарий

@nadjam, спасибо за обратную связь, подумаю

  Развернуть 1 комментарий

😎

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

Что вообще здесь происходит?


Войти  или  Вступить в Клуб