Читать книгу Бизнес-трансформация. Как перестроить традиционную модель по законам Кремниевой долины - Марти Каган - Страница 12

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

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

На самом деле в большинстве современных компаний доля по-настоящему прибыльных функций и проектов в «дорожных картах» удручающе мала. Большинство отраслевых аналитиков оценивают их в диапазоне от 10 до 30%.

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

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

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

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

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

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

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

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

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

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

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

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

ОБОЗНАЧЬТЕ КОМАНДАМ ПРОБЛЕМЫ И ПОЛНОМОЧИЯ ДЛЯ ИХ РЕШЕНИЯ

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

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

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

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

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

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

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

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