Время выполнения потоковых задач в разработке часто колеблется: один день задача занимает 2 часа, в другой — 6. Из-за этого сложно предсказать, уложится ли команда в срок. Control chart помогает отслеживать разброс времени, находить аномалии и корректировать процесс до того, как отклонения станут проблемой. 

В статье разберем, как это работает, и покажем, как можно читать график, чтобы определить SLA при работе с заказчиком.

Что такое контрольный график простыми словами и как он выглядит

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

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

Основные элементы диаграммы:

• Ось Y — вертикальная линия слева, которая показывает время выполнения задачи. Обычно используют измерение в днях.

• Ось X — горизонтальная линия снизу, которая показывает даты завершения задач.

• Точки. Каждая точка на графике — это одна ваша завершенная задача. В зависимости от ее расположения на графике становится понятно, сколько времени конкретно эта задача провела в работе.

• CL, или центральная линия — горизонтальная линия посередине. Она показывает среднее время выполнения задач за выбранный период.

• UCL, или верхняя контрольная граница — показывает порог, выше которого время выполнения задачи считается нетипично долгим для вашего текущего процесса. Задачи выше UCL — красный флаг, на который стоит обратить внимание.

• LCL, или нижняя контрольная граница — показывает порог, ниже которого задача завершилась необычно быстро. Это тоже сигнал, но часто менее критичный.

Если все точки находятся в пределах верхней и нижней границ, процесс — статистически управляемый, что обеспечивает стабильность работы команды.

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

У CL, UCL и LCL есть альтернатива — линия SLA. SLA — это договор между поставщиком услуги и заказчиком, который фиксирует четкие метрики качества и сроки выполнения работ. На контрольном графике будет одна линия. Она показывает предел, выше которого не стоит подниматься. По такому принципу устроен Control chart в Kaiten.

Например, вы договорились с заказчиком на выполнение 90% задач в срок до 5 дней. Для этого в Kaiten можно указать SLA 5, после чего на графике появится красная линия. Как это будет выглядеть в системе:

Как использовать данные Control chart

Основная задача контрольного графика — помочь понять два типа колебаний:

• Нормальные колебания, которые всегда происходят в любом процессе.

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

Главное преимущество control chart — наглядность. Он не требует сложного анализа, но сразу показывает, где процессы работают нормально, а где нужны изменения. Это экономит время на рутинные проверки и помогает быстро реагировать на реальные проблемы.

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

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

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

Как читать график: несколько примеров

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

Например, вот график, где есть 11 выполненных задач при SLA в 20 дней. Какие выводы можно сделать, глядя на него?

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

Вот более подробный график, посмотрим на него:

Здесь уже видно больше задач, а еще можно проследить негативную тенденцию. Если поначалу все карточки закрывали в пределах 14 дней, то затем постепенно срок стал увеличиваться, а три точки и вовсе вышли за пределы линии SLA. Это указывает на проблемы в процессах. 

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

Ниже следующий пример.

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

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

Следующий пример:

Здесь происходит хаос. Мы не можем прогнозировать, получится ли выполнить задачу в сроки, потому что у нас нет особо выраженной динамики и стабильности. Что в начале, что в конце отчетного периода сроки выполнения задач слишком разнятся. Опять же, это повод обратить внимание на процессы.

Теперь посмотрим пример положительной динамики:

Мы видим, что поначалу ситуация была неоднозначной. Многие задачи выполняли больше 20 дней, на одну ушло почти 50. Даже среди задач, которые выполнили в срок, многие были в зоне риска и находились слишком близко к линии. Однако со временем все стало сглаживаться — в правой части только одна задача вышла за пределы, а большинство закрыли в течение 15 дней. Это указывает на то, что в команде оптимизировали процессы, поэтому укладывать в срок стало проще.

Следующий пример:

У нас все еще указано SLA 20 дней, однако все задачи выполняют в разы быстрее, поэтому на графике нет красной линии. Несмотря на разброс между некоторыми задачами, все они находятся в пределах срока, поэтому можно не бить тревогу из-за отклоняющихся точек. Однако если стоит задача сделать Lead Time как можно меньше, то стоит обратить внимание на точки, которые ощутимо выше остальных.

Откуда берутся данные и где смотреть график

Если ваша команда использует трекер задач, то большинство из них хранят даты начала и завершения работ, поэтому данные подгружаются автоматически. Например, так все устроено в Kaiten и Jira. Эти системы фиксируют даты начала и завершения задач.

Например, в Kaiten откройте отчет Control Chart и выберите нужный период, а также доски, задачи на которых вы хотите рассмотреть. Чтобы сильнее детализировать график, можно выбрать конкретные метки и типы карточек. Показатель SLA вы выставляете вручную.

Как встроить контрольный график в управленческий цикл

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

Еженедельно отслеживать график. Можно просматривать его каждый день, но проще отслеживать показатели в динамике, чтобы определяться тренды.

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

Детализировать график. Для этого добавьте в Kaiten тип задачи для разных карточек. Например, улучшение, баг, функциональность. После этого карточкам будут присвоены разные цвета в зависимости от типа. Как это будет выглядеть на графике. 

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

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

Вы использовали контрольный график?

Если да, расскажите, помогал ли он вам оптимизировать выполнение потоковых задач, какие закономерности находили? А если нет — то с помощью каких инструментов отслеживаете эффективность процессов?