На самом деле эта книга должна была быть совсем небольшой… чем-то вроде памфлета.

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

Составлять карты до смешного просто. Работая вместе с другими, я озвучиваю историю работы с продуктом, записывая каждый шаг, предпринимаемый пользователем, на листочках-стикерах и наклеивая их слева направо. Затем мы возвращаемся к началу и обсуждаем каждый шаг в деталях, записывая подробности на листочках и наклеивая их сверху вниз под соответствующим шагом. В результате получается простая, напоминающая таблицу структура, излагающая историю слева направо и раскрывающая детали сверху вниз. Быстро и очень интересно. А эти детали образуют бэклог (backlog)[1] историй для наших проектов, разрабатываемых по Agile.

Сложно ли написать об этом книгу?

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

Если вы используете процесс разработки, описанный в методологии Agile, то ваши бэклоги и так, наверное, заполнены пользовательскими историями (user story). Я думал: раз создание историй является настолько распространенной практикой, писать о них книгу будет напрасной тратой времени. Но, как оказалось, я ошибался. Через полтора десятилетия после того, как истории впервые были описаны Кентом Беком, они стали наиболее популярны, а также наименее правильно понимаемы и используемы, чем когда-либо. Это меня огорчает. А главное, это сводит на нет все выгоды, которые мы получаем от составления карт историй.

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

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

Но время наконец пришло.

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

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

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

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

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

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

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

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

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

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

Во всяком случае, чтение книги будет особенно полезным для специалистов следующих областей.

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

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

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

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

Надеюсь, вы отнесли себя к одной или нескольким из описанных здесь групп. Если нет, подарите эту книгу кому-нибудь, кто им соответствует.

А если это все-таки вы, давайте начнем.

В этой книге нет введения.

Да, вы все прочитали правильно. И сейчас, наверное, задаетесь вопросом: «Почему же в книге Джеффа нет введения? Может быть, он забыл его написать? Не пора ли ему на покой? Или введение съела его собака?»

Нет, я не забыл написать введение. И мне не пора на покой (по крайней мере я туда не собираюсь). И моя собака не съедала введения, хотя насчет морской свинки своей дочери я не был бы так уверен. Это просто потому, что за долгое время я убедился: авторы тратят кучу времени, пытаясь убедить меня прочесть их книгу, и большая часть этого времени приходится на введение. Самое интересное во всех книгах начинается примерно с третьей главы. Кроме того, я уверен, что не я один всегда пропускаю введение.

Так что эта книга начинается прямо здесь.

И вам ни в коем случае нельзя пропускать эту часть, так как на самом деле она самая важная. Я буду доволен, если вы вынесете из книги всего две мысли. Вот эти две мысли.

• Цель работы с историями не написание идеальных историй.

• Цель разработки продуктов не создание продуктов.

Сейчас я все объясню.

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

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

Когда люди читают письменные инструкции, они истолковывают их совершенно по-разному. Если вам сложно в это поверить (в конце концов, все это тоже написано!), читайте дальше – вот несколько примеров того, как инструкции действуют абсолютно неверно.

Перед вами обложка книги Джен Ятис «Торты, которым не повезло», опубликованной в издательстве Эндрю Мак-Милла (спасибо Джен и Джону Ятис за предоставление иллюстрации). Книга получилась по мотивам ее очень забавного сайта cakewrecks.com (только не ходите туда, если у вас нет по меньшей мере часа свободного времени). На сайте собрана коллекция по-идиотски украшенных тортов, логика их создателей не поддается объяснению, хотя Джен и предпринимает попытки сделать это. Так, одна из самых часто встречающихся и в книге, и на сайте тем – неверно понятые требования. Джен, конечно, не называет их требованиями, ведь это слишком формальный термин, вместо этого она употребляет слово «записи», так как исполнитель слушает и записывает, понимая буквально то, что слышит. Глядя на эти фото, я могу вообразить сотрудника кондитерской, который слушает заказчика и записывает его пожелания, а потом передает их кому-то, кто будет украшать торт.

Заказчик: «Здравствуйте, я хотел бы заказать торт».

Работник: «Конечно, что бы вы хотели на нем написать?»

З.: «Вы могли бы написать “Всего хорошего, Алиса” фиолетовым цветом?»

Р.: «Конечно».

З.: «А вокруг надписи пусть будут звезды».

Р.: «Без проблем. Я записал ваши пожелания и прямо сейчас передам их кондитеру-декоратору. Торт будет готов к завтрашнему утру».

Вот что получилось в результате.

Вот еще один пример. В разработке программного обеспечения такие вещи мы называем нефункциональными требованиями.

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

Может быть, вы слышали о неудачной попытке отправить в 1999 году на Марс орбитальный климатический зонд, в результате аварии которого NASA понесло убытки в размере 125 млн долларов[2]? Если не слышали, вот суть случившегося. Если когда-нибудь какой-либо проект по самые уши тонул в бумажной документации, это был, несомненно, проект NASA. Но несмотря на огромное количество требований и других документов, зонд вышел из строя по той простой причине, что NASA пользовалось метрической системой измерений, а инженеры партнерской компании Lockheed Martin, которые разрабатывали навигационные команды для двигателей аппарата, – британской. В результате никто не знает, где сейчас находится зонд, и некоторые надеются, что он нашел свое место на солнечной орбите где-то за Марсом.

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

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

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

Мой бывший коллега Люк Баррет первым показал мне этот комикс, чтобы описать проблему. Я спросил, где он его видел, но он так и не вспомнил (кто-то, возможно, не получает авторских отчислений). Годами я наблюдал, как Люк демонстрирует эти четыре слайда в презентации PowerPoint, и всегда воспринимал их как нечто забавное, но довольно банальное. Видимо, я туговато соображаю: лишь много лет спустя осознал, что этот комикс иллюстрирует, наверное, самую важную особенность работы с историями при разработке ПО.

Суть в том, что если у меня есть какая-то идея, я ее записываю на бумаге, а вы затем это читаете, то вполне можете представить что-то совершенно иное, чем я. При этом можно спросить каждого: «Вы согласны с содержанием этого документа?», и все дружно ответят: «Да! Да, мы согласны!» Но если мы соберемся вместе и начнем обсуждение, вы можете описать мне, что думаете, а я смогу задать вопросы. Беседа пойдет живей, если мы можем описать наши мысли, рисуя картинки либо фиксируя идеи на стикерах или карточках. Если у каждого из нас будет возможность объяснить свои мысли с помощью слов и картинок, мы придем к общему мнению. Однако здесь мы осознаем, что все понимают всё по-разному, и это очень неприятно. Но по крайней мере теперь проблема известна.

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

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

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

Правильный ответ: просто не занимайтесь документами.

Перестаньте пытаться составлять идеальные документы.

Возьмите и напишите что-нибудь, неважно как. Затем проведите эффективное обсуждение с использованием и слов, и картинок, чтобы прийти к общему мнению.

Если вы применяете в разработке истории, но не обсуждаете их с командой с помощью слов и рисунков, то вы неправильно используете истории.

Если при чтении этой книги вы поставили перед собой цель научиться лучше писать истории, то это плохая цель.

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

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

Хорошо это или плохо, но именно так работают документы.

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

Я пару раз слышал шутку: «Мы перестали писать документацию, и поэтому у нас теперь Agile». Это называется: кто знает – тот поймет, потому что на самом деле процесс, управляемый историями, требует для работы множества документов. Но зачастую эти документы совсем не похожи на традиционные задокументированные требования.

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

Когда вы описываете историю, почти все может быть использовано как инструмент коммуникации. А поскольку мы обсуждаем истории, пишем массу заметок и рисуем кипы рисунков, надо их где-то хранить. Мы складываем их, чтобы позднее просмотреть, фотографируем, включаем в разные документы.

Но помните: самое важное и нигде не записанное – это то, что мы вспомним при прочтении. Вот он, фактор фотографии из отпуска.

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

Многие люди уверены, что их работа – формирование и сбор требований. Но это не так.

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

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

Вот как я изображаю эту модель.

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

• Какие новые продукты вы можете создать.

• Какие функции добавить в существующий продукт.

• Как улучшить создаваемые продукты.

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

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

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

Все, что находится между идеей и выпуском продукта в свет, называется объемом работы. Это то, что мы создаем. Люди, занятые разработкой программного обеспечения по Agile, обычно измеряют скорость работы и стараются увеличить ее. Те, кто создает ПО, разумеется, беспокоятся о стоимости готового продукта, в том числе о временных затратах на его создание, планируемых и реальных.

Но в таком случае объем работы не является основным, ведь мы заботимся не о количестве работы. Нас интересует то, что получается в итоге, – реальный результат. Реальный результат – то, что получается в результате работы (отсюда и название), и его нелегко оценить, поскольку невозможно измерить результат, не доведя работу до конца. Кроме того, реальный результат нельзя измерить количеством добавленных функций или новыми возможностями, предъявленными пользователям. По сути, мы фиксируем, что именно люди делают иначе для достижения своей цели теперь, в результате сделанных вами изменений, и, самое главное, стала ли их жизнь несколько лучше[3].

Ну вот вы и изменили мир.

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

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

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

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

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

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

Да, это неприятная правда в мире программного обеспечения и, как я подозреваю, во множестве других сфер. Но я хорошо знаю эту кухню. И мне точно известно, что

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

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

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

Поймите меня правильно: выработка большего объема продукта за меньшее время – это всегда хорошо, но никогда не решает всех проблем.

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

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

«Джефф, нужно, чтобы вы внесли вот эти изменения в продукт, над которым сейчас работаете».

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

Что я услышал в ответ?

«Это нужно для соответствия требованиям».

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

Она посмотрела на меня так, словно я был самым тупым человеком на свете, и повторила с нажимом:

«Это. Для. Соответствия. Требованиям».

И в этот момент я осознал, что слово «требования» на самом деле означает «заткнись».

Вот что означают требования для большинства людей. Они перестают говорить о людях и проблемах, которые надо решить. Правда же состоит в том, что, даже если вы сделаете лишь часть того, что требуется, пользователи вполне могут остаться довольными[4].

Помните: ваша работа заключается не в том, чтобы достичь соответствия требованиям. Ваша работа в том, чтобы изменить мир.

Запомните эти три вещи, даже если больше ничего не вынесете из книги.

• Истории не требования в письменной форме; создание историй с использованием слов и картинок – механизм выработки одинакового понимания.

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

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

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

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

А сейчас настало время обсудить самый интересный момент в составлении историй – построение карты историй.

«Обожаю разработку Agile! Каждые пару недель у нас начинает работать что-то новенькое! Но, кажется, я уже запутался и не вижу общей картины».

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

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

Если вы читаете эту книгу, то, наверное, знаете, что построение карт историй – способ работы с пользовательскими историями так, как это принято в процессах Agile. На текущий момент практически любая книга о разработке Agile так или иначе воспроизводит «Agile-манифест разработки программного обеспечения» (Agile Manifesto), написанный еще в 2001 году группой ребят, которым надоели громоздкие непродуктивные процессы разработки ПО, распространенные в то время. Я очень рад, что они его написали. Еще я рад тому, что долгосрочный эффект их работы затронул так много людей.

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

