Не трогайте разработчиков. Отстаньте. Просто не беспокойте

Всем привет! Меня зовут Ян, я руководитель разработки Департамента ИТ инвестиционного бизнеса Газпромбанка. Совершенно неожиданно я занял первое место на конференции Highload++ с докладом про то, как организована работа в наших командах разработки.

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

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

Естественно, такой подход имеет кучу подводных камней и подходит далеко не всем и не каждому типу команд. 

Сейчас расскажу про практический опыт.

Коротко про историю вопроса

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

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

То есть примерно до 2017 года всегда проблема была в том, что самый ограниченный ресурс — это руки разработчика. А вот позже совершенно внезапно выяснилось, что бутылочное горлышко перекочевало в продуктовую команду. И неразбериха в продуктовой команде уже прямо влияет на эффективность разработки. И лечить надо не процесс разработки как таковой, а процесс управления. Я это видел в нашем проекте розницы (мы входили тогда в топ-10 по России в онлайн-оборотах) и видел на других проектах. А потом я перешёл в банк, и там задачи встали масштабом на пару порядков больше. 

Из мира сурового водопада, который мы докручивали как могли, из мира «лежим в сторону аджайла» я вдруг попал в мир внедрённого ультрааджайла 80 lvl, где настоящие аджайл-консультанты из Пивотал (которые сделали Спрингу) очаровали руководство. Если вы не представляете, что это такое, то расскажу: это когда проблема — не в деньгах. На вопрос: «Сколько вы готовы потратить на разработку?» — смело можно отвечать: «Да!» Так вот, у нас было внедрённое парное программирование. В смысле постоянно за столом сидели два разработчика. В парах работали senior или mid +. То есть смело удвойте или утройте бюджет разработки — и не особо ошибётесь. Это были не просто, как говорят эйчары, оверквалифайд-люди, а настоящие звёзды, которых каким-то чудом удалось собрать с рынка и не дать убежать от скуки из проекта, не дать спорить о нюансах реализации до бытовых травм и не дать давить ЧСВ всех окружающих. Ещё раз удвойте бюджет разработки, кстати. У нас в банке, в чёртовом банке, процесс выделения ресурсов занимал от пяти до 15 секунд. Был полноценный портал самообслуживания, где работал сервисный брокер, который создавал нужные виртуальные среды, доступы к шине и просто присылал логин-пароль к новым средам. Работало это так: разработчик говорил: «Хочу», а все остальные вроде ИБ уже постфактум оформляли все согласования и документы так, чтобы ему жилось как можно легче. У нас не было фиксированных лидеров команд — были голосования за временных. Было религиозное 100-процентное покрытие тестами, то есть это было изначально работающее TDD как таковое. Кстати, если вы за последние два предложения ещё не удваивали бюджет разработки, то сделайте это ещё раз. Но это окупалось. Мы занимались скорингом рисков — это какой кредит и кому можно выдавать. На правильном кредитовании банк за час зарабатывал больше нашего месячного бюджета. Мы имели доступ даже к источникам вроде легальной продажи данных парсинга сообщений, которые доставали всякие плагины к мессенджерам, геопозициям и т. п., и знали, что можно делать с данными о том, что Ашот опять зовёт Ивана посидеть в кальянной или Василий замечен в точке с игровыми автоматами. ТТМ на фичи был один день: с утра ставили задачу, в обед делали роллаут, вечером приходила первая аналитика. План был в том, чтобы это глянцевое экспериментальное подразделение раскатать на весь банк через всё то же парное программирование. То есть можно было удваивать команду каждые два-три месяца.

Как вы понимаете, эта история не могла закончиться хорошо. 

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

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

Что не так с российскими условиями

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

В России раньше было три разных места ответственности:

• Принятие решений (компания-заказчик).
  
• Исполнение (интегратор).
  
• Эксплуатация (сервисная организация).

То есть если заказчик не очень хорошо обдумал требования, а интегратор кое-что сделал с особенностями, то в итоге в эксплуатацию попадает то, что через месяц выкинут. Я, конечно, утрирую, но места неэффективности вы наверняка сами видите в такой модели. Постепенно с образованием продуктовых команд всё это начало съезжаться в одно место, и в итоге ответственным становился либо ПМ, либо технический лидер команды. Конечное состояние такого процесса — «осеньоривание» команд, когда каждый отдельный человек (лично вы) отвечаете и за постановку задачи, и за исполнение, и за то, что будет дальше с кодом в проде. Если вам показалось, что я сейчас сказал «микросервис», то да, это хороший пример. 

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

Как вы, возможно, знаете, управление большими проектами, по сути, пришло в разработку из строительства. То есть план-факт и водопады — это в конечном счёте переложенные модели управления от задачи «как построить большой дом» или «как построить судно». Позже пути моделей разошлись: небоскрёб в конце строительства должен оставаться небоскрёбом, а не 10 маленькими домиками, соединёнными подземными тоннелями. А вот софт может меняться. Но даже в такой консервативной отрасли, как строительство, ответственность начала концентрироваться в одной точке: в больших проектах сначала начали эксплуатировать те же компании, что построили, а потом они же стали влиять на проектную документацию.

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

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

Что мы сделали

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

Возможные решения:

• Можно сделать центральный управляющий орган. Тогда будет очень высокое качество решений, потому что там будут сидеть лучезарные архитекторы и озарять своим светом каждого. Но тогда это будут очень долгое принятие решений и долгие процессы: на любых внешних стыках или согласованиях происходят очень большие задержки.
  
