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

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

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

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

Цифровое производство действительно двигают группы, в чем-то похожие на предпринимательскую команду в гараже. Основу этой команды обычно составляет сбалансированная группа, объединяющая все разнообразные качества и возможности, необходимые для запуска цифровых продуктов и услуг, а также для быстрой интерпретации сведений, полученных в результате двустороннего разговора. Сотрудники этих команд обычно выполняют три основные функции: проектирование, управление продуктом и дизайн. По степени устойчивости конструкции – это табурет на трех ножках. Проектирование занимается физическим осуществлением – созданием продукта. Управление контролирует жизнеспособность бизнеса – как ему поддерживать свое существование. Дизайн улавливает предпочтения – как сделать что-то, чего хотят люди[64].

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

Преобразование разработки цифровых продуктов

В 2012 году PayPal, компания электронных платежей, назначила Дэвида Маркуса на должность президента. Маркус, который присоединился к компании в 2011 году, когда она приобрела его стартап, задумал модернизировать PayPal, которая к тому времени превратилась в медлительную бюрократическую компанию. Он хотел вернуть ей предпринимательский дух, который у нее когда-то был. Маркус изменил способ распределения людей по командам. Он ограничил количество временных команд. Маркус организовал рабочие помещения так, чтобы команды могли находиться вместе. Также он изменил метод работы групп-разработчиков – вместо жестких, последовательно «каскадных» подходов предложил им более гибкий подход.

Одним из самых первых проектов PayPal, применившим такой подход, стала доработка продукта Checkout. В то время Checkout генерировал 75 % дохода PayPal, что составляло примерно 3,5 млрд долларов. Маркус собрал небольшую команду во главе с Биллом Скоттом, опытным технарем, которого переманили из компании Netflix, и поставил цель запустить модернизированный продукт через шесть недель.

Если вам такой подход кажется слишком напористым, согласимся с вами, особенно с учетом ситуации в PayPal в то время. В 2011 году на создание приложения в среднем уходило полгода, а это 26 недель. Внесение простых изменений на страницу могло занять шесть недель. На изменение текста в нижнем колонтитуле веб-страницы уходило два месяца. Дела продвигались медленно по двум причинам. Во-первых, технологическая платформа компании со временем стала фрагментированной, поэтому внесение простых изменений часто требовало кропотливой и однообразной работы. Во-вторых, административные процессы – проектирование, утверждение, построение, тестирование и снова утверждение – были очень медленными. Работа переходила от одного отдела к другому в весьма неторопливом темпе.