На то место, которое занял бы в книге этот манифест, я лучше помещу смешное фото с котенком[5]. Почему? Да потому, что, как доказано, смешные фотографии котиков притягивают в Интернете больше внимания, чем какой бы то ни было манифест.

Но вы, наверное, недоумеваете: что общего у Agile-методов и этого котика? Да, в общем, ничего. Но гибкая разработка определенно связана с этой книгой, с историями, а также с развитием карт историй.

<Звучит ретромузыка>

Я работал в одном стартапе в Сан-Франциско в 2000 году, когда компания приняла на работу Кента Бека (это тот самый парень, который придумал экстремальное программирование и впервые изложил идею историй) в качестве консультанта по наладке процесса разработки ПО. Я совершаю этот исторический экскурс, чтобы показать, что мысль о применении историй на самом деле очень стара. Если вы только начинаете работать с историями, то уже потеряли статус первооткрывателя, который могли бы иметь лет десять назад. Кент и другие пионеры экстремального программирования знали, что все известные в прошлом способы добиться точного соответствия требованиям не работали как следует. И у Кента возникла простая мысль, что все должны собраться вместе и рассказывать истории. Таким образом можно выработать единое понимание и вместе найти наилучшее решение.

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

Еще до того, как я в полной мере осознал, почему истории получили такое название, я понял, что могу написать множество историй – в виде предложения или краткого заголовка, на карточках или стикерах. Я могу менять их местами и расставлять в соответствии с приоритетом, выбирая самые важные из них. Как только я решу, что одна из историй более важная, чем другая, можно начать ее обсуждение. Это было суперкруто! Почему я раньше не записывал ничего на карточках, чтобы удобно было организовать работу таким образом?

Проблема была в том, что одна карточка могла представлять собой нечто, внедрение чего в продукт заняло бы у разработчика несколько часов. Или дней. Или недель. Или целый месяц – кто знает? Точно не я – во всяком случае, пока мы не начнем говорить об этом.

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

В 2001 году я покинул команду, где тогда работал, и начал изменять привычный ход событий. Я и моя команда пытались выработать такой подход к работе с историями, который позволял бы сконцентрироваться на полной картине. Мы разрабатывали общее видение нашего продукта, вместе находили компромиссы и соглашения. У нас было множество карточек с заголовками историй, с помощью которых мы организовывали свои идеи, а также разбивали большую картину на мелкие части, которые отправляли в очередь на разработку. В 2004 году я написал первую статью о таком принципе работы, но не употреблял термин «карты историй» до 2007 года.

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

Впервые я услышал определение паттерна от своей подруги Линды Райзинг: когда вы кому-то рассказываете о своей грандиозной идее, а он отвечает, что тоже придумал и использует что-то подобное, это значит, что вы не изобрели нечто новое, а открыли паттерн.

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

Сегодня компании одна за другой перенимают идею карт пользовательских историй. Моя подруга Мартина, работающая в SAP, в письме, написанном в сентябре 2013 года, сообщила: «…К настоящему моменту было проведено более 120 заседаний рабочих групп по картам пользовательских историй. Они так понравились многим представителям заказчиков! Это отлично зарекомендовавший себя рабочий подход в SAP».

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

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

Несколько лет назад я познакомился с Гэри Левиттом. Гэри был бизнесменом и как раз запускал новый веб-продукт. Этот продукт и сейчас работает, он называется Mad Mimi, что согласно задумке Гэри означало «маркетинговый интерфейс музыкальной индустрии»[6]. Гэри музыкант, и у него есть собственная группа. Он самостоятельно занимался административными делами, а кроме того, помогал управляться с ними и другим, работал в музыкальной студии и делал записи для клиентов.

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

Гэри нужно было, чтобы кто-то разработал этот продукт, поэтому он сотрудничал с другим человеком, и этот другой человек работал в Agile. Он попросил Гэри написать список всего, что он хотел бы видеть в продукте, и расставить элементы списка по важности. Затем они бы обсудили верхние, самые важные элементы и начали создавать их один за другим. В Agile такой список функций обычно называется бэклогом, и, по мнению Гэри, было вполне разумно так и поступить: составить список и начать с самых важных вещей. Так он и сделал.

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

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

Беседа началась. По мере того как Гэри рассказывал, я записывал ключевые слова его идей на карточках. У меня есть что-то вроде мантры, я люблю ее повторять, когда составляю карты пользовательских историй. Она звучит как «говорите и пишите», что означает: не дайте словам пропасть втуне. Запишите их на карточки, к которым сможете обратиться позднее. Вы удивитесь тому, как взгляд на пару слов, записанных на карточке, вызывает в памяти целое обсуждение. Мы можем двигать карточки по столу, выстраивая их в разном порядке. Мы начинаем использовать полезные слова вроде «это» и «то», означающие записанное на карточках. Это экономит уйму времени. Я должен был заставить Гэри вытащить свои мысли наружу – это крайне важно для обеспечения общего мнения. Для него это было непривычно, но я без труда фиксировал идеи на карточках по мере того, как он их излагал.

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

Вот как в конце дня выглядел пол.

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

Предметом первого обсуждения стала сама идея продукта. Мы говорили о бизнесе Гэри и его целях. Зачем вы это создаете? Сформулируйте, какие преимущества даст этот продукт вам и другим людям, которые будут его использовать. Какие задачи он будет решать для этих людей и для вас? Читая это, вы, наверное, догадались, что я думал о модели «до и после». Я пытался понять, какие результаты хочет получить Гэри, а не какую работу он планирует проделать.

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

Мы с Гэри продолжили обсуждение. Следующей темой разговора стали заказчики, которые купят продукт, и пользователи, которые будут непосредственно с ним работать. Мы перечислили различные типы пользователей. Обсудили преимущества, которые они получат, задались вопросом, почему они будут использовать продукт, а также что, как мы предполагаем, будут с ним делать. Что продукт должен включать в себя с точки зрения пользователей? Ответы записали на целую груду бумажек. Карточки, на которых были указаны наиболее важные пользователи, сами оказались на верхних позициях. Забавно, что иногда это работает и таким образом – без явного намерения.

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

Гэри выбрал одну, и после этого мы наконец приступили к составлению историй.

После этого я предложил: «Ну что ж, давай представим себе будущее. Предположим на минуту, что продукт выпущен и работает, и обсудим день жизни кого-то, кто использует его, а затем начнем составлять истории: сперва он делает одно, затем – другое, третье и т. д.»

И мы составили историю, расположив ее на полу справа налево. Иногда возвращались назад и вставляли какие-то элементы в середину, ведь карточки, на которых изложены идеи, очень легко перемещать.

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

По мере того как мы говорим и пишем, а я фиксирую обсуждение, мы создаем нечто по-настоящему важное. Нет, не просто множество карточек на полу. А то, что по-настоящему важно, – единое понимание! Мы находимся, так сказать, на одной волне. У Гэри никогда не было такого взаимопонимания по поводу идеи своего продукта ни с кем другим, во всяком случае, не на таком уровне детализации. Даже он сам никогда не обдумывал продукт так углубленно. Он представлял лишь ключевые моменты, что-то вроде фрагментов основных сцен фильма, которые показывают в трейлерах.

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

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

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

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

Гэри жил в Нью-Йорке и при обсуждении листовок представлял себе все те крутые штуки, которые постоянно видел на стенах и фонарных столбах города. Одни выглядели так, словно кто-то склеил вместе текст и журнальные фотографии, а потом размножил полученное на ксероксе, но другие и в самом деле смотрелись эстетично и элегантно. Записав какое-то количество деталей, я предложил Гэри оставить их в покое, чтобы вернуться к ним позже, а сейчас продолжить обсуждение истории и продвинуть ее дальше. Утонуть в деталях очень легко, особенно если вам очень интересен предмет обсуждения. Но когда нужно получить общую картину, очень важно добраться до конца истории, прежде чем погружаться в мелочи. Еще одна мантра, которую я использую при работе с историями: «Мысли на милю вперед и на дюйм вглубь». Для тех, кому привычнее метрическая система: «На километр вперед и на сантиметр вглубь». Дойдите до конца истории, прежде чем тонуть в деталях.

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

«А сейчас, – сказал я, – давай вернемся назад, проработаем детали, а также рассмотрим некоторые альтернативы».

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

• В чем особенности действий пользователя на данном этапе?

• Какие альтернативные вещи они могут сделать?

• Как можно сделать этот этап по-настоящему крутым?

• Как исправить ситуацию, если что-то пойдет не так?

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

«А что сейчас? – спросил я у Гэри. – У нас есть и другие пользователи, и решить они хотят другие задачи. Хочешь обсудить их? Только, по-моему, если мы будем продолжать, то нам потребуется другая комната, побольше. И еще, Гэри: даже на разработку всего вот этого уже понадобится куча денег. Мы можем обсудить и все остальное, но у нас уже есть довольно много. По-моему, даже если запустить продукт только с этой частью, он будет классным».

Гэри согласился: «Давай на этом остановимся».

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

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

Самое важное в картах историй – это старое доброе обсуждение, а затем его изложение в форме карты. Обычно в центре внимания находится карта – последовательное, слева направо, изложение шагов, с помощью которых можно рассказать историю. Детали шагов располагаются сверху вниз. Но самое важное, что формирует продукт и дает больше всего контекста, обычно находится вне карты – это цели продукта, информация о заказчиках и пользователях. Если ваша карта располагается на стене, то будет очень хорошо разместить рядом с ней эскизы пользовательского интерфейса (UI) и другие заметки.

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

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

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

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

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

Налейте себе чашечку кофе и усаживайтесь поудобнее. Настало время удивительных историй.

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

Сотрудникам Globo.com лучше, чем кому-либо на планете, известно, что такое дедлайны, не подлежащие смещению. Например, компания хочет выпустить новую версию Fantasy Football Game – браузерной игры, которая дополняется и обновляется регулярно к чемпионату мира по футболу – самому громкому событию в футбольном мире. Если Globo.com не будет успевать к чемпионату, то перенос даты выхода игры их не спасет. Почему? Да потому что никто не изменит дату начала чемпионата. Globo.com планирует также выпустить разную функциональность и контент к Олимпийским играм, которые пройдут в Бразилии в 2016 году[8], и я могу гарантировать, что это будет сделано вовремя – иначе никак! Кроме того, в компании выпускается масса функциональности и контента к выходу огромного количества телевизионных программ и реалити-шоу. Ничто из этого не может быть перенесено, если Globo.com запаздывает с разработкой. Компания всегда должна закончить работу вовремя. И так как это очень важно для бизнеса, Globo.com отлично справляется. Не потому, что люди там работают быстрее, чем в любом другом месте, – быстро, конечно, но не настолько быстро. Секрет в том, что они умеют делать меньше.

