Книга: Постигая Agile

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

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

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

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

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

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

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

Если программа «глючит» и часто «падает», то налицо проблема целостности. Но как только вы создаете нормально работающее программное обеспечение, его воспринимаемая целостность может стать более коварной. Один крупный новостной сайт, например, на протяжении многих лет испытывал трудности с целостностью. В течение этого времени было трудно скопировать размещенные на нем тексты и вставить их в документы или электронные письма. Первая попытка выделить текст вызывала появление на сайте всплывающего определения слова, на которое нажал пользователь. В конце концов эта функция была отключена, и у пользователей появилась возможность копировать и вставлять. Но при редизайне сайта было заблокировано выделение текста целиком, а попытка сделать это приводила к всплыванию в новом окне соответствующей статьи.

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

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

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

В течение следующего десятилетия видеоигры становились все более популярными. Поэтому разработчики упорно искали способы спроектировать игры для обеих аудиторий. Как этого удалось добиться?

Первым делом следовало уразуметь, что как случайным, так и хардкорным игрокам нужна концептуальная целостность. Забавные казуальные игры типа Tetris, Angry Birds и Candy Crush предусматривали медленное развитие со все увеличивающейся сложностью на многих уровнях. Ценность для случайных геймеров – это постоянное увеличение сложности в сочетании с постоянным чувством удовлетворения от достижения цели. Если Angry Birds начинали с пяти легких уровней, а потом сталкивали игрока с уровнем, который оказывался для него крайне сложным, то люди переставали играть, потому что обнаруживался явный разрыв в концептуальной целостности. Такой разрыв называется диссонансом.

Хардкорные геймеры не любят игры с медленным, стабильным обучением или постоянным вознаграждением за успехи, которых они не «заработали». Они часто получают большее удовлетворение от «шлифовки» или необходимости вступать в повторяющиеся и часто неприятные задачи ради получения награды, соответствующей прогрессу.

Забавной видеоигре не следует иметь уровень, чреватый фрустрацией игрока, «шлифующая» видеоигра не должна иметь легкий уровень. Игры типа Flappy Bird, Super Meat Boy и многие из игр Final Fantasy заслужили похвалы хардкорных геймеров благодаря своей сложности и тому количеству раз, которое следовало пройти многие уровни, прежде чем игра оказывалась освоена. Простой уровень в «шлифующих» видеоиграх мог вызвать такой же диссонанс в душе хардкорного геймера, какой сверхсложный уровень в относительно легкой игре – у случайных игроков.

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

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

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

Мы видели, как такие действия становятся потерями, но иногда они служат целям, которые могут не принести пользу проекту, однако необходимы для него или для компании в целом. Например, команда можете впустую тратить время (с точки зрения пользы для проекта), заполняя отчеты, не помогающие проекту. Но если они необходимы для регулятора, то нужны и компании. Как мы узнаем, какие виды деятельности действительно полезны?

Вот где проявляется следующая lean-ценность: рассматривайте ситуацию в целом. Чтобы понять, результативна ли ваша команда, оцените всю систему, чтобы иметь объективный взгляд на вещи: слишком легко в процессе решения полностью выложиться эмоционально. Например, менеджер проекта создал систему расписаний, которая требует, чтобы каждый разработчик ежедневно каждые 15 минут заполнял табель учета времени. Он, возможно, будет счастлив, обзаведясь постоянно обновляющимся статусом проекта, которого он так добивался, но при этом даже не догадывается, сколько сил уходит на это у команды. Поэтому намного проще убедить его отказаться от этих дополнительных обновлений, если удастся доказать, что они обходятся команде, скажем, в 5 % от ее производительности.

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

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

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

Пользователи очень трепетно относятся к тому, насколько команды учитывают их потребности. Клиенты хотят, чтобы их требования быстро превращались в программное обеспечение. Они чувствуют себя намного счастливее, получая от команды одну новую функцию в месяц вместо трех – но за три месяца. Именно поэтому Scrum и XP используют итерации, а agile-команды – короткие циклы обратной связи.

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

