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

Как тимлиду отвечать на вопрос заказчиков «Когда будет готово?» без гадания и вечных срывов сроков? Разбираемся вместе с Канбан-тренером ScrumTrek Василием Савуновым, автором курса «Основы Канбан-систем»

В статье — пошаговый разбор Kanban-метода и примеры, как компании используют метрики, чтобы сократить время производства и улучшить отношения с заказчиками. Вы узнаете, как уйти от субъективных оценок и начать прогнозировать сроки с опорой на реальные данные, не отвлекая сотрудников от текущих дел.

Почему тимлиды всегда оказываются крайними 

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

Обычно при постановке сроков тимлиды используют три источника «данных»: 

1. Прошлый опыт. Если в прошлый раз задачу заказчика выполнили за 3 недели, значит ориентируемся на это. 
2. Экспертное мнение. Тимлид приходит к команде и просит оценить сроки, как в нашем примере. 
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 дней.

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

Попробовать бесплатно

Перенесем теорию на практику и разберем реальный кейс.

Как Kanban-метод помогает изменить ситуацию: кейс ювелирной компании

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

Как ускорили работу и разгрузили отдел: 

1. Замерили Lead Time

У команды уже была настроена канбан-доска, поэтому первым делом определили точки принятия и завершения обязательств и построили график распределения времени за 3 месяца:

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

Исключили аномалии из статистики и получили реальный срок с вероятностью 95%: 32 дня.

2. Выделили реалистичные SLA по разным типам работ

Разделили задачи отдела по типам: простые отчеты, отчеты с интеграциями и доработки. Далее — рассмотрели текущий workflow каждого типа, чтобы собрать статистику и давать заказчикам вероятностные сроки. 1 workflow = 1 распределение по времени.

Теперь тимлид аналитического отдела может сказать заказчикам: «С вероятностью 78% ваш отчет будет готов за 10 дней» или «Ваши сроки нереальные — в следующий раз приходите раньше».

3. Замерили Cycle Time 

Cycle time — время, которое задача находится в работе. От момента, когда ей начали заниматься — передвинули в колонку «В работе» — до момента, когда она перешла в стадию «Готово».

Оказалось, что распределение Cycle Time сильно отличается от Lead Time:

• От колонки «Можно брать» до «Готово» задача находилась 8-24 дня. 
• От колонки «В работе» до «Готово» — 4-7 дней.  

То есть задача 4-17 дней находилась в колонке «Можно брать» и ждала, когда освободится сотрудник и возьмет ее в работу. 

Это говорит о перегрузке — аналитический отдел не мог принять так много задач за раз. Это повод говорить с руководством и на цифрах доказывать недостаток ресурса.

4. Нашли узкие места

Чтобы получить данные для анализа узких мест, нужно правильно спроектировать доску. Важно выделить основные этапы работ в колонках и подколонках. Для этого разделили колонку «В работе» на этапы.

Было:

Стало:

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

5. Устранили блокеры.

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

«Со статистикой невозможно спорить»

Василий Савунов, Agile-коуч ScrumTrek

Результат

Аналитический отдел смог договориться с заказчиками об SLA — реалистичных сроках выполнения задач разного типа, исходя из статистики. 

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

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

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

Зафиксируйте точки обязательств и завершения работы

Определите, с какого момента задача считается принятой в работу (точка обязательства), и когда она считается завершенной (точка отдачи обязательств). Это может быть колонка «В работе» и колонка «Готово» на доске.

Соберите данные за последние 1–3 месяца

Проанализируйте, за сколько дней задачи завершаются, и посмотрите на разброс. Это поможет убрать иллюзии о «среднем сроке» и увидеть реальную картину.

Постройте распределение по типам задач

Не все задачи одинаковы. Разделите задачи по типам (как в примере с бизнес-завтраками и презентациями), чтобы давать прогнозы, учитывая специфику задачи.

Используйте инструменты визуализации, которые упростят сбор данных

Например, в Kaiten отчет Lead Time считается автоматически для каждой доски, а Spectral Chart помогает понять реальное распределение сроков.

Настройте WIP-лимиты, чтобы сократить время производства

Одна из ключевых причин затянутых сроков — слишком много задач в работе одновременно. Ограничение количества текущих задач резко повышает фокус команды и уменьшает Lead Time.

Покажите данные бизнесу

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

Если вы хотите глубже разобраться в теме, советуем прочитать книги:

• Доминика ДеГрандис — «Визуализируйте свою работу»;
• Майк Барроуз — «Kanban from the Inside»;
• Дэвид Андерсон — «Kanban Method».

А если хотите сразу начать с практики — в Kaiten вы можете быстро настроить доску под процессы своей команды: добавить этапы работы, рассчитать Lead Time и настроить отчеты по накопительной диаграмме потока и спектральной диаграмме. Если нужна помощь с настройкой процессов под специфику вашей команды — можно обратиться к команде Kaiten за консультацией.