Посмотрите на рисунок.

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

В тот день, когда я пришел в офис Globo.com, они как раз составили эту карту и, судя по всему, вот-вот должны были угодить в ловушку плоского бэклога. Отдельные команды разработали собственные бэклоги с элементами, расставленными по степени важности. Было понятно, что предстоит огромный объем работы и что каждая группа зависит от остальных. Например, для хорошего новостного сайта требовалась работа не только группы новостей, но и других, которые создадут основные компоненты, нужные сайту для работы: фотографии, видео, данные, полученные в реальном времени, и еще многое.

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

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

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

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

После того как вы визуализировали весь продукт или какую-то функциональность, гораздо проще играть в игру «Что, если». Именно в этот момент мы начинаем задумываться: «Что будет, если что-то пойдет не так?» или «А что с этими, другими пользователями?». Играйте во «Что, если» с любыми сомнениями, которые у вас есть, и добавляйте наклейки в основную часть карты, где затем появятся идеи, которые нужно воплотить в программном обеспечении. В главе 1 Гэри играл во «Что, если», рассматривая варианты и альтернативы. Когда вы и другие команды проделаете это, то удивитесь тому, какое огромное количество проблем может обнаружиться при взаимодействии разных команд.

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

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

Когда я покидал команду реорганизации системы управления контентом в Globo.com, все было прекрасно – все отлично знали, что им делать, и понимали задачу одинаково. Однако, вернувшись через несколько дней проведать ребят, я обнаружил их в растерянности – они поняли, насколько огромная работа им предстоит, а потребуется на нее, скорее всего, больше года. И, как уже догадался проницательный читатель, когда разработчик предполагает сделать что-то за год, на самом деле это означает два. Не потому, что он некомпетентен или не умеет планировать свое время, – просто-напросто оценить временные затраты на то, чего прежде не делал, очень нелегко. Ну и, конечно, все мы склонны смотреть на жизнь с оптимизмом.

«Задача слишком велика! Нужно сделать так много и это займет так много времени!» – говорили сотрудники Globo.com.

«И что, все-все это необходимо реализовать?» – спросил я, на что они, конечно, ответили:

«Разумеется! Это же все части одной большой системы управления контентом!»

«Но ведь обычно вы не делаете проекты так долго. Я знаю вашего генерального директора, он наверняка захочет увидеть результаты гораздо раньше, верно?»

«Так и есть, – подтвердили они. – Он хочет видеть что-то рабочее к выборам в Бразилии, то есть через несколько месяцев».

«А нужно ли, чтобы к этим выборам работало все?»

Ага! Стоило мне задать этот вопрос, как у них в головах словно зажглась лампочка. Конечно же, все им было не нужно. До этого момента они концентрировались на выявлении последовательностей и зависимостей, предполагая, что должны реализовать все задуманное. Это было возможно, вопрос только в сроках. Но теперь наконец фокус сместился на реалистичный результат.

Сотрудники Globo.com сконцентрировались на выборах в Бразилии. Команды думали о великолепных результатах в виде восхищенных посетителей и рекламодателей, а также о компании-учредителе Globo, которая представит интерактивный контент о выборах в новом потрясающем стиле. Если бы им удалось этого достичь, это была бы победа.

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

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

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

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

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

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

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

Обратное тоже верно: если вы не можете определиться, каких результатов ожидаете, каких конкретных выгод хотите достичь, расставить приоритеты практически невозможно.

Заметим: команда Globo.com начинала с огромной задачи обновления всей системы управления контентом. Обновление системы – результат, которого хотела достичь команда. Это сулило множество преимуществ. Очень важно было разбить этот поистине монстрообразный результат на более мелкие, больше подходящие для фокусирования.

Запомните: результаты, которые мы кладем в основу расстановки приоритетов, – это конкретные изменения в поведении конкретных людей, вовлеченных в конкретные действия и процессы. Сконцентрировавшись на выборах в Бразилии, Globo.com стала ориентироваться лишь на людей, которые следят за новостями – особенно за обновляющимися данными голосования. Но в результате этого за бортом остались зрители мыльных опер, спортивные болельщики и множество других типов пользователей. Этим людям придется довольствоваться старой версией сайта несколько дольше. Помните, что невозможно удовлетворить всех и каждого одновременно.

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

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

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

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

Термин «минимально жизнеспособный продукт» (МЖП) давно используется в индустрии программного обеспечения. Хотя первое его употребление приписывают Фрэнку Робинсону, сейчас более популярны определения Эрика Райса или Стива Бланка. Хотя множество умных людей пытались объяснить, что такое МЖП, многие, включая меня, так и не могут толком разобраться в этом понятии. В каждой организации, где мне доводилось слышать этот термин, под ним подразумевалось что-то свое. Бывало даже, что люди, работавшие в одной организации, в разговорах друг с другом подразумевали под МЖП разные вещи.

Как и большинство слов в словаре, этот термин имеет несколько значений. Я приведу три примера определений: одно плохое и два хороших.

Начнем с плохого.

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

Если бы Globo.com воспользовалась этим определением для своего первого релиза, то, скорее всего, получила бы плохой результат. Проделанная работа не впечатлила бы никого. Компания потерпела бы убытки, и для нее гораздо лучше было бы вообще ничего не выпускать.

Когда говорят о живом организме, под словом «жизнеспособный» обычно понимают, что организм может выжить в нашем мире. К программному обеспечению это тоже относится.

Это определение мне нравится больше всего. «Минимальный» – субъективная характеристика, поэтому вам нужен конкретный субъект для определения минимума и этот субъект не вы. Точно определите, кто ваши заказчики и пользователи и что им нужно для решения их задач. Что им минимально необходимо? Я клянусь вам, это сильно облегчит обсуждение. Есть, правда, и альтернатива – когда решение принимают вышестоящие лица, но это намного хуже.

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

А сейчас мы приступим к трудной части…

Все это только гипотезы.

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

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

Это и в самом деле сложно, ведь если вы запланируете меньше необходимого, то есть меньше минимума, то у вас ничего хорошего не выйдет. А если больше (к чему, как правило, склонны люди в попытке перестраховаться), то потратите слишком много денег и велик будет риск вообще не справиться с задачей. И самый плохой вариант – может оказаться, что вы изначально выбрали неверное направление и поэтому не сделали ровным счетом ничего полезного.

Поэтому неудивительно, что определение, где фигурирует «худший продукт, который вы можете выпустить», до сих пор так распространено.

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

• Где у нас самые большие и рискованные предположения? Где неопределенность?

• Что и где мы можем узнать, чтобы заменить предположения реальной информацией?

Таким образом, мы приходим к следующему определению МЖП, ставшему популярным благодаря книге Эрика Райса «Стартап по методологии Lean» (The Lean Startup, издательство Crown Business). Как часто случается, Эрику пришлось усвоить то, о чем мы сейчас говорили, на собственном горьком опыте. Эрик работал на компанию, выпустившую жизнеспособный, как там думали, продукт, но оказалось, что это не так. Эрик поступил разумно, устремив свое внимание на изучение фактов – проверку всех тех предположений, которые сделали в компании перед выпуском первого релиза МЖП. Он заключил, что мы должны ставить небольшие эксперименты, делать прототипы и проверять наши гипотезы о том, что минимально и жизнеспособно. Если вы последуете примеру Эрика, что я рекомендую сделать, ваш первый продукт будет, по сути, экспериментом, а также следующий и так до тех пор, пока не убедитесь, что сделали нечто действительно стоящее.

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

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

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

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

 В чем состоит идея?

 Кто эти заказчики? Что за компании, как мы предполагаем, будут покупать продукт?

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

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

 Почему мы его создаем? Если мы создадим этот продукт и он будет успешным, что это нам даст?

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

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

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

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

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

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

Эрик начал работать как владелец продукта. Сначала он рассмотрел свое решение как набор простых несложных историй – пользовательских историй. Затем перешел к визуализации идеи, превратив ее в простые наброски интерфейса. А после этого создал высокоточный прототип. Это еще не было работающее программное обеспечение – всего лишь простой электронный прототип, созданный с помощью несложной программы наподобие Axure или даже PowerPoint.

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

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

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

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

Эрик прототипировал то, что считал хорошим, жизнеспособным решением. Но он не был полностью уверен в том, что оно минимально, ведь он продемонстрировал людям множество крутых идей. А когда вы показываете людям такие идеи, неудивительно, что они в восторге. Но Эрик знал, что его работа состоит в уменьшении объема разработки, притом что люди должны остаться довольными. Что же можно отбросить, сохранив при этом жизнеспособность решения?

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

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

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

Для Эрика настало время продемонстрировать свою компетентность.

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

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

И вот что сделал Эрик.

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

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

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

Над тем, что находится в верхнем срезе, выше клейкой ленты, Эрик и команда работают прямо сейчас. Этот релиз займет у Эрика два спринта: они используют методологию Scrum, где спринт, как правило, составляет двухнедельный отрезок времени, так что два спринта равны примерно месяцу. Ниже на доске тоже есть несколько срезов. Следующий слайд, по мысли Эрика, содержит то, что должно выйти в следующем релизе, и т. д. Слева от каждого среза точно так же, как было в Globo.com, наклеен стикер с названием релиза и несколькими словами о том, что ребята хотят изучить в нем, – кроме самого верхнего: там был наклеен постер из мультфильма Dilbert – какая-то шутка, понятная членам команды, но неизвестная мне.

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

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

Теперь вы поняли, какие это умные ребята?

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

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

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

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

Хенрик предлагает вот такую альтернативную стратегию.

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

По мысли Хенрика, таким образом, дело доходит до выпуска велосипеда, с помощью которого я получаю возможность передвигаться, более соответствующую моим потребностям. А получив мотоцикл, я действительно могу видеть, что ваши идеи работают, – я еду и получаю от этого удовольствие. Таким образом, это и есть минимально жизнеспособный для меня продукт. Если мне очень понравился мотоцикл, возможно, следующим шагом будет его улучшение до более крупной и быстрой модели, скажем, Harley-Davidson, а до спортивного автомобиля дело не дойдет (у меня как раз наступил кризис среднего возраста, поэтому мысль о Harley-Davidson мне очень нравится). Но принять это решение можно только после того, как я опробую мотоцикл и мы оба получим определенный опыт.

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

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

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

Эрик выполнил основную часть из цикла «создание – обратная связь – извлечение опыта», описанного Эриком Райсом. По определению Райса, каждый выпущенный релиз является минимально жизнеспособным продуктом, но, как вы могли заметить, он не был таковым в глазах конечных пользователей и заказчиков, по крайней мере пока не был. Поэтому мне нравится уточнение для определения МЖП Райса – минимально жизнеспособный продукт-эксперимент (МЖПэ). МЖПэ – самый маленький продукт, который можно создать, чтобы что-то изучить. В результате я пойму, что же в действительности жизнеспособно с точки зрения основных заказчиков и пользователей.

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

Мне нравится термин «исследование продукта» – он отлично описывает то, что мы делаем на этом этапе. Наша цель пока не в том, чтобы что-то создать, – скорее убедиться, что мы создаем правильную вещь. Как оказалось, разработать что-то и дать заказчикам этим какое-то время попользоваться – лучший способ убедиться, что проект развивается в верном направлении. Я позаимствовал определение исследования у Марти Когана[10], а мое определение включает практики Lean Startup и Lean User Experience, практики «мышления дизайнера» и множество других идей. Мое понимание того, что нужно делать на этапе исследования, постоянно развивается, но цель остается неизменной: как можно быстрее убедиться, что работа над продуктом идет в правильном направлении.

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

Рассмотрим пример. Допустим, я владелец продукта в компании, которая создает ПО для крупных сетевых магазинов. Мне очевидно, что мои продукты будут работать на основе большой базы данных в Oracle. Но также я знаю, что иметь дело с разработчиками базы данных – сущее наказание: они рассматривают, как под микроскопом, каждый мой шаг. Порой, чтобы внести самое простое изменение, требуется неделя работы, а то и больше. Это, разумеется, значительно замедляет работу моей команды. Конечно, ребят, работающих с базой данных, можно понять, ведь от этой базы зависит работа всех других приложений и пропустить какие-то проблемы с ней слишком рискованно. У них есть хорошо налаженный процесс оценки и внесения изменений в базу, он просто занимает слишком много времени.

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

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

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

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

Это Аарон и Майк. Они работают в компании под названием Workiva, где выпускают ряд продуктов на основе платформы Wdesk. Эта организация помогает другим большим компаниям решать серьезные задачи и является одной из крупнейших компаний типа «программное обеспечение как услуга», о которых вы, скорее всего, никогда не слышали.

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

Аарон и Майк только что завершили очередной раунд исследования продукта, и теперь они уверены, что нашли решение, которое стоит разработать и запустить для использования клиентами.

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

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

Очень важно отметить, что эта карта не охватывает весь продукт – она касается лишь функциональности, которую они добавляют в существующее приложение. Вот почему она намного меньше карты Гэри из главы 1 или карты команд Globo.com. Я подчеркиваю это потому, что некоторые ошибочно полагают: они должны составить карту историй всего продукта, чтобы внести крохотное изменение, и по этой причине отказываются от использования карт вообще.

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

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

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

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

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

У команды Workiva не было возможности уменьшить количество необходимых элементов в разработке. Они не могли проделать то, что сделала команда Globo.com, как описано в главе 2, то есть оставить часть запланированного на потом. В Workiva было решено, что нужно разрабатывать сразу все. На этапе прототипирования у них уже была возможность исключить многое и подтвердить, что решение до сих пор остается полезным для заказчиков. Тем не менее на карте можно выделить три среза.

«Зачем они вообще тратили на это время?» – можете удивиться вы. Действительно, предъявить треть от того, что нужно заказчикам, – это примерно как продавать одну треть спортивного автомобиля: никто не сможет на нем ездить. Но Майк владелец продукта. Он не может отойти в сторону после того, как найдено хорошее решение. Его роль немного меняется, и сейчас он больше похож на режиссера в кино: должен присутствовать при съемках каждой сцены. И ему нужно решить, какие сцены должны быть отсняты первыми, а какие – последними. Он знает, что к концу съемок фильма все сцены сложатся вместе и составят одно последовательное повествование.

Поэтому Майк и работал со своей командой над составлением плана разработки. Вот что они сделали – разделили карту тремя поперечными срезами.

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

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

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

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

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

Еще один страшный секрет оценки (который на самом деле вовсе не должен быть секретом) заключается в том, что оценки… оцениваются заранее. Я уверен: порывшись как следует в сборниках оксюморонов, выложенных в Интернете, вы непременно найдете там термин «точная оценка». Если нам точно известно, сколько времени займет какая-то работа, разве мы вообще называли бы это оценкой?

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

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

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

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

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

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

В зависимости от того, насколько плохо будут обстоять дела, понадобится увеличение запасов пива.

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

Что сделал бы да Винчи? Я часто задаю себе этот вопрос. Ладно, хорошо, не задаю. Но, возможно, мне следовало бы так поступать.

По сути Майк и Аарон выбрали ту же стратегию, которой пользуются художники, когда хотят завершить свои произведения вовремя. Точно такой же подход я применяю при создании программного обеспечения на протяжении многих лет. А когда я познакомился со своими будущими друзьями в Globo.com, оказалось, что и у них такой же подход, потому что, как я уже говорил, даже если они запоздают с разработкой нового интерактивного продукта к Олимпиаде, Олимпийский комитет не станет переносить открытие Игр. Я также думаю, что и вы привыкли следовать той же стратегии, даже не задумываясь над этим.

Начну объяснение с того, чего не делал Леонардо да Винчи, но, к сожалению, часто пытаются проделать обычные люди, занимающиеся созданием программного обеспечения.

Представьте себе, что вы Леонардо да Винчи и собираетесь написать картину, следуя той же стратегии, к которой традиционно прибегают большинство команд в мире разработки[11]. Вы можете начать работу с четким представлением о картине, по крайней мере вам так кажется. Вы разбиваете картину на несколько частей. Допустим, на эту работу отведено пять дней и каждый день вы рисуете по одной части. А к концу пятого дня – бах! – вы закончили! Что может быть проще?

Проблема лишь в том, что в реальности это не работает, по крайней мере для художников. Что-то создать таким образом можно, если предположить, что изначальное видение точно и правильно. Необходимо также, чтобы автор был высокопрофессионален и способен точно выделить части работы без визуального представления их в контексте. Если вы поступаете подобным образом при разработке программного обеспечения, это называется стратегией постоянного прироста (инкрементальной). По сути, таким образом каменщик строит стену, и этот способ хорошо работает, если размеры всех кусочков одинаковы и хорошо определены – как у кирпичей.

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

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

Мне, к сожалению, не приходилось наблюдать за Леонардо, но, я полагаю, он делал что-то очень похожее.

Даже Леонардо да Винчи, вероятно, признал бы, что его первоначальное видение картины не было идеальным, а он кое-что понимал в рисовании. В первый день, как мне представляется, он рисовал эскиз композиции или, может быть, делал легкий набросок. Я уверен, что на этом этапе он вносил в композицию небольшие изменения: «Хм, кажется, здесь самое важное – ее улыбка. Надо убрать руку от губ. А эти горы на заднем плане… Кажется, они слишком высокие, недостает пространства».

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

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

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

В области разработки программного обеспечения термин «итерация» имеет два значения. С точки зрения процесса он означает повторение одних и тех же действий снова и снова. Вот почему отрезок времени, в течение которого идет разработка, в методологии Agile часто называют итерацией. Но, используя этот термин в отношении программного обеспечения, которое вы уже создали, вы подразумеваете его оценку и изменение. Часто необходимость внести изменения во что-то уже существующее выглядит как провал: если бы требования были прописаны лучше или границы проекта не расширялись постоянно, то люди, принимающие решения, что и как программировать, не ошибались бы и ничего исправлять бы не пришлось. Но, как мы знаем, на самом деле исправления – всего лишь неизбежный результат увеличения знаний.

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

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

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

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

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

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

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

Именно так и поступили Майк с Аароном и вся команда разработчиков. Теперь вы поняли, почему они так рады?

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

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

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

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

Встретимся в главе 5.

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

Приготовьте пачку стикеров, ручку – и начнем. Не спешите, приступим, когда у вас будет достаточно времени. Я подожду.

Готовы?

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

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

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

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

Карты организуются слева направо согласно хронике повествования – порядка, в котором вы рассказываете историю.

Добавьте пропущенные детали. Приятная особенность составления карт с помощью стикеров заключается в том, что увидеть и оценить общую картину очень легко. А видя историю, организованную по порядку хроники повествования, вы обязательно заметите, что каких-то частей истории не хватает.

Посмотрите на свою карту и подумайте, не пропустили ли вы какие-нибудь шаги.

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

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

Задумайтесь на минуту о том, что вы делали вчерашним утром. Если найдутся какие-то действия, отличные от того, что вы делали сегодня утром, запишите их на стикерах и добавьте на карту.

Бывает, что утром все катится кувырком. Что вы будете делать, если у вас в доме внезапно отключат горячую воду? Если внезапно не окажется молока, или овсяных хлопьев, или чего-то еще, что вы привыкли есть на завтрак? Если дочка внезапно вспомнит о домашнем задании, которое нужно было обязательно сделать к сегодняшнему дню (у нас это происходит регулярно)? Что тогда? Запишите возможные действия и добавьте их на карту.

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

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

Мой друг Дэвид Хассман называет этот процесс игрой во «Что, если» – вы, наверное, помните эту фразу из глав 2 и 3. К сожалению, в эту игру можно играть бесконечно, в результате чего карта разрастется до невероятных размеров. Я добавил в свою карту только то, что когда-либо происходило на самом деле – я делал зарядку или позволял себе немного расслабиться за завтраком. Кроме того, добавил несколько распространенных вариантов развития событий, которые, как правило, могут наблюдаться по утрам.

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

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

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

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

Расслабьтесь.

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

К этому этапу ваша карта должна была здорово увеличиться в ширину, а если вы продумали некоторое количество вариантов – еще и в глубину. Скорее всего, в ней около 30 задач и выглядит она как скелет с ребрами, принадлежащий какому-то доисторическому животному.

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

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

Если у вас не оказалось под рукой стикеров другого цвета, вот маленькая хитрость: на самом деле в каждой пачке стикеров находятся листки двух различных форм! Просто поверните стикер на 45°, и – оп! – он из квадрата превратится в ромб. Вы можете использовать этот простой способ всегда, когда нужно заставить стикер выглядеть иначе.

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

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

Часто смысл операций, в отличие от задач, нелегко передать простым языком. Как, например, вы назовете тот набор мелочей, которые проделываете перед выходом из дома: приготовить сумку, захватить список покупок, заглянуть в прогноз погоды и при необходимости взять зонтик? Я, например, условно называю это «собраться перед выходом». Можете придумать собственное название.

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

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

Например, в созданной вами карте в левом верхнем углу наверняка имеется нечто вроде «Прихлопнуть будильник» или «Переключить будильник». Представьте, что было бы, если бы сегодня утром вы пропустили этот шаг? Это могло произойти, к примеру, если вы забыли включить будильник накануне вечером. Вы открываете глаза, смотрите на часы и с ужасом понимаете, что вам нужно прибыть куда-то уже через несколько минут! Вы страшно опаздываете! Не нужно, впрочем, по-настоящему впадать в панику – пока все происходит только в воображении.

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

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

Это моя карта с задачами, выполнив которые я за считаные минуты оказываюсь готов к выходу.

