По некоторым из элементов работа уже началась и должна продолжаться. Когда рабочие элементы требуют доработки уже после проверки менеджером, они возвращаются в начало процесса. Давайте убедимся, что они представлены на канбан-доске, – мы добавим столбец в начале пути, назовем его «На доработку» и передвинем стикеры влево (ставим маленькую точку на каждом стикере, чтобы сразу обнаружить, если они попадутся во второй раз).

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

Только команда может делать так много работы. Мы узнали об этом при изучении Scrum и ХР, и это важная часть бережливого мышления. Когда команда соглашается сделать больше того, на что способна, случаются неприятности. Она либо игнорирует некоторые виды работ, некачественно создавая продукт, либо работает в неустойчивом темпе, что в будущих релизах обойдется очень дорого. Иногда не сразу становится очевидно, что команда взяла на себя больше обязательств, чем может выполнить: каждый отдельный дедлайн выглядит разумным, но если предполагается, что все работают в многозадачном режиме в нескольких проектах или с несколькими элементами одновременно, то команда постепенно начинает испытывать перегрузки и требуются дополнительные усилия для переключения с одной задачи на другую. А это приводит к потере до 50 % производительности.

Визуализация рабочего процесса позволяет команде распознать перегрузку. Это первый шаг к устранению проблемы. Неравномерность и перегрузки, о которых мы узнали в главе 8, проявляются на канбан-доске, когда стикеры собираются в одном столбце. К счастью, теория массового обслуживания не только предупреждает нас о проблеме, но и предлагает способ ее исправить. После выявления неравномерностей в рабочем процессе мы можем управлять объемом работ во всей системе, поставив жесткое ограничение на выполнение незавершенной задачи. Такая канбан-практика называется ограничение на выполнение незавершенных работ (limit work in progress, WIP-лимит).

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

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

Для этого Канбан возвращается к бережливому мышлению – в частности, к принципу вариантного мышления, о котором говорилось в главе 8. Одна из причин, почему канбан-команда использует канбан-доску, – это возможность увидеть на ней все варианты. Если вы как разработчик только что закончили создавать архитектуру нового функционала, то легко предположить, что теперь вы возьметесь за код. Но работа над кодом для данного функционала – это возможность, а не обязательство. Глядя на канбан-доску, вы видите много стикеров, с которыми можно дальше работать. Вероятно, есть другие стикеры, сообщающие о необходимости разработки нового функционала, или столбец с ошибками, найденными во время тестирования функционала и ждущими исправления. Как правило, у вас большой выбор. Какой вариант вы предпочтете?

Установление WIP-лимитов на этапы в рабочем процессе подразумевает ограничение количества элементов работы, допустимых на этом этапе. Это облегчает команде выбор элементов работы, позволяет избежать перегрузки и способствует равномерному и максимально эффективному протеканию рабочего процесса в ходе разработки функционала. После ее завершения вы видите, что взять в разработку новый функционал невозможно из-за ограничений лимита. Тогда вы смотрите на другие возможности применения своих навыков, имеющиеся на доске, и работаете с ними – и команда тестировщиков не будет перегружена. (Представляете себе, как это может сократить среднее время разработки функционала? Если да, то вы начали приобретать навык системного мышления!)

Давайте вернемся к команде, которая использует пять «почему», чтобы найти причину проблемы во времени, отведенном на выполнение заказа. После того как мы создали для них канбан-доску, определилась перегрузка: стикеры начали накапливаться в колонке «приемка руководством». Поэтому, чтобы ограничить объем выполняемых работ для этой команды, мы просто нашли способ ограничить количество скапливающихся элементов до того, как менеджеры проведут сессию приемки.

В Канбан, узнав о такой проблеме рабочего процесса, как эта, вы устанавливаете WIP-лимит (или работаете с ограничением на выполнение незавершенных работ). Для этого команда должна встретиться с руководством, чтобы убедить всех принять новые правила. Новая политика устанавливает WIP-лимит, подразумевающий, что в столбце «приемка руководством» может накапливаться только определенное количество элементов работы. Канбан-доска и подсчет времени на выполнение заказа дают команде и руководителю проекта достаточно объективных доказательств, чтобы убедить менеджера согласиться с этим.

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