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

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

Представьте реакцию руководителя, когда он увидит, сколько времени было затрачено на ожидание, особенно если ему приходится иметь дело с нетерпеливым и требовательным клиентом. Если команда сможет найти способ снизить количество потерь и время ожидания, то она сумеет существенно сократить время поставки будущих функций. Это осчастливит клиента, который, в свою очередь, сделает счастливым руководителя. И вот как визуализация потерь позволяет проще убедить всех – особенно руководителя: что-то нужно менять.

Постарайтесь глубже понять продукт

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

Существуют два аспекта – внутренняя и внешняя целостность. Программное обеспечение должно иметь целостность с точки зрения пользователей (внешнюю) и с позиции разработчиков (внутреннюю). Lean включает в себя два инструмента, помогающие понять внутреннюю целостность: рефакторинг и тестирование. Это ровно то же самое, о чем вы узнали в главе 7. Очень эффективный способ построить систему с высокой степенью внутренней целостности заключается в использовании инструментов XP – особенно разработки через тестирование, рефакторинга и инкрементальной архитектуры.

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

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

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