Тимлиды и разработчики

Вернёмся года на два назад, когда я был разработчиком. Что я думал? Хочу стать тимлидом. Это круто, он решает все вопросы, получает больше денег, им становятся после сеньора. Тогда не было никого, кто сказал бы мне: это вообще про другое. Пришлось учиться на своих ошибках.

Я дважды становился тимлидом

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

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



А еще делали все сами как умели. Помню, как ставил Ubuntu на рэковый сервер, который отдал нам один из инвесторов. Когда я включал его, он издавал звук взлетающего вертолета!

Там я дорос до статуса техдира и работал с командой из 10 человек. По сути, первый, по наитию, опыт тимлидства случился там.

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

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


Особенно запомнилась Scrum и XP: заметки с передовой от Хенрика Книберга. Процесс в D был выстроен близко к этой методологии: в результате весь менеджмент и продавцы отлично понимали, когда будет результат.

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

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

Так Петя меня раскусил и узнал про опыт руководства командой в T и заочном обучении скраму в D.

В какой-то момент он предложил мне провести стендап.


Операция преемник в моем случае выглядела вот так и заняла 6 минут)

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

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

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

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

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


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

Что поменялось и как я с этим боролся

Первые несколько дней ты живешь с ощущением эйфории, триумфа и восторга. Ещё бы: ты у руля целой команды, на тебя сделана ставка, у тебя больше возможностей и ответственности! С момента ухода из Т прошло несколько лет, я набрался опыта, проанализировал свои ошибки, увидел продвинутые процессы и методологии и поработал по ним. Все это давало мне силы и уверенность для второго захода в тимлидство.

Однако со временем чувство эйфории прошло, наступили будни. Вот что я заметил за собой.

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


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

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

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

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



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

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

Ты рискуешь превратится в оператора колл-центра и если не остановить это, выгорание гарантированно в течении одного-двух месяцев.

Тут я хочу передать привет сказать искреннее спасибо своему продакту. Увидев эту проблему, он отправил меня читать Джедайские техники Дорофеева, Тайм-менеджмент Архангельского, а также изучать каналы и чаты для тимлидов, записи с конференций и так далее.

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

В общем, пришлось ломать свои привычки и экстренно осваивать кучу полезных техник.

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

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

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

Больше не тимлид: как не потерять себя и найти снова

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

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

Проработав на позиции лида полтора года (с сентября 2018 по февраль 2020), я осознанно решил оставить эту роль и вернулся в разработку. За это же время тимлид, канал которого я читал, дорос CTO в моей компании.



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

А этим летом мы с еще парой ребят, прошедших подобный путь, сделали внутренний митап о своем опыте. И самый главный вопрос, который возник у слушателей: ок, а как понять, когда думаешь, куда развиваться дальше, роль тимлида это твоё или нет?

Так пришла идея обсудить его в публичном формате с:

• Егором Толстым (подкаст и курсы Podlodka) он сделал выбор в пользу управления продуктом и расскажет о моменте, когда понял, что устал от руководства разработкой,
• Вадимом Мартыновым (Контур и сообщество RndTech) он вернулся в разработчики и расскажет, как переучивался писать код и как все это сказалось на финансах,
• и Евгением Котом (Wrike и тот самый доклад о болях тимлида) в качестве ведущего.

Все пройдет онлайн в ближайшую среду (2 сентября) в 19 часов по Москве/Киеву/Минску на ютубе: для зрителей будет чат и простая возможность включиться голосом. А если у вас останутся силы пообщаемся в зуме.


Здесь можно поставить напоминалку в календарь.

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

фото с сайта pilot.com
В 2012 году Джессика МакКеллар с командой друзей из MIT (Мичиганский Технический Университет) запустила стартап скрытого чата Zulip. Менее двух лет спустя его выкупил Dropbox. И в этом не было ничего необычного. С ее командой такое уже случалось, когда они так же быстро продали Ksplice компании Oracle. Такая бешеная гонка дала МакКеллар больше опыта в разнообразных возможностях менеджера, чем обычный инженер получает за всю карьеру. Она была тимлидом, основателем, техлидом в огромной корпорации, а сейчас руководит десятками сотрудников в быстрорастущем международном стартапе. (Да, она еще и значимая фигура в мире Python). В статье Джессика рассказывает о своем опыте и подходе к управлению командами.

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

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

Что значит напрямую поддерживать команду?

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

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

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