Можете опробовать этот прием на различных целях, которые могут оказаться с левой стороны. Например, «Провести утро мечты» или «Утро в середине двухнедельного отпуска». Как вы убедитесь, хроника повествования останется практически неизменной, но вам придется добавлять или убирать задачи, чтобы обеспечить достижение различных целей.

Используйте срезы, чтобы выделить все задачи и детали, соответствующие достижению определенного результата.

Было ведь несложно, правда? По мере построения карты вы должны были усвоить следующее.

 Задачи – это короткие глагольные фразы, описывающие то, что делают люди.

• Всем задачам соответствуют разные уровни целей.

• На карте задачи образуют хронику, изложенную слева направо.

 Глубину карты создают различные варианты и альтернативные задачи.

• Задачи образуют операции на протяжении всей карты.

• Операции формируют каркас карты.

• Вы можете выделить на карте срезы, куда войдут задачи, необходимые для достижения какого-то особого результата.

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

Думаю, что для многих из вас это очевидно, но на всякий случай подчеркну: карта, которую мы только что составили, имеет фундаментальное отличие от карт, упомянутых в первых четырех главах. Карты Гэри, Globo.com, Эрика и Майка с Аароном представляют собой воображаемые способы работы пользователей с продуктом в будущем, после того как его выпустят. Они записывали задачи и операции, которые, по их предположению, пользователи будут выполнять, работая с продуктом. А карта, которую вы создали, касается ваших теперешних задач – тех, которые вы выполняли этим утром. И оказывается, что основа и концепция одинаковы в обоих случаях. Поэтому будьте уверены: вы потратили время не зря.

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

• проблемы – что-то, что не работает, вызывает трудности, что люди ненавидят;

• выгоды или радости – то, что доставляет удовольствие и вдохновляет;

• вопросы – «Почему люди делают это?», «Что происходит, если они делают это?»;

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

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

В начале 2000-х я руководил небольшой компанией по разработке продуктов под названием Tomax. Мы работали над программой для розничных магазинов – тех самых, куда ходили за покупками, прежде чем с головой погрузились в Интернет. У нас появился новый клиент – крупная сеть магазинов лакокрасочной продукции и предметов интерьера. Мы немного разбирались в розничной торговле, а также в людях, которые обслуживают покупателей в магазине и работают с оборудованием, но совсем ничего не знали о многих вещах – в основном о деталях, характерных для торговли красками и предметами интерьера. Например, нам были неизвестны особенности продажи краски индивидуальных оттенков или жалюзи на заказ. А учиться нужно было быстро.

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

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

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

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

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

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

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

Держите это в уме, и все мало-помалу получится.

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

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

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

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

Давайте задержимся здесь на минуту. Я имел удовольствие работать с множеством команд. Очень часто работа начиналась с обсуждения наших самых больших затруднений. И разумеется, чаще всего я первым делом узнавал о «неудачных требованиях». Каждый тычет пальцем в этот несчастный документ. Автор документа готов сгореть со стыда – наверняка он должен был написать больше или меньше либо, может быть, использовать какие-то новейшие техники составления документации. Те, кто подписал этот документ, ощущают себя не лучше и поэтому занимают оборонительную позицию: «Вы что, ожидали, что я вчитаюсь в каждую деталь? В конце концов мы обсуждали это целыми днями! Я думал, вы поняли, что я сказал. Я вообще не понимаю, откуда взялся этот дурацкий документ!» А те, кто работал над самим программным продуктом, и вовсе сбиты с толку – они выполнили свою задачу, руководствуясь этим злосчастным документом, но оказалось, что все по-прежнему неправильно. В общем, все хотят отправить эти бумаги в печку и немедленно написать новую, лучшую документацию.

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

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

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

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

Поскольку все вокруг говорили только о написании историй, мне пришлось задать Кенту вопрос: не пропустил ли я чего? Во время длинного обсуждения по электронной почте Кент объяснил мне происхождение идеи: «Я хотел развить известную ситуацию, когда пользователи сами излагают истории работы крутых функций, которые умеет выполнять их рабочая программа. [Например,] когда я впечатываю в поле почтовый индекс, а программа автоматически заполняет город и штат, мне не приходится нажимать ни одной кнопки.

Я думаю, именно этот пример натолкнул меня на мысль. Если вы можете рассказывать истории о том, что делает программа, вызывая интерес и живой отклик у слушателя, почему же не рассказать эти истории еще до того, как программа сможет это делать?» (Кент Бек в личной переписке, август 2010 года).

Как видите, идея – в рассказе, и вы сами знаете: если рассказ правильный, то у слушателей пробуждаются интерес и энергия, предмет рассказа предстает перед ними как живой. Не правда ли, здорово? Да и звучит намного интереснее, чем просто чтение типичного документа с требованиями[13].

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

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

Хорошее обсуждение историй всегда требует множества слов и картинок.

Во время обсуждения держите перед глазами критерии приемки, к которым вы пришли. Эта команда использует большие листы бумаги для записи хода обсуждения.

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

А если нет?

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

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

Идея историй на самом деле очень проста. Может быть, даже слишком проста. Множество людей, занятых в разработке программного обеспечения, воспринимают обсуждения как что-то очень непривычное… и, может быть, даже слегка неприятное. В результате многие скатываются к простому обсуждению требований, к которому они привыкли.

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

Это моя подруга Рэчел Дэвис. У нее в руках карточка историй.

В конце 1990-х Рэчел работала в компании под названием Connextra, которая была одним из первых адептов экстремального программирования, процесса Agile, откуда берут свое начало истории. Когда работники Connextra начали использовать истории, почти сразу обнаружились несколько распространенных проблем. Большинство людей, которые составляли в Connextra истории, работали в отделах продаж и маркетинга, поэтому они были склонны просто записывать функциональности, нужные пользователям. Но когда приходило время дискуссий между разработчиками, им приходилось искать того, кто предложил функциональность, и начинать настоящее обсуждение, включающее все «Для кого?» и «Почему?». Простая запись названия функциональности никак не помогала им понять, с какими людьми следует поговорить, или начать правильное обсуждение. Кроме того, в то время не было достаточного количества информации о том, что может или должно быть на карточках. Шаблон развивался в Connextra постепенно, с течением времени. Он был детищем не одной Рэчел, а скорее являлся следствием желания всей организации создавать по-настоящему значительные вещи.

Ребята из Connextra использовали этот шаблон некоторое время, а потом захотели поделиться своим замечательным изобретением с другими. Они напечатали стопку карт-образцов, которые продемонстрировали на XPDay 2001, небольшой конференции в Лондоне. На фотографии Рэчел держит именно такую карточку. Это последняя карточка из того набора и, возможно, последняя из существующих, поэтому ее можно назвать историческим памятником.

Вот как выглядит этот шаблон:

Как [тип пользователя], я хочу [сделать то-то и то-то], таким образом я смогу [получить такую-то выгоду].

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

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

Если у вас есть отдельная карточка, не принадлежащая карте историй, то шаблон – отличный способ завязать обсуждение. Помните, в главе 1 я упомянул одну из карточек в карте Гэри, где было написано: «Загрузить изображение»? Эта карточка была одной из деталей шага «Отредактировать рассылку». Я всегда пишу на карточках, составляющих карту, такие короткие глагольные фразы – они означают действия, которые люди выполняют, используя мой продукт. Но когда я рассматриваю какую-то карточку в отдельности, мне нужно увидеть историю внутри большого путешествия пользователя по продукту, которое представляет собой карта. Поэтому я могу сказать: «Как администратор музыкальной группы, я хочу загрузить изображение и отредактировать свою рассылку таким образом».

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

Но не забывайте, это только запуск обсуждения. Продолжиться оно должно примерно так.

• «Почему администратору группы может понадобиться отредактировать рассылку?»

• «Ну, наверное, потому, что на рассылке должно быть фото группы, а оно там не появляется автоматически. Кроме того, администратор, вероятно, хочет, чтобы его рассылка выделялась и привлекала внимание – кому интересны стандартные рекламки?»

• «Это звучит разумно. А где, как вы думаете, люди наподобие администраторов хранят такие фотографии?»

• «Да где угодно. Они могут быть на жестком диске компьютера, в аккаунте Flickr и вообще в любом месте в Интернете».

• «Да? Признаться, я об этом не думал, я предполагал, что они хранят их только на жестких дисках».

• «Нет, много людей, с которыми мы говорили, хранят фотографии в самых разных местах. Наверное, стоит это учесть».

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

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

Термин «шаблонные зомби» впервые появился в книге Тома Де-Марко и его соавторов «Адреналиновые наркоманы и шаблонные зомби: понимание паттернов поведения проектов»[16]. Название говорит само за себя, но я приведу и авторское определение.

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

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

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

Человек на этой фотографии учиться кататься на горных лыжах[17]. Если вы когда-нибудь тоже этому учились и вам помогал инструктор, то вы хорошо знаете, что делает этот человек. Он выполняет прием торможения «плугом» – сводит носки лыж вместе и скользит на внутренних ребрах. Это самый простой способ контролировать скорость и оставаться в вертикальном положении, несмотря на то что к вашим ногам прикреплены две скользкие доски. Это самый лучший прием для начинающих лыжников. Но это не просто самый лучший прием – это самый лучший обучающий прием. В программе соревнований горнолыжников на Олимпийских играх нет упражнения «плуг». Ни один катающийся на склоне горы не будет восхищен вашим великолепным исполнением «плуга». Но, разумеется, стесняться здесь нечего. Видя, что вы катаетесь таким способом, все понимают, что вы новичок и пока учитесь.

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

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

Кто:

Что:

Почему:

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

 По-настоящему обсудите «Кто?». Пожалуйста, не говорите о пользователях вообще. Будьте конкретны. Ясно называйте тех пользователей, которых подразумеваете. Например, с Гэри мы говорили об администраторе группы или ее фанатах.

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

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

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

Случаи, когда можно учитывать только одного пользователя, очень редки.

 Как следует обсудите «Что?». Я очень люблю, когда истории начинаются с пользовательских задач – действий, которые пользователи хотят выполнить, применив мой программный продукт. Но что же делать с сервисами, работа которых не видна в пользовательском интерфейсе, – теми, которые авторизуют вашу кредитную карту для покупки или пускают вас на сайт страховки? Вашим пользователям не приходится явно делать выбор, чтобы авторизовать свои кредитные карты или подтвердить введенные данные для авторизации. Поэтому не только можно, но и нужно обсудить самые разные сервисы и системы, которые могут их вызывать. Стоит также рассмотреть особые компоненты UI и поведение экрана. Просто не упускайте из виду заинтересованных людей и их мотивы.

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

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

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

 Обсудите, что произойдет, если все пойдет не так. Что будет, если произойдет какой-то сбой? Что случится, если система вдруг прекратит работу? Какими альтернативными способами пользователи могут достичь своих целей? Как они удовлетворяют свои нужды сейчас?

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

Запланируйте время на проверку своих предположений. Действительно ли вы понимаете пользователей? Вы точно знаете, чего они хотят? Реальны ли их проблемы? Смогут ли они, используя ваше решение, справиться с этими проблемами?

