Если есть система – неважно какая, – то большинству такие вопросы могут даже не приходить в голову. Даже если вы используете Scrum или XP, вы можете терять впустую много времени, не подозревая об этом. Привычные проблемы очень трудно обнаружить. Каждый может следовать правилам и делать все верно. Но так же как поведение формируется самой системой, потери складываются из совместной работы многих людей.
Такой пример приведен в главе 8: команда невольно увеличивает производственный цикл, даже если все активно трудятся и никто намеренно не затягивает работу. Но несмотря на это, заказчику кажется, что проект сильно задерживается. Хотя в команде даже не заметили этого, потому что делают все возможное, чтобы выполнить задачу как можно скорее.
Это и есть та проблема, которую решает Канбан.
Первый шаг к улучшению системы – признание того факта, что она существует. Идея
Каждая система принимает входные сигналы и превращает их в готовую продукцию. Как выглядят scrum-команды с точки зрения системного мышления? Вы можете думать, что Scrum – это система, которая берет задачи бэклога проекта на входе, а на выходе выпускает код. Многие scrum-команды имеют бэклог проекта, который состоит исключительно из историй. Такие команды считают себя «машинами», которые превращают истории в код.
Но очевидно, что они остаются командами, и мы предпочитаем рассматривать их участников как людей, а не роботов. Однако полезно думать о задаче, которую вы выполняете, как о части большой системы. Если применить системное мышление к scrum-команде, то становится ясно: выполняемая работа напрямую (или даже косвенно) способствует превращению историй в код. Признавая, что все в Scrum – система, вы поймете, как начать работать лучше и вносить усовершенствования. Такое мышление приводит к улучшениям, таким как дополнительные вопросы Джеффа Сазерленда для ежедневных scrum-митингов, о которых вы узнали в главе 5. Это хороший пример системного мышления, применяемого к Scrum, что приводит к эволюционному усовершенствованию.
Канбан призывает начать с понимания системы, которую использует ваша команда. И даже если вы не будете следовать какой-то определенной методологии, вы все равно сможете применять системное мышление в своей команде для выяснения способа работы.
Легко понять, что команда, исповедующая Scrum, использует систему. Но что если ваша команда не применяет подобные методы? Может быть, вы просто погружаетесь в работу над программным обеспечением? Выглядит все так, будто вы каждый раз запускаете проекты по-разному. Поэтому вы не имеете системы, правда?
Но самое забавное, что люди – особенно команды –
Lean предлагает инструмент, чтобы принять неписаные правила и превратить их в систему: систематизирование потока создания ценности.
Когда вы берете ММФ (минимальную маркетинговую функцию, о которой мы узнали в главе 8, – например, историю, требование или пользовательский запрос) и выявляете систематизированный поток ценности, ведущий к написанию кода, вы должны записать путь через вашу систему.
Если вы работаете в команде, которая придерживается неписаных правил, то вполне вероятно, что одна ММФ сильно отличается от другой. Но поскольку люди интуитивно следуют правилам, довольно вероятно, что вы можете наметить небольшое количество потоков создания ценности, охватывающих основные ММФ, которые ваша команда превращает в код. Если вам удастся сделать это, то вы сможете создать очень точное описание системы, которой следует ваша команда. Прежде всего система решает, какой поток создания ценности MMФ будет из нее вытекать.