Тимлид-ипохондрик: что за зверь и нужен ли он команде
Если в вашей команде разработки есть тимлид, который перед каждым релизом спрашивает «а что, если ляжет?», не берет таск без подробного ТЗ и доводит проджект-менеджера до нервного срыва, эта статья поможет заглянуть ему в голову, понять, зачем он нужен и как работать с ним без войны.
В ИТ такие люди встречаются часто. По моим наблюдениям, особенно много их среди тимлидов бэкенда, инфраструктуры и всего, что связано с деньгами и данными. Это и понятно: сама работа отбирает тех, кто первым делом думает, что сломается.
Проблема в том, что их поведение почти всегда интерпретируют неправильно. Одни руководители видят в таком человеке тревожного и пытаются его успокоить. Другие считают его вредным и давят. Третьи записывают в пессимисты и перестают слушать. Все три подхода не работают. За его занудством стоит не вредность, а способ справляться с неопределенностью. Чтобы с ним договориться, нужно понять, как это устроено.
«Я с ним больше не могу»
С этой фразы начался мой разговор с проджект-менеджером одной компании. Готовили запуск новой фичи.
Тимлид, по ее словам, «терроризировал» ее весь проект. На планировании отказался давать оценку, пока не разберется, как будет устроена интеграция 1С с CRM. Посреди спринта завел десяток задач на случай, если синхронизация с 1С отвалится в самый неподходящий момент. А за четыре дня до релиза написал в одиннадцать вечера: «Выкатывать на прод без имитациеи пиковой нагрузки я не готов».
Руководство давило на проджекта, проджект — на тимлида. Тимлид не сдвинулся. При нагрузочном тестировании выяснилось, что при большом количестве заказов синхронизация с 1С не успевает обрабатывать запросы: статусы обновляются с задержкой, а при повторной отправке запроса система может начислить бонусы дважды — защиты от дублей в интеграции нет. Обе проблемы устранили и повторно провели тесты
Если бы фичу выкатили в день запуска рекламной рассылки на всю клиентскую базу, компания рисковала получить зависшие заказы, некорректные начисления и шквал обращений в поддержку. Релиз пришлось отложить, зато пользователи ничего не заметили.
Проджект рассказывала это с явным раздражением, а потом добавила: «Но если честно, он оказался прав».
С этого «но если честно» обычно и начинается понимание такого человека.
Что у него в голове
Начну с того, что со стороны почти не видно. Такой тимлид плохо переносит неожиданности. Если что-то пошло не так и он к этому не готов, он теряется. Первые минуты может буквально выпасть из реальности, эффективность падает. Ему нужно время, чтобы собраться, включить голову и направить силы на решение. Он не глупее других, просто на ходу он медленно перестраивается.
Поэтому он делает все, чтобы в такую ситуацию не попадать. У него в голове что-то вроде внутреннего вики. На каждый баг, который можно предвидеть, есть свой пункт: что сломается, по каким признакам это понять и что делать. Если проблема случается, ему не нужно думать в моменте. Он открывает нужный пункт и действует, причем быстро и четко.
Отсюда его любовь к документации, инструкциям и порядку в таск-трекере. Отсюда и бесконечные вопросы по ТЗ и перед релизом. Он не пытается замучить проджекта до смерти и не ставит палки в колеса, он дописывает свой вики. Каждое его «а что, если...» — новый пункт. Чем больше пунктов заполнено, тем спокойнее ему выкатывать фичу.
Даже если команда приняла решение, с которым он не согласен, он все равно пойдет вместе со всеми. Но сначала ему нужно понять, где именно может сломаться, чтобы в нужный момент у него был готов ответ.
Если неожиданностей становится много, для него это не просто стресс, а почти физическая нагрузка. Тут и становится понятно, почему тип назвали ипохондрическим. Внутреннее напряжение у таких людей настолько сильное, что начинает «бить» по телу: скачет давление, болит голова. У мужчин я чаще слышу про спину, неврологию и сердце. Ну или классика - ОРВИ! Тело просто не выдерживает постоянной готовности к удару.
Отсюда и аптечка, которая почти всегда есть у таких людей с собой. Логика у нее та же, что и в работе: «Я знаю, что со мной может случиться, у меня в рюкзаке лежат таблетки от этого, и если что, я приму их сразу, и все будет нормально». Таблетки — это тот же вики, только для тела. В коде у него, кстати, своя аптечка: план отката, фича-флаги, бэкапы, мониторинг на все подряд.
Поэтому он и становится душным. Перепроверками он поднимает свою уверенность. А заодно подсвечивает проджекту и руководству тонкие места, где будет сложно не только ему. Если там что-то сломается, может понадобится подключать другие команды, поддержку, бухгалтерию, и все бросят свои дела. Он-то, может, и разрулит, но ценой сил и внимания всей компании.
Зачем он нужен
В компании со своей разработкой все связано со всем: приложение с 1С, 1С со складом, склад с кассами. Чем больше связей, тем больше мест, где может сломаться. Тимлид, который продумывает эти места заранее, снижает число аварий и экономит не только деньги, но и ночи всей команды.
Его оценки честные. Если он говорит «три недели», это три недели с запасом, а не две недели оптимизма плюс месяц пожара.
И его команда обычно лучше всех готова к сбоям. Он заставляет писать инструкции на случай аварии, поэтому, когда что-то все-таки ломается, у команды уже есть план.
Какие проблемы он создает
Тут без иллюзий: проблемы реальные, и проджекты и продакты не зря на него жалуются.
Он закладывает запас во все подряд. Оценки честные, но он страхуется от каждого сценария, включая маловероятные.
Он может заблокировать релиз из-за риска, который вероятен, но стоит копейки. Съехавшую кнопку и падение оплаты он обсуждает с одинаковой серьезностью.
Без подробного ТЗ он не начинает. Для критичных вещей это нормально, а для эксперимента «давайте за неделю проверим, нужна ли пользователям эта фича» плохо.
Свое «нет» он часто произносит без альтернативы. «Так выкатывать нельзя», и точка. Проджект остается с проблемой один на один.
А иногда за осторожностью прячется обычное нежелание брать ответственность. Пока релиз не вышел, он не может упасть. Отличить одно от другого помогает вопрос: «Что конкретно сломается и во что это обойдется?» Если тимлид называет сценарий, сроки, деньги или пользователей, это предусмотрительность. Если звучит «ну мало ли», «лучше перепроверить» и «плохое предчувствие», это избегание, и разговаривать нужно по-другому.
Как с ним договориться
Этот раздел для проджекта и для руководителя, который устал их мирить.
Договоритесь о цене ошибки заранее, а не накануне релиза. Разделите задачи на две группы.
- Эксперимент: можно ошибиться, откатим.
- Критичное: деньги, данные клиентов, связка с учетными системами.
Для первой группы его проверки минимальны, для второй его слово решающее. Когда граница проведена на старте проекта, половина конфликтов исчезает.
Помогите ему дописать вики до релиза. Сядьте вместе на двадцать минут и пройдитесь по сценариям: что делаем, если 1С не отвечает, если нагрузка выше прогноза, если нужно откатиться. Ответы запишите в короткий документ. Для бизнеса это двадцать минут, а для него ответ на вопрос, готов ли он выкатывать. Такой документ, кстати, пригодится всей команде.
Предлагайте компромисс на его языке. «Выкатываем на 5% пользователей под фича-флагом, откат за минуту» успокаивает ипохондричного тимлида лучше любых уговоров. У него есть “аптечка”, у бизнеса есть запуск.
Зовите его на планирование, а не на этап «мы уже все решили, оцени». Его вопросы в начале проекта стоят дешево. За три дня до релиза они стоят дорого.
Если в середине проекта меняете курс, дайте ему время перестроиться. Фраза «завтра делаем по-другому» для него означает, что половину вики можно удалить. Он перестроится, но не за вечер.
И просите от него цифры. Любой риск, который он поднимает, должен идти с ответом: насколько это вероятно и во что обойдется. Первое время ему будет непривычно, потом он сам начнет отсеивать мелочи.
Как помочь ему самому
Об этом почти никто не думает, а зря. Такой тимлид часто выгорает от ответственности за прод.
- Посмотрите, сколько раз за последний месяц ночью будили именно его. Если почти всегда его, сделайте нормальную ротацию дежурств. Он будет сопротивляться, потому что «никто лучше не разберется», но долго такой нагрузки не выдержит.
- Следите не только за нагрузкой, но и за количеством неожиданностей. Двенадцать часов работы по понятному плану он выдержит. А неделя, где каждый день что-то ломается так, как никто не предвидел, его подкосит. Если он начал жаловаться на голову, давление или спину, это часто сигнал, что неопределенности вокруг стало слишком много. Шутить об этом не стоит. Лучше посмотреть, какие неожиданности можно снять.
- Если “авария” все-таки случилась, не требуйте от него решения в первую же минуту. Дайте пять-десять минут собраться. Потом он, скорее всего, будет действовать точнее всех, особенно если этот сценарий уже есть.
- Отдайте ему разборы инцидентов. Постмортем — его стихия. После каждого разбора он добавляет новый пункт в вики и чаще всего именно он превращает аварию в инструкцию, чтобы в следующий раз она не застала команду врасплох.
- Помогайте ему отпускать контроль на фактах, а не уговорами. «Доверься команде» на него не действует. А вот «за квартал в этом сервисе не было ни одного бага на проде, давай уберем обязательное ревью от тебя» действует.
- И научите его говорить «да, если» вместо «нет». «Выкатить можем, если добавим таймаут и откат» звучит для проджекта совсем иначе, чем «выкатывать нельзя». По сути это то же самое, но разговор идет дальше, а не обрывается.
Какой он руководитель
Команде с ним спокойно. Прод стабильный, ревью кода серьезное, джуны быстро учатся писать надежно. “Аварий” у его команды мало, а если случаются, их быстро разбирают по инструкции.
Обратная сторона — гиперконтроль. Он ревьюит все сам и становится узким местом: таски копятся в очереди на его проверку. Архитектурные решения не отдает даже сильным разработчикам. Сеньоры, которым нужна свобода, со временем уходят туда, где им доверяют больше. А те, кто остается, перестают предлагать решения: «Он все равно перепроверит».
Контролирует он не из недоверия к людям. Он слишком хорошо знает, как трудно ему собраться, если что-то пойдет не по плану. Поэтому совет «просто контролируй меньше» не сработает. Сработает только честный разбор: где контроль реально спасает, а где остался по привычке.
Есть и моя позиция, с которой многие не согласятся: тимлидом команды, которая живет экспериментами и быстрыми гипотезами, ипохондричному лучше не быть. Ему будет плохо, команде тоже. Его место там, где надежность важнее скорости: деньги, учетные системы, инфраструктура и все, что должно работать в три часа ночи без людей.
Так нужен ли он команде?
Проджект из этой истории теперь сама просит ставить его на свои релизы. Говорит, нервы он ей по-прежнему треплет. Но перед запусками она спит спокойнее.