Kitobni o'qish: «Карьера продакт-менеджера. Все что нужно знать для успешной работы в технологической компании»

Джеймсу – я люблю тебя бесконечно.

Джеки

Дэвису, Тобину и миллиардам их вопросов.

Гейл

Gayle Laakmann McDowell

Jackie Bavaro

Cracking the PM Career: The Skills, Frameworks, and Practices to Become a Great Product Manager

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

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

В книге возможны упоминания организаций, деятельность которых запрещена на территории Российской Федерации, таких как Meta Platforms Inc., Facebook, Instagram и др.

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

Переводчик О. Миронова

© СareerCup

© Перевод на русский язык ООО «Прогресс книга», 2023

© Издание на русском языке, оформление ООО «Прогресс книга», 2023

© Серия «Библиотека программиста», 2023

© ООО Издательство "Питер", 2023

Часть 1
Предисловие от Мариссы Майер

Глава 0
Предисловие от Мариссы Майер

Продакт-менеджмент, или управление продуктом, – один из главных и основополагающих процессов в современных технологических компаниях. Но по иронии судьбы роль продакт-менеджера (PM)¹ остается самой непонятной. Какие у него обязанности? Чем измеряется успех его работы? Какими навыками он непременно должен обладать? Как проходит собеседование на эту должность? Как продвинуться по карьерной лестнице? Гейл Макдауэлл (Gayle McDowell) и Джеки Баваро (Jackie Bavaro) проделали отличную работу и в своей книге «Карьера продакт-менеджера» подробно описали, в чем заключается роль PM, какие к нему предъявляются требования, с чего начинается его карьера и что делать, чтобы преуспеть в этой должности.

В 1999 году я стала одним из первых сотрудников Google и проработала там 13 лет. За это время компания выросла и серьезно видоизменилась, и в 2002 году мы с коллегами запустили направление продакт-менеджмента. В общей сложности я была PM и руководителем более десяти лет. Исходя из личного опыта, могу сказать, что продакт-менеджмент – это интересное, многогранное и сложное направление. Постоянно происходит что-то новое, все продукты уникальны, каждый PM по-своему подходит к задачам и вносит нечто свое. Кроме того, в разных компаниях роль PM существенно варьируется.

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

Когда я запускала в Google программу обучения младших продакт-менеджеров – Associate Product Manager (APM) program, – основная идея была в том, чтобы пригласить в компанию выпускников колледжей и вырастить из них прекрасных PM с учетом специфики Google. Для этого мы должны были определить самые важные навыки, необходимые для данной роли, и понять, какая поддержка требуется тем, кто их осваивает. В книге «Карьера продакт-менеджера» представлен длинный список качеств, которыми должен обладать PM: умение общаться и слушать других, способность к организации процессов и расстановке приоритетов, знание пользователей и рынка, эмпатия и многое другое.

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

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

МАРИССА МАЙЕР (Marissa Mayer) – соучредитель и CEO в Sunshine, стартапе в области потребительских технологий, созданном для упрощения повседневных рутинных задач. С 2012 по 2017-й занимала пост генерального директора и президента Yahoo. За время работы в Yahoo полностью изменила культуру компании, увеличила количество пользователей до миллиарда, наняла более 5000 человек и провела около 50 сделок по приобретению активов.

До Yahoo Марисса работала в Google, где стала не только одним из первых сотрудников, но и первой женщиной-инженером. Участвовала в создании корпоративной структуры по управлению продуктом. Будучи вице-президентом по поисковым продуктам и пользовательскому опыту, она отвечала за продакт-менеджмент для Search, Maps, News и других сервисов Google. Она также основала и возглавила программу Associate Product Manager от Google. Эта престижная программа ротации кадров, в рамках которой компания нанимает молодых выпускников колледжей и готовит их в качестве PM, стала первой подобной инициативой в отрасли.

Часть 2
Роль продакт-менеджера

Глава 1
Знакомство с профессией

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

Позвольте мне объяснить.

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

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

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

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

Однако одной моей веры оказалось недостаточно, ведь я не могла заставить всех делать то, что мне хочется.

Я много раз говорила своим подопечным, что PM не может просто отдавать приказы. Он должен разработать концепцию, собрать данные, взвесить риски и мотивировать людей следовать общей идее, цели или задаче.

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

Надежда, которую зажигает эта книга

У хорошего PM есть цели. Есть они и у нашей книги (а это тоже продукт). Вот эти цели.

Наша цель – создать руководство, которого у нас раньше никогда не было.

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

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

Наша цель – создать руководство, которого никогда не было у наших учеников.

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

За восемь лет число сотрудников Asana превысило 500 человек, я стала руководителем команды из 20 PM и вела roadmap³ продукта. Я запустила программу APM от Asana и стремилась все делать так же правильно, как делали мои менторы, и даже круче (и при этом не допускать их ошибок).

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

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

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

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

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

О мифических существах

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

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

Как пользоваться книгой

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

В книге Андерса Эрикссона (Anders Ericsson) и Роберта Пула (Robert Pool) «Peak: Secrets from the New Science of Expertise»⁴ авторы исследуют вопрос о том, как люди развивают свой потенциал и достигают высокого уровня мастерства. Их главный вывод – опыт человека зависит от качества его мысленных представлений. Например, когда гроссмейстер смотрит на шахматную доску, он видит не разбросанные по ней фигуры, а целиком всю игру, в которой белые сыграли ферзевый гамбит, а черные от него уклонились.

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

С опытом в ответ на жалобу инженера по поводу технического долга⁵ вы скажете: «Так это же классический конфликт roadmap, вызванный приоритизацией несопоставимых задач в одном ранжированном списке, и его легко решить, создав roadmap по принципу сбалансированного портфеля»⁶. Это не совсем похоже на «уклонение от ферзевого гамбита», но тоже сойдет.

НАВЫКИ PM

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

В этой книге мы сгруппировали навыки, необходимые успешному лидеру по продукту, по пяти категориям:

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

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

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

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

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

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

Для каждого навыка мы выделили:

• Обязанности: то, что вы должны делать.

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

• Концепции и фреймворки: мысленные представления, инструменты и справочные материалы. Этот раздел дается первым в том случае, если данная информация необходима для понимания обязанностей.

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

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

ПРОФЕССИОНАЛЬНЫЕ НАВЫКИ

Для успешной карьеры недостаточно быть отличным PM и уметь запускать классные продукты.

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

Мы рассмотрим следующие темы:

• Карьерная лестница PM.

• Как получить повышение.

• Постановка карьерных целей.

• Работа с руководителем.

• Оптимальный цикл перформанс-ревью.

• Нетворкинг.

• Возможности карьерного роста за пределами продакт-менеджмента.

• Вопросы и ответы от успешных лидеров по продукту.

Карьерная лестница PM

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

Почему?

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

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

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

В главе 32 «Карьерная лестница» (с. 337) мы подробно описали, что представляет собой каждый уровень и как его достичь. Мы охватили все позиции от APM до руководителя по продукту и описали типичный для каждого уровня объем работ, степень самостоятельности и влияния.

Если у вас мало времени…

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

Я НОВИЧОК В УПРАВЛЕНИИ ПРОДУКТОМ

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

• Начните с главы 2 «Роль продакт-менеджера» (с. 22) – изучите основы жизненного цикла продукта и то, чем занимается PM на каждом этапе.

• Прочтите главу 3 «Первые 90 дней» (с. 31) – сосредоточьтесь на том, как проводить вводные совещания. Роль PM в разных командах немного отличается, поэтому важно уметь строить разговор так, чтобы узнать, чего от вас ждут коллеги.

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

Я НЕ МОГУ ПОЛУЧИТЬ ПОВЫШЕНИЕ

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

• Начните с главы 32 «Карьерная лестница» (с. 337), узнайте, чем один уровень должности отличается от другого, и получите конкретные советы о том, как добиться повышения.

• Не пропустите главу 34 «Навыки для карьерного роста» (с. 418).

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

Я ЛИДЕР ПО ПРОДУКТУ УРОВНЯ СЕНЬОР

Основы можете пропустить – для вас есть информация поважнее.

• Пробегитесь по главе 32 «Карьерная лестница» (с. 377), чтобы получить представление о том, как меняются роли на верхних уровнях продакт-менеджмента.

• Изучите обязанности и точки роста для каждого навыка PM, отмеченного знаком . Стратегические навыки (с. 193) становятся особенно важными по мере вашего продвижения.

• Прочтите часть 7 «Навыки управления людьми» (с. 313) – это поможет вам в вопросах оптимизации операционной деятельности.

Я ХОЧУ РАЗВИТЬ СВОИ НАВЫКИ В ОБЛАСТИ ПРОДАКТ-МЕНЕДЖМЕНТА

Сосредоточьтесь на областях, в которых вы хотите совершенствоваться.

• Изучите раздел «Практики роста» для каждого навыка PM.

• Проверьте, вся ли информация из разделов «Обязанности» и «Концепции и фреймворки» вам известна.

• Загляните в раздел «Обучение на основе обратной связи» (с. 426), чтобы научиться извлекать максимальную пользу из замечаний и комментариев.

Я ХОЧУ ПОЛУЧИТЬ ДОЛЖНОСТЬ PM

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

• Изучите основные навыки в разделах «Навыки работы с продуктом» (с. 43), «Навыки реализации» (с. 131), «Стратегические навыки» (с. 193) и «Лидерские качества» (с. 242).

• Ознакомьтесь с главой 49 «Как получить работу PM» (с. 531), где обсуждаются вопросы на собеседовании.

• И прочтите нашу первую книгу «Cracking the PM Interview: How to Land a Product Manager Job in Technology»⁸, в которой основное внимание уделяется подготовке к собеседованию.

Приятного чтения!

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

Не стесняйтесь, пишите нам по адресу gayleandjackie@careercup.com и следите за нами в интернете:

• twitter.com/jackiebo

• facebook.com/jackie.bavaro

• https://medium.com/@jackiebo

• twitter.com/gayle

• facebook.com/gayle

• https://medium.com/@gayle

Глава 2
Роль продакт-менеджера

Если спросить у пятерых человек, кто такой PM, можно получить шесть разных ответов.

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

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

Вот наш ответ на вопрос, кто такой продакт-менеджер:

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

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

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

Продуктовая триада

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

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

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

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

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

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

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

Жизненный цикл продукта

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

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

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

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

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

ИССЛЕДОВАНИЕ ПРОДУКТА

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

Что же пошло не так?

Вы пропустили этап исследования продукта (product discovery) и восприняли распоряжение вашего VP слишком буквально. Нужно было копнуть глубже и разобраться, какая проблема его заботила изначально.

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

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

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

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

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

Видеокассеты Betamax и VHS

К стандартным задачам на этапе исследования продукта относятся:

• Изучение запросов на добавление новых функций.

• Анализ показателей воронки продаж.

• Опрос клиентов.

• Тестирование идей.

• Обсуждение долгосрочной стратегии.

• Изучение конкурентов.

• Анализ рынка.

• Проведение мозговых штурмов.

• Запуск дизайн-спринтов (пятидневных сессий, во время которых прорабатываются идеи и тестируются прототипы продукта. – Примеч. ред.)¹².

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

ОПРЕДЕЛЕНИЕ ПРОДУКТА

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

Что пошло не так?

А дело в том, что вы внесли недостаточно ясности на этапе определения (define phase). Вы не сопоставили масштабы проблемы и то, как должен выглядеть желаемый результат работы. Возможно, вы предположили, что в первом релизе вы решите только небольшую часть задач, но не объяснили это вашему дизайнеру.

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

К стандартным задачам на этапе определения продукта относятся:

• Приоритизация задач, поставленных на этапе исследования продукта.

• Выбор целевого клиента.

• Составление пути клиента (customer journey).

• Определение показателей успеха.

• Создание ви́дения продукта.

• Составление предварительной дорожной карты (roadmap).

• Определение первоначальных сроков.

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

ДИЗАЙН ПРОДУКТА

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

В данном сценарии вы не рассмотрели разные варианты решений и не протестировали бумажные прототипы на этапе дизайна (design phase).

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

К стандартным задачам на этапе дизайна относятся:

• Написание спецификации.

• Определение функционала.

• Согласование зависимостей с другими командами.

• Вайтбординг¹³ с дизайнерами и инженерами.

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

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

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

РАЗРАБОТКА ПРОДУКТА

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

К стандартным задачам на этапе разработки относятся:

• Составление тикетов (запросов) на разработку.

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

• Расстановка приоритетов по исправлению багов.

• Регулярная помощь коллегам по команде в затруднительных ситуациях.

• Практическая проверка функций по мере их создания и предоставление обратной связи.

• Предоставление актуальной информации стейкхолдерам и руководству.

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

ЗАПУСК ПРОДУКТА

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

Многое на этапе запуска может пойти не так. И именно PM должен проследить за тем, чтобы все прошло хорошо. Ведь вы не хотите в день запуска обнаружить, что продукт полон багов и выводит из строя серверы один за другим. Вряд ли службы продаж и поддержки будут рады изменениям, которые они не смогут объяснить клиентам. И маловероятно, что вам понравится перспектива отправки тысячам клиентов писем с просьбой загрузить приложение, которое еще не доступно в AppStore (Как? Оно же там было!).

К стандартным задачам на этапе запуска относятся:

• Выполнение этапа валидации: догфудинг¹⁴, бета-тестирование, A/B-тесты и тесты на устойчивость.

• Организация процесса обеспечения качества (quality assurance, QA).

• Работа с партнерами и проверка их готовности к запуску продукта (в том числе наличия всех разрешений).

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

• Обучение менеджеров по продажам и сотрудников службы поддержки.

• Вечеринка с командой в честь успешного запуска.

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

АНАЛИЗ ПРОДУКТА

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

К стандартным задачам на этапе анализа (debrief) относятся:

• Ретроспективная оценка того, что было сделано правильно, а что нет.

• Анализ метрик запуска.

• Изучение отзывов клиентов о запуске.

• Определение очередности «мер быстрого реагирования» на основе обратной связи от клиентов.

• Оценка успешности запуска.

• Информирование всех сотрудников компании о результатах запуска.

• Составление плана дальнейших действий (следующей итерации).

Время и энергия, которые вы потратите на «разбор полетов», помогут вам вырасти как PM и укрепить свой авторитет.

ДРУГИЕ ВИДЫ ДЕЯТЕЛЬНОСТИ

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

С этой точки зрения перед PM встают следующие задачи:

• Подбор кандидатов на вакансии и проведение собеседований.

• Менторство других PM.

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

• Участие в таких корпоративных процессах, как постановка целей и подготовка текущих отчетов.

• Обзор спецификаций других PM.

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

• Презентация продуктов важным клиентам.

• Регулярные встречи с клиентами.

• Обмен полученным опытом.

• Участие в процессах в масштабах всей компании.

• Выступления на общих собраниях.

• Участие в обсуждениях стратегии.

• Участие в отраслевых конференциях.

• Отслеживание передового опыта в области продакт-менеджмента.

Как стать хорошим продакт-менеджером

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

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

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

На то, чтобы стать хорошим PM, могут уйти годы практики и опыта.

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

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

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

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

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

