Делай раз, делай два.

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

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

Он спросил: «Что делать, если система не работает, а на приведение всё в порядок нет ни времени, ни ресурсов, ни кредитов доверия?»

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

Шаг 1. Перестать обещать сроки вслепую.

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

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

Шаг 2. Встроить «рефакторинг» в каждую задачу.

Второй приём — к каждой основной задаче добавлять небольшую подзадачу, объёмом не больше 10% от общей работы. Эта микро-задача обязательно должна быть направлена на улучшение инфраструктуры, документации или инструментов, связанных с основной задачей. С виду — мелочь, и её добавление редко вызывало вопросы: никто не ждал, что пропащая команда будет попадать в сроки, так что чуть больший объём работ никто не замечал.

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

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