Это выглядит неопровержимым свидетельством того, что команда проекта успешно создает программное обеспечение, предоставляя те возможности, о которых просили пользователи. Более того, менеджер может указывать на буферы в расписании, чистый перечень рисков и систему учета работ, демонстрирующую, что проект полностью контролируется и все необходимые предосторожности были сделаны для известных и неизвестных рисков в будущем. Как руководителю вам приятно осознавать, что у вас есть контроль над проектом, представление о том, как он работает, и способ справиться с неожиданными проблемами.

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

Но как убедить команду побыстрее ответить на самые важные запросы? Можно пытаться противостоять ей, но разработчики указывают на положительные отчеты о состоянии дел и утверждают, что с их точки зрения проект идет очень хорошо. Как заставить их увидеть проблему?

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

Вот как его высчитывают. Каждый раз, когда пользователь делает запрос, записывайте дату. Когда версия ПО, включающая эту просьбу, будет выпущена, зафиксируйте дату окончания. Разница между этими датами – это и есть время выполнения для каждого запроса. Сложите время выполнения всех запросов в релизе и разделите сумму на количество функций, чтобы вычислить среднее время выполнения для данного релиза[79].

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

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

Теперь, когда речь зайдет о жалобах на работу команды, вы сможете что-то противопоставить менеджеру проекта, который ссылается на успешные отчеты, и указать на объективное измерение времени выполнения. Так вы докажете, что у команды действительно есть проблема. Это гораздо лучше, чем фраза «я здесь главный, поэтому делайте так, как я сказал», потому что есть четкая и объективная цель, над которой может работать каждый. Речь не идет о произвольном решении или магическом мышлении.

Проводить измерения и видеть объективную истину в отношении проекта и команды – это только первая часть видения целого. Вторая часть – понимать первопричины (или фактические причины) проблемы.

В конце главы 6 мы обещали вернуться к причинно-следственному анализу, потому что, будучи важной частью бережливого мышления, он также является одним из методов вывода для команд XP. Команды XP и lean-группы используют метод пяти «почему», чтобы выяснить коренную причину проблемы. Как и многое в бережливом мышлении, эта техника зародилась в японской автомобильной промышленности, но отлично подошла agile-командам. Согласно этой простой практике, члены команды задают вопрос «почему» и делают это не менее пяти раз (хотя получают ответы), пока не обнаружат первопричину проблемы.

В нашем примере команда может использовать метод пяти «почему», задавая примерно такие вопросы:

• Почему среднее время выполнения так велико? Потому что выполнение пожеланий большинства пользователей требует более шести месяцев, чтобы превратить их в программное обеспечение.

• Почему требуется более шести месяцев, чтобы превратить запросы в программное обеспечение? Потому что эти запросы на функции почти всегда отодвигаются, чтобы освободить место в расписании для изменений, поступивших в последнюю минуту.

• Почему существует так много подобных изменений? Потому что, прежде чем команда сможет выпустить ПО для пользователей, она должна сделать обзор со старшими руководителями, которые практически всегда запрашивают некие базовые, фундаментальные изменения.

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

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

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

Понимание первопричины долгого времени выполнения дает несколько вероятных решений. Команда может создавать ПО более итеративно и попросить менеджеров принимать участие в демонстрации в конце каждой итерации, а не только основного релиза. Менеджеры могут делегировать свое право утверждать продукт тому (например, владельцу продукта), кто принимает более активное участие в проекте и чаще встречается с командой, и доверить этому человеку право принимать полномочные решения. Кроме того, команды и менеджеры могут продолжать создавать программы таким же образом и оставить неизменными длительные сроки выполнения, но обзавестись аккаунт-менеджерами для работы с пользователями и клиентами, чтобы управлять их ожиданиями.

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

Оглавление книги