Рассмотрите также свои технические предположения. На какие базовые системы мы полагаемся? Будут ли они в самом деле работать так, как мы планируем? Есть ли какие-то технические риски, которые необходимо учесть?

Все эти вопросы и предположения могут потребовать дополнительного исследования или изучения. Составьте для этого особый план.

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

 Обсудите «Как?». Очень часто, присутствуя на обсуждении историй, я слышу чей-то раздраженный голос: «Мы должны обсуждать, что мы делаем, а не как!». Под этим обычно подразумевается, что нужно обсуждать действия и мотивы пользователей, а не код, который необходимо написать. А я чувствую точно такое же раздражение, когда мы говорим только о «Что?», не затрагивая «Почему?». В действительности при хорошем обсуждении мы стремимся к оптимизации всех трех составляющих. На самом деле нехорошо, когда кто-то предполагает, что определенное решение или какой-то способ технической реализации является требованием. Поэтому без явного обсуждения «Как?» (а если вы разработчик, вы неизбежно думаете об этом аспекте) очень трудно оценить стоимость решения. А слишком дорогое решение никак не может быть наилучшим.

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

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

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

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

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

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

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

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

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

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

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

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

Если я бизнес-аналитик, я должен погрузиться в море деталей, понять, как должен выглядеть пользовательский интерфейс, а также вникнуть в бизнес-правила компании, которые лежат в его основе.

Если я тестировщик, мне нужно думать о том, в каком случае продукт может дать сбой. Я хотел бы обсудить, что мне нужно учесть при составлении плана тестов.

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

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

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

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

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

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

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

Если я возьму из картотеки карточку, на ней будет ровно столько информации, сколько нужно для поиска книги. Скорее всего, там указаны название, автор, аннотация, количество страниц, жанр – скажем, «научно-популярная литература», – а также код (помните десятичную классификацию Дьюи?[18]), с помощью которого можно найти экземпляр этой книги в хранилище. Карточка – просто символ, который легко хранить и просто найти. Никто не перепутает карточку с книгой. Библиотечная картотека очень удобна, так как занимает намного меньше места, чем тысячи книг. А карточки можно сортировать множеством способов, например по авторам или по темам.

Ваши истории должны работать примерно так же: вы можете записать их на карточках, разместить на большом листе либо занести в свой любимый инструмент для планирования или систему, которую используют все в вашей компании (периодически ругая на все корки). Находясь в библиотеке, вы знаете, что там есть нужная книга, и если нашли в картотеке нужную карточку, то и книгу с легкостью найдете. То же с историями: вы знаете, что у вас есть растущий объем информации. Она развивается и увеличивается с каждым обсуждением. И если в вашей компании хоть сколько-нибудь ценится прозрачность сведений, найти ее тоже будет легко.

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

В своей книге «Создание программного обеспечения как коллективная игра»[20] Алистер Коберн употребляет термин «информационный радиатор», чтобы описать, как информация, размещенная в комнате на видном месте, помогает работающим там действовать эффективно. Люди постоянно подходят, чтобы посмотреть на нее. Если эта информация актуальна и полезна, около стены разворачивается множество обсуждений, во время которых люди могут обращаться к записям, дополнять и развивать их.

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

В Atlassian мне прежде всего бросилось в глаза то, что вся имеющаяся у них информация – как внутри, так и вне их инструментов – актуальна и полезна.

Наши три «П» только начало.

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

Если мы закончим цикл, модель будет выглядеть так, как на стр. 158.

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

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

• Программисты могут начать писать код.

• Тестировщики – составить план тестирования и начать его выполнять.

• Графические дизайнеры – создать детальные проекты UI и электронные ресурсы, если они еще этого не сделали в процессе выработки одинакового понимания.

• Технические писатели – написать или обновить файлы справки, а также другие текстовые документы.

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

Здесь я хочу сделать паузу. Подумайте об этом.

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

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

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

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

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

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

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

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

Говоря о качестве, я начинаю дискуссию с трех аспектов.

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

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

 Качество кода. Хорошо ли написана программа? Соответствует ли код нашим стандартам? Мы будем еще какое-то время иметь дело с этим продуктом, поэтому очень важно, чтобы легко было работать с кодом, развивать и поддерживать его. Или же у нас появилась очередная порция технического долга, с которым придется разбираться позднее?

У меня для вас плохая новость: скорее всего, найдется довольно много вещей, которые можно было бы сделать лучше.

Чтобы все были спокойны, стоит четко разделять два соображения. Первое: сделали ли мы то, что договорились сделать? Второе: если мы видим именно то, что договорились сделать, нужно ли внести какие-то изменения?

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

В этот момент у меня в голове начинает звучать старая песня Rolling Stones. Если вы ее знаете, подпевайте: «You can’t always get what you want. But, if you try sometime, you just might find, you get what you need…»[21] Какая ирония – в мире программного обеспечения все происходит ровно наоборот.

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

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

Простите меня. Я припас для вас еще немного новостей – снова плохих.

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

Не обманывайте себя.

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

Случалось ли вам когда-либо наблюдать, как какой-нибудь пользователь работает с продуктом, в создании которого вы участвовали? Вспомните, как это было в первый раз. Как все прошло? Я, конечно, не присутствовал при этом, но почти уверен, что все было совсем не так, как вы ожидали.

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

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

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

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

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

Гуру разработки Agile, уже упоминавшийся здесь мой друг Алистер Коберн, однажды сказал мне: «В бэклог историй нужно отправлять не одну написанную тобой историю, а три».

На мой вопрос «Почему?» он ответил: «Просто делай это».

«Что же мне писать в двух других историях?» – спросил я.

«Не имеет никакого значения».

«Что ты имеешь в виду? – удивился я. – Мне же нужно там что-то написать!»

«Ну хорошо, – сказал Алистер, – если тебе так уж нужно, запиши то, что хочешь разработать, на первой карточке, а на второй напиши: “Исправить первую карточку”. Потом на третьей – “Исправить вторую”. Если ты не пройдешь этот цикл трижды для каждой истории, то никогда ничему не научишься».

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

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

Стратегия Моны Лизы, использованная Майком и Аароном из главы 4, помогла им разделить каждую историю на маленькие компактные части, которые, правда, нельзя было представить пользователям, но они позволяли ребятам обучаться быстрее и управлять бюджетом разработки, в результате чего работа была завершена вовремя.

Это две замечательные стратегии обучения. Попробуйте их. Изобретите собственную. Только, пожалуйста, не думайте, что вы правы всегда и во всем! Уверяю, вас ждет великое разочарование.

В 2011 году Кент Бек – создатель метода историй – начал одну из первых конференций Lean Startup с пересмотра манифеста Agile. Будь на его месте, например, я, это было бы, пожалуй, святотатством; но Кент, один из авторов манифеста, знал, что делает. Он пересмотрел принцип, касающийся работающего ПО, и отныне он читается так: «Эмпирическое обучение важнее работающего продукта».

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

Мне нравится использовать истории для управления работой по созданию простых прототипов или планированием пользовательских тестов либо интервью. Мне нравится говорить о том, кто это делает, что нужно сделать и почему. Я люблю сначала договориться о том, что мы делаем, а уж потом приступить к работе. Закончив работу, я анализирую ее результаты, чтобы оценить, удалось ли изучить что-нибудь.

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

Две недели назад был день рождения моей дочери и нам нужен был торт. У нашей семьи есть собственный кондитер, у которой мы заказываем торты всегда. Не сказать, что мы очень богаты или не умеем печь торты сами, просто Сидни, наш кондитер, делает удивительные, невероятно вкусные торты. Я не знаю точно, какой кулинарной магией она пользуется, чтобы создать такое чудо, но, когда ни спросишь моих детей, какой торт они хотят на день рождения, ответ всегда один: «Мы хотим торт Сидни!» – и от заказа уже не отвертеться.

Чтобы у нас появился торт, я звоню Сидни по телефону. Она всегда спрашивает, для кого торт и по какому случаю. Две недели назад я сказал ей, что Грейс скоро исполнится 12. «А чем она сейчас увлекается?» – спросила Сидни. Мы немного поговорили о Грейс, ее вкусах и интересах. После этого мы обсудили формы тортов, имеющиеся у Сидни, а также подумали, как можно украсить торт, чтобы он был готов вовремя. В этот раз мы остановились на торте в форме птички.

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

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

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

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

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

То же самое могло произойти, когда я обсуждал свой торт с Сидни. Я мог представлять себе какой-то особенный торт, форм для которого у Сидни бы не оказалось, или украшения, которые невозможно сделать. Я не смог бы позволить себе такой торт, а Сидни не смогла бы обещать, что изготовит его ко дню рождения моей дочери.

В главе 7 я сказал, что, если решение, которое мы приняли, оказалось слишком дорогим, нужно сделать шаг назад и реалистично оценить проблемы, которые мы пытаемся решить, и результаты, которые надеемся получить. Затем нужно рассмотреть имеющиеся альтернативы. Таким образом, у нас будет торт поменьше или, может быть, просто пирог.

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

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

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

Сейчас наша аналогия немного затрещит по швам, но вскоре будет восстановлена. Способ, который сработает в отношении большого программного торта, – это разбиение его на множество маленьких капкейков[22]. Каждый из них является законченным продуктом, а кроме того, рецепты всех примерно одинаковы: немного сахара, немного муки, одно-два яйца и т. д.

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

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

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

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

Но горка капкейков не может быть свадебным тортом… или может?[23]

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

Мой друг Люк Хоуман привел забавную поговорку: «Половина готового торта и наполовину готовый торт – не одно и то же». Половины готового пирога может быть недостаточно для всех гостей на свадьбе, но ее хватит, чтобы все смогли отведать его и с нетерпением ждать добавки.

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

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

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

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

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

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

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

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

Мой инструмент для разбивания камней – большой молот. И он отлично работает.

Большие истории разбиваются на меньшие истории, и эти меньшие истории тоже могут быть разбиты на совсем маленькие. Но любого размера, даже самого маленького, это все равно история. А какой инструмент лучше всего применить для разбивания историй? Правильно: обсуждение. Иногда достаточно просто немного поразмыслить, но если вы обсуждаете историю и работаете над ней совместно с кем-то еще, то одновременно расширяете одинаковое понимание.

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

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

Эпик – общепринятый термин (я не знаю, кто первым употребил его) для описания крупных пользовательских историй, так же как слово «валун» используется для обозначения очень большого камня. Буду с вами честен: мне понадобились годы, чтобы воспринимать важные вещи, которые мы разрабатываем, как истории, но сейчас я понимаю, почему они так называются. Термин «эпик» смущает меня до сих пор. Насколько я помню, учитель английской литературы объяснял, что эпические поэмы обычно повествуют о героях, борющихся со злом, – Беовульфе, Ахилле, Фродо – обычно с помощью какого-то волшебного оружия или при поддержке богов. Но, кажется, я отвлекся…

