Если что-то считается потерями с точки зрения разработки ПО, то это не обязательно бессмысленные действия. Просто они не помогают построению программного обеспечения. Возможно, старший менеджер действительно нуждается в плане проекта, потому что с его помощью хочет убедить акционеров продолжить финансирование. А протоколы совещаний бывают необходимы государственным регулирующим органам. Заявление о приеме на работу бесполезно для команды, но оно обязательная часть процесса заключения трудового договора. Все это может потребоваться, но не приносит пользы непосредственно проекту. Поэтому мы говорим о потерях.
Устранение потерь начинается с выявления. Умение видеть их – первый инструмент мышления для данной ценности.
Часто расточительная деятельность – это приоритет для кого-то (руководителя проекта, который не является частью команды, аккаунт-менеджера, кого-то из старших менеджеров), поэтому ее трудно распознать. Некоторые потери принимаются командой. Например, все знают, что процесс бюджетирования занимает много времени и не включает никакой деятельности, напрямую приводящей к созданию программного обеспечения. Есть вид потерь, настолько привычных, что они, по сути, невидимы. Так, члены одной команды могут располагаться в трех различных частях офиса, и, чтобы дойти до напарника и поговорить с ним, нужно дополнительно потратить пять минут.
Мэри и Том Поппендик решили определить семь потерь разработки программного обеспечения. Как и многое другое, связанное с Lean, эта идея позаимствована у компании Toyota в середине прошлого века. Поппендик обнаружили, что это поможет увидеть потери в вашем проекте.
Частично проделанная работа
Когда вы осуществляете итерации, вы лишь приближаете работу к состоянию «сделано», потому что если это не полностью работающий продукт, то он не создает ценности для пользователей. Любая деятельность, не предоставляющая ценность, – потери.
Дополнительные процессы
Пример дополнительного процесса – антипаттерны управления проектом (глава 7), где команда тратит 20 % времени на отчет о состоянии проекта и оценки, которые используются исключительно для обновления отчета о его состоянии. Все это требует дополнительных усилий в процессе отслеживания проекта и формирования отчетности, но не создает стоимости.
Лишние функции
Когда команда создает никем не заказанную функцию вместо той, которая на самом деле нужна пользователям, – это потери. Иногда причина в том, что кто-то в команде слишком увлекся новой технологией и хочет воспользоваться возможностью изучить ее. Возможно, это ценно для того, кто таким образом улучшает свои навыки, и даже для всей команды (в долгосрочной перспективе). Но это не помогает построению ценного программного обеспечения, так что является потерями.
Переключение между задачами
Некоторые команды работают в многозадачном режиме, и часто он выходит из-под контроля. Люди понимают, что полностью заняты (созданием программного обеспечения) и к тому же имеют дополнительные задачи, относящиеся к частичной занятости (поддержка, обучение и т. д.). И каждый кусочек работы важен и приоритетен. Scrum-ценность «сосредоточенность» демонстрирует нам, что переключение между проектами или не связанными между собой задачами в рамках одного проекта вызывает неожиданные задержки и усилия, потому что создает дополнительную нагрузку на способность к восприятию задач. Теперь мы можем назвать это иначе: потери.
Ожидание
Есть множество вещей, заставляющих профессиональных разработчиков ПО сидеть и ждать: кто-то должен закончить обзор спецификации, утвердить доступ к системе проекта, исправить проблемы с компьютером или получить лицензию… Все это – потери.
Движение
Когда члены команды располагаются в разных помещениях, людям приходится вставать и идти к коллегам, чтобы обсудить проблемы, связанные с проектом. Если сложить время, затраченное на такие прогулки, то потери составят несколько дней или даже недель.
Дефекты
Разработка через тестирование предотвращает множество дефектов. Каждый программист, «зараженный тестированием», хорошо знаком с ситуацией, когда модульный тест обнаруживает ошибку, которую было бы очень сложно исправить позднее, и понимает: требуется гораздо меньше времени на написание всех тестов, чем на отслеживание одной ошибки, особенно если пользователи обнаружат ее после выпуска новой версии. Но если команде приходится задерживаться, чтобы исправлять ошибки, которые можно было предупредить, – это тоже потери.
Кажутся ли вам некоторые перечисленные нами потери полезными? Даже когда что-то теряется, это обычно полезно (или кажется полезным) для кого-то. Так, очевидно неэффективное размещение разработчиков по разным офисам, вероятно, помогает офис-менеджеру решать какие-то организационные проблемы. Если вы видите потери, то сможете понять эти мотивы и объективно оценить, насколько они важнее, нежели возможность сделать ваш проект качественно. Даже принося кому-то пользу, все эти вещи расточительны по отношению к созданию продукта, который обеспечивает ценность для пользователей и компании. Бережливое мышление предполагает четкое видение деятельности людей (внутри и за пределами команды), не добавляющей ценности для конкретных целей проекта.
Платформенная ловушка в главе 7 – хороший пример командных потерь. Если разработчики создают большую платформу для решения проблемы, которую можно устранить с гораздо меньшим количеством кода, то это означает, что эта платформа и есть потери – что довольно иронично, учитывая, что изначальной целью создания платформы было как раз предотвратить потери за счет автоматизации повторяющихся задач и устранения дублирования кода. Еще хуже, что эта платформа часто становится препятствием в будущем, потому что команде приходится либо расширять ее, либо выстраивать работу вокруг нее, когда необходимо добавить компоненты, которые она явно не поддерживает. Эти дополнительные усилия – тоже потери.
Команда, которая может разглядеть потери, ясно видит, что эта платформа предотвращает добавление ценности в проект. Люди понимают: потери влияют на то, как они выполняют свои задания, и ясно видят эти потери в своей ежедневной работе. Даже если их сочтут необходимыми для компании, они все-таки выглядят как мусор, потому что не добавляют ценности продукту.
В своей книге Lean Software Development Мэри и Том Поппендик рекомендуют запастись карандашом и бумагой и выполнить простое упражнение, чтобы помочь вам найти потери. Его называют «карта потока ценности», и вы можете реализовать его для любого процесса. Как и многие методы, используемые в сочетании с Lean, он возник в производственной сфере, но актуален и для разработки программного обеспечения.
Чтобы создать карту потока ценности для проекта, требуется не более получаса. Вот как нужно действовать. Начните с небольшого рабочего элемента, несущего ценность клиенту, уже созданного командой и представленного пользователям. Попробуйте найти наименьшую единицу, такую, например, как минимальная маркетинговая функция (ММФ) или самый маленький «кусочек» продукта, приоритетный для потребителей. Заново продумайте все шаги, проводящие этот фрагмент от начала до поставки. Нарисуйте прямоугольник для каждого из шагов, используя стрелки, чтобы соединить этапы друг с другом. Поскольку вы рисуете актуальный путь, который проходит реальная функция, это будет прямая линия. Нет никаких точек принятия решения или развилок, потому что перед вами история реального объекта.
Концепция ММФ очень важна. К счастью, вам уже знакомо это понятие. Когда владелец продукта в scrum-команде управляет элементами в бэклоге, он имеет дело с типичными ММФ. Они часто принимают форму пользовательских историй, требований или запросов.
Затем оцените, сколько времени потребовалось для выполнения работы на первом шаге и сколько – до момента начала следующего. Повторите эту процедуру для каждого шага и нарисуйте линии под прямоугольниками, чтобы представить с их помощью время работы и время ожидания.
Рисунок 8.2 показывает пример карты потока ценности для реального объекта, проходящего через традиционный процесс водопада.
Рис. 8.2. Эта карта потока ценности показывает, как объект в проекте разработки программы проходит через традиционный цикл управления проектами. Команда может его использовать, чтобы отчетливее видеть, где время тратится впустую
Карта потока ценности наглядно показывает, сколько времени было потрачено на ожидание. В общей сложности с момента, когда коллектив начал работать над программой, и до момента развертывания проекта прошел 71 день. Из этого количества 35,5 дня ушли на ожидание. На это может быть множеством причин: на формирование требований могло потребоваться много циклов ревью и утверждений, пришлось долго ждать встречи по оценке проекта, поскольку график каждого из ее участников был слишком плотный, планы всегда рассматриваются комитетом, собирающимся всего раз в неделю, и т. д. Карта потока ценности показывает совокупное влияние этих задержек на объект, не нагружая вас подробностями, почему так произошло. Видение общего воздействия помогает вникать в то, какие задержки – это потери, а какие необходимы для реализации проекта.
Для команды, возможно, это ожидание не казалось слишком долгим, потому что она наверняка занималась работой над другой функцией. Но клиент, который нуждается в этой функции, не всегда знает о других приоритетах команды. И, откровенно говоря, они ему неинтересны. Главное он знает точно: на создание нужной ему функции от момента запуска проекта до момента поставки ушел 71 день.
Представьте реакцию руководителя, когда он увидит, сколько времени было затрачено на ожидание, особенно если ему приходится иметь дело с нетерпеливым и требовательным клиентом. Если команда сможет найти способ снизить количество потерь и время ожидания, то она сумеет сущ