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

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

Привет! Это pmclub. В блоге на vc.ru мы рассказываем обо всём из мира менеджмента продуктов и проектов: личные истории экспертов, кейсы, разборы и переводы, подборки инструментов, новостей и полезных статей. В новом материале мы сделали выжимку статьи Холмса — это продакт, который более 10 лет работал в eBay и британских банках. Из статьи вы узнаете, как мотивировать команду, распределять ответственность и не дёргать сотрудников по пустякам.

Иллюстрация Александра Панова
Иллюстрация Александра Панова

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

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

Здоровый подход

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

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

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

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

Скорость не должна мешать концентрации

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

Децентрализуйте принятие решений

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

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

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

Мотивируйте команду

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

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

«Можно ли быстрее?»

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

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

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

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

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

То есть скорость — это поведение, а не навык.

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

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

Не пытайтесь всё контролировать

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

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

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

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

Пусть команда сама выберет метод разработки

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

<p>Наиболее популярные системы организации для управления процессами разработки продукта</p>

Наиболее популярные системы организации для управления процессами разработки продукта

Наиболее популярные системы организации для управления процессами разработки продукта

Предложите им популярные методологии и вкратце расскажите о каждой:

  • Scrum — даёт предсказуемый результат и сдерживает стейкхолдеров, которые приходят с кучей запросов.
  • Kanban — более гибкий, может адаптироваться в зависимости от динамики.
  • Scrumban — лучшее из обоих миров. Позволяет выбирать инструменты из Scrum и Kanban
  • План → создание (итерация) → отправка. В этой схеме инженеры, руководители и дизайнеры работают вместе над разработкой небольших функций.
  • Упаковка продукта — шестинедельные циклы разработки.
  • GSD (Get Shit Done, покончи с этим дерьмом) – подход, который популяризирует Shopify. Похож на предыдущий пункт. Ключевые принципы: думай, исследуй, создавай.

Инвестируйте в DevOps

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

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

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

  • Быстрый доступ к новым ценностям для клиентов.
  • Мотивация для инженеров — они сразу видят, как клиенты используют их функции.
  • Стейкхолдеры и руководители чувствуют рост и доверяют команде, потому что видят результат.

Да, на старте придётся немало заплатить за DevOps. Но в итоге вложения окупятся.

Автоматизируйте всё

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

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

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

Спасибо, что дочитали до конца. За новыми материалами вы можете следить в нашем Telegram-канале.

1515
3 комментария

"Нанимайте быстрых разработчиков".... И как таких вычислить на этапе собеседований?

1
Ответить

А никак

1
Ответить

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

Ответить