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

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

А что если вы попросите об этом же неэффективную команду с типичным водопадным процессом? Велика вероятность того, что у них раздробленное видение (мы писали об этом в главе 2). Наверняка каждый расскажет, как выполняет свою ежедневную работу: разработчики будут писать о кодировании, тестировщики – о тестировании, бизнес-аналитики – о сборе требований и т. д. Руководитель проекта может иметь более широкую перспективу, потому что должен знать роль каждого в создании плана проекта, поэтому, вероятно, включит в описание работу всей команды. Но также не исключено, что он просто опишет шаги, которые необходимы для планирования и отслеживания проекта.

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

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

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

Сложные процессы и неписаные правила обычно возникают со временем и особенно распространены в командах с раздробленным видением. Усложнение процессов контроля изменений может произойти, потому что для бизнес-аналитика проблематично поддерживать большое количество изменений в последнюю минуту и он громко и часто возмущается при всей команде, что «наше программное обеспечение не удовлетворяет потребностям конкретного пользователя». Он может усложнить процесс, чтобы контролировать границы изменений и убедиться, что существуют бумажные документы, благодаря которым можно спасти свою шкуру, если в дальнейшем кто-нибудь решит изменить мнение. Трудно винить бизнес-аналитика в создании оборонительной бюрократии. Это может оказаться единственно возможным способом контролировать спецификацию, за которую он несет ответственность.

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