Текст книги "Управление продуктом в Scrum. Agile-методы для вашего бизнеса"

Вопросы для самоконтроля

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

Следующие вопросы помогут успешно применить роль владельца продукта.

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

• Кто определяет и описывает потребности клиентов и функциональность продукта?

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

• Что потребуется для внедрения роли владельца продукта в той форме, которая описана в данной главе?

2. Планирование концепции продукта

В начале 1990-х телефонные конференции были настоящим испытанием. Участникам нередко приходилось отворачиваться от стола и кричать в микрофон. Когда люди говорили одновременно, их голосов не было слышно, так что разговор напоминал какой-то гул. Компания Polycom занималась телепрезентациями и решениями по передаче видеокартинки, голоса и контента. Там осознали, что клиентам необходимы телефонные конференции, которые были бы больше похожи на личное общение, без искажений, эха и других помех. Поэтому Polycom запланировала концепцию продукта со следующими свойствами (Lynn and Reilly, 2002; 63):

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

• Простота в использовании, без загадочных кнопок и проводов.

• Привлекательный внешний вид, подходящий для использования в конференц-зале руководства.

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

Видение продукта

– Скажите, пожалуйста, куда мне отсюда идти?

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

– Да мне почти все равно, – начала Алиса.

– Тогда все равно, куда идти, – сказал Кот.

Льюис Кэрролл, «Алиса в Стране чудес»[13]13
  Перевод Б. Заходера. Прим. перев.


[Закрыть]

Способность представить себе то, как должен выглядеть новый продукт или его новая версия, необходима для того, чтобы куда-то прийти. Представления о продукте выливаются в видение – набросок будущего продукта[14]14
  Хотя концепция продукта не входит в структуру Scrum, она упоминается у Швабера и Бидла (Schwaber and Beedle, 2002; 34). Кен Швабер пишет: «Концепция описывает причины, по которым запускается проект, и его желаемый результат» (Schwaber, 2004; 68).


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

• Кто будет покупать этот продукт? Кто его целевой клиент? Кто будет использовать продукт? Кто его целевые пользователи?

• Каким потребностям будет отвечать продукт? Какую ценность он создает?

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

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

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

• Осуществимо ли производство продукта? Сможет ли компания его разработать и продавать?

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

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

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

Желаемые качества видения

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

Общее и объединяющее

Все люди, связанные с разработкой продукта, должны разделять его видение: scrum-команда, руководство, клиенты, пользователи и другие заинтересованные лица. Питер Сенге формулирует это так: «Концепция действительно является общей, когда у нас с вами возникает схожая картина и мы оба хотим, чтобы эта картина возникала у нас обоих, а не у каждого индивидуально» (Senge, 2006; 192). Общее видение порождает единение и заряжает энергией всех, кто вовлечен в процесс разработки. Оно способствует эффективной командной работе и облегчает обучение команды. «Когда люди действительно разделяют одно видение, они связаны друг с другом общими надеждами» (Senge, 2006; 192). Если же у членов команды видение не совпадает, они будут двигаться в разных направлениях, а не к общей цели. Отличный способ добиться общего видения – привлечь к его разработке членов scrum-команды и заинтересованных лиц.

Широкое и мотивирующее

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

Мы подбираем в команду людей, которые действительно очень заинтересованы в предмете. Считаю полезным, что мы по-прежнему отказываемся от детальных спецификаций продукта. Если вы пишете документ объемом 70 страниц, в котором подробно рассказывается, какой продукт вы должны сделать, – вы убиваете творчество. А так, например, инженер приходит и говорит: знаете, вы тут забыли функцию, а я хочу ее добавить. Нельзя изгонять творческое начало из работы. Консенсусный подход, при котором команда сообща вырабатывает концепцию того, что они делают, и оставляет достаточно пространства для творчества каждому члену команды, действительно способен вдохновлять и нередко приводит к наилучшим результатам[15]15
  “Inside Google’s New-Product Process”, BusinessWeek.com, June 30, 2006.


[Закрыть].

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

Краткое и приятное

