Ознакомительная версия. Доступно 12 страниц из 59
«Всегда думайте: “А зачем?” — настаивает Мина Радхакришнан. — Нет смысла делать функцию, если не знаете, для чего она. Новых идей тысячи, но к чему они приведут? Какова цель их воплощения? Как они связаны с целями компании?»
В интервью мы услышали столько ценных предложений, что решили составить шпаргалку, о чем лидеру стоит задуматься, уравновешивая потребности клиента и своей организации:
• понять, зачем решать эту проблему клиента;
• понять, приведет ли предлагаемое компанией решение к желаемому результату;
• понять проблемы обеих сторон — клиента и компании — и выяснить, как они связаны;
• сосредоточиться на «проблеме номер один», а не «два» или «три»;
• выделить в недельном расписании время для общения с клиентами или пользователями;
• узнать о насущных потребностях пользователя, проведя опросы или наблюдения;
• разработать роадмап с обозначением ключевых тем и приоритетов;
• определить время, которое понадобится команде на внедрение проекта;
• выяснить, нужна ли команде помощь со стороны (фрилансеры, агентства и т. д.);
• обсудить технические детали того, как сделать результат интересным и инновационным.
Всем командам на сбор и анализ этой информации потребуется разное количество времени. Опытный лидер продукта всегда контролирует и направляет процесс принятия решений во избежание расползания границ и возникновения сдерживающих факторов. Для этого требуется постоянно напоминать коллективу о целях компании. Аманкона рассказывает: «Мы делаем это с помощью целей и ключевых результатов (OKR), установленных для всей компании Google. Большинство команд полностью полагается на них. У нас есть ежегодный план, с которым мы сверяемся в конце года. Мы только что завершили планирование на 2017 год и предусмотрели анализ сделанного: что прошло хорошо и где мы еще упускаем возможности? Какова ситуация в нашей сфере? К чему мы идем? На что сделаем крупные ставки в предстоящем году? Руководство объединилось, и при помощи всех команд мы пытаемся определить ключевые задачи на будущий год. Это может быть что угодно — от небольших изменений и подтверждений, что именно это стоит продолжать, до значительных преобразований».
Цели и ключевые результаты, видение продукта и другие важные показатели помогут команде решить, что в черновом роадмапе стоит вложения усилий.
Знакомство с клиентом
В книге мы часто упоминаем Directed Discovery, дизайн-спринты и другие методы исследований. Они представляют большую ценность, и успешные лидеры продукта постоянно обращаются к ним. Исследуйте, собирайте данные, делайте прототипы, пока не поймете проблему и не сформулируете решение, четкое и несомненное. В наше время тестирование очень доступно, а инструменты прототипирования практически бесплатны, поэтому неверной формулировке проблемы и соответствующего решения нет никаких оправданий.
В докладе InVision по дизайну продукта за 2016 год[27] предложено 87% дизайнерских прототипов. Это число впечатляет и вдохновляет, но лидеру продукта нужно, прежде всего, убедиться, что все команды занимаются такими исследованиями и пользовательскими тестами, имеющими непосредственное отношение к прототипированию. В Pluralsight, Fresh Tilled Soil и Mind the Product количество прототипов достигает 100%. Тестируются все без исключения проблемы, потому что отсутствие тестов не может быть оправдано ничем.
Предварительное тестирование среди пользователей и сбор обратной связи до начала работы пойдут на пользу и вам, и продукту, и компании. «Реальная стоимость функции — это не издержки на дизайн, инжиниринг, продукт и все остальное, что для нее нужно, — предупреждает Майк Браун. — Реальная стоимость станет понятна только после выпуска. И не раньше, потому что только тогда у вас есть что-то, что может сломаться. Это нужно учитывать во всем, что будет надстраиваться позже. Вот почему реальная стоимость известна только после реализации». Браун считает (и мы с ним согласны), что это обязывает к предварительному сбору информации для принятия решений и определения требований до начала работы.
Опыт в нашей сфере это подтверждает: основываясь на данных о своих членах, Институт электротехники и электроники (IEEE) установил, что исправление программной проблемы после внедрения обойдется в сто раз дороже, чем до[28].
Браун усвоил трудный урок и настаивает на прототипировании всех инноваций. «Вот, например, на этой неделе мы делаем бумажный прототип, который будем тестировать на сотрудниках компании. Мы спрашиваем их: “Какой смысл в этих аспектах взаимодействия? Есть ли что-то непонятное?”[29] Когда закончим с этим этапом, перейдем к деталям, и тогда подключим пациентов и понаблюдаем, как они используют конкретные взаимодействия. Таким образом мы выявим закономерности и узнаем, решат ли они какие-то проблемы сайта».
Генеральный директор Produx Labs Мелисса Перри согласна с мнением, что и в маленьких, и в крупных компаниях исследованиям отводится недостаточно внимания. «У некоторых это налаженный процесс, но большинство этим вообще не занимается, — говорит Перри. — Они создают минимальный жизнеспособный продукт, и он становится первой версией. Ее не меняют и не экспериментируют. Сделали одну версию и запустили. Они не измеряют ей свой успех. При таком подходе отсутствует логичный этап ответов на вопросы команды, возникшие до работы над кодом». Перри считает, что компании спешат вывести продукт на рынок и не выясняют, как и почему он работает. Чтобы избежать издержек в случае неудачи и кредитов на продукт, проводите хотя бы самое легкое тестирование (из разумных). Это лучший способ убедиться, что продукт окажется полезным и им будут пользоваться.
С решением правильной проблемы связаны разговоры с правильными людьми. Если знать, с кем говорить, то снижается риск, а знание, о чем говорить, принесет ценные плоды. Независимо от сферы всегда нужно знать конкретную проблему пользователей. А это можно выяснить лишь при непосредственном разговоре с ними, что требует верной постановки вопросов. Они позволят нащупать проблемы и определить, стоят ли они решения. «Это еще одна сложность стартапов и новых продуктов, — говорит Джим Семик. — Если внутри компании в чем-то видят проблему, то пользователь не обязательно считает так же. Для него может быть важнее разрешить что-то другое».
Прояснение «туманной клиентской стороны» заключается в признании лидером продукта (перед самим собой), что его приоритеты не всегда совпадают с приоритетами конечного пользователя. На ранних стадиях продукта правильный разговор не касается его компонентов, цены и внедрения. Основной фокус должен быть на понимании решаемой проблемы и оценке, стоит ли она решения. Иными словами, достаточно ли проблема важна для пользователя или клиента? Готов ли он отдать что-то ценное (время, деньги, энергию) за ее решение?
Ознакомительная версия. Доступно 12 страниц из 59
