Закрываем задачи перед Новым годом: что горит, а что можно отложить

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

Я — Даниил Динько, веду свой личный телеграм-канал, где рассказываю о себе, об IT и о Golang, а также являюсь экспертом и спикером в компании Эйч Навыки, TeamLeadом в компании-лидере в международном кибербезе, ex. старшим разработчиком в Ozon Tech. Давайте сегодня выясним: почему сроки в IT часто продлеваются — откладывается рефакторинг, минорные фичи в пользу самых важных бизнесовых, как не надо ставить сроки мидлам, тимлидам и бизнесу.

Для начала: как не нужно ставить сроки

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

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

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

А что будет, если сказать нереальные сроки

Цепочка обычно примерно следующая: мидл ставит срок «сегодня-завтра» и радостно говорит об этом лиду —> лид, конечно, верит (но я бы не верил и вам не рекомендую) —> руководитель идет с этими сроками к менеджерам на стороне бизнеса —> они бегут к маркетингу —> маркетинг — к клиенту.

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

Если вы не уверены или не знаете, как поставить сроки, здесь два пути:

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

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

Давайте разберем на примере

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

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

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

Как общаться с бизнесом

Бизнес часто приходит ко мне с просьбой проанализировать задачи, которые частично R&D. Поэтому чтобы дать хотя бы приблизительно верные сроки, надо сделать ресерч (минимум полдня), поговорить с ребятами с экспертизой в доменной области задачи и провести груминг. Но таких задач очень много, и примерный дедлайн хотят уже вчера (при этом фичей много, встреч много, код писать под конец года приходится всем и жестко). В этой ситуации я понимаю бизнес — нужно оценить возможности каждой фичи и понять, что брать в следующий квартал, а что оставить в этом.

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

Небольшой гайд по общению с бизнесом

Часто бывает такое, что бизнес уже пообещал клиенту, что какая-то фича будет готова, а вы после адекватной оценки сроков говорите, что на это нужен еще месяц. Вот несколько советов, как объяснить бизнесу, почему та или иная разработка займет гораздо больше времени:

1. Не врите и честно описывайте ситуацию. Бизнесу важно понимать, что перенос задачи — это не ваша прихоть, а способ избежать лишних рисков. Вот, что можно сказать: «Задача еще не готова на 100%, и мы рискуем запустить продукт с багами. Из-за этого у клиента перед праздниками может рухнуть сайт, поэтому лучше его доработать и выкатить стабильную версию в январе».
2. Делайте акцент на плюсах переноса сроков. Здесь возможны разные аргументы, главное, чтобы они тоже были честные, например, репутация компании или недовольство со стороны клиента и даже его потеря. 
3. Обязательно предложите альтернативу. Если бизнес ни в какую не идет вам на уступку, то предложите компромисс, например, релизнуть MVP (а бизнес пообещает договориться с начальством о новогодних премиях).

Какие задачи переносить на новый год

У нас в команде релизный формат разработки, то есть мы выдаем бизнесу проект версиями (релизами). Однако советы будут актуальны и для тех команд, где придерживаются рантайм-решений, например, логистика Ozon, которая должна работать всегда. Если вы только сейчас завершаете разработку какой-то большой фичи, то смело переносите ее на новый год. Вы уже точно не успеете подготовить к наступающему году хотя бы немного стабильную версию, если, конечно, не будете работать по 23 часа в сутки (час оставим на еду и сон). И то, вряд ли вы готовы 31 декабря в бой курантов сидеть на инцидентах и стабилизировать фичу.

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

В нашем случае представитель бизнеса сам предложил отложить фичи, которые не стабилизированы (или даже стабилизированы, но не сильно), на новый год, чтобы в 2024 отдать клиентам стабильную хорошую версию продукта, а в 2025 — быстро все допилить и как следует стабилизировать.

Давайте еще раз по пунктам — что лучше перенести:

• Сложный рефакторинг. Не стоит браться за большой объем работ, который может затянуться. Часто это задачи, результат которых будет важен только в перспективе нескольких месяцев.
• Большие задачи, которые еще не стабилизированы. Те случаи, когда QA еще не до конца проверили фичу, а разработка не пофиксила все баги высоких приоритетов. Лучше разговаривать с бизнесом на тему переноса таких доработок на следующий год, чтобы не получить инцидент в Новый год или не отдать плохую багованую версию юзерам.
• Внедрение новых технологий. Время под конец года — не для экспериментов, которые потребуют ресурсов на обучение или устранение непредвиденных ошибок.
• Стабилизация текущий релизов. Если вы понимаете, что все плохо, то точно переносите на январь. Допиливать сейчас можно только в том случае, если вы точно укладываетесь по времени, фича готова на 98% и оставшиеся 2% можно стабилизировать за две недели.

А что критично завершить:

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

Как тимлиду контролировать прогресс команды и избежать срыва дедлайнов

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

• Проводите синки. Если не каждый день, то хотя бы несколько раз в неделю. От команды нужно всего лишь 10-15 минут. Вопросы стандартные: что вчера, что сегодня, какие стопперы. Так все будут оставаться в едином контексте и понимать сроки. 
• Следите за прозрачностью задач. Контролируйте, чтобы ваши аналитики и QA писали валидные ТЗ, а уже после отдавайте задачи команде, иначе разработчики потеряют время на выяснение подробностей. 
• Контролируйте ключевые метрики. Определите для каждой задачи главные показатели, которые покажут прогресс. Например: процент написанного кода, статус тестирования, завершение критических этапов.  
• Приходите сами, если есть проблема. Если вы видите, что кто-то выбивается из графика, подключайтесь сразу: обсудите, что можно сделать, чтобы наверстать, или перераспределите задачу на других участников. И не забывайте прокачивайте софт-скиллы, но здесь важно не нянчиться, а просто приходить в крайних случаях и под конец проводить ретро и смотреть, кто что сделал не так.
• Оценивайте задачи до старта. Объясняйте команде бизнес-смысл фичи и то, насколько круто это будет для юзеров — таким образом у нее будет мотивация. Старайтесь ставить оценки не сами, а с исполнителем, чтобы они были более рациональными.
• Расставляйте приоритеты. Сходите к бизнесу и еще раз выясните приоритеты задач и бизнеса (выпускаем здесь и сейчас, но менее качественно, или после нового года, но стабилизировано). Старайтесь мыслить адекватно и не поддавайтесь всем желаниям бизнеса, транслируйте реальные возможности команды. Вы в первую очередь представитель своей команды, поэтому ее интересы и нужно защищать, но не в критический ущерб бизнесу, конечно.

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