Kitobni o'qish: «Управление продуктом в Scrum. Agile-методы для вашего бизнеса»

Roman Pichler

AGILE PRODUCT MANAGEMENT WITH SCRUM

Creating Products that Customers Love

Издано с разрешения Pearson (Addison-Wesley Professional)

Книга рекомендована к изданию Лианой Мартиросян и Наталией Юлдашевой

Благодарим за помощь в подготовке издания компанию ScrumTrek в лице Алексея Пименова, Дарьи Рыжковой, Василия Савунова и Александра Тупикова

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

Authorized translation from the English language edition, entitled Agile product management with Scrum: creating products that customers love, 1^st edition, published by Pearson, publishing as Addison-Wesley Professional.

© Roman Pichler, 2010

© Перевод на русский язык, издание на русском языке, оформление. ООО «Манн, Иванов и Фербер», 2017

* * *

Посвящается Мелиссе

Предисловие Джеффа Сазерленда

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

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

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

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

Джефф Сазерленд,

один из создателей Scrum

Предисловие Бретта Квинера

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

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

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

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

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

Бретт Квинер,

старший вице-президент по продукту Salesforce.com

Предисловие

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

В 1999 году я познакомился с agile-идеологией, и меня поразило тесное сотрудничество между техническими и бизнес-специалистами и технарями. Я всегда считал, что разработка ПО – это то, что интересует гиков², но не бизнесменов. Занимаясь коучингом своего первого agile-проекта в 2001 году, я прежде всего старался помочь менеджерам продукта перейти к миру гибких методологий. С тех пор владение продуктом всегда оставалось самым большим вызовом для компании и определяло успех всего предприятия. Так было во всех компаниях, которые я консультировал, и это помогало не только разрабатывать успешный продукт, но и применять Scrum по назначению. Можно повторить слова Криса Фрая и Стива Грина (Fry, 2007; 139), которые консультировали Salesforce.com по переходу к Agile:

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

Чем отличается agile-управление продуктом

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

Таблица 1. Управление продуктом по-старому и по-новому

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

Что предлагает эта книга и кто должен ее прочесть

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

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

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

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

1
Кто такой владелец продукта?

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

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

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

Роль владельца продукта

В Scrum Guide Кен Швабер пишет о владельце продукта:

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

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

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

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

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

В коммерческих проектах владелец продукта – обычно представитель клиента: менеджер продукта или маркетолог. Сам клиент принимает на себя эту роль, если продукт разрабатывается для конкретной организации. Например, это может быть внешний клиент, которому необходимо новое решение для хранилища данных, или внутренний клиент (в частности, отдел маркетинга), запрашивающий обновление сайта. Мне доводилось работать с клиентами, пользователями, менеджерами бизнес-направлений, менеджерами продуктов, руководителями проектов, бизнес-аналитиками и архитекторами, которые хорошо подходили на роль владельца продукта в конкретных обстоятельствах. Владельцем продукта может стать даже CEO³. Например, Ript – визуальный планировщик, позволяющий пользователям копировать и вставлять изображения и тексты из одного приложения в другое, – это плод усилий Джерри Лейборна, CEO компании Oxygen Media, который взял на себя роль владельца продукта для первого релиза программы.

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

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

Визионер⁴ и человек действия

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

Лидер и командный игрок

«Хорошие бизнес-лидеры создают концепцию, формулируют концепцию, страстно ее отстаивают и неумолимо ведут к завершению», – говорит Джек Уэлч, бывший председатель совета директоров и CEO компании General Electric. Владелец продукта – именно такой лидер. Отвечая за успех продукта, он обеспечивает руководство всеми, кто занят разработкой, и готов принимать сложные решения. Например, укажет, отложить дату запуска или ограничиться меньшей функциональностью. В то же время владелец продукта – командный игрок, он вступает в тесное сотрудничество с другими членами scrum-команды и не обладает формальной властью над ними. Мы можем определить владельца продукта как primus inter pares – первого среди равных в том, что касается продукта.

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

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

КОМАНДА ПРЕДПРИНИМАТЕЛЕЙ

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

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

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

Мудрость многих лучше, чем гений одного.

Пропагандист и переговорщик

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

Наделенный полномочиями и преданный делу

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

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

Доступный и квалифицированный

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

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

ВЛАДЕЛЕЦ ПРОДУКТА В PATIENTKEEPER

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

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

Работа с командой

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

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

Поскольку владелец продукта, scrum-мастер и команда должны постоянно и тесно сотрудничать, желательно разместить всех членов scrum-команды в одном помещении. Рассмотрим пример mobile.de. То, что владельцы продукта, scrum-мастер и команда находились в одном помещении, повысило производительность и боевой настрой команды⁷. Если владелец продукта не имеет возможности постоянно находиться вместе с командой, он должен регулярно встречаться с ее членами. Владельцы продукта, работающие удаленно, могут приходить в офис и оставаться вместе с командой на протяжении нескольких дней при каждом спринте. Если владельцы находятся в том же комплексе, но располагаются далеко от команды, я рекомендую им выполнять «правило одного часа»: проводить как минимум час в день в помещении, где трудится команда.

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

Взаимодействие со scrum-мастером

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

