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

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

Именно поэтому нельзя занимать весь спринт кросс-командными задачами: статистически в них многое пойдёт не так, и в итоге возникнут ожидания и простои. Лучше иметь внутрикомандные (а в идеале так вообще внутрикомандные и индивидуальные) задачи, которые можно делать, пока другая команда что-то пилит.

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

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

За два дня конференции тест прошли 256 человек. В финал вышли 19 человек — это примерно 7%.

Бутылочное горлышко в вашей команде

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

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

Отсюда — два следующих вопроса теста:

— При долговременной стратегии развития команды (в трёх–пятилетней перспективе) чему важнее всего уделять внимание?
1. Повышать перформанс каждый спринт за счёт повышения давления на сотрудников.
2. Правильно отчитываться руководству.
3. Развивать эффективное самоуправление команды.

— Вы разрабатываете сложный продукт. Какова наиболее вероятная причина вашего выгорания из перечисленных?
1. Все вопросы замкнуть на себе и превратиться в бутылочное горлышко команды.
2. Токсичные люди в команде.
3. Требования заказчиков и руководства чрезмерны для вашей команды.
4. Алкоголь.

В первом вопросе крайне важно решить, в какой ситуации вы находитесь сейчас: если кризис и всё горит, то, возможно, позволительно сжечь команду, но решить задачу. Такое в банковской сфере иногда случается при очень быстрых изменениях законодательства и реальных кризисах, но 95 % времени к кризисам надо готовиться заранее, а законодательство в последние годы вводят плавно со всеми предупреждениями. Так вот, в такой ситуации самое важное — чтобы команда справлялась сама. Это же соответствует методологии SAFe (Scaled Agile Framework), соединяющей проектное управление и сам SCRUM/Agile на уровне управления командой.
Хороший лидер в команде не нужен, команда справляется без него (по крайней мере, какое-то время) и сама улаживает внутренние конфликты. А вот плохой лидер делает так, что без него команда почти мгновенно рассыпается или теряет в эффективности. Когда команда развивается, это сказывается на её стабильности, а стабильность в долговременной перспективе означает принятые процессы принятия решений и другие сокращения внутренних издержек.
А вопрос про то, как выгореть, — это самый характерный способ затыкания щелей, когда лидеры слабы. Нужно делегировать, а не бросаться доделывать за всеми.

Вот ещё пара вопросов на тему, кризис или не кризис:

— Какой из этих способов принятия решений самый быстрый?
1. Решение лидера как самого грамотного специалиста.
2. Решение, принятое группой доверенных лиц.
3. Консенсусное командное решение.

— Какой из этих способов принятия решения приведёт к тому, что его исполнение наименее вероятно будет саботировано командой?
1. Решение лидера как самого грамотного специалиста.
2. Консенсусное командное решение.
3. Решение, принятое группой доверенных лиц.

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

Соответственно вопрос про презентацию уже принятого верхнеуровневого решения:

— Вам нужно рассказать о принятом решении команде. Как это наиболее эффективно сделать?
1. Приказ. Чётко, быстро, доступно.
2. Объяснить паре человек и поручить донести до остальных.
3. Объяснить всем потребность в этом решении. Собрать и обработать обратную связь.

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

Следующий вопрос достаточно простой:

— Какой из перечисленных способов улучшить работу «отстающего» сотрудника в зрелой команде с фокусом на долговременное развитие, скорее всего, сработает эффективнее?
1. Ввести жёсткий контроль за его рабочим временем.
2. Поставить задачи, превышающие его текущую производительность, и наказывать при их недостижении.
3. Публично порицать и осуждать.
4. Поставить работать в паре с успешными сотрудниками.

Тут можно пойти от противного: если сотрудника публично ругать, то на кого-то это подействует, но гораздо чаще в нашей сфере это демотивирует. Не уверен, что так бывает на производствах, где нужны просто рабочие руки (я часто наблюдал сцены, когда мат мастера участка мотивирует), но в ИТ совершенно точно ругать — это последнее, к чему стоит прибегать. Вариант 2 очень похож на то же самое: это скорее путь склонить сотрудника к заявлению по собственному желанию, потому что практический результат труда становится бесполезен. В случае линейных сотрудников часто применяется контроль за рабочим временем — это отличный инструмент для тех, у кого недостаточно самодисциплины, чтобы контролировать превращение работы в результат. И это могло бы работать для тех, кто увлекается тем же оверинжинирингом, если бы не воспринималось негативно в ИТ-среде. Поставить трекер времени? До свидания! Именно поэтому менеджеры, которые делали так в офисе без трекера (за счёт личного присутствия), стали слабы при переходе на удалёнку. Единственный рациональный результат в зрелой команде тут — работа в парах. Это же может применяться для производственных цепочек, и про это есть очень подробно у Голдратта (про планирование производств).

Следующий вопрос характерен для нашей сферы:

— Вы уже больше года развиваете банковский продукт. Где лучше всего тратить максимум ресурсов на исправление ошибок разработки?
1. На бою. Так будет минимальный TTM!
2. На тестировании. Разработчики должны разрабатывать!
3. При разработке, сдвигая методологию ближе к TDD.

Тут всё очень просто: стартап может позволить себе тесты на продуктиве, зрелый проект может выбирать баланс ТТМ и качества кода, а вот в банке ошибки заканчиваются фатально. Именно поэтому у нас много скучных тестов, включая аудиты ИБ, и именно поэтому фичи на бой выкатываются не так, чтобы прямо сразу. Наиболее подходящая для этого методология — TDD. Тяжело сказать, что мы полностью в ней, но тот же SAFe требует, чтобы мы по возможности двигались в её сторону, что мы и делаем.

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

— Когда лучше принимать решения в lean-философии?
1. Сразу. Затянутые вопросы и решения нервируют заказчиков и руководство.
2. Когда будет некоторое количество собранной аналитики, чтобы всем было комфортно и эффективно реализовывать это решение.
3. Как можно позже, чтобы быть максимально уверенными в правильности решения.

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

И последний вопрос про формирование команды для нового проекта — очень частой задачи mid-тимлидов:

— При возникновении новой большой задачи перед компанией вам нужно решить, кто будет заниматься разработкой. Какой из этих вариантов вы выберете при свободе действий?
1. Соберу новую команду из сотрудников других команд.
2. Соберу новую команду с нуля с рынка.
3. Отдам задачу в существующую сложившуюся команду, усилив её.
4. Организую проектное управление (буду запрашивать разные задачи у разных команд).

Если собрать новую команду с нуля из сотрудников других команд или с рынка, то полгода уйдёт на её стабилизацию и притирку людей, установление принципов и внутренних негласных договорённостей. Если же взять имеющуюся команду и «подсаживать» по одному людей, которые быстро впитают уже сложившиеся эффективные принципы, — эти полгода удастся сэкономить. Ну и ещё можно выбрать проектное управление — это работает для коротких задач, но если вы хоть раз таким занимались, то понимаете, почему этим хорошо поддерживать основную команду, а не делать это на 100 % проекта.

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