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

Однако важно понимать, что для последовательных, небольших и частых релизов Agile-методы необязательны.

На самом деле, многие опытные продуктовые команды по всему миру освоили методику последовательного внедрения очень маленьких релизов (так называемая непрерывная интеграция и непрерывное внедрение, или CI/CD), но при этом не следуют никаким формальным Agile-процессам или методам.

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

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

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

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

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

Глава 8. Меняем алгоритм решения проблем

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Конец ознакомительного фрагмента.

Текст предоставлен ООО «Литрес».

Прочитайте эту книгу целиком, купив полную легальную версию на Литрес.

Безопасно оплатить книгу можно банковской картой Visa, MasterCard, Maestro, со счета мобильного телефона, с платежного терминала, в салоне МТС или Связной, через PayPal, WebMoney, Яндекс.Деньги, QIWI Кошелек, бонусными картами или другим удобным Вам способом.

Notes

1

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

2

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

3

Самым вопиющим примером того, что называют фальшивым Agile, является подход SAFe (Scaled Agile Framework), но даже команды, использующие простую методику Scrum и выпускающие продукты только раз в месяц или квартал, упускают реальные преимущества Agile.

4

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

5

Рекомендуем книгу Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations (Форсгрен Н., Хамбл Дж., Ким Дж. Ускоряйся! Наука DevOps: как создавать и масштабировать высокопроизводительные цифровые организации. – М.: Альпина PRO, 2022).

6

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