Роли владельца продукта и scrum-мастера дополняют друг друга. Владелец продукта в первую очередь отвечает за создание нужного продукта. Scrum-мастер в основном несет ответственность за то, «как» правильно использовать практики Scrum. Эти два аспекта проиллюстрированы на рисунке 1.1. Долгосрочный успех достигается, когда правильный продукт создается правильными методами.

Рисунок 1.1. Создание правильного продукта правильными методами

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

Работа с клиентами, пользователями и другими заинтересованными лицами

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

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

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

Помимо клиентов и пользователей производители продукта должны привлекать и других заинтересованных лиц – например, представителей служб маркетинга, продаж и клиентского обслуживания. Их с самого начала следует приглашать на рабочие совещания во время спринтов. Эти встречи позволят заинтересованным лицам увидеть, как создается продукт, наладить контакт со scrum-командой и обменяться мнениями. Брайсон (Bryson, 2004) предлагает обзор методов выявления заинтересованных лиц, анализа их требований и работы с ними.

МЕНЕДЖЕРЫ ПО ПРОДУКТОВОМУ МАРКЕТИНГУ И МЕНЕДЖЕРЫ ПРОДУКТА

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

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

Моделирование роли владельца продукта

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

Главный владелец продукта

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

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

Иерархия владельцев продукта

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

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

Рисунок 1.2. Простая иерархия владельцев продукта

На рисунке 1.3 представлен другой вариант, подходящий для больших scrum-проектов и заимствованный из книги Кена Швабера (Schwaber, 2007; 70–73).

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

Рисунок 1.3. Сложная иерархия владельцев продукта

Сложная иерархия владельцев продукта предполагает специализацию деятельности каждого из них. Главный владелец продукта возглавляет общую разработку, координируя свою деятельность с клиентами и другими заинтересованными лицами. Владельцы продукта более низкого уровня сосредоточены на своих функциях или подсистемах и тесно сотрудничают с командами разработчиков. Швабер (Schwaber, 2007; 72) отмечает:

Владелец продукта планирует, расписывает, распределяет и отслеживает работу со своего уровня вниз… Чем выше его уровень, тем сложнее работа. Объем ответственности владельца продукта высшего уровня обычно предполагает, что им становится должностное лицо не ниже вице-президента или CEO.

Как правильно выбрать владельцев продукта

Найти подходящего человека на роль владельца продукта непросто, даже когда нужен только один такой кандидат. По каким же критериям выбирать правильных владельцев продукта для больших проектов? Ответ на этот вопрос дает понимание разных способов организации команд в большом проекте. Существует всего два варианта: функциональные команды и компонентные команды (Pichler, 2008; Larman and Vodde, 2009). Функциональная команда внедряет сквозной набор требований – например, одну или несколько тем или функций. В результате появляется сквозной вертикальный срез, который проходит через основные части программной архитектуры. Компонентная команда выдает компонент или подсистему.

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

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

Распространенные ошибки

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

Владелец продукта с недостаточными полномочиями

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

Перегруженность владельца продукта

Перегрузка на работе пагубно отражается на здоровье и моральном состоянии любого человека. А перегруженные владельцы продукта часто оказываются слабым звеном, ограничивающим прогресс проекта. Симптомы перегрузки владельца продукта – это недостаточная работа над бэклогом продукта, пропуски планирования спринтов или обзорных совещаний, невозможность задать им вопрос и слишком длительное время, требующееся для ответов. Перегруженные владельцы продукта не соответствуют идее agile-манифеста о постоянном темпе. «Agile-процессы подразумевают равномерное развитие. Заказчики, разработчики и пользователи должны постоянно поддерживать один и тот же темп» (Beck et al., 2001).

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

Чтобы не перегружать владельца продукта, попробуйте для начала освободить этого человека от всех остальных обязанностей. Ведь он занимается постоянной работой и может отвечать только за один продукт и одну команду. Кроме того, убедитесь, что команда в каждом спринте находит время для сотрудничества с владельцем продукта. Scrum отводит для этого до 10 % действий команды (Schwaber, 2007). Такое сотрудничество не только позволяет более равномерно распределить бремя нагрузки, но и дает возможность использовать коллективное мышление и творческий импульс всей команды.

Частичный владелец продукта

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

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

Удаленный владелец продукта

Удаленный владелец продукта работает отдельно от команды. Слово «удаленный», возможно, вызывает представление, что владелец продукта находится на одном континенте, а команда – на другом. На самом деле удаленность имеет самые разные формы и степени. Так называют и ситуации, когда владелец продукта работает с командой в одном здании, но в разных помещениях, и случаи, когда они находятся на разных континентах и в различных часовых поясах (Simons, 2004). Проблемы, связанные с удаленными владельцами, повсюду одинаковы: недостаток доверия, недопонимание, отсутствие единства и медленный темп работы. И причина понятна: «Самый экономичный и эффективный способ передачи информации команде разработчиков – это личная беседа» (Beck et al., 2001).

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

Заместитель владельца продукта

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

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

Комитет владельцев продукта

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

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

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

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

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

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

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

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

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

В начале 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 года. Более долгосрочный взгляд на рост продукта можно воплотить в плане развития, о котором говорится ниже.