Inspired
Inspired
Марти Каган
Вдохновленные
Каган М.
Вдохновленные / М. Каган — «Манн, Иванов и Фербер (МИФ)»,
2018 — (МИФ Бизнес)
Если вы продакт-менеджер в технологической компании или только мечтаете
им стать, обновленное издание книги известного специалиста по продакт-
менеджменту Марти Кагана поможет вам выбрать верный путь в деле
создания высокотехнологичных продуктов. В нем представлены принципы
проектирования, исследования и запуска прорывных продуктов, а также
рекомендации по управлению ими, применимые в разных контекстах.
Книга будет полезна инвесторам, продакт-менеджерам, маркетологам,
разработчикам, стартаперам. На русском языке публикуется впервые.
УДК 658.512.2
ББК 65.291.217
© Каган М., 2018
© Манн, Иванов и Фербер
(МИФ), 2018
М. Каган. «Вдохновленные»
Содержание
Отзывы 6
Предисловие 10
Часть I. Уроки лучших технологических компаний 12
Глава 1. Кто стоит за каждым отличным продуктом 14
Глава 2. Высокотехнологичные продукты и сервисы 15
Глава 3. Стартапы: как достичь соответствия «продукт – рынок» 16
Глава 4. Компании на стадии роста: успешное масштабирование 17
Глава 5. Корпорации: непрерывные продуктовые инновации 18
Глава 6. Фундаментальные причины неудач в работе над 19
продуктом
Глава 7. Lean и Agile и не только 24
Глава 8. Ключевые идеи 26
Конец ознакомительного фрагмента. 27
4
М. Каган. «Вдохновленные»
Марти Каган
Вдохновленные. Все, что нужно
знать продакт-менеджеру
Научные редакторы Андрей Аликимович, Марьяна Онысько
Издано с разрешения John Wiley & Sons International Rights, Inc. и литературного агент-
ства Александра Корженевского
© Wiley, 2018
All Rights Reserved. This translation published under license with the original publisher John
Wiley & Sons, Inc.
© Перевод на русский язык, издание на русском языке, оформление. ООО «Манн, Ива-
нов и Фербер», 2020
***
Эта книга посвящается моему отцу Карлу Кагану. В 1969
году он стал первым кандидатом компьютерных наук в США (до
этого информатика и другие компьютерные науки входили в учебные
программы по электротехнике) и написал первую книгу о базах данных
(Data Management Systems вышла в 1973 году, тоже в издательстве John
Wiley & Sons).
Он не только был потрясающим отцом, но и научил меня
программировать, когда мне было всего девять лет, – за несколько
десятилетий до того, как этот технический навык стал одним из самых
ценных и востребованных, – и привил мне любовь к технологиям в те
времена, когда многие технологии, от которых мы все сегодня зависим,
существовали только как замысел.
5
М. Каган. «Вдохновленные»
Отзывы
7
М. Каган. «Вдохновленные»
9
М. Каган. «Вдохновленные»
Предисловие
Впервые задумавшись о публикации второго издания книги, я прикинул, что придется
изменить лишь 10–20 процентов первоначального содержания – очень уж мне хотелось поме-
нять как можно меньше. Однако, приступив к делу, я понял, что для второго издания пер-
вое нужно переписать полностью. Не потому, что мне перестало нравиться то, что я написал
раньше, а потому, что я увидел, что теперь могу объяснить и раскрыть все обсуждаемые в книге
темы намного полнее и интереснее.
Надо сказать, я совсем не ожидал такого успеха от первого издания. Эта книга помогла
мне завести друзей по всему миру. Она переведена на несколько языков и, несмотря на то что
написана почти десять лет назад, все еще отлично продается благодаря письменным отзывам
читателям, сарафанному радио.
Итак, если вы читали первое издание, я выражаю вам признательность за это и искренне
надеюсь, что второе понравится вам еще больше. Если же вы читаете мою книгу впервые, верю,
что новая «версия» выполнит свое предназначение лучше предыдущей.
Первое издание я писал, когда методология гибкой разработки продуктов, Agile, еще
не вошла в практику продуктовых компаний так прочно и надежно, как теперь, а концепции
Customer Development и Lean Startup1 не были такими популярными, как сейчас. Сегодня мно-
гие команды используют их уже не первый год и больше интересуются выходящим за рамки
подходов Lean и Agile, на чем я и сосредоточился в этом издании.
Структура книги осталась прежней, но описанные в ней методы за последнее десятилетие
существенно развились и усовершенствовались. Поэтому, помимо несколько иного подхода к
объяснению тем и описанию методик, в книге есть еще одно серьезное изменение: на этот раз
я в мельчайших подробностях рассказываю о том, что назвал масштабированием продукта.
В первом издании я сосредоточился на стартапах, а здесь мне захотелось расширить
обсуждение, включив в него сложные задачи, стоящие перед компаниями на стадии роста, а
также правильные и эффективные подходы к разработке продукта в крупных корпорациях.
Нет никаких сомнений в том, что, становясь крупнее и сложнее, компания сталкивается
с серьезными трудностями и проблемами, поэтому в последнее десятилетие я значительную
часть времени уделял коучингу компаний на стадии быстрого роста. Иногда, чтобы показать,
насколько насколько сложен этот период, мы называем его болезнью роста.
Должен сказать, я получил от читателей первого издания множество отзывов, благодаря
чему узнал несколько важных вещей, на которых хотел бы кратко остановиться.
Во-первых, сегодня наблюдается острая нужда в четком фокусе на специфической работе
продакт-менеджера 2. В первом издании я много говорил об управлении продуктами, но обра-
щался к продуктовым командам в более широком смысле. Сегодня существует множество
отличных источников информации как для дизайнеров продуктов, так и для инженеров-про-
граммистов, но очень мало предназначено для менеджеров, которые отвечают за высокотех-
нологичные продукты. Вот почему в этом издании я решил сосредоточиться на их работе. Если
вы менеджер продукта в технологической компании или только мечтаете им стать, то, надеюсь,
моя книга будет для вас полезным справочником.
Во-вторых, сегодня многие ищут рецепт успеха продукта – своеобразное четкое руко-
водство или процедуру для создания продуктов, которые непременно полюбят потребители.
Я отлично понимаю подобное желание и знаю, что, по всей вероятности, продал бы намного
1
Методология Customer Development («Развитие клиента») была представлена Стивеном Бланком в 2005 году. Концепцию
Lean Startup («Бережливый стартап») в 2011 году предложил Эрик Рис. Прим. ред.
2
Словосочетания продакт-менеджер, менеджер продукта, продакт используются в книге как синонимы. Прим. ред.
10
М. Каган. «Вдохновленные»
больше экземпляров книги, если бы позиционировал ее как источник таких знаний, но, к сожа-
лению, великие продукты так не создаются. Для этого компании необходимо прежде всего
сформировать правильную культуру и выработать понимание многочисленных методик, пред-
назначенных для этапов исследования продукта и его вывода на рынок, чтобы использовать
для решения проблем, с которыми он сталкивается на своем пути, правильные инструменты.
И безусловно, это означает, что работу менеджера продукта ни в коем случае нельзя назвать
простой; по правде говоря, преуспеть на этой ниве способен не каждый. Тем не менее работа
менеджера высокотехнологичных продуктов сегодня считается одной из самых желанных в
нашей отрасли; а еще это главный испытательный полигон и основной «поставщик» руково-
дителей стартапов. Словом, если у вас есть желание преуспеть на этом поприще и вы готовы
приложить для этого усилия, я буду счастлив помочь вам добиться своей цели.
11
М. Каган. «Вдохновленные»
Часть I. Уроки лучших технологических компаний
В середине 1980-х я был молодым инженером-программистом и трудился над разработ-
кой одного важного продукта в Hewlett-Packard. В это время (впервые в истории человечества)
наблюдался стремительный рост интереса к изучению возможностей искусственного интел-
лекта, и мне посчастливилось работать в компании, которая тогда считалась одной из лучших
в отрасли высоких технологий. Я был членом чрезвычайно сильной команды разработчиков
(несколько ее членов впоследствии добились весьма значительных успехов в других компаниях
отрасли).
Перед нами поставили очень сложную задачу – разработать технологию для использова-
ния искусственного интеллекта на недорогой универсальной рабочей станции. На тот момент
для этого требовалась сложнейшая специализированная комбинация аппаратно-программных
средств стоимостью свыше 100 тысяч долларов на одного пользователя. Разумеется, такие рас-
ходы могли позволить себе не многие.
Мы упорно трудились больше года, жертвуя вечерами, ночами и выходными. По ходу
дела наша команда пополнила портфель Hewlett-Packard несколькими отличными патентами.
Мы разработали софт, соответствующий чрезвычайно высоким стандартам качества HP.
Мы сделали продукт доступным для международных пользователей и адаптировали его для
нескольких языков. Мы обучили и подготовили команду продаж. Разместили предваритель-
ную информацию о новой технологии в СМИ и получили отличные отзывы. Мы были готовы.
И вывели продукт на рынок. И отпраздновали релиз.
Только вот проблема: продукт никто не покупал.
Он с треском провалился на рынке. Да, с технологической точки зрения продукт был
весьма впечатляющим, и обозревателям он очень понравился, но это было не то, чего люди
хотели, в чем они по-настоящему нуждались.
Разумеется, такой результат очень расстроил нашу команду. Но вскоре это заставило нас
задать себе критически важные вопросы: а кто решает, какие продукты мы должны разраба-
тывать? И как это происходит? Откуда эти люди знают, что созданное нами будет нужно и
полезно?
Словом, наша молодая команда выучила тогда очень ценный урок, мы узнали то, что
многим дается весьма болезненно: неважно, насколько хороши ваши разработчики, если они
работают не над тем, что действительно стоит создавать.
Пытаясь отследить причину нашего провала, я узнал, что решения о том, что разраба-
тывать, принимал менеджер продукта – человек, который трудился в маркетинговом отделе
и отвечал за определение того, что мы должны разрабатывать. А еще я узнал, что управле-
ние продуктами не входило в число сильных сторон и компетенций HP. Впрочем, как выясни-
лось позже, это частая проблема большинства компаний, и такое удручающее положение дел,
к сожалению, все еще сохраняется.
И тогда я дал себе слово, что больше никогда не стану так напряженно и увлеченно тру-
диться над разработкой продукта до тех пор, пока не буду знать, что именно хотят пользова-
тели и клиенты.
За следующие тридцать лет мне посчастливилось поработать над некоторыми самыми
успешными высокотехнологичными продуктами современности. Я работал в HP на заре эры
персональных компьютеров; в Netscape Communications – во время появления интернета
(вице-президентом по платформам и инструментам); в eBay – в период становления электрон-
ной торговли и электронных рынков (сначала старшим вице-президентом по продуктам и про-
ектированию, а затем в качестве консультанта по вопросам стартапов сотрудничал со многими
12
М. Каган. «Вдохновленные»
из тех, кто сегодня добился огромного успеха в сфере выпуска высокотехнологичных продук-
тов).
Одни наши продукты были более успешными, другие менее, но я счастлив сказать, что ни
один из них не потерпел крах, а некоторые стали очень популярными и любимыми миллионами
людей во всем мире.
Вскоре после моего ухода из eBay мне начали звонить из организаций, которые хотели
улучшить свой подход к разработке продуктов. Начав сотрудничать с ними, я обнаружил
огромную разницу между тем, как подходят к работе над продуктами наилучшие компании,
и тем, как это делает большинство.
Я понял, что представление о том, как должно быть, очень отличается от того, как
это происходит на практике.
Оказалось, что большинство компаний все еще использовали старые, неэффективные
способы определения того, какой продукт следует создавать, как его разрабатывать и выпус-
кать. Я узнал и об остром дефиците ресурсов – как учебно-теоретических, таких как учебные
программы лучших бизнес-школ, так и практических, – от реальных компаний, которые, по-
моему, безнадежно застряли на неудачных моделях прошлого, как в случае с описанной мной
историей из опыта работы в HP.
За это время мне подвернулось множество отличных возможностей, в частности шанс
работать с величайшими умами в области управления продуктами. Нужно признать, лучшие
идеи в книге принадлежат именно этим людям. Большинство из них упомянуты в разделе «Бла-
годарности». Я очень многому у них научился и искренне признателен за это.
Я выбрал эту карьеру, потому что хотел заниматься созданием продуктов, которые нра-
вятся потребителям, – продуктов, вдохновляющих людей и несущих им ценность. И я убеж-
ден: менеджеры продукта хотят того же. Однако приходится признать, что большинство про-
дуктов никого не воодушевляют, а между тем человеческая жизнь слишком коротка, чтобы
мы пользовались скверными продуктами.
Эту книгу я писал с надеждой на то, что она поможет рассказать миру о передовых мето-
диках успешнейших продуктовых компаний и сподвигнет к созданию по-настоящему вдохнов-
ляющих продуктов, – тех, которые любят потребители.
13
М. Каган. «Вдохновленные»
Глава 1. Кто стоит за каждым отличным продуктом
Я твердо убежден, что за каждым отличным продуктом стоит тот (обычно этот человек
неустанно трудится, оставаясь за кулисами), кто руководил командой его разработчиков, сумел
соединить технологии и дизайн и благодаря этому решить реальные проблемы потребителей
тем способом, который обеспечивает и потребности компании. Это главная идея моей книги.
Обычно такого человека называют менеджером продукта, но он может быть соучредите-
лем стартапа или СЕО3. Бывает также, что он играет в своей команде другую роль, а на первый
план вышел потому, что сумел уловить подлинную потребность рынка (и своей компании).
Нужно отметить, что управление продуктом сильно отличается от дизайна, разработки,
маркетинга, управления проектами и других функций. Книга, которую вы держите в руках,
написана именно для менеджеров продукта.
В современных командах по разработке высокотехнологичных продуктов (для краткости
мы называем их продуктовыми) продакт-менеджер выполняет в высшей мере специфические и
сложные обязанности. Это чрезвычайно трудная работа, поэтому знайте: любой, кто пытается
убедить вас в обратном, оказывает вам медвежью услугу.
Прежде всего, работа менеджера продукта, как правило, предполагает полный рабочий
день и максимальную нагрузку. Я знаю не так уж много людей, способных делать все, что обя-
зан делать такой специалист, менее чем за 60 часов в неделю.
Если вы дизайнер или инженер-программист и хотите стать еще и менеджером продукта,
это замечательно, ведь в этом случае у вас будут некоторые серьезные преимущества. Но,
поверьте, вы очень быстро поймете, что управление продуктом требует огромных затрат вре-
мени и усилий. Однако если вы к этому действительно готовы, то сможете получить весьма
впечатляющие результаты.
Современная продуктовая команда обычно состоит из по меньшей мере одного про-
дакт-менеджера и от двух до десяти инженеров-программистов. А если она создает что-нибудь
для потребителя, то в ней должен быть и дизайнер продукта.
Далее мы обсудим особую ситуацию, когда приходится привлекать инженеров или дизай-
неров, работающих удаленно, из специализированного агентства или аутсорсинговой фирмы.
Но независимо от того, как вы собираете свою команду, ваша должность (продакт-менеджер)
и эта книга изначально предполагают наличие такой команды, которая вместе с вами трудится
над проектированием, созданием и запуском какого-нибудь продукта.
3
СЕО – здесь и далее генеральный директор компании. Прим. ред.
14
М. Каган. «Вдохновленные»
Глава 2. Высокотехнологичные продукты и сервисы
Хотя на свете существует множество разных продуктов, в этой книге речь пойдет исклю-
чительно о высокотехнологичных продуктах.
Конечно, кое-что из того, о чем мы с вами поговорим далее, пригодится и тем, кто
занимается другими видами продуктов, но в этом случае я никаких гарантий не даю. Да и,
честно говоря, менеджерам большинства нетехнологичных продуктов, таких как товары широ-
кого потребления, и так доступны отличные источники знаний. Я же сосредоточился на уни-
кальных проблемах и вызовах исключительно высокотехнологичных продуктов и сервисов.
Если точнее, мы будем говорить о таких продуктах, как интернет-магазины или маркетплейсы
(например, Netflix, Airbnb, Etsy), социальные сети (Facebook, LinkedIn, Twitter), бизнес-сер-
висы (Salesforce.com, Workday, Workiva), устройства (Apple, Sonos, Tesla) и мобильные прило-
жения (Uber, Audible, Instagram).
Такие продукты не обязательно должны быть чисто цифровыми. Многие из лучших на
сегодняшний день примеров представляют собой смесь онлайн- и офлайн-опыта, скажем поиск
попутчика для поездки в такси или комнаты для ночлега, оформление ипотечного кредита или
отправка почты с помощью службы экспресс-доставки. На мой взгляд, большинство компаний
сегодня становятся высокотехнологичными, а тех, кто этого еще не понял, ждет скорый крах.
Но, напоминаю, в этой книге я сосредоточился только на высокотехнологичных продуктах и
на тех компаниях, которые считают, что обязаны разбираться в новых технологиях и последо-
вательно и непрерывно внедрять инновации в интересах своих клиентов.
15
М. Каган. «Вдохновленные»
Глава 3. Стартапы: как достичь
соответствия «продукт – рынок»
В технологическом мире развитие компаний обычно находится на одной из трех ста-
дий: стартап, компания на стадии роста и корпорация. Предлагаю вкратце рассмотреть, как мы
характеризуем каждую из них, а также с какими трудностями и проблемами вы, скорее всего,
столкнетесь на этих стадиях.
В целом я определяю стартап как компанию, которая очень молода и ее продукт пока
еще не соответствует ожиданиям рынка. Соответствие «продукт – рынок» (product-market fit) –
чрезвычайно важная концепция; далее мы дадим ее определение, а пока просто заметим, что
стартап – это компания, которая еще только пытается придумать продукт, способный положить
начало жизнеспособному бизнесу.
В стартапе роль продакт-менеджера обычно играет один из соучредителей. Как правило,
в стартапе работает не более двадцати пяти инженеров-программистов, объединенных в одну-
две, максимум четыре-пять команд.
Реальность стартапа такова: вы постоянно гонитесь за достижением соответствия своего
продукта ожиданиям рынка – пока не закончатся деньги. До тех пор, пока не найден и не
разработан сильный продукт, обеспечивающий истинные потребности вашего рынка, ничто
другое не имеет значения, поэтому продукт всегда находится в фокусе внимания стартапа.
Обычно на раннем этапе финансирование стартапа ограниченно, поскольку его цель –
определить, успешно ли компания пройдет этап исследования продукта и его вывод на рынок.
И чем меньше денег остается у стартапа, тем безумнее становятся темпы работы и тем отча-
яннее трудится команда и руководство. Однако, хотя деньги и время у них в большом дефи-
ците, хорошие стартапы представляют собой оптимальную среду для быстрого приобретения
нужных знаний и навыков; а еще в них крайне редко сталкиваешься с бюрократией, препят-
ствующей прогрессу. И все же для этих компаний характерен очень высокий уровень неудач и
крахов, что, конечно же, ни для кого не секрет. Зато те немногие, кто преуспевает, – действи-
тельно мастера в деле выявления потребностей пользователей и разработки продукта, чему, в
сущности, в значительной мере и посвящена эта книга.
Работа в стартапе, в условиях неуемной погони за соответствием «продукт – рынок»,
обычно стрессовая, изнурительная и рискованная. Но такой опыт может быть на редкость пози-
тивным и, если все пойдет хорошо, еще и отлично оплачиваемым.
16
М. Каган. «Вдохновленные»
Глава 4. Компании на стадии
роста: успешное масштабирование
Оказавшись достаточно компетентным и удачливым (обычно требуется и то и другое),
для того чтобы обеспечить соответствие «продукт – рынок», стартап приступает к решению
очередной не менее сложной задачи – эффективно расти.
С ростом стартапа и превращением его в большой, успешный бизнес связано множество
серьезных проблем. И хотя это сложный вызов, с ним все же лучше столкнуться, чем пропу-
стить. Вам нужно не только нанять новых людей, но и выяснить, как повторить достигнутый
на раннем этапе успех, работая с новыми, смежными продуктами. В то же время необходимо
как можно быстрее развивать свой основной бизнес.
На стадии роста в компании обычно уже работает от двадцати пяти до нескольких сотен
сотрудников, а следовательно, людей, готовых помочь вам в решении этой задачи, теперь
намного больше, зато повсюду наблюдаются признаки организационного стресса.
Продуктовые команды жалуются, что не видят общей картины, что не понимают, спо-
собствует ли их работа (и каким образом) достижению больших целей и что значит быть само-
управляющейся командой с широкими полномочиями.
Подразделения продаж и маркетинга часто сетуют на то, что стратегии выхода на рынок,
которые оказались эффективными для запуска первоначального продукта, совсем не подхо-
дят для некоторых новых продуктов в портфеле компании. Технологическая инфраструктура,
созданная для удовлетворения требований выпуска исходного продукта, нередко расползается
по швам, и вам все чаще доводится слышать от каждого инженера, с которым вы разговарива-
ете, термины вроде «технический долг».
Непрост этот этап и для руководителей, потому что стиль и механизмы лидерства,
отлично работавшие тогда, когда компания была стартапом, не масштабируются по мере ее
роста. Лидеры вынуждены изменять свои роли и функции, а во многих случаях и модели пове-
дения.
Зато для этой стадии характерна очень высокая мотивация к преодолению подобных про-
блем. Компания может провести IPO или стать бизнес-подразделением какой-нибудь крупной
корпорации. Не менее мотивирующий фактор, безусловно, и вполне реальная возможность
оказать на мир позитивное влияние.
17
М. Каган. «Вдохновленные»
Глава 5. Корпорации: непрерывные
продуктовые инновации
Компании, успешно прошедшие стадию масштабирования и приступившие к строитель-
ству стабильного долгосрочного бизнеса, по-прежнему подстерегают сложности.
Сильные технологические компании знают, что для непрерывного создания новой цен-
ности для потребителей и собственного бизнеса им необходимо постоянно заниматься инно-
вациями. Речь идет не просто о дополнениях или оптимизации уже имеющихся продуктов
(специалисты называют это перехватом прироста стоимости), а скорее о разработке каждого
нового продукта таким способом, который позволяет полностью раскрыть его потенциал. А
между тем к этому моменту многие крупные корпорации уже начинают медленно разрушаться.
Их интересует только дальнейшая эксплуатация ценности и бренда, созданных много лет или
даже десятилетий назад. Нужно сказать, корпорации редко умирают в одночасье, и крупные
компании на этой стадии развития могут еще долго оставаться на плаву. Но не стоит заблуж-
даться на этот счет: организация тонет, и ее печальная участь предрешена.
Разумеется, это делается не намеренно, но как только компания достигает значительных
размеров и уровня сложности – и нередко становится публичной, – огромное количество заин-
тересованных сторон из самых разных подразделений бизнеса начинают изо всех сил защи-
щать те достижения, которые у нее есть в настоящий момент. К несчастью, это обычно приво-
дит к удушению новых инициатив и рискованных предприятий, которые могли бы вдохнуть
в компанию новую жизнь (поскольку они действительно подвергают основной бизнес серьез-
ному риску), или возведению такого количества препятствий и барьеров для новых идей, что
мало кто сможет и захочет увлечь компанию в новом направлении.
Не заметить симптомов такого развития событий очень трудно, ведь это и ослабление
морального духа сотрудников, и отсутствие инноваций, и даже то, что новые продукты попа-
дают в руки потребителей гораздо медленнее, чем раньше.
У юной компании было четкое и весьма привлекательное видение своего будущего.
Однако, достигнув стадии корпорации, она в основном его реализует, и люди не знают, что
делать дальше. Продуктовые команды жалуются на отсутствие цели и полномочий; на то, что
на получение нужных решений нередко уходит целая вечность и что работа над созданием
нового продукта превращается в беготню по кабинетам.
Руководство тоже не испытывает удовлетворения оттого, что продуктовые команды не
предлагают инноваций, и ради решения этой проблемы часто прибегает к приобретению или
созданию автономных «инновационных центров», стараясь так «инкубировать» новаторство в
защищенной среде. Однако такой шаг редко приводит к стабильным и результативным инно-
вациям, в которых остро нуждается компания.
А еще в компании постоянно ведутся разговоры о том, как же так получается, что такие
крупные корпорации, как Adobe, Amazon, Apple, Facebook, Google и Netflix, смогли избежать
этой печальной участи. Руководство ломает голову над вопросом, почему же им не удается
сделать то же самое. Но факт остается фактом: они смогли. И чтобы и мы смогли, нужно внести
серьезные изменения, о которых и рассказывается в этой книге.
18
М. Каган. «Вдохновленные»
Глава 6. Фундаментальные причины
неудач в работе над продуктом
Начнем с изучения основных причин того, почему многие усилия по созданию новых
продуктов терпят крах. В подавляющем большинстве компании любого размера, в самых раз-
ных уголках земного шара применяют один и тот же основной метод работы, и, должен отме-
тить, он совсем не похож на то, как работают лучшие и успешные.
Хочу сразу предупредить, что дальнейшее обсуждение может показаться вам несколько
удручающим, особенно если вы во многом узнаете в моем рассказе свою компанию, но даже
если это так, настоятельно прошу вас не бросать чтения.
Итак, на рис. 6.1 схематически представлен процесс, который по-прежнему используют
большинство компаний при создании продуктов. Воздержусь от разглагольствований и поуче-
ний – сначала просто опишу его.
Как вы видите, все начинается с идей. В большинстве компаний они поступают изнутри –
от руководителей, ключевых заинтересованных сторон или собственников бизнеса – либо
извне – от нынешних или потенциальных потребителей. В любом случае разным подразделе-
ниям нужно от вас много чего.
Затем большинство компаний определяют приоритеты для этих идей с помощью дорож-
ной карты (roadmap), что делается по двум причинам. Во-первых, они хотят, чтобы люди рабо-
тали над самыми важными вещами, а во-вторых, им хочется иметь возможность спрогнозиро-
вать, когда что будет готово.
Для этого в компании обычно проводится ежеквартальное или ежегодное совещание по
планированию; на нем руководство рассматривает и оценивает идеи и обсуждает дорожную
карту продукта. Но чтобы определить приоритетность идей, нужна оценка каждой из них в той
или иной форме. В одних компаниях приняты формальные процедуры, в других – неофици-
альные; как бы там ни было, все сводится к необходимости ответить на два вопроса относи-
тельно каждой идеи: сколько денег она принесет или какую ценность обеспечит? Сколько денег
19
М. Каган. «Вдохновленные»
или времени уйдет на ее реализацию? Далее эта информация используется для составления
дорожной карты, обычно на следующий квартал, но иногда и на целый год.
К этому моменту у организации, выпускающей высокотехнологичные продукты, все идеи
и замыслы описаны и распределены в порядке приоритетности. Если идея попала в верхнюю
часть списка, менеджер продукта первым делом проводит беседу с заинтересованными сто-
ронами, в результате чего замысел, так сказать, обрастает плотью, и «вырисовывается» ряд
основных «требований», или технических условий. Иногда эти требования представлены в
виде пользовательских историй (user stories), а иногда больше напоминают по форме техниче-
ское задание или функциональное описание. Их цель – донести до дизайнеров и инженеров,
что именно им нужно создать.
Как только требования собраны в пакет, команде дизайнеров пользовательского опыта
(если таковая имеется) предлагают спроектировать взаимодействие, разработать графический
дизайн и, если речь идет о физическом устройстве, промышленный дизайн. И наконец, требо-
вания и спецификации по дизайну передаются инженерам-программистам. Тут-то на сцену
обычно выходит методология Agile.
В любом случае инженеры, как правило, разбивают работу на итерации – отрезки вре-
мени, которые в процессе Scrum называются спринтами. Для превращения замысла в гото-
вый продукт может потребоваться, скажем, от одного до трех спринтов. Желательно, чтобы в
спринт входило тестирование качества, в ином случае специальная команда уже после окон-
чания разработки проводит тестирование готового продукта, чтобы убедиться, что новая идея
работает так, как рекламировалось, и не порождает других проблем с предыдущей версией
продукта (так называемое регрессионное тестирование).
Как только компания получает зеленый свет от команды тестировщиков, начинается
релиз новой идеи для реальных клиентов.
Большинство компаний самых разных размеров, когда я встречаюсь с ними в первый раз,
работают именно таким образом на протяжении многих лет. При этом они постоянно жалу-
ются на отсутствие инноваций и на то, что на превращение идеи в реальный продукт в руках
потребителя уходит слишком много времени. Вы вряд ли станете спорить с тем, что, несмотря
на упомянутую методологию Agile и практически всеобщее утверждение о гибком подходе к
разработке программного обеспечения, только что описанный процесс очень уж напоминает
каскадную модель, или, как ее еще называют, «водопад». Впрочем, справедливости ради надо
сказать, что инженеры-программисты обычно используют agile-методы так часто, как только
могут, учитывая более широкий каскадный контекст.
Хорошо, пусть большинство команд работают так, но почему это обязательно становится
причиной стольких проблем? Давайте-ка расставим все точки над «и» прямо сейчас, чтобы
ясно понять, почему этот распространенный повсеместно метод приводит к неудачам при
создании софта.
Далее вашему вниманию предлагается список моей топ-десятки самых больших про-
блем, которыми чреват такой подход. Имейте в виду: все это очень серьезные проблемы; даже
одна из них может свести к нулю усилия всей команды. Тем не менее для многих современных
компаний характерны несколько, а то и они все.
1. Начнем с первой проблемы в списке – источник идей. Использование этой модели при-
водит к созданию заказных продуктов, обусловленных потребностями отдела продаж, и про-
дуктов по требованию заинтересованных сторон. Мы еще обсудим эту важную тему, а пока
позвольте заметить, что это нельзя считать источником удачных замыслов продукта. Еще одно
очевидное негативное следствие такого подхода – отсутствие самостоятельности и широких
полномочий у команд. Работая по этой модели, люди просто реализуют чужие идеи; они тру-
дятся как наемный персонал.
20
М. Каган. «Вдохновленные»
2. Далее следует упомянуть о фатальной ошибке во время оценки идей. На самом деле я
ничего не имею против этого подхода, по крайней мере для идей, требующих больших инвести-
ций. Но то, как большинство компаний используют его на этом этапе для разработки дорожной
карты приоритетов идей, просто нелепо. Объясню почему. Помните два ключевых вопроса, на
которые должна дать ответ наша оценка? Сколько денег вы заработаете на этой идее и во что
вам обойдется ее реализация? Так вот, в действительности на этом этапе мы понятия не имеем
ни о том ни о другом. В сущности, мы просто не можем это знать.
Мы не можем знать, сколько денег заработаем, потому что это всецело зависит от того,
насколько правильным и удачным будет наше решение. Если команда проделает отличную
работу, она может оказаться невероятно успешной и изменит весь дальнейший ход деятель-
ности компании. Но, к сожалению, многие замыслы продуктов в конечном счете не приносят
компании ровным счетом ничего. И это вовсе не преувеличение! Буквально ничего (это опре-
деляется в результате A/B-тестирования).
Как бы там ни было, при разработке продуктов всегда нужно знать, чего мы не можем
знать, а на этом этапе мы просто не можем знать, сколько заработаем на той или иной новой
идее.
Точно так же мы понятия не имеем, во что нам обойдется создание нового продукта.
Без фактического решения проблемы инженерам чрезвычайно сложно предсказывать какие-
либо результаты. Большинство опытных разработчиков на этом этапе откажутся давать даже
приблизительную оценку, но некоторых из них заставляют или убеждают пойти на компромисс
и дать прогноз по типу размеров футболок: просто сообщите нам, каковы шансы этой идеи –
«маленькие, средние, большие или очень большие». Очень уж хочется иметь дорожные карты с
приоритетами, а для этого нужна какая-нибудь система для оценки идей и замыслов. Поэтому
люди играют в бессмысленную игру с оценками.
3. К еще большим проблемам приводит то, что происходит после, когда компании возла-
гают на составленные таким образом дорожные карты слишком уж большие надежды. За годы
работы я видел множество таких «карт», и подавляющее большинство из них были, по сути,
не чем иным, как списками функций и проектов с учетом их приоритетности. Маркетингу
нужна эта функция для проведения успешной маркетинговой кампании. Подразделение про-
даж настаивает на той функции, которая позволила бы ему привлечь нового перспективного
клиента. Кто-то мечтает об интеграции продукта с PayPal. Ну, в общем, вы меня поняли…
Но тут возникает проблема, возможно, самая серьезная, на которую все закрывают глаза.
Я называю это двумя неприятными правдами о продукте.
Первая истина заключается в том, что по крайней мере половина идей не сработают.
Это может произойти по целому ряду причин. Чаще всего потребители попросту не придут
от них в такой же восторг, как мы. И, как следствие, не выберут наш продукт. Иногда они
решают использовать его и пробуют, но отказываются от него из-за чрезмерной сложности, а
переход чреват такими проблемами, что овчинка выделки не стоит. А иногда проблема бывает
в том, что потребителям продукт, возможно, и понравился бы, но его создание требует намного
больше усилий, чем мы думали, поэтому тут уже мы решаем, что не можем позволить себе
таких трат.
Словом, я вам обещаю: половина идей из дорожной карты никогда не оправдают ожида-
ний. (Лучшие команды исходят из предположения, что минимум три четверти идей не срабо-
тают так, как им хотелось бы.)
Впрочем, будто этого мало, есть и вторая неприятная правда. Она заключается в том,
что для доведения идей, даже с уже подтвержденным потенциалом, до момента, когда они
будут приносить необходимую ценность для бизнеса, обычно требуется несколько итераций.
Мы называем это соотношением «время – деньги».
21
М. Каган. «Вдохновленные»
Один из самых важных уроков, которые я выучил за годы работы с программным продук-
том, состоит в том, что обойти эти обстоятельства невозможно, будь ты хоть ста пядей во лбу.
А ведь мне посчастливилось работать со многими исключительно хорошими продуктовыми
командами. Так что я могу точно сказать: все зависит от того, как вы справляетесь с ситуацией.
4. Далее рассмотрим роль продакт-менеджера в этой модели. В сущности, ее даже не
следовало бы так называть; на самом деле менеджер здесь является скорее менеджером про-
екта, чем продукта, потому что речь идет фактически о сборе требований и документировании
их для инженеров-программистов. А это не имеет никакого отношения к реалиям современ-
ного менеджмента высокотехнологичных продуктов.
5. То же самое можно сказать и о роли дизайна. Для извлечения его реальной ценности
уже слишком поздно, и в основном делается то, что мы назвали бы «сделать из дерьма кон-
фетку». Ущерб уже нанесен, и теперь мы просто пытаемся внешне скрасить итог, представив
хаос в лучшем свете. Дизайнеры пользовательского интерфейса знают, что он не хорош, но
стараются сделать его привлекательным и логичным, насколько это возможно.
6. В этой модели инженеров слишком поздно подключают к процессу, что, на мой взгляд,
огромная упущенная возможность. Мы всегда говорим: если ваши разработчики только пишут
коды, вы используете их вполсилы. Раскрою вам маленький секрет: инженеры-программи-
сты – лучший источник новаторских идей. А их слишком часто не приглашают принять уча-
стие в этом процессе.
7. Не только инженеров включают в процесс слишком поздно, то же самое касается прин-
ципов и ключевых преимуществ Agile. Команды, которые применяют Agile таким способом,
используют фактическую ценность и потенциал этого метода процентов на двадцать, не более.
В итоге мы чаще всего видим то, что можно назвать Agile для этапа запуска продукта, но
остальная часть организации и контекст не имеют с гибкостью ничего общего.
8. Весь этот процесс в высшей мере ориентирован на проект. Обычно компания финан-
сирует проекты, подбирает для них людей, «проталкивает» через разные уровни организации
и наконец запускает. Увы, в проекте главное – процесс, а в продукте – результат, поэтому
он предсказуемо оказывается неприглядным. В конце концов что-то создается, но оно не соот-
ветствует целям и задачам. В чем же тогда смысл? В любом случае это серьезная проблема;
совсем не так нужно подходить к созданию продуктов.
9. Самым большим недостатком устаревшей каскадной модели было и остается то, что все
риски сосредоточены в самом конце процесса; иными словами, проверка продукта на потре-
бителе происходит слишком поздно.
Как известно, ключевой принцип Lean-системы (системы бережливого производства) –
это сокращение потерь (отходов), а одной из худших форм таких потерь считается проведение
проектирования, изготовления, тестирования и развертывания функции или продукта с тем,
чтобы в конце этого долгого пути узнать, что это совсем не то, что нужно пользователю. И вот
парадокс: многие команды убеждены, что применяют Lean-принципы, а между тем используют
описанный мной базовый процесс. И тут я указываю им на то, что они проверяют свои идеи
одним из самых дорогих и самых медленных способов из всех известных.
10. И наконец, пока мы сильно заняты этим процессом и крайне непродуктивно тратим
время и деньги, наибольшей нашей потерей обычно становится цена упущенной возможности,
то есть того, что наша организация могла и должна была сделать вместо этого. А это время или
деньги, которых уже не вернешь.
Учитывая все вышесказанное, стоит ли удивляться, что так много компаний тратят цен-
ные ресурсы, получая столь жалкую отдачу. А я предупреждал, что то, что я скажу, может
огорчить вас. Но я все равно говорю об этом, потому что очень важно в полной мере понимать,
22
М. Каган. «Вдохновленные»
почему ваша компания должна изменить подход к работе – если, конечно, она работает так,
как я описал.
У меня для вас есть и хорошая новость: лучшие команды работают совершенно иначе,
и мы можем у них этому поучиться.
23
М. Каган. «Вдохновленные»
Глава 7. Lean и Agile и не только
Люди всегда искали и продолжают искать некое волшебное средство, верный рецепт
создания успешных продуктов, и всегда найдется отрасль, готовая им в этом помочь, – отрасль,
которая только и ждет, чтобы предложить им книги, коучинг, обучение и консультации. Но у
нее нет волшебной палочки, и люди рано или поздно это неизбежно понимают. И тогда для
«верных рецептов» наступает час расплаты.
Сейчас, на момент написания этих строк, в моде критиковать как Lean, так и Agile. Я не
сомневаюсь, что многие люди и команды в той или иной мере разочарованы результатами при-
менения этих методологий. Мне понятны причины их разочарования. Тем не менее, по моему
убеждению, ценности и принципы Lean и Agile пришли к нам надолго. Не столько их конкрет-
ные проявления, которые сегодня применяют многие команды, сколько принципы, лежащие в
их основе. Я сказал бы, что обе методологии представляют собой значительный прогресс, и
мне очень не хотелось бы стать свидетелем отступления на этих двух фронтах.
Но, как я уже сказал, их тоже нельзя считать волшебными средствами, и, как и в случае с
любым инструментом, нужно подходить к их использованию с умом. Множество команд утвер-
ждают, что придерживаются принципов Lean, а сами месяцами работают над тем, что назы-
вают «минимально жизнеспособным продуктом» (minimum viable product, MVP). На самом
деле они не знают, что у них получилось и будет ли это продаваться, до тех пор, пока не потра-
тят массу времени и денег. Вряд ли такая стратегия в духе Lean. Или же они бросаются в дру-
гую крайность: считают, что должны тестировать и перепроверять каждую мелочь, и, соответ-
ственно, не слишком быстро продвигаются вперед.
Что же касается Agile, то выше я уже говорил, что использование этих методов на прак-
тике большинством компаний – разработчиков высокотехнологичных продуктов не имеет
отношения к гибкости.
Лучшие известные мне продуктовые команды уже отказались от таких подходов; они
руководствуются принципами Lean и Agile, но гораздо выше поднимают планку своих целей
и способов работы. Эти команды могут по-разному формулировать проблемы, иногда их тер-
минология несколько различается, но в целом все они придерживаются трех принципов:
1. Риски нужно учитывать в самом начале, а не в конце работы над идеей или
продуктом. В лучших современных командах стараются максимально избавиться от рисков до
принятия решения о начале работы. Речь идет о риске ценности (будут ли люди покупать это),
риске юзабилити (удобства использования) (смогут ли пользователи понять, как это работает),
риске реализуемости (осуществимости) (смогут ли инженеры создать то, что нужно, с уче-
том времени, навыков и технологий, имеющихся в распоряжении) и риске бизнес-жизнеспо-
собности (будет ли это решение полезным для разных аспектов бизнеса: продаж, маркетинга,
финансов, юридических вопросов и так далее).
2. Продукты определяются и разрабатываются совместно, в сотрудничестве, а
не последовательно. Наилучшие команды вышли за рамки старой модели, в которой мене-
джер продукта выясняет и определяет технические условия, дизайнер-проектировщик раз-
рабатывает решение, обеспечивающее их выполнение, а затем инженеры-программисты осу-
ществляют их на практике – и каждому приходится считаться с ограничениями и учитывать
решения тех, кто шел в этом процессе до них. В сильных командах все трудятся плечом к
плечу, обмениваясь идеями и во всем помогая друг другу, чтобы придумать технологические
решения, которые полюбят потребители и которые принесут реальную выгоду бизнесу.
3. И наконец, главное – решить проблему, а не имплементировать новые функ-
ции. Как мы уже говорили, традиционные дорожные карты продуктов нацелены прежде всего
24
М. Каган. «Вдохновленные»
на процесс, но сильные команды знают, что их цель – не только и не столько внедрение того
или иного решения. Они обязаны гарантировать, что оно позволит устранить фундаменталь-
ную проблему. Иными словами, они нацелены на реальные бизнес-результаты.
25
М. Каган. «Вдохновленные»
Глава 8. Ключевые идеи
В этой книге я часто ссылаюсь на понятия, которые можно считать фундаментом совре-
менной работы над продуктом. И мне хотелось бы кратко объяснить их, прежде чем продол-
жать обсуждение.
ПРОДУКТ В ЦЕЛОМ
Термин продукт я использую в довольно широком смысле. Помните, я сразу акценти-
ровал ваше внимание на том, что в книге речь идет исключительно о высокотехнологичных
продуктах? Но в общем я имею в виду всеобъемлющее, максимально комплексное определе-
ние этого понятия.
Понятие продукта, безусловно, включает функциональность – функции и характери-
стики. Но сюда относятся и технологии,
26
М. Каган. «Вдохновленные»
Конец ознакомительного фрагмента.
Текст предоставлен ООО «ЛитРес».
Прочитайте эту книгу целиком, купив полную легальную версию на ЛитРес.
Безопасно оплатить книгу можно банковской картой Visa, MasterCard, Maestro, со счета
мобильного телефона, с платежного терминала, в салоне МТС или Связной, через PayPal,
WebMoney, Яндекс.Деньги, QIWI Кошелек, бонусными картами или другим удобным Вам спо-
собом.
27