Вам придется взять на себя больше стратегических обязанностей. Это похоже на выбор между яблоками и апельсинами¹⁶ при прогнозировании развития фруктового рынка. Вы будете браться за несколько проектов одновременно, что вынудит вас идти на серьезные компромиссы (при этом угодить всем заинтересованным сторонам абсолютно невозможно). Все будут требовать от вас roadmap и стратегии. А когда вашу команду попросят взяться за какую-нибудь абсурдно амбициозную задачу, вы зададитесь единственным вопросом: «Где найти для всего этого время?»

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

Примерно тогда вы и почувствуете себя хорошим PM.

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

Глава 3
Первые 90 дней

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

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

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

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

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

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

Она подошла к каждому из коллег и извинилась за то, что торопила события: «Приятно познакомиться. Мы можем начать заново? Расскажите мне немного о себе». Она поговорила со своей командой и узнала, чего от нее ждут. Она встретилась со своим руководителем и составила подробный список того, что нужно сделать, когда и с каким результатом. Затем она забила свой график встречами с клиентами, а в свободное время изучала документы по стратегии и панели мониторинга работы над проектом (дашборды).

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

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

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

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

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

• Узнайте все о компании, вашей команде и принятых культурных нормах.

• Изучите информацию о продукте и о заказчиках.

• Выясните, чего от вас ожидают.

• Согласуйте свои планы и сроки онбординга (введения в должность) с руководителем и товарищами по команде.

• Сформируйте прочные отношения с коллегами.

• Заслужите доверие.

• Одержите несколько «быстрых побед».

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

ПРЕИМУЩЕСТВА НОВИЧКА

У новичка в команде есть огромные преимущества.

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

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

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

ПЛАН ОНБОРДИНГА НА 30/60/90 ДНЕЙ

В первую неделю или две целесообразно составить план онбординга на 90 дней и обсудить его со своим руководителем.

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

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

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

• Другие PM внутри команды.

• Менеджеры на уровне вашего руководителя.

• Ключевые стейкхолдеры.

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

• Все, с кем полезно познакомиться.

Ниже представлен примерный план онбординга.

Первые 30 дней

HR и знакомство с компанией

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

• Изучить материалы о стратегии и ценностях компании.

PM и команда разработчиков

• Разобраться в процессах.

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

• Узнать о текущих планах и потребностях команды.

• Наблюдать за работой действующего PM.

Наблюдение за действиями своего ментора

• Сидеть с ним рядом.

• Присутствовать на его встречах.

• Следить за тем, как он ведет общение.

Знакомство с коллегами

• Разослать приветственное сообщение.

• Провести вводные встречи один на один.

• Проходить ежедневные пятиминутки с ментором.

• Еженедельно встречаться один на один с руководителем.

Повышение экспертности по продукту и работе с клиентами

• Участвовать в созвонах отдела продаж, выездных встречах и исследовательских сессиях.

• Читать или отвечать на обращения пользователей в службу поддержки.

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

Планируемый результат

• Выполнить стартовый проект: запустить A/B-тест к третьей неделе.

Первые 60 дней

Команда разработчиков

• Взять на себя роль основного PM под контролем предыдущего.

Знакомство с коллегами

• Продолжать встречаться с коллегами.

Повышение экспертности по продукту и работе с клиентами

• Продолжать встречаться с клиентами.

Планируемый результат

• Проследить за намеченным на 10 сентября запуском.

• Создать новый квартальный roadmap для команды к 12 сентября.

Первые 90 дней

Команда разработчиков

• Осуществлять руководство командой без контроля со стороны предыдущего PM.

Повышение экспертности по продукту и работе с клиентами

• Продолжать встречаться с клиентами.

Планируемый результат

• Достичь поставленных перед командой OKR.

ВВОДНЫЕ СОВЕЩАНИЯ

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

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

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

Непосредственный руководитель

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

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

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

Примерный список вопросов руководителю:

• Каков ваш стиль работы?

• Какой вы видите нашу совместную работу?

• Как вы предпочитаете общаться: лично или письменно?

• Что вас больше всего раздражает? Что вы любите?

• Каковы ваши главные цели на этот год?

• Как я могу помочь в достижении этих целей?

• Есть ли что-нибудь еще, что я должен о вас знать?

Вопросы о роли и ожиданиях:

• Какой вы видите мою роль?

• Что значит быть хорошим PM?

• Как для вас выглядит успех?

• Чем, по-вашему, я должен заняться в свои первые 90 дней в должности?

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

• Какой проект я должен взять в работу в первую очередь?

• В каких сферах я могу проявить инициативу, а где должен следовать текущему плану?

• Каких подводных камней мне стоит избегать?

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

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

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

• Есть ли у вас какие-то другие ожидания?

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

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

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

Ментор

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

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

В дополнение к вопросам, описанным выше в разделе «Непосредственный руководитель», вы также можете спросить:

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

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

• Следуют ли сотрудники официальным процедурам? Если они нарушают правила, то когда и почему?

• Действуют ли какие-то негласные правила или культурные нормы?

• Кто является хорошим примером для подражания?

• Состоите ли вы в какой-нибудь группе по интересам с другими коллегами? Можете порекомендовать мне какую-то из них?

Высшее руководство

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

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

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

Вот несколько «безопасных» вопросов для первой встречи:

• Что вы думаете о целях компании?

• Есть ли что-то, что не дает вам уснуть?

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

• На ваш взгляд, есть ли какие-то конкретные задачи, которые я должен выполнять на данной позиции?

• От чего зависит успех PM в этой компании?

Коллеги по команде

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

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

Знакомство:

• Расскажите о себе. (Вы живете рядом с офисом? Занимаетесь чем-то интересным вне работы? Как предпочитаете развлекаться? Вы любите путешествовать? И т. д.)

• Как вы оказались в этой компании?

• Над чем вы сейчас работаете? Расскажите о своих любимых прошлых проектах. Над чем бы вы хотели поработать?

• Каковы ваши главные цели на этот год?

Согласование ожиданий:

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

• Что вам нравилось и не нравилось в работе с тем, кто занимал мою позицию раньше? Что вас больше всего раздражает?

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

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

• Хотели бы вы что-то изменить в моем плане на 30/60/90 дней?

Возможности:

• Что вы думаете о команде? Как продвигаются дела?

• Хотели бы вы что-то изменить в работе команды?

• Что я могу сделать в первую очередь, чтобы помочь команде?

Все остальные

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

Общие вопросы:

• Расскажите о себе.

• Над чем вы работаете? Расскажите о своих любимых прошлых проектах. Над чем бы вы хотели поработать?

• Каковы ваши главные цели на этот год?

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

• Могу ли я чем-то помочь вам прямо сейчас?

ЧТО НУЖНО СДЕЛАТЬ

Воспользуйтесь преимуществом новичка и посмотрите на вещи свежим взглядом

Как сказал Брайан Джоуэрс (Bryan Jowers), VP по продукту:

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

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

Станьте экспертом по своему продукту и его пользователям

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

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

Заслужите доверие

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

Добейтесь быстрого успеха с самого начала

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

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

Найдите способ почувствовать себя частью компании

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

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

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

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

ЧЕГО ДЕЛАТЬ НЕ СТОИТ

Не стоит с самого начала говорить людям, что они все делают неправильно

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

Не давайте категоричных отказов – скажите: «Да, но…»

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

Не пытайтесь сразу что-то серьезно менять

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

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

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

Основные выводы

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

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

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

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

Часть 3
Навыки работы с продуктом

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

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

• Из главы «Анализ данных» (с. 60) вы узнаете, как проводить обзор данных, анализировать их и использовать для принятия более эффективных решений. Мы расскажем о том, как работать с метриками компании, а также рассмотрим A/B-тестирование и способы работы со статистикой.

• Глава «Аналитический подход к решению задач» (с. 75) описывает главные принципы принятия эффективных решений. Мы разберем такую тему, как системное мышление, и изучим методы устранения сложных проблем.

• Информация, изложенная в главе «Продукт и навыки дизайна» (с. 90), будет полезна для развития продуктового мышления и способности влиять на решения о продукте. Вы узнаете о создании прототипов и мозговых штурмах, а также о том, как правильно расставлять приоритеты.

• Прочтя главу «Технические навыки» (с. 109), вы научитесь взаимодействовать с инженерами и лучше оценивать затраты на разработку. Здесь же дается экспресс-курс по технологиям – API, развертывание, SQL, алгоритмы и многое другое.

• Содержание главы «Документация по продукту» (с. 123) полностью соответствует ее названию. Из нее вы узнаете, какие методы составления и использования продуктовых спецификаций являются самыми эффективными.

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

Глава 4
Понимание потребностей пользователя

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

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

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

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

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

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

Обязанности

РАЗГОВАРИВАТЬ С ДЕЙСТВУЮЩИМИ И ПОТЕНЦИАЛЬНЫМИ ПОЛЬЗОВАТЕЛЯМИ

Пользователи – это люди. Что мы делаем, чтобы узнать человека получше? Мы с ним разговариваем!

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

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

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

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

Копайте глубже

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

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

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

Как оказалось, люди не всегда знают, чего они хотят. Они чувствуют «боль» и превращают ее в конкретное решение. И отчасти ваша задача состоит в том, чтобы это решение трансформировать обратно, то есть выслушать запрос, а затем выявить лежащую в его основе проблему. Она-то и становится в итоге «jobs to be done» – «работой, которую нужно выполнить» (с. 49)¹⁹.

Чем глубже PM вникает в проблему, тем ему проще понять клиента и направить команду в нужном направлении в поисках эффективного решения.

Чтобы тщательнее проработать тему, попробуйте задать пользователю такие вопросы:

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

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

• С какими трудностями вы сталкиваетесь при выполнении этого действия?

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

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

• Вот как я понимаю вашу проблему: […]. Я ничего не упустил?

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

ПРОВЕРЯТЬ СВОИ ПРЕДПОЛОЖЕНИЯ

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

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

Луи Лека (Louis Lecat), руководитель по продукту в компании Algolia, рассказал, как проверка его предположений с помощью прототипа серьезно повлияла на конечное решение:

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

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

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

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

Предлагаем учесть следующие моменты при проверке предположений:

• Почему пользователи предпочитают именно ваш продукт.

• Какой функционал обязателен, а какой – нет.

• Сколько времени и усилий пользователи тратят на изучение продукта.

• Какова серьезность «мелких» недоработок юзабилити.

• Насколько просто найти ту или иную функцию.

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

О способах проверки предположений читайте в разделе «Исследование пользователей» (с. 53).

ПЛАНИРОВАТЬ СТРАТЕГИЧЕСКИЕ ИССЛЕДОВАНИЯ ПОЛЬЗОВАТЕЛЕЙ ДЛЯ ПОИСКА НОВЫХ ВОЗМОЖНОСТЕЙ

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

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

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

СОЗДАВАТЬ КУЛЬТУРУ, ОРИЕНТИРОВАННУЮ НА ПОЛЬЗОВАТЕЛЯ

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

В компании Twilio обнаружили, что стажировка в службе поддержки клиентов значительно повышает эмпатию сотрудников. Джейсон Насси (Jason Nassi) написал по этому поводу:²⁰

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

Вот несколько способов сделать поведение команды более ориентированным на пользователя:

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

• Ведите рейтинг среди коллег по количеству визитов к клиентам.

• Каждую неделю устраивайте для команды встречи с клиентами.

• Введите в повестку собраний команды регулярный обмен новой информацией о клиентах.

• Добавьте раздел «Информация о клиентах» в шаблон спецификации.

• Спрашивайте о потребностях клиента в ходе обзора продукта.

• Будьте образцом для подражания – сами проводите встречи с клиентами и делитесь полученными знаниями.

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

Практики роста

МЫСЛИТЕ, КАК НОВИЧОК

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

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

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

УСТАНОВИТЕ СВЯЗЬ МЕЖДУ ВЫБОРОМ ПРОДУКТА И ЗНАНИЕМ ПОТРЕБНОСТЕЙ КЛИЕНТА

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

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

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

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

РАЗВИВАЙТЕ ИНТУИЦИЮ

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

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

РАССТАВЛЯЙТЕ ПРИОРИТЕТЫ

Нужно ли устранять все обнаруженные вами проблемы с юзабилити продукта? Это сложный вопрос. И ответ – как это часто бывает в жизни (и в управлении продуктами) – таков: все зависит от ситуации.

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

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

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

РАСПРОСТРАНЯЙТЕ ЗНАНИЯ О ПОТРЕБНОСТЯХ КЛИЕНТОВ

Отличить опытного PM от новичка можно по тому, как он раскрывает актуальную информацию о клиентах.

Первый обычно действует так:

• В ходе совещаний приводит примеры из жизни.

• Указывает другим PM на интересные пользовательские исследования.

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

• Предоставляет руководству полученные сведения и их стратегический анализ.

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

ДОКАПЫВАЙТЕСЬ ДО СУТИ, КОТОРАЯ ПОМОЖЕТ ВСКРЫТЬ ПРОБЛЕМУ

ШУТКА О ГЕНЕРАТОРЕ

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

Вызвали ремонтника. Тот прислушался к тому, как работает установка, и поставил крестик мелом на одной из деталей. «Проблема здесь», – сказал он. Инженеры осмотрели указанное место, поняли, в чем дело, и устранили неполадку. Когда ремонтник выставил счет на $10 000, компания отказалась платить и запросила его расшифровку. Ремонтник с радостью выполнил просьбу и ответил так:

Мел: $1.

Знание, где поставить крестик: $9 999.

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

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

Концепции и фреймворки

РАБОТА, КОТОРУЮ НУЖНО СДЕЛАТЬ (JTBD)

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

Идея, которую популяризовал Клей Кристенсен (Clay Christensen), одновременно проста и сложна. Он объясняет ее так:

«Люди не просто покупают товары или услуги, они их “нанимают”, чтобы успешно решить тот или иной вопрос. Чаще всего они совершают покупки, чтобы решить проблему, с которой они столкнулись».

Рассмотрим, к примеру, покупку музыкального приложения. Какую «работу» хочет выполнить пользователь?

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

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

Методология «Работа, которую нужно сделать» (Jobs To Be Done, JTBD) используется для изучения мотивации и поведения клиентов²¹.

Чтобы прописать сценарий использования продукта по методу JTBD, можно воспользоваться следующим шаблоном:

Когда я <ситуация>, я хочу <мотивация>, чтобы я смог <ожидаемый результат>.

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

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

ПУТЬ КЛИЕНТА

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

Рассмотрим упрощенный пример пути клиента для приложения Netflix.

• Осведомленность: я узнал (возможно, много лет назад), что Netflix существует.

• Рассмотрение: я выяснил, что на Netflix есть мой любимый сериал. Я подумываю о том, чтобы оформить ради этого подписку. Но стоит ли оно того? Может, лучше просто купить фильм на Amazon?

• Покупка: я решил оплатить подписку на Netflix.

• Удержание: продолжаю платить за Netflix (потому что он мне нравится… или потому, что я забыл отменить подписку).

• Лояльность: на вопросы друзей я отвечаю, что любимый сериал смотрю на Netflix. И добавляю, что, похоже, у них хороший выбор фильмов и сериалов.

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

РЕКОМЕНДАЦИИ ПО ЮЗАБИЛИТИ ПРОДУКТА

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

Золотым стандартом в области удобства использования программных продуктов стали эвристические правила, созданные компанией Nielsen Norman Group.

10 основных принципов юзабилити²²

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

1. Видимость статуса системы

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

