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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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