• Можно взять этот архитектурный комитет и распределить его по компании, то есть посадить в каждую команду разработки по маленькому архитектору, входящему в центральный лучезарный комитет. Он будет загружен на 10–20%, и это раздует состав команды, ведь в идеале нужны безопасник, сетевик, юрист и архитектор в виде таких представителей.
  
• Можно распределить «маленького архитектора» по 5–10 командам, то есть он станет приходящим экспертом. Минус — эксперт не будет разбираться в продукте достаточно хорошо.
  
• И, наконец, четвертый способ — управление кросс-функциональными командами через поле знаний. Как магнитное поле выравнивает гвозди, так поле знаний выравнивает самостоятельные команды так, чтобы они двигались в одну сторону. Процессы выстраивания такого поля знаний описаны, но очевидная проблема в том, что мало кто доделал это до конца нормально.

Мы выбрали четвертый способ.

Поле знаний

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

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

И вот мы подходим к дежурствам.

Дежурства

Дежурный в команде разгребает чатики в «Телеграме», отвечает на почту (куда пишут клиенты и заказчики), берёт L2-заявки из ITSM и пользуется при этом собственной админкой, смотрит в журналы, в Кибану, в Графану, пишет техдокументацию и ОТАР (это кирпич архитектуры). К слову, в банке ОТАР был проблемой: в департаменте был один человек, который умеет писать, а он был нужен на каждый чих. Нам надоело стоять в очереди, и тогда стали писать все, кто умеет это делать. Не очень хорошо, но умеет. И выяснилось, что прочитать ман несложно, а отдать немного криво оформленный ОТАР на ревью лучезарному архитектору лучше, чем уговаривать его писать с нуля.

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

Дежурных на продуктовую команду нужно два: один — опытный и самодостаточный, а второй — молодой (например, джун). Опытный ничего не делает руками, кроме случаев ЧП, он ревьюит молодого или объясняет ему, как и что сделать. То есть это обучение всему тому, что происходит в команде.

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

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

Как вводили

Начали с инвентаризации вещей, которые отвлекают разработчиков. 

Просто выписывали две недели всё то, что бесит. 

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

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

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

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

— Вчера было 3 000 заказов, сегодня — 3 500. А ещё у вас три бага, один из которых — повторный, а тут узкое место, развлекайтесь, вот описанная таска. И ещё я задолбался заявку обновлять руками, и сделайте мне удобную страницу, поставил в беклог. 

Деплои шли так:

• Фаза 0 — senior делает. Выкладки по выходным.
  
• Фаза 1 — пришёл админ с книгами и написал скрипт. Оно стало быстрее, возможно, чаще.
  
• Фаза 2 — поговорили с архитектором и сделали обновление без даунтайма, но только архитекторы и senior знают, где какие костыли.
  
• Фаза 3 — в команде передают деплой друг другу, исчезает слепое пятно. Процесс выпрямляется в плане понимания разработчиками своего продукта. Разработчики по опыту поддержки понимают термины, задачи, процессы пользователей, лучше принимают непонятные странные задачи от бизнеса и превращают их в понятные.

Когда так делать НЕ надо

Каждый человек в команде либо склонен к пресловутому аджайловскому Т-shape, либо не садится на борт команды с дежурствами. Это значит, что на собеседованиях нужен отбор именно таких людей. Я думал, что это отсечёт около половины кандидатов, но потом, когда разработчики распробовали, как именно дежурства работают, появился гениальный довод: «А было такое, что ты что-то хотел доделать, но всё время руки не доходили?» У каждого такое есть, и много. Дежурство стало передышкой на наведение порядка и ещё решило задачу смены деятельности, то есть переключения потока. Закончилось тем, что многие даже стали ждать его почти так же, как отпуска. Итоговый отказ по причине «не хочет дежурить» — около 10–20 % в зависимости от команды. 

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

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

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

Что ещё узнали за время дежурств

У команд появилось очень чёткое системное понимание, что же они делают для клиента. Потому что, если прилетает задача «кнопки перекрасить», фронт их просто перекрасит — и всё. А фронт, который дежурил, будет понимать, зачем это нужно, и может предложить решение лучше, если пользователь чего-то не понимает. Бекэндер на дежурстве поймёт, где API, а где какие токены. Дежурство стало интерфейсом онбординга, там можно осмотреть соседский код. 

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

Дежурство снизило потребность в обучении. В командах не осталось тайных знаний, которыми владеет конкретный человек. Каждый знает всё. Отпуск, болезнь, замена человека — не беда. Слова «фактор автобуса» я слышу только на конференциях.

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

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

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

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

Улучшился ТТМ (мы не ждали этого быстро, но случилось). Дежурства вынудили уйти от тайных знаний и регламентов в пользу автоматизации. Каждый просто вынужден делать так, чтобы понять и запустить мог каждый в команде. А потом это всё ещё посмотрят 10 человек, так что скрипт точно будет хороший. К слову, сам по себе ТТМ ничего не значит, но высокий ТТМ — индикатор какой-то проблемы. Неважно, какие фичи за день можно выложить, но пока вы добьётесь релиза за один день — узнаете и архитектуру, и бекапы, и откаты, и АБ-тесты, и много всего остального, включая lowcode и nocode. Проверите процессы онбординга и создадите шаблоны новых проектов. 

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

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

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

Читай эту и другие статьи об IT в Газпромбанке в нашем блоге на Хабре.