Как тимлиду управлять сроками, не отвлекая команду
Рассказываем, какие данные помогут ответить на вопрос: «Когда будет готово?»
Показать, как работает Kaiten?
Как тимлиду отвечать на вопрос заказчиков «Когда будет готово?» без гадания и вечных срывов сроков? Разбираемся вместе с Канбан-тренером ScrumTrek Василием Савуновым, автором курса «Основы Канбан-систем»
В статье — пошаговый разбор Kanban-метода и примеры, как компании используют метрики, чтобы сократить время производства и улучшить отношения с заказчиками. Вы узнаете, как уйти от субъективных оценок и начать прогнозировать сроки с опорой на реальные данные, не отвлекая сотрудников от текущих дел.
Почему тимлиды всегда оказываются крайними
В работе любого тимлида есть знакомый сценарий: заказчик приходит с просьбой «прикинуть срок». Тимлид зовет специалиста, тот отрывается от работы, дает оценку с запасом. Тимлид увеличивает срок втрое «на всякий случай». Заказчик режет срок пополам. Проект все равно затягивается, и все недовольны.
Обычно при постановке сроков тимлиды используют три источника «данных»:
- Прошлый опыт. Если в прошлый раз задачу заказчика выполнили за 3 недели, значит ориентируемся на это.
- Экспертное мнение. Тимлид приходит к команде и просит оценить сроки, как в нашем примере.
- Бюджетные и временные ограничения. У заказчика может быть конкретный дедлайн, когда команде необходимо предоставить решение.
При таком подходе тимлид попадает в замкнутый круг оценки сроков:
1. Запрос бизнеса: «Сколько времени займет задача?»
2. Ответ команды: «Нужно уточнить детали».
3. Давление: Бизнес настаивает на примерных сроках.
4. Завышение: Разработчик называет срок с запасом.
5. Сокращение: Менеджер «режет» оценку вдвое.
6. Итог — провал дедлайна.
Проблема субъективного метода оценки в том, что сроки базируются не на реальных данных, а на ощущениях, личном опыте и желании «перестраховаться». А бизнесу важны сроки не сами по себе, а ради планирования бюджета, выстраивания маркетинга и KPI.
Вывод: субъективные оценки сроков не работают. Нужны данные, на основе которых тимлид сам сможет оценивать сроки и при этом не отвлекать команду. В этом поможет Kanban-метод.
Как превратить хаотичные сроки в предсказуемый поток задач
Многие думают, что Kanban — это доска со стикерами. На деле это метод управления потоком интеллектуальной работы с акцентом на данные, а не догадки.
Kanban-метод предлагает прогнозировать сроки на основе истории выполнения аналогичных задач с указанием вероятности того или иного срока.
Например:
- 80% задач типа А завершаются за 4 дня.
- 95% задач типа B — за 12 дней.
Такие прогнозы помогают управлять ожиданиями заказчика без постоянных переоценок и срывов.
Как собрать данные для прогнозов
Шаг 1. Собираем статистику
Для начала нужно знать две ключевые точки: когда задачу взяли в работу и когда ее завершили. В идеале — фиксировать эти точки в трекере.
Рассмотрим на примере доски в Kaiten отдела маркетинга. Здесь одна карточка — одна задача.
Точка А — начало работы над задачей. В нашем примере это момент, когда карточку из колонки «Очередь» передвигают в колонку «В работе».
Точка Б — момент, когда задачу закрыли: согласовали и сдали заказчику. Визуализация на доске через колонку «Готово».
Шаг 2. Измеряем Lead Time (время производства)
Теперь когда мы знаем, точки начала и завершения работы, можем измерить Lead Time — это расстояние от А до Б.
Lead Time (время производства) — период, за который задача проходит все этапы производства, начиная с момента получения заказа и заканчивая его полной реализацией.
Важный принцип: не пытаться измерить «чистое время» работы того или иного специалиста. Например, часы, когда маркетолог готовит презентацию или дизайнер отрисовываем баннер, а период прохождения всех этапов задачи по системе — с подготовкой, согласованиями и дизайном. Потому что реальное время, которое будет ждать заказчик, гораздо больше и включает в себя все простои, ожидания, согласования и так далее.
Массив данных должен быть достаточно большим, чтобы учесть все особенности рабочего процесса, поэтому важно проанализировать исторические данные за 3–6 месяцев. Так можно сделать выводы по всем задачам отдела с разными workflow, и узнать, какие задачи на каком этапе «застревают» и почему это происходит.
Workflow — это последовательность шагов, действий, задач, которая позволяет добиваться поставленных целей. Этот процесс может быть описан на бумаге (регламенте), или визуализирован в виде этапов на доске.
Рассмотрим 2 типа задач отдела маркетинга с разными workflow. 1 тип задач — «Подготовка презентации».
Workflow подготовки презентации состоит из этапов:
2 тип задач «Провести бизнес-завтрак».
Здесь будет больше этапов, а значит и workflow — дольше:
Построим график распределения Lead Time для двух типов задач. Каждая точка на графике обозначает одну задачу, цифры на оси X — сколько дней задача находилась в работе (Lead Time).
Из графика мы видим, что:
- Каждая из 19 задач отдела была выполнена в течение 11 дней.
- 10 задач первого типа (подготовка презентации) обычно завершаются за 1–4 дня.
- 9 задач второго типа (проведение бизнес-завтрака) были выполнены за 5-11 дней.
- 1 задача второго типа завершилась за 11 дней (аномалия).
Шаг 2. Рассчитываем вероятность
Чтобы сказать заказчику: «С вероятностью 80% задача будет выполнена за 3 дня, а за 10 дней — с вероятностью 100%» нужно рассчитать эту вероятность.
Воспользуемся формулой: количество задач которые были выполнены в течение интересующего нас Lead Time делим на число всех задач данного типа и умножаем на 100%.
Например: если 8 из 10 задач одного типа были завершены за 3 дня, то вероятность уложиться в 3 дня для новой задачи того же типа — 8/10*100 = 80%.
На основе данных, которые мы получили из графика выше, можно сделать выводы:
- 8 из 10 презентаций маркетологи готовят в течение 3 дней. Значит задачи этого типа команда завершит за 3 дня с вероятностью 80%.
- 9 из 9 бизнес-завтраков завершили за 11 дней со 100% вероятностью. А с вероятностью 77% команда проведет их за 7 дней.
Теперь тимлид сможет сказать заказчику вероятность исполнения срока, исходя из расчетов, которые являются единственным источником правды. Заказчик в таком случае видит прозрачную логику прогноза, команда не отвлекается, а сроки не выставляются субъективно.
«Статистика — это не про контроль, а про доверие. Когда заказчик видит цифры, он перестает думать, что вы тянете время»
Василий Савунов, Agile-коуч ScrumTrek
В Kaiten Lead Time рассчитывается автоматически для каждой доски, в отличие от Excel, где нужно создавать таблицы и диаграммы. С Kaiten тимлиду достаточно просто перейти на соседнюю вкладку от доски с задачами — система уже все рассчитала и построила график.
Для расчета Lead Time используется Spectral chart (спектральная диаграмма). Она показывает распределение времени выполнения задач и позволяет спрогнозировать, какой срок уйдет на выполнение новой задачи.
Например: график выше показывает, что всего за выбранный период через систему прошло 24 карточки. Максимальное время решения одной из задач — 21 день, а большинство задач — 14 карточек — выполняются за 1 день.
Следовательно, можно сказать, что новая задача может быть обработана от 1 до 21 дня. Более точный прогноз показывает красная линия перцентиля. Она говорит о том, что с вероятностью 85% команда укладывается в 7,5 дней.
Перенесем теорию на практику и разберем реальный кейс.
Как Kanban-метод помогает изменить ситуацию: кейс ювелирной компании
В аналитическом отделе компании был вечный завал. Команда обслуживала 6 бизнес-подразделений, каждое из которых продвигало свои задачи в приоритет. Заказчики были недовольны, потому что не понимали, откуда берутся сроки и почему договоренности нарушаются. А аналитики находились в постоянной перегрузке.
Как ускорили работу и разгрузили отдел:
- Замерили Lead Time
У команды уже была настроена канбан-доска, поэтому первым делом определили точки принятия и завершения обязательств и построили график распределения времени за 3 месяца:
В ходе анализа выяснили, что небольшое количество задач делались аномально долго — до 78 дней. Обычно такие задачи «застревали» из-за форс-мажоров: увольнений заказчиков, больничных и отпусков. Опираться на эти аномальные задачи при долгосрочном прогнозированииы нельзя.
Исключили аномалии из статистики и получили реальный срок с вероятностью 95%: 32 дня.
- Выделили реалистичные SLA по разным типам работ
Разделили задачи отдела по типам: простые отчеты, отчеты с интеграциями и доработки. Далее — рассмотрели текущий workflow каждого типа, чтобы собрать статистику и давать заказчикам вероятностные сроки. 1 workflow = 1 распределение по времени.
Теперь тимлид аналитического отдела может сказать заказчикам: «С вероятностью 78% ваш отчет будет готов за 10 дней» или «Ваши сроки нереальные — в следующий раз приходите раньше».
- Замерили Cycle Time
Cycle time — время, которое задача находится в работе. От момента, когда ей начали заниматься — передвинули в колонку «В работе» — до момента, когда она перешла в стадию «Готово».
Оказалось, что распределение Cycle Time сильно отличается от Lead Time:
- От колонки «Можно брать» до «Готово» задача находилась 8-24 дня.
- От колонки «В работе» до «Готово» — 4-7 дней.
То есть задача 4-17 дней находилась в колонке «Можно брать» и ждала, когда освободится сотрудник и возьмет ее в работу.
Это говорит о перегрузке — аналитический отдел не мог принять так много задач за раз. Это повод говорить с руководством и на цифрах доказывать недостаток ресурса.
- Нашли узкие места
Чтобы получить данные для анализа узких мест, нужно правильно спроектировать доску. Важно выделить основные этапы работ в колонках и подколонках. Для этого разделили колонку «В работе» на этапы.
Было:
Стало:
Выяснилось, что у аналитического отдела была зависимость от других подразделений: нужна выгрузка из 1С, данные из отдела логистики и так далее. Поэтому решение задачи могло задерживаться.
- Устранили блокеры.
Начали блокировать карточки, когда задачу тормозит другой отдел и проанализировали их. Просчитали, сколько времени задача «висит», перевели это в деньги — что послужило поводом обсудить эти проблемы с другими подразделениями и генеральным директором.
«Со статистикой невозможно спорить»
Василий Савунов, Agile-коуч ScrumTrek
Результат
Аналитический отдел смог договориться с заказчиками об SLA — реалистичных сроках выполнения задач разного типа, исходя из статистики.
- Бизнес-заказчики получили желаемую предсказуемость сроков.
- Аналитический отдел смог работать без перегрузок и аврала, поставляя результат с минимальными ошибками в сроках.
Что сделать, чтобы видеть реальные сроки и узкие места
Вы можете начать менять ситуацию, не дожидаясь крупных трансформаций в компании или идеального процесса. Даже простые шаги дадут эффект — появится прозрачность, сократятся ссоры с заказчиками и будет больше контроля над реальностью.
Зафиксируйте точки обязательств и завершения работы
Определите, с какого момента задача считается принятой в работу (точка обязательства), и когда она считается завершенной (точка отдачи обязательств). Это может быть колонка «В работе» и колонка «Готово» на доске.
Соберите данные за последние 1–3 месяца
Проанализируйте, за сколько дней задачи завершаются, и посмотрите на разброс. Это поможет убрать иллюзии о «среднем сроке» и увидеть реальную картину.
Постройте распределение по типам задач
Не все задачи одинаковы. Разделите задачи по типам (как в примере с бизнес-завтраками и презентациями), чтобы давать прогнозы, учитывая специфику задачи.
Используйте инструменты визуализации, которые упростят сбор данных
Например, в Kaiten отчет Lead Time считается автоматически для каждой доски, а Spectral Chart помогает понять реальное распределение сроков.
Настройте WIP-лимиты, чтобы сократить время производства
Одна из ключевых причин затянутых сроков — слишком много задач в работе одновременно. Ограничение количества текущих задач резко повышает фокус команды и уменьшает Lead Time.
Покажите данные бизнесу
Как показал кейс, простая визуализация процессов уже помогает наладить коммуникацию с заказчиками. Обсуждение сроков задачи, основанное на данных и статистике, перестает быть разговором «на эмоциях».
Если вы хотите глубже разобраться в теме, советуем прочитать книги:
- Доминика ДеГрандис — «Визуализируйте свою работу»;
- Майк Барроуз — «Kanban from the Inside»;
- Дэвид Андерсон — «Kanban Method».
А если хотите сразу начать с практики — в Kaiten вы можете быстро настроить доску под процессы своей команды: добавить этапы работы, рассчитать Lead Time и настроить отчеты по накопительной диаграмме потока и спектральной диаграмме. Если нужна помощь с настройкой процессов под специфику вашей команды — можно обратиться к команде Kaiten за консультацией.
