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

Если вы сделаете это и прочитаете несколько руководств по реализации, то, возможно, у вас на подходе еще 3500 страниц. Это уже кризис бюрократии.

@noahkunin, 12 декабря 2014 года[26]

Мы испытали это на себе. Потенциальный государственный заказчик из США обратился в нашу компанию за помощью в разработке новой системы. Клиент представлял мощную коммуникационную платформу, способную связать правительство и избирателей, – современную систему двустороннего разговора. Это была увлекательная и уникальная возможность: в то время ничего подобного не существовало. Излишне говорить о том, что мы хотели участвовать в этом проекте.

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

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

Но ситуация меняется. Одним из первых проектов, над которым работала цифровая служба Великобритании, был новый способ заказа проектов – иначе говоря, новый способ утверждения расходов. Признав важность проверки предположений (а не определенных требований) до разработки системы в целом, GDS потратила восемь месяцев на исследование и тестирование, прежде чем перешла к заключительной альфа-фазе. GDS описывает это так: «При проектировании сервиса невозможно предсказать все заранее. В каждом проекте существует множество проблем, и на заключительном этапе [альфа-фазе] вы начнете исследовать решения для них»[27].

В США 18F таким же методом работает над правилами закупок. С конца 2015 года они экспериментировали со способами аккредитации подрядчиков и исполнителей и публиковали результаты этих экспериментов в своем блоге. К 2016 году они запустили пилотный проект этого нового подхода и подписали контракт на участие двух правительственных учреждений: ФБР и Министерства финансов США[28].

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

Нехватка нужных людей

Требуются определенные способности к овладению стилем работы «почувствовать и отреагировать». Люди, которые успешны в этой среде, в основном скромны, любопытны и чувствуют себя комфортно в условиях неопределенности. Они ориентированы на обучение и хорошее сотрудничество. Они хотят слышать мнения по поводу своей работы и готовы исправить ее, если что-то не так. Не все подходят под это описание.

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

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

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