Пока техлид пишет код, команда ждёт

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

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

Как очередь появляется в течение недели

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

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

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

Не каждый вопрос требует решения техлида

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

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

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

Здесь участие техлида ещё нужно, но у него может быть результат полезнее одного принятого изменения. Можно вместе с разработчиком разобрать правила доступа при выгрузке и закрепить известные случаи в тестах. На следующем похожем изменении другого автора он попробует провести ревью, а техлид проверит, не упущено ли что-то существенное. Так станет понятнее, готов ли разработчик брать такие проверки на себя. Его собственные изменения по-прежнему проверяет другой участник команды. Если правила доступа принадлежат другой команде, придётся привлечь её; техлид не получает права придумать их из-за своей должности.

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

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

Если совсем перестать писать код

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

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

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

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

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

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

Срочное исправление может остаться у него

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

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

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

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

Что изменится на следующей неделе

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

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

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

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

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