Большую сложность представляет вопрос, как помогать людям строить долгосрочный план по достижению удовлетворенности и продуктивности в вашей компании. Сюда относится много факторов. Если немного упростить, то 50% помочь людям понять, что они хотят делать, и 50% включить это в ежедневную рутину, планирование и проекты.

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

Хорошие лидеры экспертно вычленяют эту информацию и делают такой вариант осуществимым.

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

1. навыки, которые они хотят улучшить;
2. технический и нетехнический опыт, который хотят получить;
3. насколько они хотят расширить пределы своего влияния в компании.

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

Раз в квартал я говорю: Отлично. Следующая неделя посвящается карьерному росту. И на личных встречах мы говорим именно об этом.

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

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

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

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

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

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

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

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

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

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

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

Производительность вашей команды = ваши возможности как руководителя

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вам нужно непрерывно прокачивать всех членов команды. Мастерство подтянется.

Помимо руководства командами инженеров в Dropbox Джессика МакКеллар еще является директором Python Software Foundation. Она ведет твиттер @jessicamckellar. Фото: Бонни Рай Миллз

Помогайте людям работать быстрее с помощью правильных инструментов

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

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

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

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

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

Среда

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

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

Летучки

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

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

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

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

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

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

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

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

Мотивация

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

Люди всегда с энтузиазмом относятся к новому большому делу. Сложнее оказывается доделать последние 5% проекта, на который ты уже потратил вечность. И в такой ситуации нам надо, чтобы над задачей трудился тот, кто горячо заинтересован в работе и хорошо понимает, откуда взялся Dropbox. Наш бренд всегда запускает что-то классное, а для этого приходится основательно вкалывать над последними 5%.

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

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

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

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

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

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

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

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

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

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

Сейчас расскажу, как узнать настроение команды, если она даже раз в квартал не хочет отвечать на занудные вопросы

Откажитесь от почты

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

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

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

Правильно задавайте вопросы

Задавайте не больше шести вопросов только самое важное. Если переборщите с количеством, это перестанет быть увлекательно и всем будет тупо лень, а ответы если и будут, то очень поверхностные. Если спросите слишком мало, то не покроете важные темы. Подумайте, что вам важно: продуктивность, переработки, удовольствие?

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


Вопросы можно изменять ситуативно: однажды мы отказались от всех встреч и сразу узнали мнение через опрос.

Вот список вопросов, которые я задаю команде:

Как часто ты чувствовал, что у тебя закончились силы выполнять задачи?

• Ни разу
• Один раз в неделю
• Два-три раза в неделю
• Почти всю неделю

Ты получал удовольствие от задач?

• Да
• Скорее да
• Задачи как задачи
• Скорее нет
• Нет

Как часто ты испытывал тревогу за задачи или проект?

• Ни разу
• Один раз
• Два-три раза в неделю
• Почти всю неделю

Сколько часов ты переработал? (сумма за неделю)

• 0
• До 2х
• От 2х до 4х
• От 4х до 8ми
• От 8ми до 12ти
• Более 12ти

Тебе понравился спринт?

• Лучший спринт
• Хороший спринт
• Норм
• Ну такое
• Это провал

Одно время вместо вариантов ответов я просил дать оценку от 0 до 10, но это абсолютно плохая идея, не делайте так. Оценка цифрой очень относительна, ведь человек, который привык овертаймить, поставит от 4 до 7 баллов за тот же набор задач, за который обычный сотрудник смело ставит больше 8. Но ещё сложнее сделать выводы и обсуждать средние значения из таких данных.

Проанализируйте ответы

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





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

Бонус. Личная динамика

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



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

---

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

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

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

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

Об уровне владения технологиями

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

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

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

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

Должен ли тимлид постоянно писать код?

На мой взгляд ни в коем случае. Иначе это не тимлид, а высокооплачиваемый разработчик. Но если тимлид не пишет код, то зачем все эти знания? Как говорит Егор Толстой: тимлид это снежинка, и наша диаграмма из предыдущей статьи тому подтверждение:

Я отнёс к блоку технологий в обязанностях тимлида четыре области:

• инженерная культура;
• Agile-процессы;
• SLA;
• постоянное улучшение качества.

Что я понимаю под инженерной культурой?

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

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

• архитектурные стандарты;
• типовые решения;
• правила оформления кода (stylе guides);
• стандарты code-review;
• автомацизация рутинных операций;
• практики сообщества;
• работа с техдолгом;
• документация.