Неплохо иметь специальное название для больших историй, но погодите немного. Термин «эпик» нередко используется в качестве оружия. Я нередко наблюдал, как член команды разработки убеждает представителя бизнеса, менеджера продукта, пользователя или кого-то еще, кто о чем-то просит, что его история – это целый эпик, а не просто история. Обычно это произносится таким тоном, словно автор истории сделал что-то не так и нанес члену команды разработки серьезное оскорбление. Поэтому, если вы член команды разработки, не используйте термин «эпик», чтобы кого-то пристыдить. Это плохое начало (и, вероятно, преждевременное окончание) того, что должно было быть продуктивным обсуждением.

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

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

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

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

Термины «эпик» и «тема» давно проникли в инструменты для управления жизненным циклом Agile, в некоторые подходы к разработке Agile со своими наименованиями, а также в общепринятый язык для обсуждения историй. По этой причине вы должны знать и понимать их.

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

Вот как может выглядеть весь цикл разбиения камней.

А сейчас разберемся со всем этим подробнее.

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

Первое качественное обсуждение истории – высокоуровневая («Кто?», «Что?», «Почему?») дискуссия, ее основная цель – принять решение: «да» или «нет». Причем «да» не означает, что мы немедленно приступаем к разработке. Это значит: пойдем дальше, проводя углубленные обсуждения, чтобы полностью понять историю. Но я не хочу двигаться вперед и тратить много времени на разговоры, если выяснится, что идея изначально для нас не годится. «Нет» – вежливый способ сказать: «Ерунда». Поэтому давайте назовем этот этап «решение того, развивать идею или отбросить ее». Помните: нам всегда требуется разработать больше, чем мы способны, так что отбросить бесперспективную возможность прежде, чем она съест слишком много времени и сил, – стоящее решение.

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

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

Во время исследования вы должны углубиться в следующие вопросы.

• Кто те заказчики или пользователи, которым, по вашему мнению, пригодится это решение?

• Как они решают свои задачи сейчас, пока продукта еще нет?

• Как изменится их мир, когда вы покажете свое решение?

• Какие внешний вид и способ взаимодействия должны быть у вашего решения?

• Сколько времени займет реализация?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Остановитесь и реально оцените качество готового решения. Спросите себя, насколько эффективным было планирование. Создано ли то, чего вы ожидали? Заняло ли это намного больше времени, чем планировалось? Или, может, меньше? Или примерно столько, сколько вы наметили? Кроме того, откровенно обсудите, насколько хорошо работает «машина». Сейчас подходящий момент, чтобы внести корректировки или изменения в процесс работы, чтобы продукт стал более качественным.

Этот первый этап оценки в Scrum называется ревизией спринта или ретроспективой. Как бы вы ни называли моменты остановки, пересмотра и размышлений, главное, чтобы они у вас были.

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

Но отдельный маленький кусочек, выходящий из машины Agile, может быть маловат для демонстрации пользователям. Я представляю себе, как все эти маленькие фрагменты один за другим укладываются на чашу весов – старомодных весов с грузом на другой чаше. На ней лежит слово «достаточно», что означает: достаточно и для тестов с участием пользователей и заказчиков, и для нас, чтобы что-то узнать.

Обычно «достаточно» означает готовый экран или последовательность экранов, которые дают пользователю возможность выполнить задачу или достичь значимой цели. И я не хочу разговаривать с пользователями. Я наблюдаю за ними не для того, чтобы сказать: «Это прекрасно». Я наблюдаю для того, чтобы изучать, и результат изучения, как правило, примерно такой: «Получилось не совсем верно» или «Сейчас, когда я использую это в реальности, то вижу, что будет лучше, если…»

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

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

Я нарисую еще одни, последние весы. На одну чашу мы кладем части, которые проанализировали, протестировали с участием заказчиков и пользователей и продемонстрировали заинтересованным лицам в своей компании. Эта чаша очень похожа на ту, что упоминалась несколько шагов назад, на стадии тестирования с пользователями и заказчиками. А на другой чаше снова лежит слово «достаточно», но в этот раз оно означает «достаточно для предъявления заказчикам и пользователям и получения нужных результатов». Как только чаши сравнялись, выпускайте релиз.

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

Если рассматривать лишь проект, ваша работа уже закончена – вы его предъявили. Но пока вы просто сделали некий продукт. А жизнь продукта начинается, когда он представлен пользователям. Обещаю: начав обращать внимание на то, что люди делают с вашим продуктом, вы обязательно увидите возможности его немного улучшить. Запишите их и примените в начале описанной здесь модели.

Это и есть реальный жизненный цикл – во всяком случае, жизненный цикл истории.

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

В практике работы по модели Agile совершенно напрасно закрепилась традиция назначать кого-то одного ответственным за написание историй и проведение всех обсуждений. В Scrum, процессе Agile, этот человек называется владельцем продукта. Однако есть по меньшей мере две серьезные причины, по которым это не работает, а может, и целый ряд более мелких причин.

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

 Основная причина № 2. Один человек не обладает всеми нужными компетенциями и не сможет посмотреть со всех возможных точек зрения, чтобы прийти к наилучшему решению. Только сотрудничество людей с различными навыками позволяет создать по-настоящему полезный продукт.

Не поймите меня неправильно. С моей точки зрения, при правильной разработке продукта лидерство владельца продукта очень важно. Он следит за тем, чтобы в ходе работы вся команда сосредоточилась на движении в верном направлении.

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

Эффективно действующие владельцы продукта окружают себя людьми, которые нужны им для принятия удачных решений. Они объединяют компетенции, мнение и опыт многих людей. Но в условиях ограниченных ресурсов, когда успех продукта находится под угрозой, решения приходится принимать им, и, конечно, всегда найдутся недовольные. Моя подруга Лиза Райшелт хорошо сказала: «…В дизайне нет ничего от демократии»[24].

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

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

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

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

Сплоченная команда исследования продукта представляет собой мощную, слаженно работающую группу экспертов, способную быстро обнаруживать проблемы и находить решения. Я часто слышу, что эту ключевую команду называют триадой. Когда я последний раз был в сиднейском офисе Atlassian, Шериф, с которым вы познакомились в главе 8, указал мне на три рабочих места, расположенных рядышком. «Здесь сидит триада», – объяснил он. Вокруг мест триады стояли рабочие столы с компьютерами, за которыми располагалась остальная команда. Мне также приходилось слышать, как триадой называли команду, где было два человека, четыре человека или даже больше, ибо три концепта, о которых мы говорим, – полезное, удобное, реалистичное – не соотносятся с тремя людьми.

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

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

¡Three Amigos! – название заурядного вестерна-комедии 1986 года со Стивом Мартином, Чеви Чейзом и Мартином Шортом в главных ролях. Что общего у этого фильма и разработки по методологии Agile, управляемой историями? Там есть тройка ловких и расчетливых героев, что очень здорово для семинаров по историям. Я не знаю, кто первым назвал их тремя амиго, но, кажется, это прозвище ушло в народ[25] (уверен, если бы фильм посмотрело больше людей, этого не произошло бы).

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

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

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

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

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

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

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

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

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

Как-то в одном разговоре мой друг Дэвид Хассман предложил лучшую метафору для отношений, которые на самом деле должны существовать между бизнес-аналитиками и представителями бизнеса, – они должны быть такими же, как отношения между музыкальным продюсером и его группой. Дэвид знает в этом толк, потому что он не только гуру Agile, но и экс-гитарист хеви-метал-группы Slave Raider, существовавшей в 1980-х годах. Ему приходилось как работать с продюсерами, так и быть продюсером самому. Группа вступает в шоу-бизнес с энтузиазмом и, хочется надеяться, некоторым талантом, но участники не разбираются в подводных камнях шоу-бизнеса или в процессе записи альбома. В этом компетентен продюсер. Это его работа – помочь группе выпустить настолько успешный альбом, насколько это возможно. Хорошие продюсеры могут вырастить из талантливого новичка популярного, коммерчески успешного артиста.

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

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

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

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

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

Я надеюсь, вы тоже думаете, что это замечательно.

Разрешите мне вернуться к сходству историй с камнями. Части, на которые вы разобьете камень, все равно можно назвать камнями, просто меньшего размера. Но это все еще такие же камни, как тот, первоначальный, который нам нужно было внимательно рассмотреть, чтобы понять, достоин он разбиения или нет. Давайте условно назовем его «нулевой камень». В терминах метода историй я бы употребил слово «возможность».

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

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

• для кого она. На этом уровне чаще всего упоминаются разные группы пользователей, заказчиков или целевой сегмент рынка;

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

• что представляет собой идея. У нас могут быть соображения о том, какими должны быть продукт или функциональность. Об этом следует поговорить;

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

• каков ее размер. На этом уровне, даже если размах идей велик, мы можем сделать осторожные оценки времени на разработку, пусть даже они и не будут особенно точными. Лучше всего рассмотреть данную возможность в сравнении с чем-то, что мы уже делали раньше: «Это звучит похоже на ту, другую функцию, которую мы выпустили в прошлом релизе. На нее потратили несколько недель, значит, и эта займет примерно столько же». Для принятия решения о том, стоит ли продолжать работу над идеей, полезно знать, сколько времени займет ее разработка – дни, недели или месяцы.

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

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

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

У вашей группы может быть недостаточно информации для принятия решения «да» или «нет». Если это так, составьте список того, что нужно выяснить, и соберите нужную информацию.

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

Я знаю, что в вашей компании, скорее всего, не используется понятие «возможности». Если она хоть немного похожа на те, с которыми мне случалось работать в прошлом, у вас есть стратегический план, куда включено то, что вы планируете разработать. Может быть, вы даже воспринимаете его как требования. Скорее всего, решение «нет» принимаете не вы. Правда заключается в том, что на самом деле мы не можем превратить все эти мудрые идеи в программные продукты независимо от должности человека, который их выдвинул.

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

Если не вы и не кто-то в вашей команде принимает решение, работать ли дальше с этой возможностью, постарайтесь выяснить это в беседе с теми, кто будет решать. Если эти люди недоступны для вас, все равно проведите обсуждение и сделайте предположения «Кто?», «Что?» и «Почему?». Затем передайте эти предположения лицам, ответственным за решения. Обещаю, они непременно поправят вас, если ваши предположения неверны. Рассматривая же корректировки, вы сможете начать правильное обсуждение.

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

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

Попробуйте построить простую, высокоуровневую карту существующего продукта. Это карта «сейчас», похожая на представленую в главе 5, где отображается ваше утро (вы же построили ее, правда?). Эти типы карт много раз встречались нам в различных формах. Часто их называют картами маршрутов. Чтобы составить такую карту для текущего состояния вашего продукта и взаимодействия пользователя с ним, просто составьте карту основных действий пользователя в вашей программе, которые ведут к какой-либо цели. Используйте эту карту, чтобы рассмотреть свои возможности в контексте, – для этого нужно добавить на карту каждую возможность. Используйте стикеры или карточки разных цветов, чтобы выделить их. Скорее всего, вы обнаружите горячие точки возможностей – места на маршрутах взаимодействия пользователей с системой, где не помешают улучшения и где, скорее всего, пользователи испытывают затруднения.

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

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

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

