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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

#менеджмент #проекты #продукты #разработка