Ко второй части относятся неосязаемые понятия, которые также зависят от тимлида:

• внутренний стандарт качества команды;
• ответственность за принятие решений;
• научный подход;
• нетерпимость к плохим решениям;
• открытость к экспериментам;
• ориентация на результат.

Agile-процессы

Почему я пишу Agile? Почему не рассматриваю другие подходы к разработке? Потому что, на мой взгляд, ничего лучше, чем Extreme Programming и принципы Agile Manifesto ещё не придумали. Как еще нам действовать в условиях неопределённости, в которых работает большинство из нас?

Почему налаживание процессов проблема тимлида? Я уверен, что невозможно выпускать стабильный продукт вовремя без налаженных процессов в разработке. Как мы передаём задачи от продукта в разработку? Как проверяем гипотезы? Как уменьшаем риски вкладывания наших усилий не туда? Как релизим? Как даём быструю обратную связь заказчику? Если на эти вопросы не будет чётких ответов, на каждом этапе разработки будут потери времени и усилий на их прояснение. Поэтому, процессы должны сидеть в подкорке мозга каждого члена команды, включая бизнес, дизайн, разработку. И работа тимлида как раз состоит в том, чтобы эти процессы наладить и закрепить. Для этого хорошо подойдёт cookbook свод правил, который стоит обсудить со всеми членами команды и выложить на Confluence/вики/базу знаний команды, показывать новым членам команды при введении в работу, и постоянно совершенствовать его.

SLA

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

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

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

Мониторинг сервисов

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

Архитектурная схема

Когда я говорю архитектурная схема, я не имею в виду чертёж размером со стену, распечатанный на листах А1 (доводилось видеть и такое). Я, скорее, подразумеваю, что тимлид должен знать все компоненты (микросервисы) в своём владении, бизнес-логику, по которой эти компоненты обмениваются данными, типовые сценарии использования сервиса. Также тимлиду нужно знать путь запроса до приложения со всеми балансировщиками, API-гейтвеями, waf-ами, IPS-ками, ингрессами и прочими проксями это позволит быстро диагностировать проблему и найти ответственных.

Настроенный доступ

Даже при хорошо налаженной схеме дежурства может случиться так, что дежурный недоступен (сел телефон, отключили интернет, крепко спит и т.д.). И в таком случае всё равно реагировать придётся тимлиду. Поэтому важно иметь настроенный доступ во все критические системы, которые могут пригодиться при диагностировании и решении проблемы. Для меня это реплики баз данных, поды Kubernetes/kubectl, ELK, CI/CD, UI RabbitMQ, и конечно VPN, чтобы добраться до всего этого.

Отношения со смежниками

Не секрет, что в современном мире команда разработки не делает продукт в вакууме: всегда, как минимум, есть команда DevOps/эксплуатации, подрядчики с дата-центрами, служба безопасности со своими прокси, DBA с базами, провайдеры связи, DNS, CDN и бесконечное число внешних интеграций. При сбое любого из этих узлов может возникнуть ощущение, что ваш продукт не работает. В этом случае координировать усилия по устранению проблемы придётся тимлиду. Очень важно при этом быть на короткой ноге со смежными командами/подрядчиками: как минимум, нужно иметь все контакты (почтового адреса недостаточно, нужен номер телефона или аккаунт мессенджера). Но лучше, когда у вас со смежниками есть общий чат, в котором в любое время можно организовать взаимодействие. Помогает также заранее провести учения по имитации недоступности систем (мы писали об этом тут), итогом которых станет протокол реагирования на инциденты.

Постоянное улучшение качества

Не секрет, что в погоне за time-to-market мы часто принимаем быстрые решения и встраиваем костыли в наш код (конечно же, с намерением вернуться и всё отрефакторить, когда будет время!).

Как только такое быстрое решение поселилось в вашей кодовой базе, оно становится проблемой тимлида, потому что влияет на поддерживаемость и расширяемость сервиса. Задача тимлида сделать так, чтобы все подобные задачи на рефакторинг регулярно попадали в бэклог команды. Иными словами, тимлид должен организовать в команде работу с техническим долгом. В нашей компании принято выделять 20 % спринта на работу с техдолгом, причём эта квота не включает в себя баги и написание тестов такие задачи мы относим к продуктовым.

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

Заключение

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