Если говорить о видении продукта, то оно должно быть кратким и сжатым, содержать только информацию, необходимую для его успеха. Например, продукты-блокбастеры, как показало десятилетнее исследование Линна и Рейли, обладали всего шестью атрибутами (Lynn and Reilly, 2002). Таким образом, видение продукта – это не список функций и оно не должно содержать избыточные подробности. Специалист по agile-управлению проектами Джим Хайсмит поясняет: «Как оказалось, описание пятнадцати-двадцати признаков или функций продукта – задача довольно легкая. А вот выбор трех-четырех из них, которые побудили бы человека этот продукт купить, – дело сложное» (Highsmith, 2009; 97). Специалист по разработке продуктов Дональд Райнертсен соглашается: «У большинства успешных продуктов есть четкое и простое ценностное предложение. Покупатели обычно выбирают между конкурирующими продуктами на основе трех-четырех ключевых факторов» (Reinertsen, 1997; 174–175).

Видение продукта обычно считается сжатым, если может пройти лифтовый тест Мура. «Можете вы объяснить, в чем идея вашего продукта, за то время, пока едете в лифте?» (Moore, 2006; 152). Если ответ отрицательный, то видение, вероятно, слишком сложное или запутанное.

Минимально функциональный продукт

Чтобы создать видение продукта, scrum-команда должна заглянуть в будущее и сформулировать то, как, по ее мнению, будет выглядеть и работать будущий продукт. Конечно, для любого человека, не наделенного даром ясновидения, верное предсказание будущего – дело чрезвычайно сложное. В конце концов, единственное, что мы точно знаем о будущем, – это то, что оно неопределенное. Не существует методики исследования рынка, способной выдавать абсолютно достоверные прогнозы. А полностью безопасные инвестиции – это лишь иллюзия. Так, Купер утверждает, что вероятность неудачи для новых продуктов колеблется от 25 до 45 % (Cooper, 2001; 10). В некоторых исследованиях приводятся еще более высокие проценты. Рынки развиваются самым неожиданным образом, реакцию клиентов предсказать трудно, что и иллюстрирует следующая история[16]16
  На точность предсказания реакции рынка влияет его динамика и степень инновационности продукта. Для стабильных рынков и продуктов, переживающих постоянные или пошаговые инновации, реакция рынка может быть просчитана довольно хорошо. Для других рынков и продуктов это сложно или даже невозможно – например, в случае прорывных инноваций. Кристенсен (Christensen, 1997; 143) отмечает: «Нельзя анализировать рынки, которые еще не существуют».


[Закрыть].

Когда в 1999 году компания Expertcity выпустила интерактивную систему технической поддержки, на нее возлагались большие надежды. Исследования рынка показали, что новый продукт будет иметь большой успех. К сожалению, продукт не оправдал ожиданий. Expertcity, однако, отметила, что пользователи стали широко применять одну из функций продукта – возможность поделиться экраном – неожиданным образом. Они начали с ее помощью управлять удаленными компьютерами. Компания тут же внесла изменения в продукт, превратив его в средство удаленного контроля. Модифицированный продукт получил название GoToMyPC. Он стал настолько успешен, что Citrix в 2003 году решила приобрести Expertcity за 225 миллионов долларов. GoToMyPC сейчас является частью пакета Citrix Online. Хотя исходное видение продукта Expertcity и оказалось неверным, способность компании к адаптации помогла ей превратить явный провал в неожиданный успех.

Поскольку наше умение предсказывать будущее ограниченно, ориентируйтесь ради успеха на минимально функциональный продукт, имеющий небольшое количество функций, которые призваны удовлетворить избранные потребности клиентов[17]17
  Термин «минимально функциональный продукт» отсылает нас к работе Марка Денна и Джейн Клиленд-Хуан. В их книге Software by Numbers (2004) предложен термин «минимальная коммерчески ценная функциональность», который обозначает наименьшую функциональность, способную все же создать ценность для покупателя. Идея быстрого формирования небольшого набора функций и пошагового улучшения продукта восходит к методу эволюционной разработки Тома Гилба (Gilb, 1988).


