Вот где проявляется следующая lean-ценность: рассматривайте ситуацию в целом. Чтобы понять, результативна ли ваша команда, оцените всю систему, чтобы иметь объективный взгляд на вещи: слишком легко в процессе решения полностью выложиться эмоционально. Например, менеджер проекта создал систему расписаний, которая требует, чтобы каждый разработчик ежедневно каждые 15 минут заполнял табель учета времени. Он, возможно, будет счастлив, обзаведясь постоянно обновляющимся статусом проекта, которого он так добивался, но при этом даже не догадывается, сколько сил уходит на это у команды. Поэтому намного проще убедить его отказаться от этих дополнительных обновлений, если удастся доказать, что они обходятся команде, скажем, в 5 % от ее производительности.
Но хотя признание характера системы, в которой команда работает, может показаться вам простым, это не всегда легко сделать. Каждый участник команды ощущает себя настолько комфортно, насколько его удовлетворяет работа в проекте и то, как он видит свой индивидуальный вклад в нее. Например, программист может считать проект удачным, если ему приходится решать интересную проблему кодирования. Менеджер доволен, когда команда не срывает сроков. Но если разработчику пришлось отказаться от сна по ночам и выходных дней, чтобы уложиться в срок, то он может почувствовать себя так, как если бы этот проект оказался значительно менее успешным.
Вот почему lean-команды применяют метрики – еще один инструмент бережливого мышления, благодаря которому каждый может видеть проект с одной и той же точки зрения. Есть множество аспектов, которые команда разработчиков способна измерить, и выбор правильной метрики помогает получить более полное представление о проекте. Различные измерения проводятся в зависимости от того, какую проблему требуется решить. Все участники проекта имеют различные точки зрения, а целевое использование метрик помогает команде воспринимать проект одинаково.
Для людей, которые не потратили много времени на измерения систем, особенно систем, которые команда использует для создания программного обеспечения, – эта идея может показаться очень абстрактной. Давайте рассмотрим конкретный пример.
Пользователи очень трепетно относятся к тому, насколько команды учитывают их потребности. Клиенты хотят, чтобы их требования быстро превращались в программное обеспечение. Они чувствуют себя намного счастливее, получая от команды одну новую функцию в месяц вместо трех – но за три месяца. Именно поэтому Scrum и XP используют итерации, а agile-команды – короткие циклы обратной связи.
Представьте, что вы владелец бизнеса, который платит за программный проект. Как понять, правильно ли вы расходуете свои деньги? Допустим, вы постоянно получаете доклады от руководителя проекта, где утверждается, что проект выполняется в соответствии с графиком, в рамках бюджета и вообще все прекрасно. В докладе много диаграмм, отчетов и завершенных задач по планам проекта, которые изобилуют зелеными точками, чтобы показать, насколько идеально совпадал с графиком ход выполнения проекта за последние четыре выпуска.
Это выглядит неопровержимым свидетельством того, что команда проекта успешно создает программное обеспечение, предоставляя те возможности, о которых просили пользователи. Более того, менеджер может указывать на буферы в расписании, чистый перечень рисков и систему учета работ, демонстрирующую, что проект полностью контролируется и все необходимые предосторожности были сделаны для известных и неизвестных рисков в будущем. Как руководителю вам приятно осознавать, что у вас есть контроль над проектом, представление о том, как он работает, и способ справиться с неожиданными проблемами.
Но если вы слышите от клиентов, использующих это программное обеспечение, что они сделали ряд простых запросов несколько месяцев назад и до сих пор не обнаружили их среди добавленных функций? Возможно, вы начинаете терять клиентов, которые переходят к конкуренту, потому что он более чутко реагирует на их потребности? И при этом вы хотите сказать, что проект удачен? Налицо серьезная проблема, и вам нужно работать с командой, чтобы это исправить.
Но как убедить команду побыстрее ответить на самые важные запросы? Можно пытаться противостоять ей, но разработчики указывают на положительные отчеты о состоянии дел и утверждают, что с их точки зрения проект идет очень хорошо. Как заставить их увидеть проблему?
В этом поможет объективная метрика. Многие команды будут измерять время выполнения для каждой функции. Это метрика среднего времени – между моментом запроса объекта и его поставкой.
Вот как его высчитывают. Каждый раз, когда пользователь делает запрос, записывайте дату. Когда версия ПО, включающая эту просьбу, будет выпущена, зафиксируйте дату окончания. Разница между этими датами – это и есть время выполнения для каждого запроса. Сложите время выполнения всех запросов в релизе и разделите сумму на количество функций, чтобы вычислить среднее время выполнения для данного релиза[79].
Если вы спросите команду, каково среднее время выполнения запросов, то что они, по вашему мнению, скажут? Разработчики, выпускающие программное обеспечение ежемесячно, наверняка догадаются, что это примерно один-два месяца. Вероятно, это приемлемый срок – большая часть ваших пользователей будут довольны им, разве что вы слышали несколько ворчливых историй от особо недовольных пользователей.
Но что если время выполнения окажется дольше того, на которое согласны клиенты? Не исключено, что реализация простого пользовательского запроса занимает у вас шесть месяцев. Это неудача команды? Может быть, ошибку допустили вы? Или длительное время выполнения – неизбежный побочный эффект того, как организован ваш бизнес? Пока вы этого не знаете. Но зато вы выявили проблему и, поскольку провели измерения – сможете помочь команде понять, что и у нее не все гладко.
Теперь, когда речь зайдет о жалобах на работу команды, вы сможете что-то противопоставить менеджеру проекта, который ссылается на успешные отчеты, и указать на объективное измерение времени выполнения. Так вы докажете, что у команды действительно есть проблема. Это гораздо лучше, чем фраза «я здесь главный, поэтому делайте так, как я сказал», потому что есть четкая и объективная цель, над которой может работать каждый. Речь не идет о произвольном решении или магическом мышлении.
Проводить измерения и видеть объективную истину в отношении проекта и команды – это только первая часть видения целого. Вторая часть – понимать первопричины (или фактические причины) проблемы.
В конце главы 6 мы обещали вернуться к причинно-следственному анализу, потому что, будучи важной частью бережливого мышления, он также является одним из методов вывода для команд XP. Команды XP и lean-группы используют метод пяти «почему», чтобы выяснить коренную причину проблемы. Как и многое в бережливом мышлении, эта техника зародилась в японской автомобильной промышленности, но отлично подошла agile-командам. Согласно этой простой практике, члены команды задают вопрос «почему» и делают это не менее пяти раз (хотя получают ответы), пока не обнаружат первопричину проблемы.
В нашем примере команда может использовать метод пяти «почему», задавая примерно такие вопросы:
• Почему среднее время выполнения так велико? Потому что выполнение пожеланий большинства пользователей требует более шести месяцев, чтобы превратить их в программное обеспечение.
• Почему требуется более шести месяцев, чтобы превратить запросы в программное обеспечение? Потому что эти запросы на функции почти всегда отодвигаются, чтобы освободить место в расписании для изменений, поступивших в последнюю минуту.
• Почему существует так много подобных изменений? Потому что, прежде чем команда сможет выпустить ПО для пользователей, она должна сделать обзор со старшими руководителями, которые практически всегда запрашивают некие базовые, фундаментальные изменения.
• Почему топ-менеджеры почти всегда запрашивают базовые, фундаментальные изменения? Потому что каждый из них имеет собственное, довольно специфическое мнение о том, как программа должна выглядеть и функционировать, какие технические средства следует использовать, чтобы ее создать, но команда не слышит этих мнений до тех пор, пока она не напишет весь код и не сделает презентацию для старших менеджеров.
• Почему команда не может услышать эти мнения до тех пор, пока она не напишет весь код и не проведет презентацию? Потому что топ-менеджеры слишком заняты, чтобы поговорить с командой в начале проекта, они появятся только на финальной презентации – и после ее завершения отправят команду обратно к чертежной доске.
Вот теперь мы наконец поняли, почему реализация запросов пользователей занимает так много времени. Проведение измерений и поиск первопричины помогли выяснить, что не во всем виновата команда. Она заканчивает разработку многих функций, но, когда проводит демонстрацию для старших менеджеров, они просят внести целый ряд изменений. Возможно, выяснится, что эти изменения необходимы, то есть идеи менеджеров правильные. Но даже полезные изменения требуют, чтобы этот конкретный менеджер провел анализ последствий, обновил план проекта и перенес измененные функции на более поздний выпуск. Что и привело в итоге к весьма длительному периоду выполнения, который был измерен. Более того – некоторые пожелания уже были запланированы на следующую версию, так что пришлось сдвинуть на еще более позднюю версию, чтобы освободить место для изменений, внесенных менеджерами. В результате время выполнения некоторых запросов настолько затянулось, что некоторые клиенты были вынуждены уйти к конкурентам.
Понимание первопричины долгого времени выполнения дает несколько вероятных р