Как быстро создавать продукты

Операционная динамика Stripe — «действуй»

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

Эти замечательные маленькие анекдоты включают в себя:

• Строительство Эйфелевой башни, которое заняло два года и два месяца.
• Первая итерация Диснейленда, которая была построена всего за 366 дней.
• Строительство Эмпайр-стейт-билдинг, которое началось и завершилось в течение 410 дней.

Принципы выполнения, изложенные бывшим учёным из Белого дома Ди Джеем Патил, включают вопрос: «Что нужно сделать, чтобы сократить сроки в два раза?».

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

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

Скорость как принцип работы над продуктом, которым можно гордиться

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

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

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

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

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

Несмотря на всё это, скорость важна.

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

Скорость против отсутствия фокуса; это не одно и то же

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

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

Почему скорость имеет значение

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

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

Выбор действовать быстро как принцип работы над продуктом

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

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

Децентрализовать принятие решений

Один из самых быстрых способов замедлить продуктовые команды — это обременить их медленными процессами принятия решений.

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

Ответственность за принятие решений

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

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

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

Мотивировать команды выполнять работу

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

По моему опыту, мотивация команд для выполнения работы включает в себя три критически важных аспекта:

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

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

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

Спрашивать «можно ли сделать это быстрее?»

На всех этапах процесса разработки продукта вопрос «можно ли сделать это быстрее?» поможет действовать быстро.

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

Пример — создание инструмента обслуживания клиентов

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

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

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

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

Нанимать быстрых работников

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

«Скорость — это поведение, а не навык. Вот почему вы должны нанимать таких людей, а не надеяться взрастить это (не работает). Это также подразумевает увольнение инженеров, которые не соответствуют вашей скорости».

Увольнение кого-то из-за того, что он не успевает, звучит немного жёстко (!), и я не согласен с тем, что скорость — это фиксированное поведение, которое нельзя культивировать, но понимание скорости как поведения — это важный момент.

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

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

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

Устранить ненужный процесс

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

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

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

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

1. Планирование понедельников — весь день будет посвящён планированию.
2. Определение размеров четвергов — вы уже догадались, всё определение размеров будет проходить в четверг.
3. Двухнедельные спринты для всех.
4. Демонстрации по пятницам — каждый будет демонстрировать свой спринт на конец двухнедельного периода.

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

Выбор процессов разработки продукта

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

Современные процессы разработки продукта могут включать в себя любое из следующего:

1. Scrum — полезен для предсказуемости и сдерживания заинтересованных сторон, которые требуют всего и сразу.
2. Kanban — более гибкий и текучий, может адаптироваться к меняющимся условиям.
3. Scrumban — потенциально лучшее из обоих миров, позволяющее выбрать элементы из Scrum и Kanban.
4. Plan -> Build (iterate) -> Ship — подобно мини-водопаду, инженеры, PM и дизайнеры работают вместе, чтобы выпускать небольшие функции.
5. Shape up — 6-недельные циклы для создания чего-то значимого.
6. GSD (Get Shit Done) — популяризирован Shopify, похож на ShapeUp с тремя этапами: think, explore, build.

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

Инвестировать в DevOps

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

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

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

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

Автоматизировать как можно больше

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

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

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

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

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

Обобщая всё сказанное

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

Это непросто.

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