Ознакомительная версия. Доступно 11 страниц из 55
медлительную бюрократическую компанию. Он хотел вернуть ей предпринимательский дух, который у нее когда-то был. Маркус изменил способ распределения людей по командам. Он ограничил количество временных команд. Маркус организовал рабочие помещения так, чтобы команды могли находиться вместе. Также он изменил метод работы групп-разработчиков – вместо жестких, последовательно «каскадных» подходов предложил им более гибкий подход.
Одним из самых первых проектов PayPal, применившим такой подход, стала доработка продукта Checkout. В то время Checkout генерировал 75 % дохода PayPal, что составляло примерно 3,5 млрд долларов. Маркус собрал небольшую команду во главе с Биллом Скоттом, опытным технарем, которого переманили из компании Netflix, и поставил цель запустить модернизированный продукт через шесть недель.
Если вам такой подход кажется слишком напористым, согласимся с вами, особенно с учетом ситуации в PayPal в то время. В 2011 году на создание приложения в среднем уходило полгода, а это 26 недель. Внесение простых изменений на страницу могло занять шесть недель. На изменение текста в нижнем колонтитуле веб-страницы уходило два месяца. Дела продвигались медленно по двум причинам. Во-первых, технологическая платформа компании со временем стала фрагментированной, поэтому внесение простых изменений часто требовало кропотливой и однообразной работы. Во-вторых, административные процессы – проектирование, утверждение, построение, тестирование и снова утверждение – были очень медленными. Работа переходила от одного отдела к другому в весьма неторопливом темпе.
Проект по модернизации Checkout назывался Hermes. Дизайнеры и разработчики работали в одной комнате. Начался еженедельный цикл проектирования, построения, тестирования и обучения. Они отказались от старых последовательных процедур. Вместо этого члены команды расписывали свои идеи на доске, а затем возвращались за свои столы и создавали то, что они только что расписали. Они тестировали продукт вместе с клиентами, обращая внимание на то, что работало, а что – нет, а затем анализировали свои разработки исходя из полученных знаний. Основываясь на этом двустороннем общении со своей целевой аудиторией, они разработали приложение в течение нескольких дней, а через несколько недель уже были уверены в нем. И даже несмотря на то, что они не могли представить продукт через шесть недель (нельзя изменить технологические циклы так же быстро, как процессы, зависящие от человека), они вышли на этап значительной трансформации. Члены команды инициировали изменения в PayPal в направлении более предпринимательской компании.
Сейчас новый совместный подход является в PayPal нормой. Над проектами работают многофункциональные команды. Они способны запустить новый код в реальном времени в течение нескольких минут, а не недель. Это свидетельствует о том, что компания осуществила радикальные изменения – в способе не только командной организации работы, но и всего технологического комплекса, устройства рабочих мест и многого другого[65].
Возможность экспериментировать и обучаться с помощью совместной работы
Почему этот подход оказался так важен для PayPal и почему он так быстро становится стандартным способом интеграции цифровых технологий в операционную среду компании? Дело в том, что такой тип сотрудничества позволяет командам заглянуть в будущее.
В индустриальной модели процесс работы упорядочен – различные отделы и специалисты отвечают за свой участок. Например, шасси автомобиля проходит через сборочный конвейер, и на каждом этапе выполняются различные операции. В цифровую эпоху данный подход иногда дублируется и для разработки цифровых продуктов.
Например, в крупных цифровых агентствах производство веб-сайтов для клиентов часто проходит через прогнозируемые последовательные стадии. Ведь чтобы продавать продукты, нужно учесть требуемые для этого людские ресурсы и объем работы. В начале проекта подход разрабатывают стратеги. Затем, как правило, подключаются исследователи, которые общаются с клиентами или проводят анализ за столом. Они преподносят свои идеи в виде отчета для клиента, который также передается проектной группе агентства. Потом исследователи и стратеги переходят к другим проектам, а этим начинают заниматься дизайнеры. Дизайнеры берут идеи исследователей и прогоняют их через wire framing – процесс создания шаблона для сайта, а затем передают эту работу другим специалистам для завершения графического дизайна. Потом проекты передаются инженерам, которые создают продукт. Наконец, работа переходит к подразделению контроля качества, специалисты которого составляют план тестирования и проверяют сайт на ошибки. После чего сайт передается операционной команде, которая ответственна за его загрузку на производственный сервер и за саму загрузку сайта. (Аутсорсинговые проектные фирмы тоже часто используют некоторые версии этого процесса, хотя на ранних этапах основное внимание уделяется определению требований, а не стратегии, и проектные работы, скорее всего, будут связаны с техническим проектированием и выстраиванием архитектуры систем).
Экономика крупного агентства, похоже, требует использования подобного подхода. В крупном агентстве загруженность персонала является ключевым показателем, поэтому такие агентства структурированы таким образом, чтобы максимизировать оплачиваемые часы каждого «ресурса». Так что на этапе определения стратегии стратеги загружены по полной, а остальные специалисты отдыхают. Клиент, по понятным причинам, не хочет платить бездействующим членам команды, поэтому, если агентство не может найти способ обосновать счет, ему самому придется платить людям за бездействие. В результате таких сотрудников, как правило, подключают к другим проектам, пока не начнется их фаза работы над данным проектом.
Это все совершенно разумно, и в то же время совершенно неправильно. Давайте выясним почему.
УПРАВЛЕНИЕ ЦЕННОСТЬЮ ПРИ ПРОЕКТНОМ ПОДХОДЕ
Первая проблема здесь заключается в том, что оригинальный подход, задуманный клиентом и командой по продажам, скорее всего, будет только частично правильным. Что означает, что он также частично будет неправильным. Проекты нуждаются в способе исправлять эту ситуацию, иначе старые ошибки будут усугубляться. Если решения и информация двигаются только в одном направлении (вниз по течению), у вас никогда не будет возможности исправлять ошибки по мере продвижения.
Вторая проблема с такого рода проектным потоком состоит в том, что знания, которые создаются на каждом этапе работы, теряются в каждой точке передачи. Знания не похожи на шасси автомобиля. Они не могут двигаться по ленте сборочного конвейера. Они живут в нашей голове. Они хаотичны и никогда не могут быть полностью переданы от одного человека к другому. Вне зависимости от того, насколько хорошо мы документируем то, что узнали, что-то из этого остается в нашей голове, а что-то либо неправильно интерпретируется, либо искажается предубеждениями носителя этих знаний или их получателя.
Все это приводит к очевидной и сокрушительной проблеме – к высокой вероятности создания неправильного продукта. Поэтому проектный подход является действенным, но не эффективным. Его применение широко распространено, но результат не создает ценности.
СОЗДАНИЕ САМОДОСТАТОЧНОЙ КОМАНДЫ
Альтернативой индустриальной модели является создание небольших, самодостаточных команд, использующих подход «почувствовать и отреагировать». Этим командам предоставляется независимость в самостоятельной работе по выполнению порученного задания – в поиске и создании ценности. Самостоятельная команда имеет полный набор возможностей для
Ознакомительная версия. Доступно 11 страниц из 55