[Закрыть]. Вспомните iPhone, выпущенный в 2007 году. Уникальное восприятие телефона пользователем полностью затмило конкурентов. Так был установлен новый стандарт для смартфонов. Одним из секретов успеха стал узкий набор потребностей клиента, которые были избраны Apple. Компания избежала искушения попытаться разом удовлетворить запросы многих потребителей, постаравшись скопировать все функции, которые предлагались конкурентами. Вместо этого Apple решила по-новому взглянуть на то, как должны выглядеть смартфоны, и сознательно отказалась от некоторых функций. Первый iPhone поступил в продажу без множества функций, которые считались к тому времени стандартом: копирования и вставки, возможности отправлять текстовые сообщения нескольким получателям и набора для разработки ПО. Однако эти ограничения не сказались на общем успехе. Урезание функциональности позволило Apple разработать и выпустить продукт в конкурентоспособное время и дало компании существенное преимущество над соперниками. Основываясь на успехе первой версии iPhone, Apple в 2008 году запустила 3G-модель, расширив возможности телефона как в программном, так и в аппаратном отношении. Она вышла и на новый сегмент рынка, нацелившись на бизнес-клиентов.

Сравните успех iPhone с другим продуктом компании – Apple Newton, вышедшим на рынок в 1993 году после пяти лет разработки. Помните объявления Apple, которые обещали вам полноценный КПК, способный делать самые невероятные вещи – например, распознавать ваш почерк? Когда Newton наконец вышел на рынок, оказалось, что он чересчур громоздкий. Более того: самая важная его функция – распознавание почерка – не работала должным образом. Продукт не оправдал ожиданий, и в 1998 году его выпуск прекратился. Сейчас можно сказать, что планы Apple на Newton были чрезмерно амбициозными. Компания выпустила продукт, который претендовал слишком на многое, и потерпела неудачу.

Создание минимального продукта дает ряд преимуществ. Это отмечают Смит и Райнертсен (Smith and Reinertsen, 1997) и Денн и Клиленд-Хуан (Denne and Cleland-Huang, 2004)[18]18
  Смит и Райнертсен (Smith and Reinertsen, 1997) называют метод разбиения инновации на более мелкие и быстрые этапы пошаговой инновацией.


[Закрыть]. Продукт выходит быстрее, время выхода на рынок сокращается, функциональность добавляется более своевременно. Снижается стоимость разработки продукта и увеличивается скорость возврата инвестиций. Быстрее можно выручить деньги за товар, что ускоряет движение наличности, убыстряются и темпы обучения. Сократив время выхода на рынок, мы имеем возможность чаще воспринимать реакцию рынка и самостоятельно реагировать на нее, а не пытаться ее предугадать. Быстрый выпуск минимально функционального продукта снижает риски. Если продукт оказывается неудачным и его приходится сразу же отзывать с рынка, мы теряем меньше денег. Это позволяет внедрить в стратегию возможность ошибки, таким подходом активно пользуется Google. Марисса Майер из Google объясняет: «Мы понимаем, что многие продукты придется просто выбросить, но помнить будут только значимые продукты, обладающие большим пользовательским потенциалом»[19]19
  “So Much Fanfare, So Few Hits”, BusinessWeek.com, July 10, 2006. Подобный же подход отражен в знаменитом изречении Арта Фрая из 3М: «Чтобы найти принца, придется перецеловать много лягушек». Заметьте, что прекрасный принц заплатит за всех этих лягушек. (Имеется в виду сказка братьев Гримм «Принц-лягушка». Прим. ред.)


[Закрыть].

Поскольку будущее неопределенно, концепция должна распространяться только на следующую версию продукта. Даже если долгосрочной мечтой Стива Джобса было доминирование на рынке мобильных телефонов, это определенно не являлось целью первого iPhone. Большие амбиции лучше всего реализовывать пошагово. «Важен только один шаг – следующий» (Gilb, 1988; 97). Как только появляется концепция, она превращается в готовый продукт благодаря использованию пользовательских и клиентских отзывов. Их собирают по результатам демонстрации новых версий продукта на обзорных совещаниях во время спринтов, а также быстрых и частых релизов продукта. Подобный метод работы позволяет scrum-команде сразу же определить, действительно ли они производят нужный продукт. Если же нет, то видение, вероятно, сформировано неверно, так что следует внести коррективы.

Заметьте, что видение продукта может воплощаться более чем в одном релизе. Например, запуску первой версии Google Chrome в декабре 2008 года предшествовало множество непубличных релизов и публичная бета-версия в сентябре 2008 года. Более долгосрочный взгляд на рост продукта можно воплотить в плане развития, о котором говорится ниже.

