AI
Кумулятивная диаграмма потока: почему команда не успевает
Команда не успевает, когда начинает задачи быстрее, чем заканчивает, а новые требования и исправления ошибок приходят быстрее, чем закрываются старые задачи: работа копится в середине процесса, и каждая следующая задача ждёт всё дольше. Увидеть это помогает кумулятивная диаграмма потока - график, на котором по неделям накапливаются задачи в каждом статусе. Помогают лимит задач в работе и решение, какие задачи не брать.
Почему все заняты, а сроки всё равно срываются
Занятость и пропускная способность - разные вещи. Пропускная способность - сколько задач команда доводит до конца за неделю. Человек может быть занят с утра до вечера, а его задачи при этом стоят на месте.
Вот эпизод, восстановленный по рабочей переписке одной компании. В 10:00 руководитель продукта написал задачу дизайнеру. Дизайнер был занят - открыл задачу через три часа, почитал десять минут и задал вопросы, потому что что-то было непонятно. Руководитель продукта сидел на встречах и ответил ещё через три часа. К тому моменту дизайнер уже не успевал: рабочий день закончился. Созвонились утром следующего дня, и только тогда появился черновик. Работа на два часа растянулась на три дня и всё равно вышла с ошибками. Задача больше ждала, чем делалась.
В другой компании первые пилоты новых продуктов хорошо продались - и под масштабирование наняли две команды. Они работали по полгода и обошлись дорого. Отмасштабировать продукты не получилось, почти всё выбросили и переделали меньшей основной командой за полтора месяца. И это работало нормально. Больше людей не дало больше скорости.
Полная загрузка людей ничего не говорит о том, когда задача будет готова.
Как устроена кумулятивная диаграмма потока
Кумулятивная диаграмма потока - это график, где по горизонтали идут недели, а по вертикали - накопленное с начала наблюдения число задач. Каждый статус рисуется как отдельная полоса.
Полос столько, сколько статусов в процессе. В трекере задач это могут быть: бэклог (список ещё не начатых задач), «к выполнению», «в работе», «проверка», «заблокировано», «сделано». Обработка заказов интернет-магазина, сделки в системе учёта клиентов, задачи маркетинга - везде есть статусы, и везде можно нарисовать такую диаграмму.
Нижняя полоса «сделано» только растёт: задачи, закрытые однажды, никуда не деваются. Верхний край всей фигуры - это всё, что поступило с начала наблюдения. Толщина любой полосы на конкретной неделе показывает, сколько задач в этом статусе прямо сейчас. Толщина полосы «в работе» - это число задач в работе (в трекерах их часто обозначают WIP, от английского work in progress).
Две вещи помогают читать диаграмму. Наклон линии - скорость: сколько задач проходит через эту границу в неделю. Расстояние по горизонтали между двумя линиями - сколько времени уходит у средней задачи на этот участок. Если линия «взято в работу» поднимается круче, чем «сделано», команда берёт задачи быстрее, чем закрывает. По одной такой картинке видно, где команда теряет время.
Учебный пример: таблица по неделям
Числа в этом примере условные. В первую неделю пришло 20 задач, дальше приходит по 12 в неделю; начинают по 10 в неделю, заканчивают по 5.
| Неделя | Поступило всего | Начато всего | Сделано всего | В очереди | В работе |
|---|---|---|---|---|---|
| 1 | 20 | 10 | 5 | 10 | 5 |
| 2 | 32 | 20 | 10 | 12 | 10 |
| 3 | 44 | 30 | 15 | 14 | 15 |
| 4 | 56 | 40 | 20 | 16 | 20 |
| 5 | 68 | 50 | 25 | 18 | 25 |
| 6 | 80 | 60 | 30 | 20 | 30 |
«В очереди» - это «Поступило всего» минус «Начато всего». «В работе» - «Начато всего» минус «Сделано всего».
Чтобы нарисовать диаграмму по этой таблице, нужны три линии: по столбцам «Поступило всего», «Начато всего» и «Сделано всего». Между первой и второй линией получится полоса очереди, между второй и третьей - полоса задач в работе. Полоса «в работе» растёт на 5 задач каждую неделю - это первый из трёх рисунков: полоса расширяется. Верхняя линия поднимается на 12 в неделю, нижняя на 5 - второй рисунок, расходящиеся наклоны. Если бы приходило, начиналось и заканчивалось по 5 задач в неделю, три линии шли бы параллельно, а толщина полос не менялась бы - третий рисунок, здоровый поток.
Три рисунка, которые видно сразу
В таблице ниже дефект - это ошибка в уже сделанной работе: её приходится исправлять, и она тоже встаёт в очередь.
| Что видно на диаграмме | Что это значит | Что делать |
|---|---|---|
| Полоса «в работе» расширяется | Задачи начинают быстрее, чем заканчивают; каждая новая ждёт дольше | Ввести лимит задач в работе и сначала доделывать начатое |
| Верхняя линия круче нижней | Новые требования и дефекты приходят быстрее, чем их закрывают; очередь растёт, и темп внутри команды её не догонит | Считать приток отдельно по видам, решать, от чего отказаться, убирать причины дефектов |
| Полосы идут ровно и параллельно | Здоровый поток: сколько пришло, столько начали и закончили; срок предсказуем | Держать лимит и смотреть на диаграмму раз в неделю |
Как это выглядело у одной команды
Диаграмму одной команды построили по данным её трекера задач. На старте у неё уже было около 100 задач. В первые пять недель в работу брали примерно по восемь задач в неделю. Линии «взято в работу» и «сделано» расходились по наклону: команда каждую неделю брала больше задач, чем успевала нормально закончить - и это было видно без всяких расчётов.
Параллельно рос счётчик сбоев. Одни люди сначала много сделали, а потом создали много работы для других. Для пользователей ничего не изменилось: жалоб и обращений меньше не стало, сколько бы задач команда ни брала.
Позже команда стала брать меньше задач в работу. Но накопленное уже сработало: задача, начатая примерно на четвёртой неделе, дошла до сдачи примерно на шестнадцатой - около 12 недель на одну задачу. Одни задачи делались за день, другие за месяц: так сказывались большие проекты.
Закон Литтла: сколько будет идти задача
Формула называется закон Литтла. Она связывает три числа.
Среднее время выполнения равно среднему числу задач в работе, делённому на пропускную способность.
Единицы должны совпадать: если пропускная способность в задачах за неделю, время получается в неделях. Формула работает для средних значений за период, когда поток примерно устойчив.
Но то же деление годится и для быстрого прогноза на сейчас. Возьмём учебные данные из таблицы выше: если задачи берут по очереди, у задачи, начатой на шестой неделе, впереди 30 задач. Команда закрывает по 5 в неделю, значит, от начала работы до сдачи пройдёт около 6 недель.
Но задачи ещё и ждут в очереди. Если смотреть на заявку, которая поступила на шестой неделе: впереди неё 20 задач в очереди и 30 в работе, вместе 50 задач - при темпе 5 в неделю это около 10 недель.
Из них около четырёх недель задача просто ждёт, пока до неё дойдут руки.
Это прогноз при нынешнем темпе, а не среднее по закону Литтла. В примере поток неустойчив - очередь и число задач в работе растут, поэтому сам закон здесь в точном виде неприменим. Если приходит 12 задач в неделю, а заканчивают 5, каждая следующая задача будет ждать дольше.
Формула объясняет и историю команды выше: когда задач в работе много по сравнению с тем, сколько команда закрывает за неделю, срок одной задачи растягивается на месяцы.
Приток против закрытия: почему план по остатку не сходится
Типичный план звучит так: надо сделать 150 единиц работы, команда закрывает по 15 в неделю - значит через 10 недель всё готово.
Но работа ещё и приходит: дефекты, уточнения, новые требования. В учебном примере: если каждую неделю добавляется 5 единиц, остаток снижается на 10 в неделю, а не на 15.
Если остаток уменьшается на 10 в неделю, 150 единиц уйдут за 15 недель.
На пять недель дольше плана. А если добавляется 15 единиц в неделю - остаток не снижается вообще.
Представьте ванну: если вливается столько же, сколько выливается, уровень не падает. Спешка ускоряет закрытие задач и одновременно производит новые дефекты - те, которых пока никто не видит. Работа над продуктом может расходиться: остаток растёт, хотя все заняты закрытием задач.
Требования на старте всегда неполные: через две-четыре недели о задаче известно больше, чем в начале. Их уточняют по ходу, и каждое уточнение тоже ложится в остаток.
Есть простой мысленный эксперимент. Новая интересная задача раз в три месяца - в радость. Раз в месяц - сроки сжаты, но терпимо. Каждую неделю - не успел доделать предыдущую, а уже пришла новая. Каждый день - не успел подумать о прошлой, а уже следующая. Такую нагрузку компания создаёт сама своей организацией работы.
С притоком работают отдельно: считают его по видам - новые требования, дефекты, срочное, - решают, от чего отказаться, и убирают причины дефектов, чтобы те не возвращались в очередь.
Счёт одних закрытых задач показывает только половину картины.
Лимит задач в работе: как ввести его без революции
Лимит задач в работе - это договорённость о максимальном числе задач на этапе или у одного человека.
Как это делается на практике:
- Посчитайте, сколько задач сейчас в работе на каждом этапе или у каждого человека.
- Договоритесь о лимите ниже этого числа.
- Новую задачу берут только тогда, когда закончена одна из текущих.
- Держите очередь на виду и раз в неделю решайте, что делать первым и от чего отказаться.
- На ежедневной короткой встрече задавайте один вопрос: что тебя сейчас блокирует.
- Раз в неделю смотрите на диаграмму: полоса «в работе» должна перестать расширяться.
Учебный расчёт: команда закрывает 5 задач в неделю, лимит задач в работе - 10.
При 10 задачах в работе и темпе 5 задач в неделю срок от начала работы до сдачи составит 2 недели.
Против шести недель при 30 задачах в работе из примера выше - при той же пропускной способности.
У лимита есть три оговорки.
Общий срок от поступления заявки до результата сокращается, только если управлять очередью: решать, что делать первым и от чего отказаться. Иначе ожидание просто переезжает из полосы «в работе» в очередь, и суммарный срок не меняется.
Если приходит 12 задач в неделю, а команда закрывает 5, лимит этот перекос не исправит. Нужно снижать приток или поднимать пропускную способность - или и то, и другое.
После снижения притока сроки не падают сразу. Сначала надо доделать то, что уже накопилось - это видно по истории команды выше: она стала брать меньше задач, а срок уже успел вырасти до 12 недель.
Что меняет AI и с чего начать
AI ускоряет и поток, и хаос. Если один человек с AI-агентами резко ускорился, он упрётся в систему вокруг, и её скорость его затормозит.
Автоматизировать сломанный процесс - значит получить тот же сломанный процесс, только быстрее и в большем масштабе. Эта ошибка внедрения разобрана в статье почему AI-проекты не достигают целей.
Диаграмму потока можно построить автоматически. AI-агент делает это по выгрузке задач из трекера с датами смены статусов - дёшево и быстро. Но результат нужно проверить так же, как любой другой отчёт агента. Как это выглядит на сложных таблицах, показано в статье как AI разбирает сложный Excel и собирает дашборд.
Если агенты делают работу, которую никто не проверяет, их незаметные ошибки становятся притоком дефектов: одно место починили, два сломали. Качество процессов оказывается важнее, когда агенты работают быстро.
Первая реакция на кумулятивную диаграмму потока обычно такая: «наверное, у всех так». На деле это просто никто не мерил. Что не измеряете - тем не управляете, и многие решения, которые кажутся эффективными, на цифрах быстро оказываются неэффективными.
Majento внедряет ИИ в рабочие процессы и начинает с одного процесса: нужен владелец процесса, данные, доступ и критерии - что считать хорошим результатом. Для первого разговора полезно описать один процесс, системы в нём и то изменение, которое хотите измерить. Среднее время задачи и число задач в работе - хорошее начало. Подробнее о подходе - на странице внедрение ИИ. Как рабочая задача команды превращается в проект внедрения, показано на демонстрации пилота.
Вопросы и ответы
Чем кумулятивная диаграмма потока отличается от диаграммы сгорания задач?
Диаграмма сгорания показывает один остаток: сколько работы ещё не сделано. Если остаток перестал падать, по ней не понять, команда стала медленнее закрывать задачи или работы стало больше приходить. Кумулятивная диаграмма потока рисует приток, работу и закрытие отдельными линиями, и причина видна сразу.
Подходит ли диаграмма, если у нас не разработка?
Да. Любой процесс со статусами подходит: обработка заявок, движение сделок в системе учёта клиентов, задачи маркетинга, заказы интернет-магазина. Нужны данные с датами смены статусов, выгруженные из трекера задач или системы учёта клиентов.
Какой лимит задач в работе поставить?
Начните с числа ниже текущего. По закону Литтла лимит примерно равен желаемому времени выполнения, умноженному на пропускную способность команды. Учебно: команда закрывает 5 задач в неделю и хочет укладываться в 2 недели - значит, лимит задач в работе около 10. Это стартовая точка: потом лимит корректируют по тому, что показывает диаграмма.
Почему после того, как стали брать меньше задач, сроки не сократились сразу?
Сначала доделывают то, что уже накопилось. Задачи, начатые в период высокой загрузки, всё ещё идут через систему. Диаграмма покажет это: полоса «в работе» будет постепенно сужаться.
Можно ли поручить построение диаграммы AI-агенту?
Да, по выгрузке из трекера с датами смены статусов. После этого нужно проверить: число задач в каждом статусе на выбранную дату должно совпадать с тем, что трекер показывает на ту же дату. Так ошибка выгрузки не попадёт в выводы.
Если хотите разобрать поток задач своей команды и найти, где застревает работа, напишите в Telegram или на hello@majento.ai.