Войти в систему
Войти с помощью соц. сетей:
В начале 1990-х телефонные конференции были настоящим испытанием. Участникам нередко приходилось отворачиваться от стола и кричать в микрофон. Когда люди говорили одновременно, их голосов не было слышно, так что разговор напоминал какой-то гул. Компания Polycom занималась телепрезентациями и решениями по передаче видеокартинки, голоса и контента. Там осознали, что клиентам необходимы телефонные конференции, которые были бы больше похожи на личное общение, без искажений, эха и других помех. Поэтому Polycom запланировала концепцию продукта со следующими свойствами (Lynn and Reilly, 2002; 63):
В итоге появился продукт под названием SoundStation, который был запущен в 1992 году. Концепция стала важным фактором его успеха. В этой главе рассказывается о методах планирования концепции продукта. Начнем с содержания и свойств эффективной концепции.
— Скажите, пожалуйста, куда мне отсюда идти?
— Это во многом зависит от того, куда ты хочешь прийти, — ответил Кот.
— Да мне почти все равно, — начала Алиса.
— Тогда все равно, куда идти, — сказал Кот.
Льюис Кэрролл, «Алиса в Стране чудес»
Способность представить себе то, как должен выглядеть новый продукт или его новая версия, необходима для того, чтобы куда-то прийти. Представления о продукте выливаются в видение — набросок будущего продукта. Видение служит объединяющей целью, которая придает энергию и направляет работу людей. В этой цели смысл существования продукта. Как и в примере с 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 страниц, в котором подробно рассказывается, какой продукт вы должны сделать, — вы убиваете творчество. А так, например, инженер приходит и говорит: знаете, вы тут забыли функцию, а я хочу ее добавить. Нельзя изгонять творческое начало из работы. Консенсусный подход, при котором команда сообща вырабатывает концепцию того, что они делают, и оставляет достаточно пространства для творчества каждому члену команды, действительно способен вдохновлять и нередко приводит к наилучшим результатам.
Нужно противостоять искушению перегружать продукт деталями или спецификациями. Дополнительная функциональность будет обнаружена и отражена в бэклоге продукта в ходе проекта.
Если говорить о видении продукта, то оно должно быть кратким и сжатым, содержать только информацию, необходимую для его успеха. Например, продукты-блокбастеры, как показало десятилетнее исследование Линна и Рейли, обладали всего шестью атрибутами (Lynn and Reilly, 2002). Таким образом, видение продукта — это не список функций и оно не должно содержать избыточные подробности. Специалист по agile-управлению проектами Джим Хайсмит поясняет: «Как оказалось, описание пятнадцати-двадцати признаков или функций продукта — задача довольно легкая. А вот выбор трех-четырех из них, которые побудили бы человека этот продукт купить, — дело сложное» (Highsmith, 2009; 97). Специалист по разработке продуктов Дональд Райнертсен соглашается: «У большинства успешных продуктов есть четкое и простое ценностное предложение. Покупатели обычно выбирают между конкурирующими продуктами на основе трех-четырех ключевых факторов» (Reinertsen, 1997; 174–175).
Видение продукта обычно считается сжатым, если может пройти лифтовый тест Мура. «Можете вы объяснить, в чем идея вашего продукта, за то время, пока едете в лифте?» (Moore, 2006; 152). Если ответ отрицательный, то видение, вероятно, слишком сложное или запутанное.
Чтобы создать видение продукта, scrum-команда должна заглянуть в будущее и сформулировать то, как, по ее мнению, будет выглядеть и работать будущий продукт. Конечно, для любого человека, не наделенного даром ясновидения, верное предсказание будущего — дело чрезвычайно сложное. В конце концов, единственное, что мы точно знаем о будущем, — это то, что оно неопределенное. Не существует методики исследования рынка, способной выдавать абсолютно достоверные прогнозы. А полностью безопасные инвестиции — это лишь иллюзия. Так, Купер утверждает, что вероятность неудачи для новых продуктов колеблется от 25 до 45% (Cooper, 2001; 10). В некоторых исследованиях приводятся еще более высокие проценты. Рынки развиваются самым неожиданным образом, реакцию клиентов предсказать трудно, что и иллюстрирует следующая история.
Когда в 1999 году компания Expertcity выпустила интерактивную систему технической поддержки, на нее возлагались большие надежды. Исследования рынка показали, что новый продукт будет иметь большой успех. К сожалению, продукт не оправдал ожиданий. Expertcity, однако, отметила, что пользователи стали широко применять одну из функций продукта — возможность поделиться экраном — неожиданным образом. Они начали с ее помощью управлять удаленными компьютерами. Компания тут же внесла изменения в продукт, превратив его в средство удаленного контроля. Модифицированный продукт получил название GoToMyPC. Он стал настолько успешен, что Citrix в 2003 году решила приобрести Expertcity за 225 миллионов долларов. GoToMyPC сейчас является частью пакета Citrix Online. Хотя исходное видение продукта Expertcity и оказалось неверным, способность компании к адаптации помогла ей превратить явный провал в неожиданный успех.
Поскольку наше умение предсказывать будущее ограниченно, ориентируйтесь ради успеха на минимально функциональный продукт, имеющий небольшое количество функций, которые призваны удовлетворить избранные потребности клиентов. Вспомните 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). Продукт выходит быстрее, время выхода на рынок сокращается, функциональность добавляется более своевременно. Снижается стоимость разработки продукта и увеличивается скорость возврата инвестиций. Быстрее можно выручить деньги за товар, что ускоряет движение наличности, убыстряются и темпы обучения. Сократив время выхода на рынок, мы имеем возможность чаще воспринимать реакцию рынка и самостоятельно реагировать на нее, а не пытаться ее предугадать. Быстрый выпуск минимально функционального продукта снижает риски. Если продукт оказывается неудачным и его приходится сразу же отзывать с рынка, мы теряем меньше денег. Это позволяет внедрить в стратегию возможность ошибки, таким подходом активно пользуется Google. Марисса Майер из Google объясняет: «Мы понимаем, что многие продукты придется просто выбросить, но помнить будут только значимые продукты, обладающие большим пользовательским потенциалом».
Поскольку будущее неопределенно, концепция должна распространяться только на следующую версию продукта. Даже если долгосрочной мечтой Стива Джобса было доминирование на рынке мобильных телефонов, это определенно не являлось целью первого 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 не ставит целью создавать продукты с богатой функциональностью: наши лучшие продукты содержат только те функции, которые нужны людям для достижения своих целей. В идеале даже те продукты, которые требуют большого количества функций и сложного дизайна, должны быть столь же просты, сколь и эффективны… Мы стараемся не просто добавлять новые функции, но и развивать продукты в других направлениях». Разработка простых пользовательских интерфейсов, по утверждению Лидуэлла, Холдена и Батлера, прекрасно оправдала себя в 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) предлагает при расстановке приоритетов для свойств продукта руководствоваться следующими факторами:
Так, чтобы поставить удобство в эксплуатации выше сочетаемости с другим оборудованием, мы должны пожертвовать остальными свойствами ради удобства в эксплуатации. В то же время мы должны попытаться сохранить сочетаемость.
Полезное, простое и дешевое решение для записи потребностей и свойств — это набор бумажных карточек. Карточки способствуют командной работе, на них легко писать и делать дополнения. Их можно группировать, вешать на стенку и перемещать. Когда работа по формированию концепции закончена, мы можем наклеить карточки на перекидную доску, повесить ее в рабочем помещении и скопировать данные на вики-ресурс проекта.
Первые дни жизни любого продукта окружены легендами и мифами, не существует четкой формулы порождения идей и развития их в видение. В данном разделе рассказывается о двух подходах к формированию видения нового продукта — это любимые проекты и Scrum. В любом случае концептуальная работа должна быть сведена к минимуму — важно быстро выпустить первый вариант продукта или демоверсию для клиентов и пользователей. Прислушайтесь к рецензиям, и поймете, на правильном ли вы пути. Затем внесите изменения. Воздержитесь от излишних процедур и мер контроля на концептуальном этапе — они сдерживают творчество и инновации. Вместо того чтобы придумывать инновации, ваши сотрудники тратят время на заполнение бумажек.
В таких компаниях, как Google, разработчикам разрешается тратить до 20% времени на «любимые проекты». Это проекты, связанные с частными исследованиями, которые приводят к новым идеям, реализуемым в прототипах. Результаты оправдывают вложения Google: большая часть всех продуктов, выпущенных за вторую половину 2005 года, начиналась как «любимый проект» (Mayer, 2006). Разработчики, выдвинувшие исходную идею, продолжают работать над проектом претворения ее в жизнь, как это было в случае с браузером Google Chrome. Бен Гуджер и Дарин Фишер, два инженера, предложивших прототип, сыграли важную роль в проекте разработки Chrome (Levy, 2008). Кен Швабер (Schwaber, 2007; 80) приводит такие аргументы в пользу этого подхода к развитию новых идей:
Я рекомендую отвести часть времени каждого сотрудника на деятельность, не имеющую отношения к scrum-командам, в которых он состоит на данный момент, но идущую на благо предприятия. Я советую использовать на это примерно 20% их времени. Пусть они соединяются в группы по интересам и работают вместе. Какое-то время займет работа с коллегами по поддержанию и расширению функциональных знаний, а какое-то — поиск и разработка прототипов новых идей. Так были разработаны желтые клейкие стикеры в 3M и почта Gmail в Google.
Если для разработки концепции необходимы более серьезные усилия, используйте для этого Scrum. Попросите владельца продукта, scrum-мастера и команду провести мероприятия по выработке продуктового видения, возглавлять которые должен владелец продукта. Сначала в бэклоге продукта будет фигурировать самое общее видение итогового продукта — например, «Доступны прототипы, исследующие варианты дизайна пользовательского интерфейса» или «Проводятся собеседования с клиентами». В процессе работы в бэклоге продукта появляются высокоуровневые свойства, описывающие будущий продукт в соответствии с продуктовым видением. Каждый визионерский спринт будет порождать обновление — шаг навстречу видению продукта, что в итоге вырастет в итоговый продукт. (Если понадобится только один визионерский спринт, то концепция продукта создается по его результатам.) Например, Supermassive Games — британская студия по разработке компьютерных игр — использует визионерские спринты для организации работы на раннем этапе, который часто именуется «предпроизводством». Команда создает наброски и прототипы для дальнейших итераций на пути к общей концепции компьютерной игры. Прототипы могут быть как моделями Lego и набросками на бумаге, так и действующими программами.
Scrum-команда, вырабатывавшая видение продукта, должна в том же составе, за некоторыми ощутимыми исключениями, проводить и разработку. В некоторых случаях команда может привлечь внешних специалистов — например, дизайнера пользовательского интерфейса или представителя службы поддержки — в команду, занимающуюся визионерскими спринтами. После формирования видения специалист может покинуть команду, становясь просто заинтересованным лицом.
В этом разделе приводится обзор техник, которые могут оказаться полезными при формировании видения продукта. Обзор не претендует на всеохватность и глубокое описание методов. Он призван снабдить вас достаточным количеством информации, чтобы можно было судить, насколько эти техники применимы к вашему проекту. Здесь рассматриваются прототипирование и макетирование, персоны и сценарии, варианты использования и пользовательские истории, последовательности и раскадровки, визуализации и обзоры, а также модель Кано.
В начале нового проекта мы часто не имеем представления о том, чего именно не знаем. Более того, наша целевая группа покупателей и основные пользователи находятся в таком же положении, поэтому не могут сразу объяснить, как должен выглядеть и работать наш продукт. Таким образом, формирование видения лучше всего понимать как процесс открытия, обретения знания и обучения, которое требует экспериментов. В экспериментах исследуются причинно-следственные взаимоотношения, когда процесс манипулирования причиной идет до тех пор, пока не будет получено желаемое следствие. Это одновременно и поощрение открытого, исследовательского, живого ума, и следование строгим процедурам. Ключ к эффективному эксперименту состоит в быстром получении необходимого знания посредством внедрения и тестирования прототипов и макетов, которые служат средствами создания знания и обучения. Они помогают понять, как должен выглядеть и работать продукт, какая технология и архитектура будут для него наиболее успешны, насколько вообще осуществима идея. Прототипы — это обычно расходные материалы, создаваемые быстро и дешево. Порой даже бумажных прототипов и набросков достаточно для тестирования идеи. Исполняемые прототипы, исследующие конкретный вопрос, иногда называются спайками.
В одном телекоммуникационном проекте были поставлены довольно амбициозные требования по удобству использования. Исследование рынка показало, что продукты компании воспринимаются как менее удобные для пользователя, чем у конкурентов. Поэтому команда построила прототип, состоящий из макета устройства и одноразовой реализации самых важных элементов пользовательского интерфейса на Flash. Клиентов пригласили протестировать прототип, и их отзывы сильно повлияли на итоговый дизайн. В результате получился новый продукт с прекрасным клиентским интерфейсом.
Организованный эксперимент проходит по четырехшаговой модели, известной также как цикл Деминга. Сначала мы вырабатываем гипотезу (планирование). Затем воплощаем ее (выполнение) и анализируем результаты (проверка). Если эксперимент оказался неудачным, мы вносим в гипотезу изменения, где необходимо, и проводим следующий эксперимент — либо для достижения лучшего результата, либо чтобы попробовать другой подход (воздействие). Томас Эдисон, создатель первой коммерчески успешной электрической лампочки, знал о неизбежности проб и ошибок — необходимости многократно ошибиться, чтобы воплотить в жизнь полноценный продукт. Хорошо известна его фраза:
«Если я обнаружил десять тысяч методов, которые не работают, это не ошибка. Я не обескуражен, потому что исключение каждого неверного метода — это шаг вперед».
Персоны помогают нам выбрать целевых потребителей. Сценарии позволяют понять, как продукт изменяет их жизнь (Cooper, 1999). Персона — это «гипотетический архетип», представляющий целевого клиента или пользователя. Можно считать персону частным случаем носителя пользовательского сценария или пользовательской роли. В их описания включается информация, важная для использования продукта потребителями: например, должностные обязанности, навыки или интересы пользователя.
Сформировав корректно персоны, мы можем исследовать то, как продукт, который мы собираемся разрабатывать, будет влиять на их жизнь. Для этого создаем сценарии, которые описывают, как персона достигает своих целей без продукта и с ним. Формальный способ создания таких сценариев — составление карты потребления: одна ее часть описывает деятельность, необходимую для достижения конкретной цели без нашего продукта, другая — деятельность, которая потребуется в будущем, когда продукт будет доступен (Womack and Jones, 2005). Использование сценариев и карт потребления позволяет установить ценностное предложение продукта: необходимы ли выбранные свойства? Создают ли они преимущества для всех персон? Можно ли определить более важные свойства продукта?
Два эффективных метода определения ценностных и коммерческих аргументов продукта — это его визуализация и обзор в отраслевом журнале. Визуализация — это макет упаковки, в которой может поставляться продукт. Для создания визуализации scrum-команда придумывает название продукта, его графическое отображение и три важнейших коммерческих аргумента, при помощи которых продукт будет продаваться. Информация размещается на передней части упаковки. На оборотной части можно указать дополнительные подробности (Highsmith, 2009; 96–97). Чтобы написать обзор в отраслевом журнале, члены scrum-команды выясняют, что бы они хотели прочитать о продукте после его запуска (Cohn, 2009; 232). Это упражнение сделать быстро и легко. Его также можно использовать для проверки того, все ли одинаково понимают и разделяют концепцию продукта.
Модель Кано помогает выбрать нужную функциональность для создания привлекательного продукта (Kano, 1984). Она рассказывает, насколько может быть удовлетворен покупатель при внедрении определенного свойства продукта. В модели разграничиваются три типа функций: основные, производительные и привлекательные. Рассмотрим работу модели Кано на примере мобильного телефона. Основные функции мобильного телефона — это его включение и выключение, совершение и прием звонков, создание, отправка, получение и чтение текстовых сообщений. Эти рудиментарные функции необходимы, чтобы продать продукт, но удовлетворенность покупателя ими быстро исчерпывается. Например, если добавить еще одну кнопку для включения и выключения телефона, это не создаст никакой дополнительной ценности. Невозможность обеспечить основные функции обычно делает продукт бесполезным. Производительные функции, как правило, приводят к прогрессивному повышению удовлетворения. Они следуют принципу «чем больше, тем лучше». Например, чем легче телефон и чем быстрее он включается, тем более удовлетворенными, вероятнее всего, будут клиенты. Они не могут насытиться требованиями производительности. Однако производительных функций недостаточно, чтобы продукт существенно отличался от всего остального на рынке. Привлекательные функции, как свидетельствует название, призваны привлекать и восхищать покупателей. Интересный дизайн продукта и способность индивидуализировать телефон — это примеры привлекательных функций. Они могут удовлетворять скрытые потребности клиентов, о которых те могли и не догадываться. Именно эти функции продукта создают конкурентное преимущество и уникальное коммерческое предложение.
Проблема в том, что нужно сочетать основные, производительные и привлекательные функции таким образом, чтобы желаемые преимущества были максимальными. Полезно бывает применить модель Кано к продуктовому видению или бэклогу продукта. Как и в случае видения продукта SoundStation, с которого мы начали эту главу, продуктовое видение часто сосредоточивается на производительных и привлекательных функциях и редко включает основные, которые можно найти в бэклоге продукта. Заметьте, что модель Кано способна делать интересное предсказание: со временем привлекательные функции превращаются в производительные, а производительные становятся основными. Когда конкуренты начинают поставлять схожие продукты, ваши продукты теряют свои преимущества. Чтобы остаться лидерами, компаниям нужно регулярно обновлять свой продукт, предлагая новые привлекательные функции. Эта корреляция — еще одна причина того, чтобы быстро запустить исходный продукт и затем регулярно его обновлять.
До сих пор в этой главе рассматривались вопросы создания видения нового продукта, что особенно сложно. По мере «взросления» продукта и выхода пошаговых обновлений визионерская деятельность обычно сокращается. Но новым версиям продукта все еще нужны цели. План развития продукта позволяет scrum-команде сформулировать цели будущих версий продукта. Пока видение заключается в создании и корректировке дорожной карты продукта.
Дорожная карта продукта — это тип плана, который показывает, как продукт должен развиваться в своих версиях, и облегчает диалог между scrum-командой и заинтересованными лицами. Дорожная карта продукта позволяет организациям координировать разработку и запуск смежных продуктов — например, линейки продуктов или продуктового портфеля. Рекомендуется не усложнять план развития продукта, а сосредоточиться на самой сути. План развития продукта должен содержать примерную дату выхода следующей версии, указание целевых потребителей и их нужд и три-пять основных функций. Не беспокойтесь о деталях. Они появятся и будут отражены в бэклоге продукта. Заметьте, что дорожная карта продукта никогда не заменит тщательного анализа реакции рынка и соответствующей корректировки продукта. Он просто утверждает, как, по нашему мнению, продукт должен развиваться на основе текущего понимания рынка. Дорожные карты продукта — это живые документы, они эволюционируют.
Составьте дорожную карту сразу после того, как продукт был успешно представлен на рынке. (Появление пятилетнего плана прежде, чем вышел релиз продукта, имеет мало смысла. Такой план скорее отражает мечту, чем предсказывает реальность.) В составлении должны принимать участие все важные для продукта лица. К ним относятся scrum-команда, ответственный за продуктовый портфель, представители команд разработки других продуктов и заинтересованные лица. Убедитесь, что дорожная карта продукта имеет реалистичные сроки. В зависимости от рынка и стадии жизненного цикла продукта ограничьтесь 6–12 месяцами и не пытайтесь делать прогнозы на следующие два-три года.
В процессе взросления продукт начинает отвечать все большему числу потребностей покупателей: обслуживает потребителей в разных сегментах и регионах. Поскольку запросы становятся многочисленнее и разнообразнее, усложняется выпуск обновлений продукта с минимальной функциональностью. Требуется все больше функций для поддержки постоянно растущего количества клиентов и пользователей. Чтобы решить проблему, мы применяем варианты продукта. Каждый вариант адресован конкретной группе пользователей и сегменту рынка. Приведем в качестве примера популярную программу Visio для создания диаграмм. Версия 2007 года доступна в двух вариантах: Office Visio Standard 2007 и Office Visio Professional 2007. Первый позиционируется как «базовое средство визуализации», а профессиональная версия является расширением Visio Standard 2007 и призвана «помочь бизнес- и IT-пользователям визуализировать, анализировать и представлять комплексную информацию, сложные системы и процессы». Эти два варианта обслуживают различные сегменты рынка — домашних и коммерческих пользователей с ограниченной потребностью в диаграммах и профессиональных пользователей, нуждающихся в дополнительной диаграммной функциональности.
Хотя варианты продукта могут стать могущественными союзниками, слишком большое их количество ведет к разбуханию продуктового портфеля, высокой стоимости поддержки и перегруженности клиентов. Представьте себе, что было бы, если бы Microsoft предлагала четыре версии Office Visio 2007: Essentials, Standard, Professional и Deluxe. Потребители затруднились бы с выбором, и им было бы непросто принять решение о покупке.
Есть и еще один недостаток: варианты продукта опасны тем, что функциональность придется внедрять снова и снова, что приведет к высоким издержкам на разработку и техническую поддержку. Решить эту проблему может создание набора шаблонов, общих для всех вариантов. Эти шаблоны называются платформой. Например, Apple использует общие компоненты для iPhone и iPod touch. Однако, осознав необходимость введения общих компонентов, не следует попадаться в ловушку — надеяться на создание идеальной мегаплатформы. Начинайте с малого. Платформа должна расти естественным путем по мере увеличения необходимости в вариантах продукта. Тщательно сохраняйте ее функциональность. Этот подход, возможно, приведет к рефакторингу архитектуры, но он исключает опасность чрезмерного усложнения платформы.
Выработка продуктового видения — это необходимый шаг в подготовке его к запуску. Берегитесь следующих распространенных ошибок: отсутствия видения, пророческого видения, аналитического паралича, а также девизов «мы-лучше-знаем-что-нужно-клиентам» и «большое — значит хорошее».
Очевидная, но, увы, распространенная ошибка — начать разработку продукта без какого-либо видения. Это чаще всего бывает, когда клиенты требуют внедрения в продукт отдельных функций, не понимая необходимости связи между ними. Получающийся при этом продукт носит название функциональной сборной солянки (DeMarco et al., 2008; 143–145). Избегайте этого: убедитесь, что вы имеете концепцию, четко указывающую на клиента, его избранные потребности и важнейшие свойства продукта. Эта концепция затем позволит определить, какие функции следует внедрить, и поможет создать полезный и ценный продукт.
Несмотря на то что продуктовое видение рисует картину будущего продукта, это предсказанное будущее может никогда не наступить. Переработка видения в продукт — это предпринимательская деятельность, которая подразумевает риск. Как вы помните, видение Expertcity вылилось в продукт, который не оправдал ожиданий. То есть даже видение не страхует от неудачи. Однако, как и в случае с Expertcity, провал может стать первым шагом к успеху. Например, программа GoToMyPC стала результатом неудачного первого релиза. Чтобы свести к минимуму любые потенциальные убытки или ущерб от неточного прогноза, выбирайте узкий набор потребностей клиента и почаще выпускайте обновления. Затем анализируйте и вносите изменения.
Как уже говорилось, не стоит увлекаться предварительным исследованием рынка, иначе вы можете попасть в ловушку аналитического паралича, когда приходится проводить все новые и новые изыскания, причем без всякого прогресса. Чрезмерное исследование рынка грозит не только потерей времени и денег, но и тем, что вы не предъявите привлекательный продукт вовремя. Понимание рынка и забота о клиентах очень важны, но ориентация только на клиентов, без собственного понимания того, как должен выглядеть и работать продукт, вряд ли приведет к успеху.
Чаще всего причина аналитического паралича — излишняя забота о безопасности инвестиций. Компании, злоупотребляющие подобным поведением, часто нетерпимы к неудачам и требуют всего и сразу. Руководство хочет получить точные прогнозы, в том числе конкретную долю рынка и доходы, и только тогда готово утвердить концепцию. Аналитический паралич можно предотвратить, сведя концептуальную часть к минимуму, как можно быстрее разработав продукт и оперативно адаптировав его к рынку на основании реакции клиентов.
Некоторые компании впадают в другую крайность и совсем не обращают внимания на рынок. Они полагаются исключительно на интуицию руководства или техническое совершенство разработчиков. Эти организации считают себя знатоками того, что нужно клиентам. Конечно, при этом возникает риск потратить время и деньги на разработку никому не нужного продукта. Чтобы не заниматься инновациями в башне из слоновой кости, стоит включить в процесс разработки самих клиентов и пользователей, приглашая их на обзорные совещания по спринтам, а также быстро и часто выпуская ПО.
Создание продуктов с огромным количеством функций может, как отмечают Престон Смит и Дональд Райнертсен, создать большую шумиху вокруг вашей компании (Smith and Reinertsen, 1998; 67):
Всем нам нравятся истории успеха разработки, достигнутого героическими стараниями. Команда разработчиков берется за, казалось бы, невозможный проект и прилагает сверхчеловеческие усилия… Эти проекты похожи на длинные передачи, приводящие к тачдауну и сводящие с ума болельщиков. Они гораздо интереснее, чем обычная игра, в которой за один раз не проходишь и 10 метров.
Но какими бы увлекательными ни были огромные проекты, есть у них и недостатки: на них уходит масса денег и времени, при этом очень велик риск провала. «Компании часто совершают ошибку — пытаются найти идеальное решение, которое с первого же дня всех устроит. Часто это выливается в создание слишком сложных дорогих продуктов, которые не очень хорошо функционируют» (Anthony et al., 2008; 125). При этом в больших проектах очень сложно развивать продукт на основании отзывов клиентов и пользователей, поскольку многие функции предопределены.
Этой ошибки можно избежать, начав с работы над продуктом, призванным удовлетворить узкий набор клиентских требований и предлагающим минимальную, но достаточную функциональность. Быстро запустите его, изучите реакцию рынка и внесите соответствующие изменения.
Убедитесь, что вся scrum-команда разделяет видение будущего продукта. Это видение должно быть умеренным и ориентированным на ближайшую версию продукта. Думайте о большом, но начинайте с малого. Проверьте свое видение, приглашая на обзорные совещания во время спринтов потребителей и клиентов и быстро выпуская обновления продукта. Затем развивайте продукт на основе клиентских отзывов.
Следующие вопросы помогут вам применить идеи для концепции, обсуждавшиеся в этой главе.
Войти с помощью соц. сетей: