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

Становление самодостаточной команды: непрерывное обучение

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

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

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

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

КАК ДЕЙСТВОВАТЬ: СОГЛАСОВАННОСТЬ РЕШЕНИЙ

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

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

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

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

Команды стратегии и управления продуктами спорили и предлагали каждая свое. В конце концов команда управления продуктом приняла решение создать приложение «одного брокера» (вариант 2). Важно отметить, что это решение было принято на основе аргументов его сторонников, а не на основе обратной связи с рынком.

Итак, команда разработчиков получила задание: создать приложение «одного брокера», где был бы предоставлен основной и новый бизнес.

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

МЫ ПРИВЯЗЫВАЕМСЯ К ИДЕЕ. И НЕВАЖНО, НАСКОЛЬКО ОНА ХОРОША. МЫ ХОТИМ ПРЕПОДНЕСТИ КОНЕЧНЫЙ ПРОДУКТ, КАК РОЖДЕСТВЕНСКИЙ ПОДАРОК ПОД ЕЛКОЙ. МЫ ХОТИМ ВЕЩЬ.

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

ИСПОЛЬЗОВАНИЕ ПОЭТАПНОЙ И ЦИКЛИЧНОЙ РАЗРАБОТКИ

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