2. Соответствие системы и реальности

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

3. Пользовательский контроль и свобода действий

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

4. Последовательность и соответствие стандартам

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

5. Предотвращение ошибок

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

6. Распознавание вместо запоминания

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

7. Гибкость и эффективность использования

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

8. Эстетичность и минимализм дизайна

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

9. Распознавание, диагностирование и исправление ошибок

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

10. Справка и документация

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

Помимо перечисленных выше правил, существует несколько общих рекомендаций, которые следует запомнить:

• Ограниченное внимание: в жизни пользователи обращают на пользовательский интерфейс (user interface, UI) намного меньше внимания, чем вам кажется. Люди подсознательно игнорируют большие кричащие баннеры и любые другие элементы, похожие на рекламу. Они не читают длинные абзацы и даже предложения. В любой момент их могут прервать или отвлечь. Если им не будет четко понятна последовательность действий, они даже не попытаются в ней разобраться.

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

• Доступность: около 4 % населения страдают той или иной степенью дальтонизма, а около 2 % населения имеют другие нарушения зрения²³. Тестирование продукта на совместимость с программами считывания с экрана, предназначенными для слабовидящих и людей с цветовой слепотой, позволит избежать потери некоторых пользователей. Важные объекты UI желательно не только выделить цветом или обозначить изображением, но и снабдить альтернативным текстом. В придачу ко всему от так называемого универсального дизайна, который применяют, чтобы сделать продукт доступным для людей с ограниченными возможностями, выигрывают и обычные пользователи²⁴.

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

Исследование пользователей

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

Большинство исследований (за исключением некоторых опросов) направлены на изучение качественных, а не количественных показателей²⁵. Они помогают получить ответ на такие вопросы, как «Какие критерии учитывают клиенты при принятии решения о покупке?», но совершенно не подходят для вопросов типа «Каков процент людей, которых волнует цена продукта?».

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

ТИПЫ ИССЛЕДОВАНИЙ ПОЛЬЗОВАТЕЛЕЙ

Существует бесчисленное количество видов пользовательских исследований. Вот самые распространенные из них²⁶.

Полевые исследования

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

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

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

Дневниковые исследования

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

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

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

Интервью

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

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

• Что важно помнить: на интервью люди ведут себя нарочито оптимистично (например, отвечают: «Конечно, я бы использовал эту функцию»). Чтобы получить более реальный ответ, просите привести конкретные примеры из прошлого (например, «Расскажите, пожалуйста, когда вы в последний раз создавали дашборд?»).

Опросы

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

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

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

Тестирование концепции и юзабилити продукта

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

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

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

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

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

Совместный дизайн

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

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

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

Сортировка карточек

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

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

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

Бета-версия программы

• Что это: предоставление ограниченному числу пользователей раннего доступа к новым функциям программы в обмен на честный отзыв. Бета-версия позволяет опробовать идеи на реальных пользователях и получить обратную связь до официального запуска продукта.

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

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

Как запустить бета-версию программы

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

Вопрос о соответствии продукта рынку: как сильно вы будете разочарованы, если больше не сможете использовать этот продукт?

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

Как получить обратную связь

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

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

ПОДБОР УЧАСТНИКОВ ПОЛЬЗОВАТЕЛЬСКОГО ИССЛЕДОВАНИЯ

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

Чтобы узнать мнение текущих или потенциальных клиентов, разместите на своем сайте приглашение пройти опрос, используя такие инструменты, как Ethnio или Intercom. Отзывы случайных людей проще всего собирать через специальные сайты (например, UserTesting.com) или поставив стенд в каком-нибудь кафе.

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

КАКИХ ОШИБОК СЛЕДУЕТ ИЗБЕГАТЬ

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

Вы задаете неправильные вопросы

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

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

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

• Если все прошло хорошо: переходим к более точному прототипу.

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

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

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

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

Вы воздействуете на ответы участников

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

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

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

Вы взяли слишком много участников для юзабилити-теста

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

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

Вы не воспринимаете исследователей пользователей как партнеров

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

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

Основные выводы

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

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

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

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

Глава 5
Анализ данных

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

Однако здесь есть подвох, и не один.

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

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

Обязанности

ИЗУЧИТЬ КЛЮЧЕВЫЕ ПОКАЗАТЕЛИ УСПЕХА ВАШЕЙ КОМПАНИИ

Что для вас означает успех? Это интересный вопрос как для отдельно взятого человека, так и для организации. И, как выясняется, компании (и команды) отвечают на него по-разному.

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

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

В вашей компании должен быть дашборд, показывающий все нужные метрики в динамике. Если его нет, создайте его вместе со своей командой! Оптимизировать показатели невероятно сложно, если трудно понять, что они означают (см. «Создать дашборд для своей команды» на с. 61).

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

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

НАУЧИТЬСЯ ПОЛУЧАТЬ ДАННЫЕ САМОСТОЯТЕЛЬНО

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

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

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

СОЗДАТЬ ДАШБОРД ДЛЯ СВОЕЙ КОМАНДЫ

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

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

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

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

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

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

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

• Показывайте средние значения за 7 дней: некоторые продукты отличаются своим непостоянством и могут резко набирать популярность благодаря вирусной публикации или какому-то другому событию. И чтобы лучше разобраться в тенденциях, полезно просмотреть среднее значение за 7 (или 14, 28 и т. д.) дней. Это касается и продуктов, объем использования которых варьируется в зависимости от дня недели.

РЕГУЛЯРНО ПРОВЕРЯТЬ ПОКАЗАТЕЛИ СВОЕЙ КОМАНДЫ

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

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

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

• Превысил ли какой-либо показатель свой порог настолько, что это стоило бы отметить?²⁸

• Прослеживаются ли какие-нибудь долгосрочные тенденции? Можно ли увидеть, какие показатели подтверждают или опровергают продуктовую стратегию?

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

ИЗУЧАТЬ ДАННЫЕ

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

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

РАССМОТРИМ ТАКОЙ СЦЕНАРИЙ

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

Вероятно, существует много ответов на этот вопрос. Я поступила так.

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

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

Я подумала, что те же самые пользователи также периодически искали конкретные рестораны или магазины. Теперь вопрос заключался в следующем: когда они искали конкретные адреса, они совпадали с почтовым индексом или с IP-адресом?

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

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

Проявите любопытство и изучите, какие данные доступны в вашей компании. Это могут быть дашборды Google Analytics, необработанные логи пользователей, отчеты NPS²⁹, журналы поиска – все, к чему у вас есть доступ. Начните с любых вопросов, пришедших вам в голову, независимо от того, связаны ли они непосредственно с вашими проектами или просто с чем-то интересным для вас. Ищите что-то необычное, затем попробуйте разобраться, что это может означать и чем было вызвано. Если вы найдете нечто интересное, обязательно поделитесь этим с другими людьми.

СФОРМИРОВАТЬ КЛЮЧЕВЫЕ ПОКАЗАТЕЛИ УСПЕХА ВАШЕЙ КОМПАНИИ

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

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

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

Смотрите также разделы «Значимые показатели против метрик тщеславия» на с. 66 и «Пиратские метрики» на с. 67.

ОТВЕЧАТЬ ЗА ПРИБЫЛИ И УБЫТКИ

В некоторых компаниях PM-сеньор отчитывается за то, какие прибыли и убытки (P&L) показывает их структурное подразделение. Это означает, что они выходят на другой уровень ответственности, где им приходится работать не только с командой разработчиков, но и с другими группами, например отделом продаж или маркетинга. PM в данной позиции отвечает не только за создание отличного продукта, но и за то, чтобы тот приносил достаточную прибыль и не вызывал лишних затрат.

Если вы отвечаете за P&L, вам приходится вести бюджет своей команды с кем-то из отдела финансов. Бюджет содержит плановые и целевые показатели на год, обычно с разбивкой на кварталы или месяцы. В нем учитывается количество людей, которых вы собираетесь нанять на каждую позицию, затраты на рекламу и другие издержки. Также он включает в себя доход, прогнозируемый на основе дохода предыдущего периода, сезонности, численности персонала отдела продаж, маркетинговых мероприятий и запуска продуктов³⁰.

Может показаться, что правильный прогноз получить невозможно; но, к счастью, он и не требуется. Илай Лернер (Ely Lerner), отвечающий за P&L в Yelp, поделился своей точкой зрения:

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

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

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

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

Анализ движущих факторов может показаться сложным. Но, как сказал Сачин Рекхи (Sachin Rekhi), руководитель по P&L в LinkedIn, такой анализ улучшает продуктовую интуицию и способен сделать из вас хорошего PM:

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

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

Практики роста

ИСПОЛЬЗУЙТЕ БЕНЧМАРКИ ДЛЯ ОСМЫСЛЕНИЯ ДАННЫХ

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

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

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

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

УЧИТЕСЬ ИНТУИТИВНО ПОНИМАТЬ ДАННЫЕ

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

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

ПОВЫШАЙТЕ КАЧЕСТВО ЭКСПЕРИМЕНТОВ

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

Нунду Джанакирам (Nundu Janakiram), директор по продуктам для пассажиров Uber, рассказал о том, почему важно повышать эффективность экспериментов:

«Хорошие PM учатся на ошибках… а лучшие меньше ошибаются.

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

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

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

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

Концепции и фреймворки

ЗНАЧИМЫЕ ПОКАЗАТЕЛИ ПРОТИВ МЕТРИК ТЩЕСЛАВИЯ

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

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

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

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

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

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

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

Как правило, они представляют данные за неделю или месяц (например, удержание клиентов за первую неделю) или дают разбивку значений на одного клиента (например, средний доход на одного пользователя, или ARPU – average revenue per user). Увеличение таких показателей будет с большей долей вероятности отражать реальное улучшение ситуации.

ПИРАТСКИЕ МЕТРИКИ

Один из самых запоминающихся наборов правильных показателей – тот, что Дейв Макклюр (Dave McClure) назвал «пиратскими метриками» (в английском языке первые буквы их названий образуют забавную аббревиатуру AARRR)³². Это показатели жизненного цикла клиента, и называются они «метриками воронки» (некая метафора дырявой воронки, из которой капает вода). Идея в том, что сверху воронки вы помещаете большое количество клиентов, но потом постепенно теряете их на каждом следующем этапе. Те, кто доберется до самого дна воронки и не «утечет», как раз и дадут реальный доход.

• Привлечение (acquisition): новые пользователи продукта, например число подписок или загрузок в месяц.

• Активация (activation): количество довольных пользователей; для каждого продукта оно представлено своим показателем. Например, для Facebook это может быть добавление семи и более друзей. Для SurveyMonkey – получение не менее пяти ответов на рассылку опроса. Как правило, это месячный показатель конверсии, то есть процент новых пользователей, перешедших от знакомства с продуктом к его использованию.

• Удержание (retention): число клиентов, повторно использующих продукт. Отслеживается в виде таких показателей, как количество активных пользователей в день (DAU, daily active users), в месяц (MAU, monthly active users) или их соотношение (DAU/MAU). Также сюда относятся метрики использования, такие как количество минут просмотра видео на YouTube.

• Рекомендации (referral): готовность клиентов советовать продукт другим пользователям. Можно оценивать, например, по количеству отправленных приглашений. Многие компании также отслеживают индекс потребительской лояльности (NPS, net promoter score), рассчитываемый на основе ответов на вопрос: «Какова вероятность, что вы порекомендуете наш продукт?» Этот вопрос показывает, насколько успешным может быть сарафанное радио.

• Доход (revenue): объем дохода. Например, стоимость подписки, приобретение продукта или продажа рекламы. Здесь важно отслеживать пожизненную ценность клиента (lifetime value, LTV), чтобы сравнить ее со стоимостью его привлечения (cost of acquiring a customer, CAC). Существует универсальное правило – соотношение LTV: CAC должно быть не менее 3: 1. Когда действующий клиент отменяет подписку, это называется оттоком.

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

A/B-тестирование и статистика

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

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

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

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

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

ЧТО НУЖНО ЗНАТЬ О СТАТИСТИКЕ

• Принцип, лежащий в основе A/B-тестирования, достаточно прост – сравнить две вещи и выбрать ту, что лучше. Все!

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

Представьте, что вы пытаетесь определить, «честная» ли у вас монетка, то есть дает ли она равную вероятность выпадения орла и решки. После 20 бросков количество орлов равно 60 %. Значит, монета «нечестная»? Трудно сказать. Однако, если вы подбросите монетку 1000 раз и орел выпадет снова в 60 % случаев, вы можете сделать вывод, что монета, вероятно, и правда не совсем «честная».

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

Это касается и A/B-тестов. Проверять варианты А и В нужно так долго, пока не появится уверенность в правильности выбора, но не затягивать их настолько, чтобы нельзя было принять решение или испробовать другие варианты.

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

Чтобы определить статистическую значимость, можно вычислить одну из следующих величин: доверительный интервал (confidence interval) или p-значение (p-value). Обе они помогают понять, является ли результат статистически существенным, но доверительный интервал дает дополнительную информацию о диапазоне возможных значений.

Доверительный интервал

Предположим, что мы хотим узнать средний рост учащихся в школе. Чем больше детей мы измерим, тем ближе наши расчеты будут к фактическому среднему значению. Допустим, мы измерили рост 50 случайных учеников, и с вероятностью в 95 % (стандартное значение, используемое большинством компаний) получили доверительный интервал от 122 до 132 сантиметров. Это значит, что с вероятностью в 95 % фактический средний рост – если бы мы измерили рост всех учеников в школе – составляет от 122 до 132 сантиметров³⁴. Однако все еще существует вероятность в 5 %, что мы ошибаемся, и средний рост выше или ниже этого диапазона.

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

Если эксперимент с вероятностью в 95 % показывает доверительный интервал количества зарегистрированных пользователей в 10–12 %, это означает, что вариант B увеличил количество новых регистраций на 10–12 %. Отлично! Если бы вместо этого он показывал диапазон от –12 до –10 %, это был бы провал.

Часто доверительный интервал охватывает сразу отрицательные и положительные значения, а также ноль, например от –4 до 3 %. Это значит, что нам неизвестно, привело ли изменение продукта к росту или снижению показателей. Поскольку доверительный интервал включает в себя ноль, изменение может дать как отрицательный результат – потерю до 4 %, так и положительный – прирост до 3 %.

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

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

Чем дольше длится эксперимент, тем сильнее уменьшается доверительный интервал (то есть диапазон сокращается, и мы получаем более точную информацию об ожидаемом воздействии изменений). Если к концу эксперимента интервал равен 1–2 %, это означает, что с вероятностью в 95 % тестируемые изменения улучшат показатели на 1–2 %. Это можно считать успехом.

P-значения

Другой вид расчетов, о которых вы могли слышать, это вычисление р-значения. Оно отражает вероятность получения результатов эксперимента при проигрышном или нейтральном изменении метрик. Большинство компаний в качестве порогового значения используют 0,05 (5 %), что соотносится с 95 % доверительной вероятности.

Доверительный интервал и р-значение напрямую связаны. Если р-значение ниже 0,05, нижний предел доверительного интервала при вероятности в 95 % будет выше нуля. Большинство PM предпочитают работать с доверительным интервалом, так как он дает больше информации о наилучшем и наихудшем сценарии событий.

Остерегайтесь p-хакинга

