От автора перевода

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

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

Уверен, что с аналогичными проблемами сталкивается абсолютное большинство продуктовых компаний. В качестве рабочего инструмента для решения этих проблем полезным представляется подход, описанный в статье Ленни Рачитски, product lead Airbnb.

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

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


_{Первые наработки запущенного продукта, дающие возможность путешественникам Airbnb находить мероприятия, в которых можно участвовать вместе с другими путешественниками}

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



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

• Шаг 1. Кристаллизация проблемы
• Шаг 2. Согласование проблемы с командой и стейкхолдерами
• Шаг 3. Постоянный возврат к проблеме

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

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

Шаг 1. Кристаллизация проблемы

Начните с ответа на эти вопросы о своем проекте.

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

Описание: что это за проект?

Это краткое описание идеи. Люди, читающие его, смогут быстро понять суть. Будьте кратки.

Проблема: какую проблему он решает?

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

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

1. Проблема кратка. Цель – описать проблему одним предложением. Чем больше вам требуется объяснений, тем менее ясной становится проблема в конечном итоге.
2. Сфокусирована. У нас есть единственная ясная проблема, которая может быть решена одной командой и в разумные сроки. Часто очень полезно привести несколько примеров других проблем, которые вы НЕ решаете.
3. Связана с неудовлетворенной потребностью. Сосредоточьтесь на потребностях пользователя или бизнеса. Тут крайне полезно использовать вот этот фреймворк.
4. Включает ответы на вопрос что и почему. Что идет не так и почему это проблема? Возможно, вам придется вернуться сюда в следующей секции.
5. Не зависит от решения. Подавляйте в себе желание слишком быстро перейти к решению проблемы.

Хорошие примеры постановки проблемы

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

Плохие примеры постановки проблемы

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

Почему: как мы поняли, что это реальная проблема и ее нужно решать?

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

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

Несколько советов для этого шага.

1. Изучите количественные и качественные доказательства. Соберите все данные, которые указывают на то, что это действительно реальная и важная проблема.
2. Качество важнее количества. От 3 до 5 прямых фактов лучше дюжины косвенных. Во втором случае ваши выводы будут слабее, так как они будут основаны на второстепенных и не имеющих отношения к делу фактах, выглядящих как куча доказательств. Лишний перфекционизм также ни к чему.
3. Сыграйте сами с собой в адвоката дьявола. Попытайтесь убедить себя, что это совершенно незначимая проблема. Какие пробелы имеются в ваших доказательствах? Действительно ли доказательства соответствуют тому, что вы думаете? Проверьте себя.

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

Успех: как мы узнаем, что проблема решена?

Вы достигли того, что планировали достичь? Как вы узнаете? Ответьте на этот вопрос и запишите ответ.



Этот критерий становится невероятно важен на протяжении всего проекта, так как он помогает принимать решения и расставлять приоритеты. Фича X увеличивает шансы достичь поставленной цели? Если нет, не делаем ее.

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

Несколько советов для определения критериев успеха.

• Постарайтесь получить конкретное число, например: 10% – прирост показателя X; 50% – уменьшение показателя Y.
• Цель должна быть достижима, но амбициозна. Достижение какой цели приведет вашу команду и руководителей в восторг?
• Если вы не смогли придумать метрику для своей цели (думать нужно долго и напряженно), опишите, как будет выглядеть мир в случае успеха проекта. Сделайте это критерием успеха.

Аудитория: для кого мы делаем это?

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

Что: как будет выглядеть реализация в продукте?

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

Шаг 2. Согласование проблемы с командой и стейкхолдерами

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



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

Я обычно подхожу к этому шагу так.

1. Возьмите документ, созданный на первом этапе (это может сделать и любой член вашей команды, вовлеченный в эту проблему).
2. Поделитесь им со всей командой. Соберите обратную связь. Доработайте документ с учетом полученной обратной связи и снова предоставьте его на общее обозрение.
3. Если обратная связь сходится и команда выглядит синхронизированной – отлично. Если нет, соберите всех вместе и обсудите разногласия.
4. Когда согласие внутри команды будет достигнуто, синхронизируйтесь в понимании проблемы со стейкхолдерами. Важно, чтобы ваша команда и люди, которые будут оценивать результаты, одинаково понимали проблему, которую вы решаете, до того, как вы плотно приступите к работе по проекту.
5. Соберите команду и снова произведите ревью постановки проблемы. Отыщите ответы на нерешенные вопросы и убедитесь, что у команды есть все необходимое, чтобы начать работать.

Шаг 3. Постоянный возврат к проблеме

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



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

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

Избежать этой ловушки помогут полезные привычки.

1. При каждом ревью проекта удостоверьтесь, что исполнитель начинает с постановки проблемы. Если это не очевидно, задайте вопрос: «Какую проблему мы пытаемся решить?».
2. При каждом отчете о ходе проекта перед стейкхолдерами возвращайтесь к постановке проблемы. Убедитесь, что у всех остается одинаковое ее понимание.
3. Перед финализацией проекта спросите себя: «Чувствую ли я уверенность в том, что мы готовы решить проблему, которую планировали решить изначально?».

И в заключение

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

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

Марк Менсон. Тонкое искусство пофигизма

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

Очень рекомендую прочитать следующие 5 книг.

1. Deep Work (Кэл Ньюпорт. В работу с головой. Паттерны успеха от IT-специалиста)
2. The Subtle Art of Not Giving a F*ck (Марк Менсон. Тонкое искусство пофигизма)
3. Good Strategy, Bad Strategy (Ричард Румельт. Хорошая стратегия, плохая стратегия. В чем отличие и почему это важно)
4. Measure What Matters (Джон Дорр: Измеряйте самое важное. Как Google, Intel и другие компании добиваются роста с помощью OKR)
5. Lean Analytics (На момент написания статьи не переведена на русский)

От автора перевода

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



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

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