Если же вы приняли решение «да», настало время засучить рукава и взяться за работу. Именно об этом следующая глава.

Видя простые модели описания Agile Development, я часто замечаю, что с левой стороны, где они начинаются, расположен большой список – бэклог продукта. Я считал бы это смешным, если бы многие люди не думали, что это очень просто. Получение хорошего, выверенного бэклога из накопившихся возможностей неизбежно займет очень много времени и сил – он не появится сам по себе. И конечно, этот бэклог не может просто состоять из того, что люди хотели бы создать. Это отдельный исследовательский процесс, который начинается с концентрации на углубленном изучении «Для кого?», «Что?» и «Почему?».

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

• Какие проблемы мы решаем в действительности?

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

• Как должно выглядеть решение, наиболее удобное и эффективное в использовании?

• Что мы имеем возможность реализовать, учитывая имеющиеся время и средства?

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

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

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

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

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

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

Вообще-то частично я ввел вас в заблуждение.

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

На самом деле истории, которые я рассказывал о MadMimi и Globo.com, еще не завершены. Это правда, что в обоих проектах использовались исследовательские обсуждения для выявления минимально жизнеспособного решения, но действительно ли именно это решение является жизнеспособным или нет, пока только догадки. По сути, все в этих историях – лишь догадки, пока продукт не представлен на рынок и мы не знаем, как на него реагируют пользователи и заказчики. Начальные исследовательские обсуждения, как и карты историй, помогли сделать хорошие стартовые предположения. Но для обоих проектов это было лишь начало куда более длинного пути к созданию действительно жизнеспособного продукта.

Таким образом, мы подошли к одной из крупнейших ошибок, которые обычно делают люди, – твердой уверенности, что минимально жизнеспособное решение непременно будет успешным.

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

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

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

Исследования, опубликованные организацией Standish Croup в отчетах Chaos прошлых лет, доказывают, что от 64 до 75 % функциональностей используются редко или не используются никогда[27]. А 75–90 % всех IT-стартапов (в зависимости от того, что считать неудачей) не достигают успеха[28].

Такие данные очень демотивируют, если о них задуматься. Неудивительно: большинство организаций придерживаются стратегии «сделаем вид, что у нас все работает».

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

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

Но, к счастью, есть способы работы получше.

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

В то время я был известен как специалист по дизайну пользовательского взаимодействия и разработке Agile. Я подумал: «Раз я дизайнер и способен мыслить, значит, у меня есть мышление дизайнера». Но я был не прав. Это было не то, что имел в виду клиент. К счастью, я не высказал свою мысль вслух.

Мышление дизайнера – это способ работы, изначально внедренный компанией IDEO. Затем в школе дизайна Стэнфордского университета этот способ изучили и начали преподавать. В наши дни ему обучают во множестве университетов и используют во множестве компаний по всему миру.

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

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

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

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

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

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

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

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

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

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

Но само по себе дизайнерское мышление может вызвать некоторые проблемы.

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

Вот несколько замечательных способов безнадежно испортить процесс дизайна.

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

• Потратьте уйму времени на доскональные исследования и формирование сути того, что вы изучили. Вопросы без ответов никогда не закончатся, но не сдавайтесь! (В этом случае очень полезно будет строгое ограничение времени на исследования.)

• Не тратьте время на разговоры с людьми и получение от них сведений. В конце концов, у вас есть множество данных! А идеи решений гениальны! Надо просто поскорей приступить к дизайну.

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

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

• Не тратьте времени на рассмотрение нескольких идей, ведь одна замечательная у вас уже есть.

• Тщательно разработайте прототип, который выглядит совсем как настоящее приложение, и неважно, что он не выполняет того, чего хотят заказчики и пользователи. Зато, лишь увидев этот прототип, они тут же вскричали: «Как классно он выглядит!»

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

• Не беспокойтесь о стоимости реализации решения. Решение безоговорочно верное, и любая стоимость разработки оправданна.

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

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

Эрик Райс – автор книги под названием «Стартап по методологии Lean»[29]. В этой книге Эрик рассказывает, как он угодил в ловушку, описанную мной ранее под названием «старые недобрые времена». Он участвовал в создании продукта, который собиралась выпустить его компания, в качестве технического директора. Успешность продукта не вызывала сомнений ни у кого, кроме заказчиков и конечных пользователей. Встречались положительные отзывы, отрицательные отзывы, явное безразличие. Компания, конечно, ожидала совсем не такого результата.

Одним из консультантов компании Эрика был Стив Бланк. Стив написал книгу «Четыре шага к прозрению»[30], где говорит, что первая вещь, о которой вы должны позаботиться, – не продукт, а клиенты. Он описывает процесс прогрессивного подтверждения достоверности используемых сведений: сперва вы убеждаетесь, что клиенты, которых вы нашли, заинтересованы в вашем решении, а затем – что придуманное решение заинтересует их настолько, что они согласятся его купить, использовать и порекомендовать другим. Бланк назвал все это процессом эмпирического обучения.

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

Вы можете спросить: «А какое отношение к этому имеют истории и карты историй?» Это хороший вопрос.

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

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

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

Что теперь? Если истории нужны для планирования и управления дискуссиями, с помощью которых разрабатывается программное обеспечение, похоже, всем нам придется очень много разговаривать.

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

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

Сейчас наконец настало время для проведения лучших, завершающих обсуждений.

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

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

Со стороны такая машина и в самом деле кажется волшебной. Но внутри нее вы и ваша команда обсуждаете, дорабатываете и совершенствуете попавший в машину элемент. Этот особый секретный механизм, скрытый внутри машины, называется семинаром по историям.

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

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

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

Предметом всех обсуждений до этого момента были детали, но мы погружались в них ровно настолько, чтобы принять необходимые на тот момент решения. Теперь же нужно принимать решения, чтобы точно ответить на вопрос: «Что конкретно мы разрабатываем?»

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

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

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

Утомительные совещания по планированию – такая распространенная проблема, что многие команды интуитивно предпочитают проводить обсуждения историй в дни, предшествующие таким совещаниям. Как правило, такие обсуждения занесены в их ежедневники как «совещания по предпланированию», «окончательная обработка бэклога» или «лакировка бэклога». Но что происходит чаще всего? Та самая тягомотина, которую они так ненавидят на планировании, просто переносится на другой день. Словно пытаясь усугубить проблему, членов команды просят прервать их текущую продуктивную работу, чтобы посидеть на скучном совещании. Неудивительно, что никто не испытывает восторга по этому поводу.

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

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

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

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

Надеюсь, вы знаете, что корень слова software (программное обеспечение), soft, означает «мягкий». Это значение не ограничивается тем, что мы подразумеваем, говоря о губках или булочках. Лучше подойдет ассоциация с большим документом или книгой. Если бы вы писали книгу, как стараюсь делать сейчас я, вы бы не пытались сделать все за один раз. Вы бы написали, допустим, главу в один присест. Я, например, пишу за раз одну главу, а Питер, опытный и доброжелательный редактор, с которым я сотрудничаю, просматривает ее, делая необходимые предложения и поправки.

Но это не значит, что глава готова. До этого еще далеко.

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

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

• Материал понятен мне и лично проверен мной.

• Материал понятен моим редакторам и отредактирован ими.

• Книга снабжена иллюстрациями, которые облегчат читателям понимание материала и визуализируют ключевые моменты.

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

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

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

Я разделил бы работу над книгой на следующие истории.

• Огранка, полировка и создание первого чернового текста.

• Огранка, полировка и создание второго чернового текста.

• Огранка, полировка и создание текста с иллюстрациями.

• Огранка, полировка и создание текста с учтенными замечаниями и поправками.

• Огранка, полировка и создание текста с предметным указателем.

• Огранка, полировка и создание текста с глоссарием.

• Огранка, полировка и создание окончательной версии текста.

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

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

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

При традиционном подходе к разработке программного обеспечения работу по контролю и удалению неудачных фрагментов непременно объяснили бы плохими требованиями. Но после того, как вы надели плащ и шляпу рыцаря Agile, эта работа становится обучением и итеративным улучшением.

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

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

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

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

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

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

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

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

Если вы примерно одного возраста со мной, то, может быть, вспомните (с ностальгией), как играли в одну из первых видеоигр под названием «Астероиды». Давайте на минутку предадимся воспоминаниям: обещаю, это вполне в рамках темы.

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

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

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

Разбивайте истории на части постепенно и лишь тогда, когда это необходимо.

Во всех обсуждениях историй, на всех стадиях разбиения работайте, помня следующее.

1. Обсуждая возможности, рассмотрите, для кого они предназначены, какие проблемы решают и хорошо ли сочетаются с вашей бизнес-стратегией. Есть смысл на этом этапе разделить слишком объемные возможности.

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

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

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

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

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

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

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

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

Составьте карту только того, что вам нужно для обсуждения вашей функциональности.

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

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

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

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

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

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

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

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

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

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

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

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

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

 Бизнес-партнеры. Для них может быть достаточно добавления функциональности, критической с точки зрения привлечения новых заказчиков. Или, возможно, им достаточно полученных вами сведений о деталях, которые обязательно нужно включить в эту функциональность для обеспечения конкурентоспособности.

 Заказчики. Для них может быть достаточно добавления функциональности, которая обеспечит им реальную выгоду, когда они или сотрудники их организации начнут использовать обновленное приложение.

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

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

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

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

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

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

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

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

Как только вы почувствуете, что создали достаточно и уверены в возможности получить эти результаты, настало время выпустить ваше произведение в свет.

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

• встраивать в продукт показатели, которые позволят вам отслеживать использование новых функциональностей;

• планировать мероприятие, на котором будете наблюдать, как пользователи работают с вашим новым продуктом.

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

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

А сейчас я должен напомнить вам несколько горьких истин о разработке программного обеспечения.

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

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

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

Вы продвигаете свой продукт к релизу – историю за историей. Как только намеченная вами дата релиза начинает угрожающе приближаться (а такая дата есть всегда), задайтесь вопросом о каждой основной пользовательской линии действий: «Если бы нужно было выпустить продукт прямо сейчас, какую оценку мы бы поставили сами себе?» Если вы используете буквенные оценки вроде тех, что приносят из школы мои дети, то в конце концов получите целый табель для своего продукта.

Например, если у вас продукт или функциональность с пятью основными линиями действий пользователей, а в табеле написано: A, A-, B+, D, B+[33], то, разумеется, за оставшиеся до релиза недели вам следует сосредоточиться на той части, которая получила оценку D. Если в конце релиза вы получаете только А и В, это довольно хорошо. Конечно, быть круглым отличником лучше, но уложиться в срок в мире разработки гораздо важнее.

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

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