Станислав Капинус
Тимлиды
2. Стендапы
Рабочий день почти каждой команды тимлидов Профсоюза начинался со стендапа. Это был короткий созвон, на котором все участники команды рассказывали о том, чем занимались в предыдущий рабочий день и чем планируют заниматься в этот. До пандемии, когда люди ещё ходили в офисы, стендапы проводились очно и иногда стоя, отсюда и пошло название мероприятия. Смысл совещания на ногах был в том, что оно должно быть настолько коротким, чтобы участники не успевали устать. Стендап был индикатором процессов, протекающих в команде, и любому опытному программисту, тестировщику или аналитику в первый же день работы в команде открывал глаза на то, не зря ли он принял оффер12.
Долгие стендапы с нудными диалогами обычно были свидетельством того, что организатор мероприятия, будь то тимлид или менеджер, не в курсе происходящего в проекте, поэтому ему нужны долгие общекомандные собрания, на которых ему объяснят проект. Часто, если стендапы вел менеджер и он растягивал собрание, это были знаком его низкой технической грамотности и неспособности решать технические задачи. Такой менеджер будто слепец ориентировался на интонации участников, не доверял коллегам. Он не был способен самостоятельно понимать проект и будто проводил очные ставки между подчиненными. Неизбежным выводом из долгого утреннего совещания также было то, что его организатор не очень ценил рабочее время: свое и своих коллег. Чем большее время тратилось на совещания, тем меньше времени оставалось, собственно, на работу.
Тимлид, который проводил стендап и хотел, чтобы его команда в этот день успела поработать, делал стендап коротким. При этом ещё до стендапа он, скорее всего, знал все, что ему на стендапе скажут участники. О выполненных или не выполненных задачах он знал из репозитория и таск-менеджера, которые посмотрел перед совещанием. Кроме того, он, скорее всего, вел краткую запись сказанного на стендапе и мог быстро освежить воспоминания о предыдущем. Стендап был своего рода кратким ежедневным парадом, на котором надо было убедиться, что все в добром здравии, помнят, какой сегодня день и чем они занимаются. Это не было совещанием, на котором действительно решаются важные организационные или технические вопросы. Разумеется, такой подход требовал от тимлида работы: частые созвоны один-на-один и коммуникация в мессенджерах были необходимым условием эффективной работы команды в условиях удаленной работы.
Важнейшим вкладом руководителя в общее дело являлось определение процессов и коммуникации внутри команды. Перечень обязательных совещаний, регламент этих совещаний, допустимая лексика и формат общения участников, формы постановки задач и проверки результата, вопросы найма и увольнения, инкорпорации нового участника и вывод за пределы команды увольняемого – эти вопросы опытный тимлид должен был определить для себя и «продать» своей команде. Это мог быть популярный в России, имеющей развитую военную культуру, агрессивный армейский стиль, допускающий обсценную лексику и разные формы психологического давления. Таким стилем мог быть и более современный, не связанный с строгими иерархиями, способ взаимодействия участников, в котором поощрялось горизонтальное взаимодействие всех участников, в том числе и руководителя, который в практикующем эту схему коллективе становился первым среди равных, и от которого, как и от всех остальных, требовалось вносить вклад в общее дело, а не только присваивать себе чужой результат.
В конечном счете культура и стиль руководителя, проецируемые на команду, приводили к прибылям или убыткам. Люди уходили из команд с плохой организаций, с хамоватым и технически некомпетентным руководством, бежали от неоплачиваемых переработок, и наоборот, с удовольствием работали в командах с минимумом совещаний, слышащим их руководителем и настроенным процессом разработки.
В 9:30 Вячеслав привычно начал стендап руководителей в своем основном проекте. На стендапе были тимлиды всех подчиненных ему команд и некоторые менеджеры. Каждый из тимлидов говорил о результатах своей команды на вечер пятницы предыдущей недели. Вячеслав уже посмотрел их репозитории, понимал, что было сделано, двигаются ли команды в соответствии со своими планами или отстают. В целом все было в порядке. Система, выстроенная им, работала как часы. Лишь одно на этом стендапе, как и на предыдущих за две недели, вызывало беспокойство. Тимлид команды «Кастомных13 решений» вовсе не хотел быть тимлидом. «Кастомными решениями» в компании назывались доработки коробочной версии системы документооборота, являющейся основным продуктом, для крупных заказчиков, которые хотели иметь особенную функциональность. Обычно эти доработки были связаны с устаревшим программным обеспечением на стороне заказчика, для интеграции с которым и требовались доработки.
Тимлид, который возглавлял эту команду более трех лет, перед новым годом заявил об увольнении и сразу после праздников ушел из компании. Он захотел стать тревел-блогером, путешествующим по миру и публикующим в социальных сетях рекомендации о том, как это делать правильно. Работу java-разработчика и руководителя разработки он назвал предельно скучной на данном этапе его жизни, впрочем, на выходном интервью высоко оценив уровень разработки в компании, сказав пару приятных слов в адрес Вячеслава. Последний оказался в сложной ситуации выбора технического руководителя важной с точки зрения бизнеса команды в короткий срок без явных кандидатов на должность. В обычных обстоятельствах он бы временно возглавил команду сам и без спешки нашел нового тимлида. Но уже несколько месяцев все мысли Вячеслава были связаны с подготовкой дела, дополнительная нагрузка была совершенно некстати. Поэтому тимлидом был назначен один из старших разработчиков команды, не имевший прежде опыта руководства.
Когда до него дошла речь на стендапе, Вячеслав попросил задержаться после собрания. Нужны было понять, сколько времени есть у компании до потери одного из лучших разработчиков компании из-за выгорания на должности, которая была тому лишь обузой. Оставшись вдвоем, Вячеслав начал:
– Как у тебя дела, Дмитрий? На стендапе сказал, что все по плану, но тон был мрачноватый. Надеюсь, это из-за бурно проведенных выходных? – ответ он знал, но надо было с чего-то начать диалог с 28-летним разработчиком, которого он насильно вытолкнул из зоны комфорта.
– Вячеслав Сергеевич, нет, выходные были спокойные, с подругой провел. Я уже говорил, не радует меня тимлидом быть. И коллег-разрабов тоже не радует, что я тимлид. И ваши советы про созвоны один-на-один не работают, – тараторил разработчик. – От меня ждут лидерства, энергии, решений, нет их у меня. В итоге мне приходится половину времени изображать себя лидером, а за вторую половину рабочего времени делать свои задачи и задачи разрабов, которые они делают вид, что не могут сделать! Я устал от этого, давайте что-то делать.
– Понимаю, Дим, – успокаивающе начал руководитель, – у меня так же было на первых проектах, где я лидом был. Коллегам, которые знают тебя как разработчика, сложно привыкнуть к твоему новому статусу и смене ролей.
– Да не в этом дело, – распаляясь, перебил Дмитрий. – Мне самому сложно привыкнуть, да и не хочу я привыкать. Мне нравится работа разработчика, нравится спокойно решать технические задачи, писать код. То, как у нас разработка устроена, меня полностью устраивает, но с позиции разработчика, а не тимлида. Все, что я хочу, это получить нормальную задачу в jira14, задать пару вопросов аналитику, писавшему постановку задачи, и начать код делать. А потом быстро найти решение задачи, отдать тестировщику и без багов провести ее в мастер-ветку. А в конце спринта с гордостью видеть, что я сделал больше задач за две недели, чем любой другой разраб в команде. А что сейчас? Я все время на нервах, у меня весь день в совещаниях, код пишу урывками, все мне вопросы задают, а я не хочу на них отвечать! Я сам вопросы хочу задавать!
Вячеслав рассмеялся, полностью понимая психологическое состояние коллеги, он и сам когда-то такое чувствовал. Понимал он и то, что этот сложный переходный этап надо перетерпеть, перерасти. Эта была затянувшаяся инициация, которую адепт проваливал, соскальзывая в свое предыдущее состояние. Для роста нужен мотив, а здесь его не было.
– Ладно, – примирительно сказал тимлид тимлидов. – Дай мне две недели, за это время я найду тимлида и перестану тебя мучать. Подходит?
– Да!
Закончив конференцию, Вячеслав откинулся в кресле перед компьютером и прикрыл глаза. До следующего стендапа оставалось 8 минут, этого было достаточно для непродолжительной медитации. Работа, состоящая из большого числа быстро сменяющих друг друга совещаний, требовала важного навыка: не потерять себя в этом калейдоскопе серых скучных разговоров, большей части из которых можно было бы избежать, будь их организаторы более умны и менее ленивы. Опустив фокус внимания внутрь себя и сосредоточившись на наблюдении за потоком бегущих мыслей, Вячеслав обнаружил пустоту: поток был пока тих. Это было хорошим знаком, знаком того, что происшествия утра ещё не внесли хаос в его внутреннее состояние, полет был нормальным.
Следующий стендап был отдыхом: в десять утра по времени Петербурга проводилось ежедневное совещание блокчейн-стартапа, в котором Вячеслав был кофаундером15. Время было неудобно почти всем участником распределенной по миру команды – они жили в разных часовых поясах России, Европы, США, Азии – и было выбрано волюнтаристски: так решили трое основателей из Петербурга. На стендапе этой команды было без сюрпризов: работа медленно, но шла. Инвестиций, полученных в последнем раунде, хватит ещё на год, поэтому разработка шла без спешки, в роадмап16 укладывались.
В это же время по всей стране проводились аналогичные утренние совещания в командах разработки и эксплуатации всех продуктов, какими пользовалась страны, континенты, мир. Вслед за Азией и Россией, начинали работать команды Восточной Европы, затем Западной, поддерживая жизнь человечества, немыслимого без программного обеспечения телефонов, компьютеров, сетей, невозможного без железа, на котором этот софт крутился, без серверных мощностей, дата-центров, распределенных по миру, за которыми следила армия системных администраторов и девопсов. Все эти люди делали невидимую и незаметную работу, а заметной вершиной айсберга этой работы были сотовый телефон в кармане каждого человека планеты, исправно соединяющий его с миллиардами людей и организаций в единый организм.
3. О тимлидстве
В начале рабочей недели мессенджеры и почта были в центре внимания Вячеслава. Они, будто перебрав с жирной едой и алкоголем за выходные, требовали к себе пристального внимания примерно до середины недели. Если этого внимания они не получали, начинались проблемы. Отправители сообщений, спрашивавшие подтверждение на что-то или нуждавшиеся в помощи в связи с своей работой, откладывали беспокоящие их вопросы без решения или решали самостоятельно, как могли, без учета целого. Правильно выстроенная коммуникация имела тот плюс, что к Вячеславу попадали только те вопросы, которые действительно требовали его участия, исключения были редки. Большинство задач брали на себя тимлиды и менеджеры команд разработки. Над системой документооборота трудилось с десяток таких команд, всех тимлидов Вячеслав нанимал лично и был в них уверен, зная сильные и слабые стороны каждого.
В задачи тимлида входило три круга вопросов: технические, организационные и психологические. Во-первых, тимлид был техническим специалистом, чаще всего разработчиком, и должен был принимать архитектурные решения в своем проекте, смотреть код, по возможности писать код, оптимизировать работу приложений, искать пути технического усовершенствования компонентов проекта, пристально следить за состоянием модели данных и взаимодействий приложений между собой и базами данных. Круг подобных вопросов был широк и здесь тимлид выступал как старший разработчик и архитектор. В рамках этого круга вопросов тимлид мог быть демократичен и принимать решения в совете с подчиненными или более авторитарен, навязывая свои решения коллективу. И здесь при любой более-менее большой команде начиналась «политическая» жизнь команды, на свет выходили вопросы власти и подчинения, конкуренции, мобилизации, пассивности и апатии. Если команда не доходила до подобной политики, это означало, что общение между участниками поверхностно, вовлечение в проект низкое, следствием была низкая продуктивность. Способность использовать «политическое» как инструмент, влияющий на эффективность команды, была опасным и редким навыком высококлассного тимлида.
Следующим набором вопросов, решаемым тимлидом, была организация процесса разработки внутри команды. Эти вопросы были связаны с предыдущими. При хорошей архитектуре проекта и высокой технической компетентности команды можно было организовать достаточный набор устойчивых стендов разработки, автоматический деплой на эти стенды из единого репозитория проекта любой ветки кода, прозрачную структуру самих проектов в репозитории, автоматическую работу статических анализаторов и прогон автотестов. Впрочем, были нередки проекты, где разработчики делали ручную сборку проекта и самостоятельно выкладывали каждый артефакт на стенд для тестирования, где покрытие тестами почти отсутствовало и где для любой операции с кодом требовалась вовлеченность нескольких участников. Сделать слаженный конвейер разработки от получения требований заказчика и фиксации их в таск-трекере через ревью этих задач командой, разработку, тестирование, код-ревью к выкатке релиза было нетривиальной задачей и не каждый тимлид был к ней готов. Эта была менеджерская, управленческая работа, требовавшая непрестанного контроля и исправления неэффективностей. Менеджер никогда не брал ее на себя, так как в сущности и не знал, что нужно технарям, и был заинтересован лишь в выполнении задач заказчика. Лидер технарей должен был взять на себя эту ношу.
Последним, замыкающим набором задач тимлида были вопросы психологические. Они также были связаны с вопросами организации и техники в команде. Психология команды юных новичков-студентов отличалась от психологии зрелых сеньоров с женами и ипотеками. Любое нестандартное в сравнении с среднеотраслевым распределение участников по гендеру, культурным особенностям, языку, навыкам, возрасту также накладывало свой отпечаток на работу тимлида с командой. Тимлид был обязан навязать коллегам общий стиль коммуникации и некое видение, объединяющее отдельных людей в единую команду. В случае, если такого не происходило, если команда была только на бумаге, эффективность работы была низка. Деятельность тимлида мало отличалась от работы тренера футбольной команды в этом аспекте. Если он не справлялся, по полю бегало одиннадцать не слаженных хулиганов без царя в голове. Если же ему удавалось сделать свою работу, то на поле выходила эффективная машина, где каждый знал и любил свою роль, четко взаимодействовал с другими, видел свою и общую цель. Взаимная поддержка при личной ответственности каждого делала разрозненных индивидов единым организмом.
Обычно тимлидами становились старшие программисты. Чтобы качественно руководить командой разработки надо было иметь большую насмотренность на проекты, команды, людей в отрасли. Для приобретения такого опыта нужно было побывать и в хороших, и в плохих проектах. Нужно было насмотреться на тимлидов и менеджеров, кричащих на подчиненных, неспособных к планированию даже на пару недель вперед, технически безграмотных и психологически незрелых чтобы четко понимать, как делать не стоит. Это было необходимо, чтобы знать установки травмированных предыдущим профессиональным опытом людей, приходящих в команду. Это было важным и чтобы видеть и правильным образом взаимодействовать уже с собственным руководством, которое зачастую рекрутировалось из тех самых кричащих и неспособных.
Особенностью рынка труда был огромный дефицит работников: разработчиков, тестировщиков, аналитиков, девопсов. Найм квалифицированных сотрудников был непростой задачей даже для крупных компаний с узнаваемыми брендами и большими зарплатами. Поэтому каждый участник команды был ценностью, а не рядовым винтиком. Если же руководство не понимало этих очевидных вещёй, в команде росла текучка кадров, умные уходили, приходили разные, качество разработки падало, росло число багов в релизах. Хорошие разработчики естественным образом перетекали из плохих команд в лучшие, часто в конечном итоге оказываясь за границей. Россия проигрывала в этом отношении многим другим странам не столько деньгами, которые могла предложить своим умным сынам и дочерям, сколько традиционно бездушным и холодным отношением к ним. Традиционная управленческая культура страны много брала от армейской коммунистической или царской организации, навязывала жесткие иерархии. Проецируя на команду разработки устаревший мировоззренческий взгляд, она неизбежно выдавливала всех, кто перерос позицию рядового солдатика, готового за случайные интересы начальника к невиданным жертвам.
Команды, основанные на принципах меритократии17, а не отрицательной селекции в долгосрочной перспективе имели преимущество перед остальными. Лидеры, способные объединить вокруг себя коллективы, были ценны и значимы. Вместе с тем они представляли опасность для тех, чье кредо было «разделяй и властвуй». Проектная работа часто не предполагала долгосрочности и позволяла на короткой дистанции выживать управленцам низкого качества. Как разработчики в поисках лучшей жизни в конечном счете зачастую оказывались за границей, так и низкокачественные управленцы с тем же естественным каждому человеку желанием в итоге часто оказывались на государственной или окологосударственной службе. Именно эта часть рынка вбирала в себя вполне определенный тип менеджеров, чувствовавших себя как рыба в воде среди крупных государственных контрактов, бессмысленных идей, низкой технической компетентности, имперско-реваншистских фантазий и абсолютно безразличного отношения к человеку.
Бегло просматривая пришедшие за выходные сообщения Вячеслав выстраивал в уме последовательность необходимых действий. Его базовой задачей, как он ее себе представлял, была расчистка пути для каждой из команд, находившихся в его подчинении. Под расчисткой пути он понимал устранение любых препятствий, мешающих или замедляющих работу команд. Программой-минимум было сделать разработку возможной, убрать стопперы. Программа-максимум заключалась в том, чтобы разработка, которая стала возможна, была быстрой и качественной. И здесь Вячеслав старался усилить каждого из своих тимлидов, желательно без погружения внутрь их команд.
Так, кто-то из тимлидов мог быть прекрасным программистом, возможно единственным человеком команды, сопровождающим проект с самого старта, знающего каждую строчку кода. Но будучи слабым коммуникатором он проваливал организационные и психологические задачи, стоящие перед тимлидом. Это требовало компенсации, так как команды без здравой организации и хорошего психологического фона разваливались. Такие проекты имели тенденцию превращаться в сцену солирования такого незаменимого разработчика. Ключевым вопросом было: тимлид ли он, объединяет ли он вокруг себя людей, сплочает ли он коллектив, ведет ли он людей за собой, мотивирует ли он их просыпаться на работу или все, чего они ждут – это окончания рабочего дня? Вячеслав находил людей с лидерскими качествами среди старших разработчиков и именно их ставил на позиции тимлидов. Таких было видно: они даже без официального титула объединяли вокруг себя несколько разрабов послабее, менторили18 их. Они находили неэффективности процесса разработки и меняли его, они старались оптимизировать свою работу и автоматизировать ее.
Проблемой попроще была нехватка у тимлида технических компетенций. При должных навыках общения и способности к обучению тимлид быстро компенсировал это с помощью сеньоров проекта, попутно сплочая коллектив тем, что не боялся выглядеть в глазах других не знающим чего-то, не старался быть самым умненьким в комнате. Ведь главной задачей тимлида было движение разработки вперед, а то, в какие отношения он захочет и сможет поставить себя по отношению к другим участникам команды, было второстепенным. Усилить команду и тимлида в техническом смысле можно было и введением новых сеньоров в команду. Но важным источником роста команды, который никогда нельзя было недооценивать, была синергия, возникающая на стыке составных частей команды. Так, сильный тестировщик, не пропускающий забагованный код, стимулировал разработчиков строже относиться к своему труду. Сильный девопс, способный автоматизировать процессы работы с репозиторием, базами, стендами, освобождал разработчиков от рутины и сохранял их время для важного: написания кода. Высококлассный аналитик четкими определенными постановками минимизировал возможные разночтения в задаче, давая возможность разработчику и тестировщику одними глазами смотреть на работу. Менеджер и тимлид, грамотно организовавшие внутрикомандную коммуникацию, минимизировавшие бесплодное общение, потери времени, берущие на себя внешнекомандную коммуникацию, позволяли разрабам сосредоточиться на работе без энергозатратного переключения контекста. Каждый вносил свой вклад и обогащал другого при правильной организации работы.
Тимлид был и психологом своей команды. Специфическая селекция, делавшая многоступенчатый отбор в профессию, начиная с математических классов школ через технические факультеты университетов, ставящая перед людьми особенные интеллектуальные задачи, приводила к преобладанию в отрасли определенного типа человека. И этот человек часто с трудом понимал свое психологическое состояние, не умел с ним работать, задвигал в долгий ящик свои внутренние проблемы. В той или иной мере он имел сложности или особенности в общении с людьми вне работы. Тенденция к улучшению была, но на эти изменения требовались долгие годы. Кто-то должен был помогать этим людям справляться с кризисами, переработками, давлением на работе и дома, неудачами, успехами. Максимальные шансы понять переживаемое разработчиком были у его товарища-тимлида, который уже прошел этот путь. Он мог помочь, только если действительно прошел этот путь. Тогда у него был нужный опыт, он мог его артикулировать, был способен установить контакт с коллегой и поделиться знанием. Такое было редкостью, компенсировать этот недостаток тимлида было сложнее всего.