Простота

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

Бритва Оккама

Простота как руководящий принцип – это давняя традиция. Еще в XIV веке францисканский монах Уильям Оккам, как считается, заявил, что при выборе между функционально эквивалентными решениями следует отдавать предпочтение более простому (Lidwell, Holden, and Butler, 2003; 142). Эта идея известна как бритва Оккама.

Простота – это не только эстетика продукта. Это концентрация на его сути, когда создается только действительно необходимое и есть возможность быстро и легко изменять и расширять продукт. Простые, но адекватные продукты удобны в использовании – например, Apple или iPod. Основанный на колесе прокрутки и кнопках на нем, iPod прост и минималистичен, но предлагает все необходимые функции. Бек и Эндрес пишут: «Проекты, тяготеющие к простоте, идут на пользу и человечеству, и производительности» (Beck and Andres, 2005; 110).

Чем меньше, тем лучше

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

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

Джон Маэда, специалист по простоте решений и профессор Массачусетского технологического института, согласен с этими положениями: «Легче всего достичь простоты при помощи обдуманного исключения. Если вы сомневаетесь в функции, исключите ее» (Maeda, 2006; 1). Стиву Джобсу приписывают фразу: «Инновации – это не значит всегда и всему говорить “да”. Это значит говорить “нет” всему, кроме самых важных функций». Agile-манифест разделяет эту точку зрения, называя простоту одним из 12 принципов и определяя ее как «искусство увеличения работы, которую вы не делаете» (Beck et al., 2001). Каждый раз, когда у вас появляется идея новой функции или вы обнаруживаете новое требование, задайте себе вопрос, насколько эта функциональность значима для успеха продукта. Если она не критична – откажитесь от идеи. В результате получается простой и лаконичный продукт, который предлагает только те функции, которые действительно нужны клиенту или пользователю.

Простые пользовательские интерфейсы

Google – компания, которая открыто взяла на вооружение принцип простоты как ключевой при взаимодействии с пользователем. «Google не ставит целью создавать продукты с богатой функциональностью: наши лучшие продукты содержат только те функции, которые нужны людям для достижения своих целей. В идеале даже те продукты, которые требуют большого количества функций и сложного дизайна, должны быть столь же просты, сколь и эффективны… Мы стараемся не просто добавлять новые функции, но и развивать продукты в других направлениях»[20]20
  “Ten principles that contribute to a Google user experience”. www.google.com/corporate/ux.html.


[Закрыть]. Разработка простых пользовательских интерфейсов, по утверждению Лидуэлла, Холдена и Батлера, прекрасно оправдала себя в Google: «В то время как другие интернет-поисковики стремились добавлять на свои сайты рекламные сервисы и применимые для конкретных случаев функции, Google придерживалась своего простого и эффективного дизайна. Результат – самый производительный и удобный в использовании поисковик в сети» (Lidwell, Holden, and Butler, 2003; 143). А Бернар Жирар, автор книги The Google Way (Girard, 2009; 34), считает, что именно благодаря простоте AdWords – рекламная программа Google – стала такой успешной.

Подобно интуитивному Macintosh GUI, благодаря которому продукты Apple выглядят такими дружелюбными и удобными в использовании, дизайн и направленность на пользователя интерфейса AdWords от Google помогли ему победить. Любой рекламодатель сразу же понимает, как разместить объявление…

Потребности покупателя и свойства продукта

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

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

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

Рассмотрим два свойства – сочетаемость с другим оборудованием и удобство в эксплуатации. Способность взаимодействовать с разнообразными системами и устройствами обычно требует определенного уровня архитектурной сложности. Удобство в эксплуатации, напротив, предполагает использование простой открытой архитектуры. В результате появляется напряжение: владелец продукта, scrum-мастер и команда вынуждены прилагать усилия, чтобы примирить непримиримое и найти наилучшее решение для удовлетворения потребностей покупателя. Алистер Кокберн (Cockburn, 2005; 147) предлагает при расстановке приоритетов для свойств продукта руководствоваться следующими факторами:

• Пожертвовать остальными ради этого.

• Попытаться сохранить.

• Пожертвовать этим ради остального.

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

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