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

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

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

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

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