Читаем Постигая Agile полностью

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

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

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

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

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

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

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

Так новое поведение проявляется и вне команды. Вместо того чтобы просто обвинять разработчиков за неравномерную нагрузку, в чем необязательно они виноваты, всех начинают волновать стикеры в первом столбце, потому что именно ими будет заниматься команда. Можно организовывать встречи для определения приоритетов, устраивать «торги» между собой или искать любые другие пути, чтобы решить, какие задачи выполнять в первую очередь. Но, главное, команде больше не нужно брать на себя вину, потому что она не должна работать на пределе возможностей.

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