Применять пороговое значение 5 % нужно аккуратно, иначе это вызовет некоторые проблемы.

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

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

Теперь представьте, что мы пытаемся оценить потенциальное воздействие нововведений на десятки функций: чат, профили пользователей, поиск, группы, события, экспорт данных и т. д. Установив возможный порог ошибки в 5 %, мы, скорее всего, увидим воздействие на одну из десятков функций с вероятностью в 95 %³⁵.

Это так называемый p-хакинг (p-hacking) – попытка выудить нужные вам значения и связи из общего объема данных. Если долго мучиться, что-нибудь получится. Просто случайно (см. «P-хакинг на примере комикса xkcd» на с. 73).

Что же делать? Действуйте методично.

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

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

СТАТИСТИКА И ЭКСПЕРИМЕНТЫ

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

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

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

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

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

Основные выводы

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

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

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

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

P-хакинг на примере комикса XKCD

Публикуется с разрешения неизменно потрясающих xkcd (https://xkcd.com/882/).

Глава 6
Аналитический подход к решению задач

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

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

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

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

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

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

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

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

Обязанности

ВЫЯВЛЯТЬ И СТРУКТУРИРОВАТЬ НЕОДНОЗНАЧНЫЕ ПРОБЛЕМЫ

ВНЕСТИ ЯСНОСТЬ

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

Лили Раховин (Lili Rachowin), PM-лид в Asana, взяла на себя ответственность за процесс принятия решений. На обсуждении вопроса она представила таблицу, в которой были собраны все известные факты и цифры, а также некоторые новые данные, которые мы еще не рассматривали. Она утверждала, что, поскольку это был первый перевод, наиболее важным фактором была готовность клиентов спокойно относиться к ошибкам в нем. Раньше эта мысль нам в голову не приходила, но мы с ней согласились. Предложение Лили было незамедлительно одобрено.

Раховин внесла ясность в неоднозначную проблему.

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

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

• Стоит ли откладывать запуск продукта, чтобы включить в него новые функции или что-то доработать?

• Улучшением каких показателей нам стоит заняться?

• На какой проблеме пользователя мы должны сосредоточиться?

• Как увеличить доход?

• Как увеличить объем использования этой функции?

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

• Почему графики показали падение показателей в определенный день?

В целом эти и другие неоднозначные проблемы можно разделить на два основных типа:

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

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

Давайте рассмотрим и те, и другие.

Поиск решений

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

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

Например, проблему «Как увеличить доход?» можно разбить на следующие составляющие:

• Новые и существующие клиенты: как увеличить число платежеспособных клиентов или как заставить существующих пользователей платить больше?

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

• Источники дохода: как повысить доход от подписки и от рекламы?

• Тип клиента: как увеличить доход с каждого пользователя и пользовательского профиля?

Вопрос «Почему в определенный день произошло неожиданное падение показателей?» можно разбить следующим образом:

• Внутренние и внешние изменения: проводились ли у нас какие-то мероприятия типа запуска продукции или изменения затрат на рекламу? Или что-то произошло в мире, например международный праздник или анонс нового продукта от конкурента?

• Географический фактор: зафиксированы ли изменения в разных странах?

• Линейка/область продуктов: наблюдалось ли снижение показателей по всем нашим продуктам (или по всем компонентам нашего продукта) или оно было локальным?

• Воронка: отмечался ли спад только в одной части воронки?

• Источник: исходила ли причина падения показателей от какого-то конкретного реферального источника?

• Тип клиента: затронуло ли изменение только пользователей какого-то одного типа?

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

Принятие решений

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

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

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

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

• Низкий или высокий риск.

• Низкий или высокий уровень инвестиций.

• Краткосрочная или долгосрочная выгода.

• Ориентированность на рост или на доход.

• Проектировать или покупать.

• Любое другое распределение по группам.

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

Дополнительные подходы к структурированию проблем описаны в разделе «Концепции и фреймворки» на с. 84.

САМОСТОЯТЕЛЬНО ИЗУЧАТЬ ДАННЫЕ

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

За год до того, как Лили Раховин решила вопрос с тем, на какой язык делать первый перевод приложения (см. «Выявлять и структурировать неоднозначные проблемы» на с. 76), она нашла решение другой проблемы, просто самостоятельно изучив все данные. В должность PM она вступила как раз тогда, когда продукт готовился к запуску. На тот момент больше десяти человек уже несколько недель спорили о дате запуска. Лили создала электронную таблицу, взяла в финансовом отделе нужные данные и подсчитала, сколько денег теряется за каждую неделю отсрочки. Когда люди увидели цифры, споры сразу прекратились.

ПОМОГАТЬ В СОРТИРОВКЕ И ВОСПРОИЗВЕДЕНИИ БАГОВ

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

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

Чтобы определить приоритет бага, необходимо учитывать следующие факторы:

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

• Ущерб для компании: может ли баг нанести крупный или долгосрочный ущерб компании? Может ли это серьезно навредить ее репутации?

• Влияние на показатели: оказывает ли баг серьезное воздействие на ключевые показатели компании? Влияет ли на затраты или доходы? Вредит ли привлечению, активации, удержанию, доходу или рекомендациям (модель AARRR)? Является ли он причиной большого количества обращений в службу поддержки?

• Масштаб воздействия: скольких пользователей затронул этот баг? Пропорционально ли он повлиял на важных (платежеспособных или крупных) клиентов? Больше или меньше пользователей он затронет в будущем?

• Обходные пути: существуют ли способы обойти баг? Найдет ли пользователь обходной путь самостоятельно?

• Простота исправления: легко ли его устранить? Сколько времени для этого потребуется?

• Сейчас или потом: своевременно ли исправлять баг сейчас? Что дешевле: отладить его сегодня или сделать это позже? Запланированы ли какие-то маркетинговые мероприятия, касающиеся этой части продукта?

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

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

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

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

СИСТЕМНОЕ МЫШЛЕНИЕ

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

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

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

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

Вот некоторые типы взаимосвязей, о которых полезно помнить:

• Циклы обратной связи: будут ли полученные сейчас результаты использоваться в качестве вводных данных на следующем этапе?

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

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

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

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

• Элементы UI: будут ли изменения, примененные к какому-то компоненту в одном месте, работать и в других местах его использования?

• Платформы: работает ли обновление одинаково на мобильных устройствах, стационарных компьютерах и через API разработчика?

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

• Требования к ресурсам: приведет ли это изменение к проблемам масштабируемости на стороне сервера или в системах клиентского обслуживания?

• Жизненный цикл пользователя: какие последствия в долгосрочной перспективе будет иметь изменение (например, предоставление неограниченного пространства новым пользователям)?

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

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

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

Практики роста

БУДЬТЕ ЛЮБОПЫТНЫ: ПРОГНОЗИРУЙТЕ И ИССЛЕДУЙТЕ

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

Начните с прогнозирования ваших ожиданий:

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

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

• Если вам предстоит тренинг, предположите, чему вы на нем научитесь.

Это поможет вам замечать что-то действительно интересное или неожиданное.

Без прогнозов ваш мозг может вас обмануть, и вы решите, что полученная вами информация соответствует вашим ожиданиям. Постфактум очень легко ошибочно принять мысль «Это имеет смысл» за «Я этого и ждал».

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

НЕДОСТАТОЧНО ПРОСТО УКАЗАТЬ НА ПРОБЛЕМУ

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

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

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

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

ОЗВУЧИВАЙТЕ СВОИ ФРЕЙМВОРКИ

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

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

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

Это дает массу преимуществ:

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

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

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

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

• Более эффективное принятие решений: ваши фреймворки будут становиться лучше, если вы их озвучите. Допустим, вы считаете, что для начала вашей новой команде следует взять простой проект. Вы объясняете коллегам, что полезно провести пробную совместную работу (с участием PM, инженеров, дизайнеров) без серьезного вмешательства руководства, и таким образом лучше узнать друг друга и изучить новую кодовую базу. Эти детали помогут сузить поиск и совместно найти тот «простой» проект, который подойдет лучше всего. Если бы вы не представили свой фреймворк команде, возможно, этот проект даже не пришел бы вам в голову.

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

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

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

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

РАСШИРЯЙТЕ ГРАНИЦЫ ОПТИМИЗАЦИИ И УЧИТЫВАЙТЕ ДОЛГОСРОЧНУЮ ПЕРСПЕКТИВУ

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

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

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

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

ВИЗУАЛИЗИРУЙТЕ

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

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

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

Изучайте компоненты в контексте фреймворка. Это могут быть UI-компоненты (например, настройки цвета или кнопки) и инфраструктура (например, Elastic Search от Amazon). Для каждого элемента выполнение задач может быть легким, требовать более дорогостоящей кастомизации или быть совершенно невозможным. Если вы визуализируете, какие компоненты использовать при создании обновления, вы сможете предсказать все связанные с ними преимущества и ограничения.

Концепции и фреймворки

МАТРИЦА 2×2

Матрица 2×2 – очень популярная схема. Она невероятно проста, но очень хорошо подходит для оценки вариантов и организации информации в целом.

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

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

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

Эти критерии и варианты можно оформить в виде модели 2×2 и упростить решение проблемы.

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

КРАСНО-ЖЕЛТО-ЗЕЛЕНЫЕ ТАБЛИЦЫ

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

МЫ ОПТИМИЗИРУЕМ, ЧТОБЫ…

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

ДЕРЕВО РЕШЕНИЙ

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

Для текстового варианта дерева можно использовать маркированный список с отступом:

• Если результат A/B-теста…

◊ Положительный

« Если есть жалобы от клиентов…

+ Опросить клиентов и повторить.

« Если нет жалоб от клиентов…

+ Запустить продукт

◊ Отрицательный

« Не запускать продукт

◊ Нейтральный

« Если есть довольные клиенты…

+ Если нет жалоб от клиентов…

○ Запустить продукт

« В остальных случаях…

+ Не запускать продукт

ЭЙГЕН-ВОПРОСЫ

Когда Шишир Мехротра (Shishir Mehrotra), соучредитель и CEO Coda, работал продакт-менеджером в YouTube, в компании шли бурные и безрезультатные споры. Инженеры предлагали сделать ссылки, которые бы вели на сторонние сайты с ТВ-шоу, недоступными на YouTube. Представители бизнеса не соглашались. Что же было делать?

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

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

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

Мехротра назвал такой тип корневой проблемы «эйген-вопрос» (eigenquestion)³⁶. Ответ на него, как правило, подходит и для последующих, вытекающих из первого, вопросов³⁷.

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

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

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

3. Вместе со своей командой перечислите варианты ответов на эйген-вопрос и определите плюсы и минусы каждого из них.

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

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

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

ПЯТЬ ПОЧЕМУ

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

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

Чтобы применить фреймворк «Пять почему», сделайте следующее:

1. Составьте график работы с людьми, вовлеченными в проблему.

2. Объясните, что цель в том, чтобы выявить более глубокие системные проблемы, а не найти виновных.

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

4. Сформулируйте проблему и спросите, почему она возникла. Запишите все ответы первого уровня.

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

6. Продолжайте копать, пока не почувствуете, что нашли первопричину. Часто это технологический сбой.

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

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

Основные выводы

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

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

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

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

Глава 7
Продукт и навыки дизайна

У меня был телевизионный пульт, на котором я не могла найти кнопку включения в темноте (почему она находилась не в верхнем углу?), и еще один пульт, такой крошечный, что вечно терялся в подушках дивана (спасибо, Apple TV!). Мое приложение для электронных книг зависает на мгновение каждый раз, когда я переворачиваю страницу. Когда приходит время платить налоги, я судорожно тыкаю на все вкладки и меню на сайте моего банка, чтобы найти нужные формы оплаты. А антивирусные программы раз в неделю отрывают меня от работы своими сообщениями о том, что проблем не обнаружено.

Это напоминает мне о важности хорошего чувства продукта и о том, как плохо, когда его совсем нет.

Иногда проблемы с продуктом намного серьезнее тех, что я описала выше. Из-за путаного UI люди отправляли свои поисковые запросы (или что похуже) в твиттер. Алгоритмы социальных сетей позволяют продвигать экстремистский контент. У телефонов Galaxy Note 7 отмечалась «маленькая» проблема – самопроизвольное возгорание.

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

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

Обязанности

ПРОВЕСТИ ИССЛЕДОВАНИЕ ПРОДУКТА

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

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

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

Существует много способов исследования продукта, но один из самых хорошо документированных – дизайн-спринт по методологии Google Ventures (GV Design Sprint)³⁹. Он представляет собой хорошо структурированный пятидневный процесс.

• Понимание (перед спринтом): сбор информации от экспертов со всей компании о проблемах, возможностях и целях.

• Определение (день 1): выбор проблемы или возможности, постановка целей и уточнение показателей успеха.

• Эскиз (день 2): генерация широкого списка потенциальных решений.

• Решение (день 3): выбор концепции для создания прототипа.

• Прототип (день 4): подготовка тестируемого прототипа.

• Проверка (день 5): представление прототипа пользователям и получение обратной связи для подтверждения концепции или отказа от нее.

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

Подробное руководство по исследованию продукта дал Марти Каган (Marty Cagan) в своей книге Inspired⁴⁰.

ВСЕГДА ПОМНИТЬ О ПОСТАВЛЕННЫХ ЦЕЛЯХ

Одна из основных задач PM – поддерживать связь между поставленными целями и действиями.

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

Кто-то вообще целится не в то ведро. А кто-то направляет шланг в нужную сторону, но со временем сбивается c правильного курса.

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

Вот несколько примеров того, как можно уточнить цели:

• Что является ключевым показателем успеха: привлечение новых пользователей, повышение вовлеченности или монетизация?

• Экономит ли новая функция время пользователей или помогает им достигать лучших результатов?

• Пытаетесь ли вы переманить клиентов своего конкурента?

• Хотите ли вы внедрить какой-то особый сценарий использования продукта?

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

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

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

Не скрывайте внутренние цели и ограничения

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

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

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

Нам всем иногда приходится идти на компромиссы, это понятно и не делает нас плохими PM. Но объяснять контекст, в котором возникает проблема выбора, так же важно, как показывать пользовательские данные, на которых основаны те или иные ваши решения.

ПРИНИМАЯ РЕШЕНИЯ, ОЗВУЧИВАТЬ СВОИ ИДЕИ И ДОВОДЫ

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

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

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

ВЗАИМОДЕЙСТВОВАТЬ С ДИЗАЙНЕРОМ В ПОИСКАХ ЛУЧШЕГО РЕШЕНИЯ

Кэти Гусман (Katie Guzman), PM-лид в Asana, пришла в команду в разгар масштабного редизайна. Она приняла почти все предложенные решения за исключением одного, которое показалось ей немного странным – заголовок занимал слишком много места. Дизайнер согласился, но не мог предоставить ни одного варианта, который прошел бы дизайн-ревью. Кэти попросила разрешить ей сделать небольшую корректировку и придумала дизайн, который всем понравился.

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

PM не должен диктовать дизайнеру, каким должно быть решение. Скорее, он должен делиться с ним своими мыслями, уважая при этом его работу⁴¹.

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

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

Подробнее о том, как правильно взаимодействовать с дизайнером, при этом подкидывая ему не только решения, но и проблемы, читайте в разделе «Работа с дизайнерами» на с. 300.

СОЗДАВАТЬ ЭТИЧНЫЕ ПРОДУКТЫ

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

Это не всегда легко. Микал Льюис (Mikal Lewis) рассказал, как ему пришлось решать проблему, когда на кон были поставлены и продукт, и карьера⁴²:

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

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

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

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

Шэрон Ло (Sharon Lo), PM, отвечающая за вопросы этики и общественности в Microsoft, рассказывает о том, как создавать этичные продукты с фокусом на осознанности.

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

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

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

БЫТЬ СТОРОННИКОМ СБАЛАНСИРОВАННЫХ РЕШЕНИЙ

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

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

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

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

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

ДАВАТЬ ГРАМОТНУЮ ОБРАТНУЮ СВЯЗЬ О ПРОДУКТЕ

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

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

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

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

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

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

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

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

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

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

РАЗРАБАТЫВАТЬ ПРИНЦИПЫ СОЗДАНИЯ ПРОДУКТА (И/ИЛИ ДИЗАЙНА)

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

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

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

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

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

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

Практики роста

ВЫБИРАЙТЕ САМЫЕ БЫСТРЫЕ И ЛУЧШИЕ СПОСОБЫ ПРОВЕРКИ ГИПОТЕЗ

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

Вот несколько способов ускорить проверку гипотез:

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

• Используйте такие сайты, как usertesting.com, для подбора участников тестирования. Если набирать их самостоятельно, у вас уйдет приблизительно неделя, чтобы распланировать все тестовые сеансы, и кто-то обязательно подведет вас, отменив свое участие. А онлайн-тестирование на сайте позволит получить результаты уже на следующий день. Готовьте тест тщательно, так как возможности внести какие-то изменения отдельно для кого-то из участников у вас не будет.

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

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

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

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

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

• Проводите быстрые A/B-тесты. Для простой корректировки текста или дизайна иногда быстрее внести изменения в код, чем запускать пользовательские тесты. Особенно результативен такой подход при тестировании изменений, дающих немедленную обратную связь (например, увеличивается ли число открываемых сообщений при изменении строки темы письма или возрастает ли количество кликов по кнопке при ее перемещении в другое место).

• Проводите тесты Fake Door («фальшивая дверь»). В таких тестах вы создаете точку входа для новой функции, не разрабатывая саму функцию. Это позволяет оценить, насколько она интересна пользователям. Например, кликнув по надписи «Дашборды», пользователь попадет на страницу с надписью: «Спасибо за ваш интерес. Мы сообщим вам, когда дашборды станут доступны». Поскольку подобные тесты могут надоесть пользователям, лучше всего проводить их в течение короткого времени или использовать тщательно продуманные лендинги⁴⁶.

• Создайте консьерж MVP⁴⁷ (minimum viable product, минимально жизнеспособный продукт) для нескольких клиентов. Прежде чем создавать готовую функцию, вы можете придумать не полностью автоматизированное решение, которое не афишируется и работает только для небольшого числа пользователей. Например, можно вручную, по кастомизированным скриптам, создать дашборды для нескольких ваших клиентов, чтобы понять, готовы ли люди за них платить.

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

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

СОЗДАВАЙТЕ «ЗАЛИПАТЕЛЬНЫЙ» ПРОДУКТ

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

Вот несколько подходов, которые помогут вовремя вернуть людей к вашему продукту:

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

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

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

• Геймификация. Такой прием, как «серия побед» (streaks), когда человек пользуется приложением несколько дней подряд для получения бонуса (пусть даже условного), может выработать у пользователя привычку заходить в приложение регулярно. Однако если такую серию случайно прервать, привычка может и не сформироваться.

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

ФОРМИРУЙТЕ ПРОДУКТОВОЕ МЫШЛЕНИЕ

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

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

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

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

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

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

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

Развитие продуктового мышления поможет вам принимать более правильные решения.

УЧИТЕСЬ ОПРЕДЕЛЯТЬ ЦЕЛИ И РАССТАВЛЯТЬ ПРИОРИТЕТЫ

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

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

Запишите все бизнес-цели и цели клиентов, какие только придут вам в голову

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

Микал Льюис, основатель Praxis Product Leadership, предлагает задуматься, зачем люди на самом деле носят наушники в офисе. Это делается не только для того, чтобы слушать музыку; таким образом они пытаются вежливо дать понять, что они не хотят, чтобы их беспокоили. Можете ли вы также найти какие-то неочевидные цели для своего продукта?

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

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

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

Определите приоритет целей

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

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

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

ОТСЛЕЖИВАЙТЕ ХОРОШО РАЗРАБОТАННЫЕ ПРОДУКТЫ

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

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

Иногда дизайн продуктов развивается подобно моде, когда один стиль сменяет другой.

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

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

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

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

ПОВЫШАЙТЕ ПЛАНКУ КАЧЕСТВА

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

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

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

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

Чтобы повысить планку качества, требуется следующее:

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

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

Вот примерный вариант того, что вы можете сказать:

«Итак, только что мы всей командой провели тщательный обзор продукта и выявили десять проблем. Я их записал. Давайте пройдемся по ним и решим, какие из них мы будем исправлять перед запуском.

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

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

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

Подробнее о расстановке приоритетов читайте в главе 17 «Roadmap и расстановка приоритетов» (с. 219).

РАСШИРЯЙТЕ КРУГОЗОР: РАССМАТРИВАЙТЕ БОЛЕЕ РАДИКАЛЬНЫЕ РЕШЕНИЯ

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

Обдумайте следующие вопросы:

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

• Что, если бы вы могли перенести сроки?

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

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

• Что, если бы вы могли изменить бизнес-модель?

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

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

Концепции и фреймворки

ВАРФРЕЙМЫ, ПРОТОТИПЫ И ПОТОКИ

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

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

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

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

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

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

ДЕРЕВО ВОЗМОЖНОСТЕЙ

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

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

Хорошую модель этого процесса предложила Тереза Торрес (Teresa Torres); она назвала ее «дерево возможностей»⁴⁸. С помощью этой модели вы можете расширить свое видение и представить возможные решения, которые помогут достичь вашей цели.

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

РАЗБОР ПРОДУКТА

Разбор продукта может принести ряд преимуществ, в том числе расширить знания предметной области, принципов дизайна и креативности. Он заключается в том, что вместе с коллегами вы берете чужой продукт и подробно его разбираете. Дженс-Фабиан Гоцманн (Jens-Fabian Goetzmann) описывает этот процесс так⁴⁹:

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

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

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

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

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

• Креативность: пытаясь развивать свой творческий потенциал, изучите сразу много разных продуктов и проведите мозговой штурм на тему применения чужих шаблонов в своих продуктах. Может быть, они как-то хитро подходят к онбордингу⁵⁰ или используют машинное обучение? Каким мог бы стать ваш продукт, если бы вы попытались его пересобрать, как это сделали Spotify, Slack и Waze?

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

МОЗГОВОЙ ШТУРМ

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

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

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

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

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

Приглашайте участников из разных команд и с разными ролями

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

Это даст следующие преимущества:

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

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

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

Структурируйте каждый мозговой штурм

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

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

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

• Разные «шляпы»⁵¹: попросите людей придумать идеи заданного типа, например одну обычную, одну глупую, одну дорогостоящую, одну фантазийную. Этот подход также можно использовать для мозгового штурма идей отдельно для каждого типа клиентов или варианта использования продукта.

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

Кейт Беннет (Kate Bennet), директор по продукту в Lab Zero, использует шаблоны ретроспективы спринта, среди которых есть несколько подходящих для проведения мозгового штурма:

«В некоторых ретроспективах я рисую на доске парусник. Ветер олицетворяет то, что нам помогает; якорь – то, что нам мешает. Акула представляет страхи команды, а тропический остров – ее надежды или цели. Я даю каждому участнику стопку стикеров (или ссылку на онлайн-доску) и пять минут, чтобы они могли приклеить стикеры со своими идеями на соответствующую часть изображения. Смешанный формат, когда задание меняется в соответствии с потребностями группы, делает участников более заинтересованными и включенными в ретроспективу. Так они охотнее делятся тем, что для них действительно важно».

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

Основные выводы

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

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

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

• Учитывайте потенциальные вредные последствия: PM несет ответственность как за положительное, так и за отрицательное воздействие продукта. Конечно, добавление средств защиты и ограничений не такое уж приятное занятие, но важно сделать так, чтобы ваш продукт не принес вреда.

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

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

Глава 8
Технические навыки

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

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

Обязанности

ПРИНИМАЙТЕ РЕШЕНИЯ О ПРОДУКТЕ ВМЕСТЕ С ИНЖЕНЕРАМИ

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

Лайка Каяни (Laika Kayani), старший директор по управлению продуктами платформы искусственного интеллекта (ИИ) в Lumiata, рассказала, как она работает с инженерами, чтобы создавать отличные продукты:

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

Решения, которые принимаются сообща, зачастую лучше, чем те, которые мы принимаем самостоятельно.

ИЗУЧАЙТЕ ТО, КАК ТЕХНИЧЕСКАЯ ИНФРАСТРУКТУРА ВЛИЯЕТ НА ПРОДУКТ

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

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

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

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

ЕСЛИ ВЫ УМЕЕТЕ ПИСАТЬ КОД, НЕ ОТКАЗЫВАЙТЕ В ПОМОЩИ

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

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

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

Практики роста

УЗНАЙТЕ МНЕНИЕ РУКОВОДИТЕЛЯ И ИНЖЕНЕРОВ

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

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

УЧИТЕСЬ ИНТУИТИВНО ОЦЕНИВАТЬ ЗАТРАТЫ

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

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

Прежде чем идти дальше, я еще раз хочу повторить:

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

Итак, что вы можете сделать со своими собственными прогнозами? Предлагаем несколько вариантов:

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

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

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

Как развить интуицию в отношении оценки затрат

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

На стоимость обычно влияют два главных фактора:

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

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

Концепции и фреймворки

ТЕХНИЧЕСКИЕ ТЕРМИНЫ И ПОНЯТИЯ

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

API

API (Application Programming Interface) – интерфейс программирования приложений. Это эквивалент UI для взаимодействующих друг с другом компьютеров.

Существуют внутренние API, с помощью которых разные продукты и системы внутри компании «общаются» между собой, и внешние API, которые могут использоваться внешними разработчиками для подключения к вашему продукту или проектирования на его основе. Так же как пользователь ограничен UI (например, мобильная версия приложения не обладает той же функциональностью, что и веб-версия), компьютеры ограничены доступными API.

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

Внедрение API-интерфейсов

Когда речь заходит об API, вы можете услышать слово CRUD, что означает создание, чтение, модификацию и удаление (Create, Read, Update, Delete) – четыре основные функции, используемые при работе с данными. Например, применение CRUD API в Twitter для твитов позволило бы создать новый твит, считать его текст (если вы знаете числовой идентификатор твита), отредактировать или удалить твит⁵². Обычно именно CRUD API первым делом предоставляется с продуктом, а уже позже добавляются более специализированные API, например для закрепления твита в профиле.

Многие API-интерфейсы используют XML или JSON (нотация объектов JavaScript) для форматирования передаваемой информации. Оба языка имеют текстовый формат, легко анализируются и считываются компьютером. Когда кто-то упоминает объекты JSON или большой двоичный объект JSON (JSON Blob), имеется в виду фрагмент данных, которые были соответствующим образом отформатированы, чтобы их легче было читать и обмениваться ими.

Для аутентификации (authentication, auth) API обычно используют маркеры доступа (access tokens) вместо отправки имени пользователя и пароля при каждом запросе. Они как печати, которые вам ставят на руку в музее, после того как вы покажете входной билет.

Клиент (или фронтенд) и сервер (бэкенд)

Клиент – это часть продукта, запускаемая на устройстве пользователя, например мобильное приложение или веб-сайт, который вы видите при загрузке страницы. Сервер – это часть продукта, которая запускается на компьютерах компании или в облачных сервисах, таких как Amazon Web Services (AWS). Любые данные, к которым вы можете получить доступ с разных устройств, хранятся на сервере, а клиент получает только их временную копию.

На стороне клиента могут выполняться только мгновенные действия. А то, что требует полного цикла приема и обработки запросов от клиентов на сервере (round trip to the server) – клиент отправляет серверу сообщение о том, что он хочет, а сервер отвечает, – часто выполняется с заметной задержкой в четверть секунды или более.

Мобильные и веб-приложения

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

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

Оптимизация

Нужно, чтобы все работало быстрее? Вот несколько общепринятых подходов:

• На сервере часто выполняются фоновые задачи или cron-задачи (отложенные). Задача в данном контексте – это независимая часть кода, которая выполняется отдельно от остальной части серверного кода, а не в качестве прямой реакции на запрос клиента. Cron-задача выполняется регулярно по заданному графику (например, каждые десять минут или каждую ночь) и может применяться, например, для ежедневной рассылки сводок по электронной почте. Выполнение задач в фоновом режиме – это, по сути, асинхронное выполнение каких-то медленных действий, ожидание которых было бы слишком долгим для пользователя. Фоновыми могут быть как задачи пользователя (например, создание большого экспортируемого файла), так и системы (например, когда распространение нового имени профиля внутри системы занимает несколько минут).

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

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

Дополнительно об оптимизации работы с базами данных читайте на с. 117.

Развертывание и разработка, тестирование, индексирование, бета-версии и рабочие серверы

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

Инженеры начинают с локальной «песочницы», также называемой сервером разработки (development server) или dev, разворачиваемой на персональных компьютерах⁵³. Эта изолированная среда может серьезно отличаться от реальной (например, иметь только небольшое количество фиктивных данных), но помогает очень быстро понять, как работает код, и запустить итерации с ним. У каждого инженера есть своя собственная «песочница», так что все могут писать код одновременно. После набора текста кода инженеру, возможно, придется выполнить сборку кода или компилировать его, и это может занять определенное время в зависимости от используемого языка и архитектуры кодовой базы. Ускорение времени компиляции может существенно повлиять на скорость проектирования, поскольку позволяет разработчикам быстрее тестировать свой код.

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

Управление кодом

Когда инженеры пишут код, они используют систему управления версиями, например git или github, чтобы фиксировать свои изменения и получать новый код, написанный другими разработчиками. Централизованная копия кода называется основной ветвью разработки (master branch).

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

Коммит кода

В ходе работы инженер выполняет коммиты, то есть сохраняет изменения в системе управления версиями и обновляет историю версий. Как только все готово, он объединяет свою ветвь с основной веткой кода, создает запрос на включение изменений, или пул-реквест (pull request, PR), иначе называемый список изменений. PR подсвечивает все diffs, то есть изменения (добавленные, удаленные или измененные строки кода). Иногда в него полезно заглянуть, если вы умеете читать код, например чтобы узнать, какое имя присвоено тому или иному событию в журнале.

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

Как только запрос на включение изменений будет принят, все изменения в основной ветви, внесенные другими разработчиками, сливаются в локальную ветвь. То есть если все редактировали разные строки кода, в объединенный код автоматически будут добавлены все изменения. Если два человека попытаются отредактировать одну и ту же строку, это приведет к конфликту слияния (merge conflict) – и инженеру потребуется исправить проблему вручную.

Проверка кода перед развертыванием

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

Тестовый сервер обычно выполняет модульные (unit tests) и интеграционные тесты (integration tests). Модульные тесты – это небольшие изолированные тесты, которые автоматически запускают все функции компонента и проверяют правильность полученных результатов. На самом деле смысл этих тестов заключается не в проверке правильности только что написанного кода; скорее, они нужны для того, чтобы убедиться, что чужие изменения не смогут нарушить ваш код. Интеграционные тесты масштабнее, они применяются к потокам и нужны для полной проверки срабатывания вариантов использования продукта.

Если компания применяет непрерывное развертывание (continuous deployment), после автоматического прохождения тестов код объединяется с общей основной ветвью и развертывается на следующем сервере. Это может быть рабочий сервер (production server, prod), используемый реальными клиентами, бета-сервер для внутренних сотрудников или небольшого процента клиентов либо промежуточный сервер (staging server). Последний представляет собой точную копию производственного и используется для выполнения нагрузочных тестов (load tests). У каждой компании есть свой набор правил, которые определяют, когда код готов для перехода на следующий сервер (например, через несколько часов или тогда, когда скажет разработчик).

Когда код завершен

Если из-за отправки кода останавливается компиляция основной ветви разработки, происходит прерывание сборки (breaking the build). Обычно это случается, когда инженер пропускает этапы тестирования в попытке сэкономить время. Никто не может отправлять новый код, до тех пор пока сборка не будет исправлена.

Запуск кода не всегда означает, что пользователи сразу же видят новую функциональность. Изменения или новые опции могут быть скрыты за флагом функции, который представляет собой параметр настройки (он включает или выключает ту или иную функцию). Флаги часто используют в рамках A/B-тестирования, когда в произвольном порядке у каждого пользователя та или иная функция включена или выключена. Код прописывает использование флагов просто: «Если флаг включен, запустить такой код; если флаг выключен, запустить другой код».

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

Аналитика и ведение журнала событий

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

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

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

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

SQL и базы данных

Базы данных (БД) – это системы хранения данных, похожие на сложные многоуровневые электронные таблицы⁵⁴. Существует несколько типов баз данных, предназначенных для разных целей.

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

Для журналов событий и бизнес-аналитики ваша компания также может использовать специальное хранилище данных (data warehouse), например Redshift. Журналы перемещаются в хранилище данных с помощью процесса, называемого ETL (Extract, Transform, Load – извлечение, преобразование, загрузка).

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

SQL

SQL – сокращение от Structured Query Language (язык структурированных запросов). Это язык программирования, используемый для добавления, редактирования и извлечения данных из большинства БД. Как пользователь, вы можете применять SQL для прямого взаимодействия с базами данных, но, как правило, только с базами данных журналов, но не с рабочими базами. Для работы с последними код сервера генерирует SQL-запрос и отправляет его в базу.

В целом с кодом SQL работать намного быстрее, чем с серверным кодом, однако SQL умеет далеко не все.

Оптимизация баз данных

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

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

Алгоритмы и структуры данных

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

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

• O(1) (постоянное время): скорость выполнения алгоритма в целом остается неизменной независимо от количества данных.

• O(log n) (логарифмическое время): выполнение алгоритма замедляется по мере увеличения объема данных, но даже их удвоение мало что меняет. Например, десятикратное увеличение набора данных может удвоить время выполнения алгоритма.

• O(n) (линейное время): скорость выполнения алгоритма увеличивается пропорционально размеру набора данных. Таким образом, если набор данных увеличится в 10 раз, время выполнения алгоритма также может увеличиться в 10 раз.

• O(n log n) (линейно-логарифмическое время): алгоритм такой сложности немного хуже линейного. Увеличение набора данных в 10 раз может, например, повысить время выполнения алгоритма в 11 раз. Это допустимо для решения практических задач и обычно совпадает с реальным временем сортировки данных.

• O(n^2) (квадратичное время): алгоритм такой сложности значительно хуже линейного. Если набор данных возрастет в 10 раз, время выполнения алгоритма может увеличиться в 100 раз. Обычно такой алгоритм применяется, только если заранее известно, что ПО будет работать с небольшим объемом данных.

• O(2^n) (экспоненциальное время): кошмар. Алгоритм такой сложности гораздо хуже линейного; возрастание объема данных в 10 раз может привести к увеличению времени выполнения в 1000 раз. А увеличение в 20 раз означает повышение скорости алгоритма в 1 000 000 раз. Видите проблему? Подобный алгоритм крайне редко используется в расчетном ПО. Он слишком медленный.

O(n) быстрее, чем O(n^2)? Трудно сказать. Если объем данных невелик, то, возможно, и нет. Но если он значительно увеличивается, то определенно да. При этом один алгоритм O(n) может быть намного быстрее другого алгоритма O(n). Математикам это вряд ли понравится, но вы можете представлять нотацию «О-большое» как упрощенное объяснение того, как медленно будет выполняться алгоритм при больших объемах данных. Алгоритмы O(1) и O(log N) считаются лучшими, O(n) и O(n log n) – обычно приемлемы. O(n^2) или более медленные, как правило, непригодны. Но все зависит от того, какую задачу вы решаете!⁵⁶

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

Еще несколько терминов

• Поскольку клиенты и серверы могут находиться в любой точке мира, из-за разницы часовых поясов может возникнуть путаница во времени и датах. Чтобы этого не было, в коде, в том числе для расчетов, обычно используется время в формате UTC (Coordinated Universal Time – всемирное координированное время), которое переводится в местное для отображения пользователю. Время UTC почти совпадает со средним временем по Гринвичу (GMT, часовой пояс Лондона, Англия), но не учитывает переход на летнее время.

• Swag расшифровывается как Scientific Wild-Ass Guess – «метод научного тыка» – и используется для описания оценки затрат. Это слово передает, что оценка не точная, а предположительная. Используя этот метод при составлении графиков, стоит умножать свои оценки на два или даже на четыре, чтобы учесть неточность подсчетов и затраты на выполнение ежедневной рутины, например код-ревью или написание тестов.

• UUID или GUID означает универсальный уникальный ID (Universally Unique Identifier) или глобальный уникальный ID (Globally Unique Identifier). Это очень длинные, случайно сгенерированные строки (например, «712f58d0-0208-4fc4-b80f-fc4e960bfac2»), которые обычно используются в качестве ID объекта в базе данных. Они удобны, поскольку могут считаться уникальными и не требуют фактической проверки того, использовался этот ID раньше или нет. (Почему проверять не нужно? Потому что такой случай крайне маловероятен.)

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

ЧТО ОЗНАЧАЕТ ФРАЗА «ЭТО СЛИШКОМ СЛОЖНО»?

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

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

Разработка будет слишком затратной

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

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

• Возможно, вы недооцениваете объем работ, необходимый для воплощения вашей идеи.

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

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

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

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

Производительность будет низкой, а масштабируемость решения слишком слабой

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

Существует несколько способов решения вопросов производительности:

• Установите ограничения. Например, можно показывать значение «99+», если количество элементов превышает 99.

• Измените продукт так чтобы за один раз требовалось производить меньше расчетов. Например, проводить сравнение только с одной позицией в списке.

• Потратьте больше времени на разработку системы, которая быстрее выдает результаты. Например, вы можете денормализовать (с. 117) или кешировать (с. 113) информацию либо произвести предварительные вычисления.

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

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

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

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

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

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

Основные выводы

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

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

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

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

Глава 9
Документация по продукту

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

Но будьте осторожны.

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

Неважно, каким документом вы пользуетесь: спецификацией (spec), техническим заданием (Product Requirements Doc, PRD), одностраничным шаблоном (lean product canvas) или продуктовым брифом (product brief) – у них всех одно назначение, и в них нет никакой магии. Любой из этих документов – всего лишь инструмент, который помогает прорабатывать важные моменты, обмениваться идеями, получать обратную связь и улучшать план работы. И, как и любые другие инструменты, их иногда неправильно используют.

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

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

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

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

Сделайте документ легким и понятным для чтения

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

Дадим несколько советов:

• Используйте диаграммы и рисунки для иллюстрации концепций.

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

• Будьте кратки – переместите как можно больше сведений в приложение к документу.

• Упомяните о рассмотренных альтернативах и предоставьте свои аргументы.

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

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

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

Используйте спецификацию в качестве основы для обратной связи

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

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

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

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

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

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

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

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

Сосредоточьтесь на результатах

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

Пример спецификации

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

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

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

ПРОБЛЕМЫ

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

• PM не всегда знают, что от них требуется.

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

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

ЦЕЛИ

• Больше качественных продуктов

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

• Больше эффективных PM

◊ Как должен выглядеть успех: книга хорошо продается и получает хорошие оценки от PM и их руководителей.

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

◊ Как должен выглядеть успех: в отзывах на платформе Amazon читатели пишут, что книга помогла им получить повышение.

• У менторов больше времени для индивидуальной работы с учениками

◊ Как должен выглядеть успех: менторы PM рекомендуют книгу.

• Международное признание

◊ Как должен выглядеть успех: читатели не говорят, что книга слишком ориентирована на США.

ВАРИАНТЫ ИСПОЛЬЗОВАНИЯ

Формат «Работа, которую нужно сделать (JTBD)» (из одноименного раздела).

• Если я только в начале карьеры, я хочу:

◊ Получить навыки PM, узнать секретные приемы и хитрости, чтобы

« быть лучшим в своем деле;

« не оказаться в неловком положении, совершив ошибку.

◊ Понять структуру карьерной лестницы PM, чтобы

« сосредоточиться на наиболее важных навыках;

« быстро продвигаться вверх.

◊ Научиться ставить карьерные цели, чтобы

« быть уверенным, что я получаю правильный опыт;

« понять, хочу ли я руководить людьми;

« избежать участия в крысиных бегах.

• Если я не могу получить продвижение, я хочу:

◊ Четко понять ожидания, предъявляемые PM на каждом конкретном уровне, чтобы

« выявить ошибки;

« сосредоточиться на важных действиях.

• Если я занимаю руководящую должность в продакт-менеджменте, я хочу:

◊ Научиться лучшим методам управления командой, чтобы

« настроить свою команду на успех;

« помочь росту PM в своей команде.

◊ Получить документ с описанием того, каким должен быть лучший PM, чтобы

« показать PM из своей команды, на чем им нужно сфокусироваться, чтобы получить продвижение;

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

ГРАФИК

1. Содержание (1 день).

2. Первый черновой вариант (4 месяца).

3. Углубленные интервью (2 месяца).

4. Доработка проекта (3 месяца).

5. Отзывы бета-ридеров и редактирование рукописи (2 месяца).

6. Публикация (1 месяц).

ПОДРОБНОЕ ПРЕДЛОЖЕНИЕ

Навыки PM

• 80 % книги.

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

• Распределить по группам: продуктовые, стратегические, лидерские, управленческие навыки и навыки реализации.

• Добавить реальные цитаты везде, где это возможно.

Управление карьерой

• 20 % книги.

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

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

ОСНОВНЫЕ ДИЛЕММЫ И РЕШЕНИЯ

Как сгруппировать навыки PM

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

Как выделить информацию, которая касается PM-сеньоров и руководителей

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

ОСНОВНЫЕ ВЫВОДЫ

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

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

Часть 4
Навыки реализации

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

• «Управление проектами» (с. 131) – в этой главе вы научитесь составлять план ведения проекта и придерживаться его без отклонений. Мы расскажем вам о методологии Agile и других наиболее эффективных практиках, которые помогут вам ускорить работу вашей команды.

• Глава «Определение объемов и пошаговая разработка» (с. 146) научит вас разбивать процесс запуска на несколько этапов, чтобы ускорить его и сделать более успешным. Вы узнаете о минимально жизнеспособных продуктах (MVP) и о том, насколько важно представлять продукт реальным пользователям.

• В главе «Запуск продукта» (с. 157) речь пойдет о подготовке запуска. Как выбрать дату, что включить в лист проверки запуска, какие стратегии запуска существуют – обо всем этом написано здесь.

• «Как довести дело до конца» (с. 172) – это глава о том, как управлять своим временем и преодолевать препятствия. В ней мы познакомим вас c концепцией 4D и научим, как эффективно работать с командами в удаленном режиме.

Больше всего навыки реализации могут пригодиться в середине и в конце жизненного цикла продукта.

Глава 10
Управление проектами

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

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

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

Концепции и фреймворки

Agile, Lean, Kanban и Scrum – это современные концепции и методологии, применяемые к разработке программного обеспечения в большинстве технологических компаний. Если вы слышали о спринтах (sprints), бэклоге продукта (product backlog) или ежедневных стендапах (daily standups), значит, с некоторыми концепциями вы уже знакомы. Большинство современных команд используют некоторые из этих элементов⁵⁷.

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

МЕТОДОЛОГИИ

Lean

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

Agile

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

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

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

Agile можно представить в виде спектра. Большинство команд склоняется к этому подходу. Для этого достаточно уменьшить размер цикла (то есть разбить работу на несколько мелких этапов и запусков) и заменить объемную официальную документацию ситуативной совместной работой.

Scrum

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

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

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

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

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

Часто команды выбирают только несколько элементов Scrum или по-своему адаптируют эту концепцию к своей работе. Почти невозможно найти команду, которая бы неукоснительно следовала принципам, описанным в «Руководстве по Scrum™». К счастью, адаптивность – это именно то, чего хотели создатели Scrum!⁵⁸

Kanban

Kanban – еще один метод гибкого управления, известный благодаря так называемой kanban-доске.

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

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

БЭКЛОГ ПРОДУКТА

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

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

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

Для задач или историй обычно составляется смета затрат, например в виде стори поинтов (Story Points), или единиц истории. Стори поинты – это абстрактная единица оценки сложности работы. Один поинт означает самую простую задачу, два поинта присваивается задаче, на выполнение которой уйдет в два раза больше времени, чем на задачу с одним поинтом, и т. д. Составлением смет занимаются инженеры (не PM).

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

ЧТО ТАКОЕ «ПОИНТ»?

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

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

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

КАК ИССЛЕДОВАНИЕ ПРОДУКТА И ДИЗАЙН ВПИСЫВАЮТСЯ В РАБОТУ

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

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

Дизайнеры идут на один спринт впереди инженеров

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

Стадии исследования и дизайна продукта стартуют задолго до начала разработки

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

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

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

Обязанности

ЧЕТКО ПРОГОВАРИВАТЬ С КОЛЛЕГАМИ ВАШИ ОБЯЗАННОСТИ ПО УПРАВЛЕНИЮ ПРОЕКТАМИ

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

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

АКТУАЛИЗИРОВАТЬ И ПРИОРИТИЗИРОВАТЬ БЭКЛОГ

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

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

ВЫДЕЛЯТЬ ЭТАПЫ И РАССТАВЛЯТЬ КОНТРОЛЬНЫЕ ТОЧКИ

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

Если говорить в общем, то определить, какой процент крупного проекта выполнен, крайне сложно. Принцип Парето гласит, что написание последних 20 % кода занимает 80 % времени. Именно поэтому так важно разбивать работу на этапы – пока команда не дойдет до четко обозначенной контрольной точки, представить, сколько еще осталось сделать, очень трудно.

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

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

ПИСАТЬ ХОРОШИЕ ОТЧЕТЫ О ХОДЕ РАБОТ

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

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

Как правило, отчет о ходе работ включает в себя ответы на следующие вопросы:

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

2. Что произошло за последнее время? Сделайте акцент на ключевых достижениях и важных изменениях. Заодно можно отпраздновать завершение каких-то промежуточных этапов вместе с командой.

3. Что дальше? Обсудите следующий этап работы и цели, которые необходимо выполнить.

4. Существуют ли какие-либо проблемы или риски? Заранее проинформируйте стейкхолдеров о своих опасениях и дайте им возможность оказать вам помощь.

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

КОНТРОЛИРОВАТЬ РАБОТУ КОМАНДЫ

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

• Они застряли на одной задаче и просто топчутся на месте.

• Они не согласны с распределением задач и не хотят ничего делать.

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

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

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

• Задание оказалось более сложным, чем предполагалось.

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

СОВМЕСТНОЕ РЕШЕНИЕ ПРОБЛЕМЫ

Однажды топ-менеджер по продукту Саир Бакл (Sair Buckle) заметила, что один из инженеров-сеньоров выполняет задачи медленнее, чем обычно. Она не стала делать выводов о том, что он просто не укладывается в график, и отправила ему неофициальное сообщение с просьбой рассказать о том, как он планировал свою работу.

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

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

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

КОРРЕКТИРОВАТЬ ПЛАНЫ ПО МЕРЕ ИЗМЕНЕНИЯ СИТУАЦИИ

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

• Добавить в проект больше людей.

• Перенести дату запуска.

• Сократить объем.

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

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

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

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

ДЕЛИТЬСЯ НАКОПЛЕННЫМ ОПЫТОМ С КОЛЛЕГАМИ

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

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

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

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

Практики роста

БУДЬТЕ НА СВЯЗИ

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

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

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

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

СОКРАТИТЕ ЗАВИСИМОСТИ

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

Иногда зависимости стратегически полезны. Например, Apple в день запуска новой версии iOS с новыми возможностями API хочет иметь несколько приложений, которые смогут сразу ее использовать.

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

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

ОПТИМИЗИРУЙТЕ РЕСУРСЫ КОМАНДЫ

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

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

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

• Ограничения по продакт-менеджменту: выбирайте простые проекты, которые не требуют множества действий по исследованию продукта.

• Ограничения по разработке: сосредоточьтесь на стратегии.

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

УЛУЧШАЙТЕ ПРОЦЕССЫ ВНУТРИ КОМАНДЫ

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

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

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

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

Установите ПО для управления проектами

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

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

Применение подобных программ важно по нескольким причинам:

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

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

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

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

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

Используйте демонстрации как побуждающий фактор

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

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

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

Установите специальные дни для проработки пропущенных моментов

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

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

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

• Внутренние инструменты: совершенствование внутренних инструментов и процедур многократно увеличивает скорость работы команды.

Если назначить отдельный день для каждого из этих вопросов, то можно добиться значительного прогресса. Запланируйте для своей команды или всего подразделения «охоту за багами» (bug bash), «дни шлифовки» (polish week) или «неделю ускорения процессов» (grease week)⁶⁰.

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

ВЫЯВЛЯЙТЕ И СМЯГЧАЙТЕ РИСКИ

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

Для каждого риска нужно разработать план мероприятий по его снижению.

• Как понять, является ли риск реальной проблемой? Вы можете провести проверку концепции или юзабилити-тест.

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

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

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

СПОСОБСТВУЙТЕ УЛУЧШЕНИЮ КАЧЕСТВА И СКОРОСТИ РАБОТЫ ПРОДУКТОВЫХ КОМАНД

Достаточно ли быстро действуют ваши продуктовые команды и эффективны ли они? Лидеры по продукту могут многое сделать, чтобы ускорить работу команды и улучшить качество продукта.

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

Вы можете выявить несколько проблем.

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

• Сроки запусков не были соблюдены. Неправильно были проведены расчеты? Что-то замедлило работу команды? Более тщательная оценка, увеличение состава команды, вклад в инфраструктуру разработки проекта могут помочь решить эту проблему.

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

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

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

Ваш вклад в решение этих проблем многократно повысит эффективность ваших команд.

УЧИТЫВАЙТЕ ВОЗМОЖНОСТЬ ПАРТНЕРСТВА И ПРИОБРЕТЕНИЯ КОМПАНИЙ

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

Илай Лернер (Ely Lerner), ответственный за интеграцию двух приобретенных компаний в Yelp, предлагает постоянно сотрудничать с отделом корпоративного развития и держать их в курсе волнующих вас проблем. Встречи с потенциальными партнерами могут оказаться очень ценными, даже если партнерство не принесет ожидаемых результатов, поскольку они дают вам новый взгляд на отрасль.

Покупка активов подразумевает как высокую прибыль, так и большой риск. В большинстве случаев компании терпят неудачу, но некоторым самым успешным брендам удалось преуспеть после приобретений: PayPal, YouTube и Instagram – лишь некоторые из них.

Лернер дал два совета относительно интеграции приобретенной компании в существующий бизнес:

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

ОСНОВНЫЕ ВЫВОДЫ

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

• Не думайте, что кто-то другой отвечает за управление проектом: лид-инженер может взять на себя многие процессы управления проектами, но не всегда. Уточните, за какие вопросы вы должны отвечать, по мнению команды. Если никто не захочет взять управление в свои руки, это придется сделать вам.

• Следите за постоянной загрузкой команды: убедитесь, что у вашей команды всегда есть важная и выполнимая задача. Планируйте заранее, чтобы к началу работы дизайнера было проведено нужное число исследований, а перед передачей проекта инженерам в достаточной степени был выполнен дизайн. Отслеживайте готовность к переходу к той или иной стадии вместе с коллегами по команде.

Глава 11
Определение объемов и пошаговая разработка

Когда я только стала PM, мне хотелось, чтобы мои продукты были идеальными. Я изучила проблемы клиентов и составила длинный подробный список функций, которые покрывали бы все потребности. Мой идеализм очень быстро разбился о реальность, когда я узнала, что на разработку у меня есть только 40 дней. А для того, чтобы выполнить все пункты моего списка, потребовалось бы как минимум 100!

Так я столкнулась с вопросом определения объемов работ: мне предстояло научиться аккуратно выбирать, что включать в список задач, а что нет. Сказать «да» одной функции означало сказать «нет» другой. Стоит ли поработать над тем, чтобы показать количество комментариев к каждому сообщению в блоге, или лучше потратить это время на упрощение загрузки изображений? Сделать ли вики-страницы настраиваемыми или полезнее вместо этого сократить время загрузки страниц?

Подобные вопросы казались мне очень сложными, но потом выяснилось, что на самом деле все просто. У меня было фиксированное время, поэтому оставалось только решить, как его заполнить.

На своей следующей позиции мне пришлось не только выбирать, что включать в объем работ, а что нет, но и решать, сколько времени потратить на реализацию проекта. Не имея четко обозначенного срока в 40 дней, я позволила своим командам отказаться от необходимости доводить продукт до совершенства и сообщить мне, когда они будут готовы к запуску. Некоторые проекты были реализованы быстро, но один длился в течение нескольких кварталов.

Я разрешила инженерам задать темп работы, и они двигались с хорошей скоростью (ну, или я так думала). Сначала я не понимала, что наша проблема заключалась в растянутом цикле разработки. Честно говоря, только в ходе моего перформанс-ревью я поняла, что проект нужно было уже давно запустить.

Теперь, по прошествии времени я понимаю, что все было логично – если команда не сдает проект, значит она не приносит никакой пользы. Как только мы сформулировали, что требуется для запуска продукта в следующем квартале, мы сразу же нашли новый подход и все быстро сделали. Определение сроков сделало новое решение практически очевидным.

Это вовсе не значит, что наш подход – установить дату и выбрать продукт для запуска – подходит для других сценариев. Когда я пришла в Asana, разработка велась в течение нескольких лет, но публичного запуска пока не было. Произвести его немедленно было бы ошибкой, так как хороший запуск должен вызвать резкое увеличение спроса, по крайней мере, это предполагается. Для нас было важно представить продукт высокого качества, даже если бы это было на месяц или два позже.

Хотя мы не могли откладывать запуск надолго, сначала мы определили, какие моменты могут навредить нашей репутации, если мы реализуем их неправильно. Мы решили исправить визуальный дизайн и создать мобильное приложение. Мы знали, что получим много запросов на добавление функций. Но если люди будут пользоваться продуктом достаточно долго, чтобы иметь какие-то пожелания, это будет приятной проблемой.

Существует множество способов разбить запуск на несколько частей. Какие-то из них лучше, какие-то хуже. Самые эффективные подходы позволяют учиться и вносить изменения в процесс по ходу дела, в итоге получая продукт, полностью отвечающий потребностям конечных пользователей. Если все делать правильно, можно сократить сроки реализации проекта на несколько месяцев. Что еще важнее, можно получить продукт, который люди полюбят.

Как PM, вы отвечаете за определение объемов работ и решаете, что войдет в релиз, а что нет. Вы определяете, какие идеи проверять в первую очередь. Вам необходимо иметь собственное суждение о том, какие задачи можно пропустить, а какие являются критическими для проекта. И вы должны уметь убеждать свою команду менять планы, основываясь на результатах прошедших релизов.

Концепции и фреймворки

ПОШАГОВАЯ РАЗРАБОТКА

Пошаговая разработка – это разбиение крупного запуска на несколько релизов и использование их результатов для проведения каждого последующего. Вместо того чтобы три года работать над продуктом и только в день запуска выяснить, нравится ли он людям, можно чаще показывать свою работу клиентам и получать критические замечания на более ранней стадии.

Одним из самых известных примеров, иллюстрирующих такой подход, является метафора Хенрика Книберга (Henrik Kniberg) о скейтборде⁶¹:

• В первом примере команда разбила работу на несколько релизов, но выпущенные шины и частично собранный автомобиль были непригодны для использования. Такая разбивка не имела никакой ценности для клиентов и ничему не учила команду.

• Во втором примере в каждом релизе было представлено что-то функциональное. В первом релизе клиент не оценил скейтборд, но команда получила полезную информацию о том, что для клиента важно. Следующие релизы уже имели потребительскую ценность, и команда узнавала о предпочтениях пользователя и о том, какие из запланированных функций ему не нужны. В результате вместо обычного автомобиля команда создала кабриолет с откидным верхом, который полюбился клиентам.

Многие продуктовые идеи не несут никакой пользы клиенту или бизнесу в первом своем воплощении. Как сказал Марти Каган в своей книге «Inspired»: «Половина наших идей просто не сработает». Даже у лучших PM есть много идей, которые в конечном итоге не оказывают ожидаемого воздействия. Разница в том, что хорошие PM оценивают свои идеи на раннем этапе, чтобы быстро отбросить неудачные варианты и потратить больше времени на создание продукта, который действительно будет работать.

МИНИМАЛЬНО ЖИЗНЕСПОСОБНЫЙ ПРОДУКТ (MVP)

Определение минимально жизнеспособного продукта (minimum viable product, MVP) из книги Эрика Риса (Eric Ries) «The Lean Startup»⁶² звучит так: «Это версия нового продукта, позволяющая команде собрать максимальное количество проверенных сведений о клиентах с минимальными усилиями»⁶³.

В качестве MVP может выступать ранний рабочий прототип, но это необязательно. Чтобы измерить интерес пользователей, можно запустить кампанию AdWords. Или добавить кнопку, при нажатии на которую появляется сообщение: «Скоро в продаже». Можно сымитировать работу бэкенда, выполняя операции вручную.

Распространенные ошибки при работе с MVP

Концепция MVP сразу стала популярной. Но, к сожалению, иногда ее применяли неправильно, и это приводило к негативным последствиям.

Низкокачественные эксперименты: MVP «Горелая пицца»

Дес Трейнор (Des Traynor), соучредитель Intercom, поделился мысленным экспериментом. Одна команда попыталась выяснить, существует ли рынок сбыта пиццы. В целях экономии участники взяли второсортную печь. В итоге пицца каждый раз подгорала, и покупать ее никто не хотел. Но доказывает ли это, что рынка сбыта для пиццы не существует? Нет! Это лишь говорит о том, что нет рынка сбыта для горелой пиццы.

То же самое происходит, когда команда использует самые дешевые способы для добавления новой опции в приложение, тем самым снижая его производительность. Так можно лишь узнать, что пользователи любят быстрые продукты, но ничего полезного об обновлении.

Следите за тем, чтобы MVP был достаточно качественным и полным, чтобы соответствовать целям, ради которых он используется.

Недоработанный и неустойчивый продукт

Некоторые команды используют бережливый MVP для получения новых знаний, но затем бросают его и не пытаются сделать из него продаваемый или устойчивый продукт.

Например, пользователям понравился интерфейс Inbox (недолговечного почтового приложения от Google), но компании не удалось перевести корпоративных клиентов Gmail на новый продукт без воссоздания многих расширенных функций Gmail. В результате продукт был неустойчивым и продаваться не стал. Было принято решение отказаться от него и интегрировать отдельные элементы пользовательского интерфейса в Gmail, вместо того чтобы поддерживать две кодовые базы. Если бы команда с самого начала сосредоточилась на устойчивости продукта, ей, возможно, удалось бы найти подход, основанный на имеющейся функциональности Gmail.

ВРЕМЯ И ЦЕННОСТЬ

Улучшения продукта не несут никакой ценности, пока ими не начнут пользоваться.

Допустим, вы создали новый продукт, который будет избавлять людей от утомительной работы и экономить им несколько часов в день. Но до запуска, пока вы ведете разработку и проводите итерации, он не поможет высвободить ни одного часа.

Конечно, потраченное на доработку время сделает продукт лучше.

Чтобы выбрать время запуска, можно воспользоваться следующим графиком:

При выпуске релизов в контрольных точках 1 и 2 ценность продукта, полученная пользователями, равна зонам А и В. Если же первый запуск произошел лишь в точке 2, ценность соответствует только зоне В. Чем больше зона А, тем логичнее задуматься о более раннем запуске. Если продукт после первой контрольной точки уже приносит большую пользу или если до точки 2 должно пройти много времени, то лучше запустить продукт раньше и продолжить итерации.

Обязанности

РАЗБИВАТЬ ПРОЕКТ НА НЕСКОЛЬКО ЗАПУСКОВ И ПРОВОДИТЬ ПРОВЕРКУ НА РАННЕЙ СТАДИИ

PM должен правильно определять, что должно входить в каждый релиз. Если объединить слишком много функций, людям придется долго ждать, прежде чем они смогут воспользоваться вашим великолепным продуктом. Если же вы забудете включить в релиз какую-то важную функцию, запуск может провалиться, а вы сделаете ошибочные выводы о жизнеспособности идеи в целом.

Вот несколько советов о том, как можно разбить запуск продукта на несколько этапов:

• По допустимости риска и уровню дружелюбия: начните с релиза для пользователей, которые терпимо отнесутся к большинству багов, недостатку функциональности и проблемам с интерфейсом, чтобы получить обратную связь до того, как все эти моменты будут отточены. Можно разбить релиз так: сначала выпустить версию для тестирования в команде и внутри компании (догфудинг); далее – бета-версию для лояльных клиентов, затем сфокусироваться на новых пользователях, после – на всех остальных; и, наконец, осуществить полный запуск. Онбординг и продажу премиум-версии можно отложить до начала экспериментов с новыми пользователями.

• По сложности потребностей: сперва ориентируйтесь на клиентов с простыми потребностями, постепенно переходя к тем, у кого более комплексные запросы. Например, начните с тех, кто использует только ваш продукт, затем задействуйте тех, кто работает как с вашим продуктом, так и с продуктом другой компании, и, наконец, тех, кто предпочитает продукт конкурента. Первый релиз будет содержать лишь базовые опции, но более поздние версии будут иметь функционал, необходимый продвинутым пользователям.

• По настраиваемости: в первую очередь установите фиксированные опции, которые соответствуют ряду сценариев использования продукта, затем добавьте возможность кастомизации. Например, чтобы пользователь мог сначала создать шаблонный отчет, а затем уже настраиваемый.

• По типу клиента или варианту использования: подготовьте перечень требований для каждого типа пользователя или сценария применения, затем составьте на его основе небольшой список первоочередных задач. Начните с максимально короткого списка. Например, сначала можно создать продукт для любителей, а затем расширить функционал для профессионалов.

• По продолжительности взаимодействия: сначала разработайте опции, необходимые в первую неделю использования продукта, а позднее – уже те, которые потребуются при более плотной работе с ним. Например, можно отложить создание еженедельных email-сводок или отчетов об оттоке клиентов до завершения первого запуска.

• По стоимости: изучите все сметы расходов и выделите самые дорогие статьи. Проверьте, существует ли альтернативный вариант, который позволит избежать больших затрат, особенно при создании ранних версий. Например, можно применить простой эвристический алгоритм, а не алгоритм машинного обучения, или начать с использования уже готового компонента, не разрабатывая его специально под клиента.

Единственное, чего нельзя делать – это отказываться от шлифовки.

Если не хотите поссориться с дизайнером, то не стоит исключать шлифовку из объема работ или включать ее в более поздний релиз. Отточенность продукта и удовольствие пользователя от его использования очень важны для первого впечатления. Без шлифовки качество продукта заметно снизится. Поэтому лучше взять один пользовательский сценарий и проработать его максимально хорошо, чем заняться сразу несколькими, но сделать это кое-как.

Открыто поговорите с дизайнером о том, в каком объеме необходима шлифовка продукта. Но действуйте добросовестно: нельзя сначала добавить ее в объем работ, а потом исключить, если сроки будут поджимать.

Следите, чтобы объем работ не был слишком маленьким

Несмотря на то что важно не завышать затраты на разработку релиза и постараться запустить продукт как можно раньше, чтобы проверить потребности клиентов, – еще важнее следить за тем, чтобы между затратами и потенциальной выгодой соблюдался баланс. Если объем работ будет слишком маленьким, это может вызвать ряд проблем. Иногда дополнительные несколько дней или недель работы имеют решающее значение для юзабилити, удовлетворенности клиентов и успеха продукта. Зачастую гораздо дешевле создать полный набор функций с тем кодом, с которым инженеры уже знакомы, чем ждать целый год, пока они изучат новый, и только тогда просить заняться разработкой.

НЕПРАВИЛЬНОЕ ОПРЕДЕЛЕНИЕ ОБЪЕМА РАБОТ

Ноа Гано (Noa Ganot) поняла, во что может вылиться слишком маленький объем работ, выбирая, какие версии баз данных будет поддерживать продукт, который разрабатывала ее компания. Сначала предполагалось, что это будут только самые популярные версии, а новые всегда можно быстро добавить, если это потребуется клиенту.

К сожалению, при таком раскладе отделу продаж приходилось узнавать, какую конфигурацию использует каждый клиент, вместо того чтобы уверенно заявлять, что поддерживаются все версии. На раннем этапе это было приемлемо, но в какой-то момент стало проблемой. Некоторые клиенты даже не знали, какую версию базы данных они используют. Гано узнала об этой проблеме, поговорив с сотрудниками отдела продаж. Она поняла, что это тот случай, когда попытка не только удовлетворить срочные потребности клиентов, но и выполнить более масштабную работу (обеспечить поддержку всех версий баз данных, даже тех, которые пока не запрашивали) стоила вложений. Команда внесла изменения и в результате получила увеличенную конверсию продаж.

Вместо того чтобы неукоснительно следовать правилу включать в работу только те вещи, которые абсолютно необходимы для запуска, вместе с дизайнерами и инженерами взгляните на более длинный список желательных функций. Оцените их стоимость, размер выгоды, риски, которые могут возникнуть, если вы не включите их в релиз, и то, как изменятся затраты, если вы решите разработать их позднее. Если вы заложите в проект достаточное количество резервного времени, вы сможете использовать его для добавления пары приятных фишек, которые порадуют пользователей и увеличат ваши шансы на успех.

СОГЛАСОВЫВАТЬ ДЕЙСТВИЯ КОМАНДЫ ПО ПРИНЦИПУ БЕРЕЖЛИВОГО MVP

Если ваша команда еще не является приверженцем идеи бережливого MVP, можно попробовать приобщить ее к этой идее. Чтобы убедить людей начинать с мелких релизов или написания одноразового кода для целей тестирования, необходимо, чтобы они были готовы вас выслушать, хотели чему-то научиться и доверяли вам.

И действовать надо в зависимости от того, какие опасения и сомнения есть у вашей команды.

• Страх того, что код останется в незавершенном состоянии: найдите способы сделать так, чтобы код был дописан до конца. В зависимости от принятых в вашей компании процедур это могут быть четко обозначенные OKR, общее понимание того, что подразумевается под словом «готово», установленная для всех дата запуска или фиксированный процент пользователей будущего обновления. Список дополнительных работ, которые команда должна выполнить, прежде чем перейти к новой задаче, лучше начать составлять как можно раньше.

• Опасение, что руководство может снять людей с проектов после завершения MVP: если в вашей компании уже случалось, что людей слишком рано отстраняли от проектов, попробуйте сперва убедить руководителей в том, что MVP не является окончательным вариантом продукта. Попробуйте договориться о том, чтобы команда продолжала работу до тех пор, пока продукт не станет стабильным и пригодным для запуска в производство или не будет полностью уничтожен.

• Беспокойство по поводу затрат времени на бесполезную работу: попробуйте приучить команду к работе с MVP, построенными на совсем коротком коде или вообще без него. Приведите пример, как подобное разовое действие может сэкономить время во многих ситуациях.

Если команда в целом согласна с принципами бережливого MVP, но при этом настаивает на ненужном расширении границ проекта, то возможно, что вы недостаточно точно определили, какую информацию вы хотите получить от конкретного MVP. Четко сформулируйте свою гипотезу и риски, которые нужно просчитать при помощи MVP. Здесь пригодится дерево решений: оно наглядно покажет вашим коллегам, в какой момент можно расширить границы проекта, как они того хотят.

ВКЛАДЫВАТЬСЯ В СИСТЕМЫ, КОТОРЫЕ ПОДДЕРЖИВАЮТ ПОШАГОВУЮ РАЗРАБОТКУ

Пошаговая разработка приносит более высокие результаты, если есть инфраструктура и все компоненты, необходимые для быстрого создания прототипов и дешевых ранних версий продукта. Если для реализации каждой маленькой идеи требуется много новых компонентов, миграция данных и тщательные дизайн-ревью, то вам будет трудно убедить команду создавать прототипы или MVP.

Если самым уязвимым местом является дизайн, направьте основные силы и средства на развитие системы проектирования и создание повторно используемых компонентов. С точки зрения процессов, можно установить правила «кратчайшего пути». Например, можно ввести правило, по которому любые А/В-тесты с использованием имеющихся компонентов будут проводиться без дизайн-ревью или согласований на высшем уровне.

С точки зрения инженерии, здесь может сработать улучшение модели данных или корректировка фреймворка с целью поддержки необходимых вам видов экспериментов. Обсудите с инженерами, какие меры потребуются для проведения быстрых тестов.

Практики роста

ПРИЗНАЙТЕ, ЧТО ВЫ НЕ ЗНАЕТЕ ТОЧНО, КАКИМ ДОЛЖЕН БЫТЬ ПРОДУКТ

Велосипедные шлемы – хорошая штука, не так ли? Они снижают риск летального исхода от удара головой при падении минимум на 50 %. Как шлем вообще может навредить? Ну, разве что испортить прическу?

Оказывается, все немного сложнее. Когда люди надевают шлем, их поведение меняется. Они начинают ездить быстрее, выезжают в плохую погоду, пользуются дорогами с оживленным движением, смелее входят в крутые повороты. Автомобилисты на дорогах не так охотно уступают им место.

Кто-то не хочет таскать с собой шлем и предпочитает доехать на встречу на машине – поэтому трафик на дорогах усиливается, количество велосипедов снижается, загрязнение растет, люди меньше двигаются, перестают понимать, как обращаться с велосипедом на дороге, и т. д. В Австралии после введения закона об обязательном ношении шлемов был отмечен резкий спад использования велосипедов⁶⁴. Вот так.

ТО ЕСТЬ ШЛЕМЫ – ЭТО ПЛОХО?!?

Нет! Мы не выступаем против шлемов. Нисколько. Именно шлем спас моему мужу жизнь, ну или по крайней мере функционирующий мозг, несколько лет назад⁶⁵.

Тем не менее, то, что может быть разумным само по себе, не всегда идеально вписывается в реальную жизнь. Люди – сложные существа, как и весь мир.

Что это значит с точки зрения разработки продукта? Получается, что нужно проявить скромность и принять тот факт, что идеи, которые на первый взгляд кажутся замечательными, могут разочаровать вас на практике. Поэтому нужно относиться к ним как к гипотезам.

Очень хочется верить, что вы точно знаете, что нужно клиенту, особенно после того, как вы хорошо поработали и проанализировали продукт. Но и люди, и продукты очень сложны. Обратная связь, которую вы получаете, проводя исследования пользователей в контролируемых условиях, не всегда соответствует тому, как люди будут применять (или не применять) ваш продукт в реальной жизни.

Мы убедились в этом однажды во время разработки настраиваемых полей для Asana. Мы провели обширное исследование потребностей пользователей и составили список обязательных функций. Но во время бета-тестирований нам постоянно поступал один и тот же запрос на добавление полей с цветовой маркировкой. В первоначальных исследованиях этот момент не всплыл, потому что пользователи не могли знать о том, что им это понадобится, пока не опробовали функцию на собственном опыте. К счастью, внести изменения было несложно, и мы успешно запустили продукт.

Запуская продукт частями, вы получаете обратную связь на более раннем этапе и можете сделать более качественный продукт.

ПЛАНИРУЯ ОПТИМИЗАЦИЮ, УЧИТЫВАЙТЕ СРОКИ

Не стоит всегда начинать работу с MVP или каждый раз уменьшать объем работы до минимума.

Например, иногда дешевле внести изменения, когда у вас есть лишь часть кода, чем переносить их на несколько месяцев вперед. Когда ведется активная работа, вы остаетесь полностью в курсе дел. А вот спустя месяцы вам может потребоваться освежить свою память или даже заново настроить среду разработки. Поэтапные запуски могут повлечь дополнительные расходы, и иногда лучше не разбивать работу, пока она успешно ведется. Кроме того, увеличение сроков реализации проекта на 5–10 % особой роли не играет.

Продвигаясь по служебной лестнице, важно научиться более гибко смотреть на то, что должно войти в тот или иной релиз. Постарайтесь разработать фреймворки для тех случаев, когда добавление функциональности или более глубокой шлифовки будет оправданно. Учитывайте следующие моменты:

• Стоимость работы с точки зрения дополнительного времени на решение этих вопросов: сколько процентов от общего времени оно составляет и как повлияет на распределение контрольных точек. Если затраты невысоки и вы можете уложиться в срок, то можно рассмотреть добавление задачи в общий перечень работ.

• Выгода, которую могут получить клиенты и бизнес от работы. Если она огромна, а главное, может серьезно повлиять на успех проекта, то такую задачу стоит рассмотреть.

• Моральный дух команды. Если кто-то в команде очень сильно беспокоится о какой-то задаче и при этом она не требует больших затрат, то может иметь смысл ее выполнить.

• Сроки оптимизации (шесть месяцев или год). Будет рискованно тормозить работу ради выгоды, которая не окупится и через полтора года.

• Вероятность подтверждения гипотезы. При высоком шансе успешного запуска дополнительная работа может дать вам определенное преимущество. Но если весь проект будет закрыт, то вы просто потратите ресурсы впустую.

УТОЧНЯЙТЕ И УПРОЩАЙТЕ ГИПОТЕЗЫ

Когда несколько проблем и вопросов переплетаются между собой, это может помешать правильно определить объем работ. Внимание переключается с одной задачи на другую, и становится сложно с уверенностью сказать, какие из них можно исключить.

Только распутав клубок вопросов и выяснив ключевую проблему, вы сможете эффективно определить объем работ.

УТОЧНЕНИЕ ГИПОТЕЗЫ

Когда Сэм Гертлер (Sam Goertler) работала PM в Asana, ей поручили разобраться с тем, что продукт казался клиентам слишком сложным в использовании. Вместе с командой она превратила эту неоднозначную и трудноразрешимую проблему в такую гипотезу: если добиться максимальной ясности для данного сценария управления проектом, количество новых пользователей увеличится. Затем она сократила ее до фразы «максимальная ясность», чтобы всем было проще эту идею запоминать, применять и передавать.

Это уточнение помогло команде разрешить такие сложные задачи, как изменение дизайна, направленное на оптимизацию всех других сценариев управления проектами. Вскоре все члены команды на любой вопрос отвечали: «Какой вариант обеспечит максимальную ясность?»

ПООЩРЯЙТЕ ПРИМЕНЕНИЕ КОНЦЕПЦИИ MVP И ПРОТИВОДЕЙСТВУЙТЕ ПЕРФЕКЦИОНИЗМУ В СВОЕЙ ОРГАНИЗАЦИИ

Для многих людей перфекционизм не представляет собой ничего ужасного – когда кто-то говорит, что это его самая слабая сторона, многие воспринимают это как шутку.

Но для большинства продуктовых команд перфекционизм является настоящей проблемой. Очевидно, что это не касается программных систем с повышенными требованиями к критичности, таким как ПО для космических ракет или медицинских устройств. Но зачастую намного лучше запустить продукт с багами или недоделками, чем вкладывать в него неоправданно большие силы и средства.

Чрезмерная трата времени на выполнение какой-то задачи приводит ко многим проблемам:

• Время разработки имеет реальную цену – это зарплата команды. Если у вас стартап, вам будет сложнее взять разгон – шансы на успех компании заметно снизятся.

• Откладывание запуска сопряжено с издержками упущенной выгоды. Клиенты начнут получать ценность от продукта и платить за нее только после запуска.

• Если вы не получаете обратную связь от реальных клиентов, вероятно, ваши действия по улучшению продукта направлены не туда. Например, вы пытаетесь провести тонкую настройку UI, хотя его необходимо полностью менять, или исправить баг, от которого пострадает всего пара пользователей.

Вы, как руководитель, должны сделать так, чтобы ошибаться было безопасно. Если команда извлекла урок из какой-то ситуации – отпразднуйте это. Удалось четко определить объем работ – похвалите. Не позволяйте людям подтрунивать друг над другом за неправильный выбор. Проследите, чтобы время итераций после запуска MVP не сокращалось, – у команды должно быть время на применение полученных знаний. Убедитесь, что цели команды или OKR не противоречат принципам пошаговой разработки. Укажите людям, на какие задачи они могут тратить меньше времени.