Войти в систему
Войти с помощью соц. сетей:
Фундаментальная цель — достичь «мелкости» в крупных организациях.
Эрнст Фридрих Шумахер
Представьте себе следующую ситуацию. На дворе 1997 год, вам только что пришла в голову отличная идея — создать тонкое портативное устройство, которое помещается в карман и выполняет множество функций посредством прикосновения пальца. Это одновременно портативный телефон, адресная книга, карта, навигатор, посадочный талон, музыкальный и видеопроигрыватель, телевизор, камера, фонарик, диктофон, секундомер, будильник, переводчик, пульт дистанционного управления, хранилище газет и журналов со всего мира, библиотека с тысячами книг и так далее. Более того, устройство молниеносно выполняет любые запросы, и его можно адаптировать под индивидуальные потребности и предпочтения сотен миллионов человек со всего мира.
Звучит неплохо, не так ли? Вы уверены в беспроигрышности идеи. Но как ее воплотить? Что ж, сейчас 1997 год, и вы применяете лучшие на этот период управленческие практики. Первые несколько лет уходят на то, чтобы заверить всех в осуществимости идеи и убедить стратегический комитет крупной корпорации в разработке и выведении на рынок вашего нового потрясающего устройства. Когда одобрение наконец получено, вы нанимаете огромную команду дизайнеров и разработчиков. Последующие несколько лет команда занимается разработкой детализированных спецификаций устройства и строит график поставки и интеграции его различных компонентов. Затем вы берете на работу сотни тысяч инженеров и прочих специалистов, чтобы создать это устройство, и десятки тысяч менеджеров, которые будут управлять и контролировать действия технических сотрудников — в соответствии с четким планом. Вы вводите масштабные системы отчетности, чтобы высшее руководство знало, на что потрачен каждый доллар и насколько продвинулась работа над каждым компонентом. Вы создаете систему комитетов по координации, чтобы убедиться, что все многочисленные подразделения, словно слаженно играющий симфонический оркестр, трудятся над созданием устройства.
Что в итоге? Спустя многие годы, потратив миллиарды долларов, вы обнаруживаете, что ваше устройство по-прежнему не готово к выходу на рынок. Технические проблемы не устраняются, а, похоже, лишь растут в геометрической прогрессии. Координация работы между подразделениями вызывает огромную головную боль, несмотря на все усилия, приложенные соответствующими комитетами. Идет ожесточенный поиск виноватых в технических проблемах и задержках. Отдельные компоненты кажутся многообещающими, но зачастую несовместимы между собой. Подразделения обвиняют друг друга, но отрицают собственную вину. Устранение проблем занимает вечность: как только найдено решение одной, возникает другая.
Организовав работу подобным образом, вы надеялись достичь эффекта масштаба. Но результаты в корне противоположны. Затраты, связанные с организацией и координированием работы такого большого числа сотрудников, растут гораздо быстрее, чем любая добавочная стоимость, ими же создаваемая. Окончание работы по-прежнему остается под вопросом.
К сожалению, несмотря на затраченные годы, усилия и финансы, руководство принимает решение прикрыть ваш проект. Дело в том, что конкурент — Apple — к 2007 году разработал схожий продукт «с нуля до выхода на рынок». На это компании понадобилось всего 18 месяцев и гораздо меньшие затраты на традиционный менеджмент.
Как ей это удалось? Вместо того чтобы создавать очень сложное устройство с очень сложной организацией согласно разработанным спецификациям, Apple поступила с точностью до наоборот. Она создала сравнительно простое физическое устройство — iPhone. При этом она работала короткими циклами, постоянно совершенствуя продукт. Компания не стала нанимать сотни тысяч инженеров, чтобы создать монолитное ПО для выполнения функций устройства, а подготовила технологическую платформу и пригласила сотни тысяч независимых команд, которые могли создавать собственные специализированные приложения, удовлетворяющие любые потенциальные потребности пользователя. Команды разработчиков предлагают их потребителям Apple напрямую. Все эти приложения выполняют практически бесконечное множество функций. Они добавляются по мере разработки, при этом их авторы напрямую взаимодействуют с пользователями. Последние решают, какие приложения отвечают их потребностям. В результате появилось многофункциональное устройство, которое адаптируется под индивидуальные предпочтения и сиюминутные прихоти сотен миллионов отдельных пользователей. Совершить такой подвиг традиционными методами управления невозможно. Вместо раздувания организации для решения сложной задачи Apple минимизировала проблему, разбив ее на крошечные части, с которыми вполне могут справиться маленькие независимые команды, работая короткими циклами и постоянно получая обратную связь от пользователей.
Успех iPhone компании Apple часто приписывают гению Стива Джобса. Блестящему маркетингу. Превосходному дизайну. Тщательному вниманию к деталям. Инновационному мышлению. Огромному стремлению решать проблемы. Все это верно. Однако зачастую из виду упускается тот факт, что все эти элементы были бы бесполезны, если бы Apple методом итераций не разработала сравнительно простое электронное устройство и не создала бы платформу для независимых разработчиков ПО. Сотни тысяч микрокоманд проявили свои мастерство и талант, чтобы создавать приложения, напрямую взаимодействуя с потребителями.
Закон микрокоманды прост. Он предполагает, что для решения масштабных и сложных задач в VUCA-мире компаниям следует не создавать раздутые структуры, а по мере возможности разбивать эти задачи на мелкие блоки и передавать их кросс-функциональным автономным командам, которые работают методом итераций, то есть короткими циклами в состоянии потока. При этом они получают быструю обратную связь от потребителей и конечных пользователей.
История о провальных попытках создать портативное устройство при помощи традиционных управленческих практик, описанная в начале главы, выдумана. Однако некоторые ее детали подозрительно напоминают мытарства Newton, личного цифрового ассистента, за создание которого в 1987 году отвечал Джон Скалли, бывший на тот момент CEO Apple. В 1998 году Стив Джобс прекратил разработки Скалли.
То, что попытки решать сложные проблемы в рамках нисходящей бюрократии часто заканчиваются крахом, — это факт. Например, в 2006 году ВВС США запустили проект по модернизации менеджмента логистики. Они заключили контракт на сумму $628 млн с Computer Sciences Corporation, которая выполняла в проекте роль системного интегратора. Компания занималась конфигурацией, разработкой, проведением обучения и управлением преобразованиями перед запуском.
«Мы никогда не пытались одновременно изменить процессы, инструменты и язык всех 250 тысяч сотрудников нашего бизнеса, — говорил Гровер Данн, директор отдела по преобразованиям ВВС. — Но сейчас мы собираемся сделать именно это». Элизабет Макграт, заместитель начальника по вопросам управления военного ведомства, поясняла: «Мы начали с одномоментной реорганизации и определили все возможные требования к программе, что сделало ее громоздкой и сложной».
На протяжении последующих семи лет проект несколько раз реструктурировался. В 2013 году ВВС подсчитали: на воплощение одной четверти изначально запланированных возможностей потребуется еще $1 млрд, и даже при этих огромных вложениях на запуск системы уйдет еще семь лет. В итоге проект, затраты на который уже составили $1,3 млрд, закрыли.
Возможно, вы скажете, что разделение работы на микрочасти имеет смысл, лишь когда речь идет о персональных устройствах вроде iPhone. Правомерен ли такой подход в отношении серьезного промышленного проекта, например для создания истребителя нового поколения? Да, правомерен, и тому уже есть подтверждение. Так, шведский производитель воздушных судов Saab разработал истребитель Gripen именно на основе Agile-практик. Каждые полгода Saab объявляет о новом выпуске операционной системы истребителя. Она делает его быстрее, дешевле, легче, эффективнее, мощнее, улучшает электронику и обеспечивает более продвинутые системы наведения. Ведущие эксперты по вопросам обороны назвали Gripen «лучшим малозаметным истребителем в мире».
Авторитетная международная издательская группа IHS Jane’s, специализирующаяся на военной тематике, провела исследование, сравнив операционные издержки детища Saab с издержками истребителей F-16 и F-35 (Lockheed Martin), F/A-18 Super Hornet (Boeing), Rafale (Dassault) и Typhoon (Eurofighter). И пришла к выводу, что Gripen имел «наименьшие операционные расходы среди всех изученных истребителей». При этом рассматривались такие факторы, как расход топлива, предполетная подготовка и ремонт, а также регулярное аэродромное техобслуживание совместно с сопутствующими затратами на персонал».
Программное обеспечение играет все более значимую роль в разработке и эволюции Gripen. «Головная боль, с которой сталкиваются производители истребителей, — пишет Билл Свитман в Aviation Week and Space Technology, — заключается в том, что каким бы грамотным ни был ваш проект, разработка и создание этих самолетов ведет к огромным расходам. Кроме того, их жизненный цикл от проектирования до утилизации намного превосходит рамки политического или технологического горизонта». Gripen был разработан с учетом этих особенностей: «Продолжительный срок службы требует гибкости как в отношении боевых миссий, так и на протяжении жизненного цикла».
Тот же феномен наблюдается в мире автомобилей. На протяжении первого века существования автомобилей человек покупал машину без всякой возможности модифицировать впоследствии свое приобретение, например увеличив его мощность или повысив функциональность. Теперь ситуация изменилась. В частности, Tesla может дополнить новыми функциями — автоматическим торможением при вероятном столкновении, частичной системой автопилота и автоматизированной системой парковки — уже проданные автомобили, загрузив в них новое ПО. Подобные возможности предлагаются и другими производителями автомобилей класса люкс вроде Audi или Mercedes-Benz. Разница лишь в том, что Tesla Model S разработана с возможностью постоянного апгрейда «на лету».
«Model S, по сути, представляет собой очень сложный компьютер на колесах, — рассказывает CEO компании Илон Маск. — Tesla разрабатывает как ПО, так и аппаратное обеспечение. Мы относимся к апгрейду автомобиля так же, как к обновлению телефона или ноутбука».
Четырехколесные «железные кони» все больше напоминают гибкие электронные устройства, а не механические сооружения. Как и iPhone, автомобиль становится платформой для приложений.
В этой связи полезно вспомнить, что Agile-менеджмент начал ассоциироваться с программным обеспечением лишь с 2001 года. Исторические же его корни лежат в сфере производства — в quality movement в Японии, в частности в Toyota Production System. Компания начала с того, что стала экспериментировать с маленькими промышленными сериями и обнаружила, что работа короткими циклами, определяемыми спросом, оказалась более эффективной, чем массовое производство.
Такая модель распространилась в Японии в 1970-х годах и в 1980-х добралась до США. Обнаружилось, что при правильном ее применении длительность производственного цикла с учетом мелких партий можно сократить в 10–100 раз, а объем запасов — более чем на 90%, что высвобождало огромные суммы денег. К «вторичным» эффектам относились повышение качества, ускорение обучения и снижение себестоимости продукта.
Итерационный подход, распространенный затем на другие производственные сферы, описан в статье Хиротаки Такеучи и Икуджиро Нонаки The New New Product Development Game, опубликованной в Harvard Business Review в 1986 году. Авторы писали:
Компании все больше осознают, что старый последовательный метод разработки новых продуктов попросту не работает. Вместо него японские и американские компании используют целостный подход. Как в регби, мяч передается между членами команды, которые слаженно передвигаются по полю.
Этот целостный подход обладает шестью характеристиками: встроенной нестабильностью, самоорганизующимися проектными командами, параллельными фазами разработки, мультиобучением, неявным контролем и передачей знаний внутри организации. Шесть элементов складываются, словно пазл, в быстрый, гибкий процесс разработки нового продукта. Не менее важен тот факт, что новый подход может инициировать перемены. Это инструмент создания креативных идей и процессов, ориентированных на рынок, внутри существующей организации.
В качестве примеров в статье приводятся Fuji-Xerox, Honda и Canon, разрабатывающие аппаратное, а отнюдь не программное обеспечение.
В 1990 году итерационный микрокомандный подход распространился шире. В классической книге «Машина, которая изменила мир» он получил название «бережливое производство». Однако, зародившись в сфере аппаратного обеспечения, систематическое использование микрокоманд и итерационных подходов получило подлинное признание именно в сфере разработки ПО после публикации Agile-манифеста в 2001 году.
Какие именно практики входят в Закон микрокоманды? Зависит от того, с какой стороны посмотреть. В течение первого десятилетия после публикации Agile-манифеста его приверженцы яростно спорили друг с другом, пытаясь определить «настоящие Agile-практики». Одни называли Scrum. Другие твердо верили, что это Канбан, третьи — что это Lean (бережливое производство). В конце концов стало понятно, что правильный ответ звучит иначе. Закон микрокоманды подразумевает образ мышления, а не конкретный набор инструментов и процессов, которые можно перечислить в практическом руководстве. Если вы относитесь к Agile как к последнему, вы не стоите на правильном пути. Нельзя прийти в магазин и «купить немного Agile-менеджмента».
Закон микрокоманды определяет, как должна выполняться сложная работа. Практики возникают как результат сочетания Agile-мышления с особыми организационными условиями. Именно по этой причине сотрудничество с консалтинговой фирмой, сотрудники которой «придут и научат наш персонал инструментам и процессам Agile-управления», редко приводит к успеху.
За последние годы члены SD Learning Consortium обменивались визитами, чтобы понять условия, необходимые для успешного внедрения Agile. В каждом успешном кейсе мы обнаружили, что компания начинала с общих принципов и использовала опыт предшественников, а затем разрабатывала набор практик в соответствии с собственными потребностями (а порой и брендами) и корпоративной культурой. Хотя универсального рецепта успеха не существует, мы заметили поразительное сходство некоторых управленческих практик. Далее описаны главные характеристики.
Почти каждая компания, внедряющая Agile, когда-то столкнулась с провалом больших и сложных планов, в которых содержалось слишком много неизвестных. Перемены же происходили так быстро, что сотрудники не успевали вносить корректировки. Выход из положения был найден: мини-блоки работы, микрокоманды, короткие циклы и быстрая обратная связь — фактически «маленькое все».
В сфере разработки ПО общепринятое определение «готово» включает в себя полный код, завершенное интеграционное, нагрузочное и юнит-тестирование и одобрение пользователем. Это сложная задача, если команда работает над большим заданием. Дробление на небольшие задачи позволяет в конце каждого короткого цикла получать продукт, который потенциально можно протестировать на пользователе, следовательно, команда имеет возможность своевременно выявлять подводные камни и ошибки, а не накапливать технический долг.
Такой метод работы возник из практического опыта и обширного экспериментирования. Продуктивен ли он? Google считает, что да. «Высшее руководство компании долгое время полагало, что сильные команды создаются путем объединения лучших специалистов», — говорит Абир Даби, менеджер из подразделения People Analytics в Google. Но на деле оказалось, что это не так. Подробное исследование, получившее название «Аристотель», показало, что состав команды мало влияет на ее продуктивность. Влияние оказывают пять ключевых факторов, поддерживаемых практиками Agile-управления.
Результатом организации работы в соответствии с Agile становится не только ее более быстрое выполнение. В отличие от традиционных компаний, где полностью вовлечен в работу лишь каждый пятый сотрудник, в компании, практикующей Agile, все сотрудники находятся в состоянии потока. Термин «поток», введенный в оборот Михаем Чиксентмихайи, означает глубокое вовлечение, фокус и радость от процесса работы. Желая доставить радость пользователям или клиентам, исполнители «заставляют свой мозг работать».
Этот феномен объясняет высокую мотивацию, которую мы наблюдали у членов команд посещенных нами компаний. Мы спрашивали у них, хотели бы они поработать в структурах с традиционными управленческими практиками, и каждый раз мы слышали один и тот же ответ — «никогда».
Хотя в методах управления Agile-компаний явно заметно сходство, каждая из них разработала уникальную комбинацию практик. Интересен опыт Menlo Innovations, компании, занимающейся проектированием и разработкой ПО. Это детище увлеченного CEO Ричарда Шеридана и сооснователя Джеймса Гобеля расположено в Энн-Арборе, Мичиган. В основном компания работает в секторе B2B, зачастую с партнерами из очень важных отраслей, например здравоохранения. Приятный факт: Menlo всегда рада гостям. Вы можете приехать в Энн-Эрбор и побывать в этой компании будущего.
Люди приезжают в Menlo, чтобы научиться практикам Agile и бережливого производства. «Мы, разработчики, нужны для того, чтобы создавать продукт, который восхитит мир, обрадует людей, — говорит Шеридан. — Все, что мы называем Agile, или бережливым производством, или другими процессами, при хорошем исполнении отвечает на вопрос: как мы служим другим?»
«При этом мы позаимствовали кое-что из многих концепций, — объясняет Шеридан. — Вот почему вы нечасто услышите здесь слово Agile. Люди изучают наш опыт и говорят: “Ваша компания кажется очень гибкой. Почему вы не называете ее Agile?” Мы так работаем не потому, что хотим быть Agile, а потому, что своими продуктами хотим радовать мир».
Все началось 20 лет назад, когда Шеридан, на тот момент менеджер в компании, производящей ПО, устал от неудачных организационных практик. В своей фирме он поставил конкретную цель: положить конец страданиям разработчиков ПО.
Перед тем как основать Menlo Innovations, он занимался практически одной задачей — устранял кризисы программного обеспечения при поломке систем или серьезных сбоях. Традиционные управленческие процессы провоцировали «пожары», Шеридан же должен был «тушить» их. Он ощущал себя настоящим борцом со стихией. Уровень стресса был огромен. Поэтому он решил создать компанию, в которой будут иначе относиться к сотрудникам. Компанию, в которой бы отсутствовали постоянные авралы, способные кого угодно довести до инфаркта. Шеридан хотел, чтобы люди гордились тем, что они делают, и тем, как они это делают. Он хотел, чтобы специалисты испытывали от работы радость, а не стресс.
Между тем слово «радость» в ХХ веке обычно не ассоциировалось с работой. Последняя могла быть эффективной или продуктивной — но чтобы радостной? Сама мысль об этом изначально казалось нелепой.
Однако вот уже 15 лет Menlo Innovations занимается именно этим — обеспечивает условия, радующие как исполнителей (разработчиков ПО), так и заказчиков. «Мы не верим ни на секунду, — подчеркивает Шеридан, — что можно служить другим и не заботиться при этом о своей команде. Поэтому мы создали систему, которая в первую очередь сосредоточена на помощи другим и на создании отличных результатов. Но для этого нам нужно было изменить способ разработки и создания ПО».
Цель по организации дружелюбного рабочего пространства, поставленная Шериданом, означает создание супернадежного кода. Его невозможно сломать, и он не нуждается в исправлениях. «В последний раз критическая ситуация, связанная с ПО, возникла у нас в 2004 году, — вспоминает Шеридан. — Зато нам пришлось наблюдать нечто подобное у одного из своих клиентов, с которым мы только начали работать. Это был конец света! Группа сотрудников той компании запустила крупный проект, который готовился много лет, и он оказался катастрофическим. Люди работали по ночам и выходным, пытаясь исправить ситуацию. Неудача серьезно отразилась на их бизнесе и снизила объем продаж их продуктов на рынке».
Menlo же создала среду, свободную от сбоев. Когда сотрудники Menlo увидели, что произошло в компании клиента, они сказали: «Ого, так вот как выглядит экстренная ситуация!». Они никогда не сталкивались с подобным.
«Мы создаем свободу посредством тирании, — говорит Шеридан. — Мы действительно создали радостную среду, и наши сотрудники любят свою работу. Они полностью вовлечены. Однако мы также насадили тиранию, избавившись от неопределенности. В нашем мире люди знают, с кем и для кого они работают. Они знают, над чем они работают и в каком порядке нужно это делать. В этом суть тирании. В остальном — полная свобода. Я предупреждаю: “Теперь вы свободны в том, чтобы делать любимую работу. Никто не будет заглядывать вам через плечо, вмешиваться и спрашивать, над чем вы сейчас трудитесь и как обстоят дела”».
«У нас есть процесс, — продолжает Шеридан, — и команды верят в него, поэтому мы не нуждаемся в “полицейских”, которые будут проверять, работают ли сотрудники. Процесс понятен им и нашим клиентам. Командная работа обязательна. Претворяя в жизнь идею работы в микрокомандах, мы создаем свободу для сотрудничества».
Как Menlo удается создавать «безаварийное программное обеспечение»? Возможно, ответ кроется в постоянстве команды. Многие компании вроде Microsoft и Ericsson практикуют Agile-менеджмент и прикладывают усилия к объединению членов команд, добиваясь их сходства со спортивными. Каждый знает навыки коллег и их характерные особенности. Более того, люди, создающие код, понимают его и в состоянии его поддерживать. Если возложить на них ответственность за решение проблем с качеством («багов»), у них появится стимул не ошибаться вначале. В подобных компаниях команда рассматривается практически как продукт.
«Такой подход применим, — говорит Шеридан с улыбкой, — до тех пор, пока команда бессмертна, а люди никогда не берут отпуск! Мы же делаем обратное, потому что знаем: если программное обеспечение зависит от отдельных членов команды, нам нужно задуматься, что произойдет, когда один из них не выйдет на работу. Если в традиционных условиях проект реализуют четыре человека, каждый из них является источником эксклюзивных знаний и опыта в конкретной области. В результате вы не сможете работать при отсутствии одного из четверых. Вы не можете лишиться парня, отвечающего за базы данных, или ноу-хау, или промежуточное ПО. Дело в том, что каждый из них знает только свою часть кода. Фактически это ловушка. Нам нужны команды и программное обеспечение, не зависящие от отдельных людей».
Сотрудники Menlo выполняют работу в очень коротких рабочих циклах. Каждый длится всего неделю, после чего состав команд меняется. «Из-за этой смены каждая команда имеет дело с кодом, который был написан кем-то другим на прошлой неделе, — поясняет Шеридан. — Мы моментально тестируем его на предмет надежности и удобства в сопровождении. Новая команда должна понять этот код, чтобы эффективно внести изменения. Если что-то непонятно, новые “хозяева кода” обращаются к команде, которая писала его. Возможно, эти люди сидят за соседним столом.
В результате мы имеем действительно понятный, надежный и простой в сопровождении — и самое главное, безаварийный — код».
Второй особенностью Menlo является подход к найму персонала. Многие компании пытаются найти кандидата, который соответствует вакансии на 100%. Они ищут кого-то точно с теми навыками, которые им требуются, например знанием Python 4.6, Oracle 9.1.1.1 и так далее.
Menlo поступает обратным образом. Она стремится создать культуру сотрудничества, приспосабливаемости, прозрачности и доверия. «Все начинается с наших практик найма, — говорит Шеридан. — Если наши люди не будут соответствовать нашей культуре, мы не сохраним ее в будущем. Когда нам нужны новые работники, мы организуем “быстрое свидание” соискателей со старожилами. Вопрос звучит следующим образом: хотел бы ты трудиться бок о бок с этим человеком? При положительном ответе мы приглашаем кандидата на работу на день, затем на неделю и на месяц. Если наши сотрудники не разочаровываются, мы берем его».
«Мы разработали процесс собеседования в соответствии с нашей культурой, — продолжает Шеридан. — Вначале мы не задаем много вопросов. Мы не уделяем особого внимания резюме. Нас не интересует, учились ли вы в университете. Для начала мы постараемся выяснить, соответствуете ли вы нашей культуре. Если да, тогда речь пойдет о ваших навыках. Но, положа руку на сердце, освоить навыки не так сложно, как сформировать мировоззрение».
Третьей поразительной особенностью Menlo является работа в парах. Для традиционных менеджеров ситуация, когда два сотрудника сидят за одним компьютером, по определению непродуктивна и неэффективна. (Многие из них считают, что работа в парах сокращает продуктивность в два раза.) Шеридан же утверждает обратное: по его словам, при работе в парах продуктивность повышается в 10 раз в отличие от работы поодиночке.
Ранее в своей карьере Шеридану приходилось встречаться с боссами, которые были уверены: если два человека работают вместе, то как минимум один из них отлынивает. В Menlo думают иначе. Это не единственная компания, практикующая работу в парах. Но такие организации по-прежнему встречаются редко.
Четвертая поразительная особенность Menlo заключается в том, что ключевую роль в работе играют антропологи. «К сожалению, индустрия программного обеспечения создает технологии, не учитывающие потребности людей, а потом их считают “тупыми пользователями”, — сетует Шеридан. — В Menlo действует другой подход. Мы хотим создать программное обеспечение, которое не требует руководств по использованию или служб технической поддержки. Для этого мы изучаем интересы тех, кому служим. Мы называем эту практику “хайтек-антропологией”. Наши антропологи, исповедующие эмпатию, сострадание и особые методы исследований, “отправляются в мир”. Они анализируют не только среду, но и лексикон, рабочий процесс, привычки, страхи и мечты людей. Все эти знания задействуются при разработке программного обеспечения».
Таким образом, Menlo применяет четыре нетипичные практики: особый наем, работу в парах, смену состава команды и привлечение антропологов. Я отнюдь не утверждаю, что они лучше приемов, применяемых в других организациях, и что все должны следовать их примеру. Нельзя подходить ко всем с одной меркой.
Как уже говорилось, Закон микрокоманды предполагает работу короткими циклами. В Microsoft и Ericsson он составляет три недели, в Menlo — одну неделю. И это не предел. Рассмотрим Etsy, онлайн-рынок товаров ручной работы. Впервые услышав об этом стремительно растущем миллиардном бизнесе, в рамках которого ежедневно внедряется более 30 инноваций, я представил, под каким прессом находятся работники. И был поражен тем, насколько реальность отличается от моих фантазий. Все оказалось с точностью до наоборот: непрерывная поставка используется в Etsy не только для ускоренного создания инноваций. Оно также помогает преодолеть чрезмерный стресс на рабочем месте.
Семь лет назад Etsy меняла код каждые две-три недели — довольно часто по сравнению с другими компаниями того времени. Например, Salesforce выпускал обновления три раза в год, а Microsoft Office — раз в два года. Как и многие субъекты рынка, Etsy создала отдельную группу для разработки ПО и отдельную — для его поставки. Действовала следующая схема: разработчики создавали новое ПО, операторы внедряли ряд изменений, которые разработчики объединяли вместе. Сотрудники Etsy часто задерживались в офисе сверхурочно, особенно когда обнаруживался сбой, а это происходило регулярно. Так же часто возникали длительные простои. Причина отчасти заключалась как раз в том, что ПО писала одна группа, а вводила его в действие и управляла им другая.
В 2010 году руководство Etsy решило изменить ситуацию. Оно обязалось ни много ни мало «ввести инновации или умереть». Компания поставила целью устранение препятствий, не позволяющих улучшать и масштабировать сайт. Справедливости ради надо отметить, что уже на тот момент этот сайт был огромным: ежемесячное количество уникальных просмотров превышало 60 млн. Менеджеры Etsy понимали, что преобразования должны включать в себя не только написание качественного кода, но и улучшение адаптируемости и сокращение сроков ожидания отклика в случае проблем. Планировалось также создать сильную команду разработчиков, которые смогут трудиться без авралов. Как и многие Agile-компании, Etsy исповедовала принципы «автономии, мастерства и целеустремленности», сформулированные Дэниелом Пинком. Кроме того, компания хотела снизить уровень стресса, связанного с выпуском обновлений.
Менеджеры Etsy внедрили систему непрерывной интеграции и автоматического тестирования. Теоретически система позволяла выявить воздействие любого изменения в коде на абсолютной копии сайта на тестовом окружении. Однако на практике продолжали происходить неожиданные вещи — например, запускалась распродажа, которая моментально наводняла сайт огромным количеством пользователей. Или аппаратное обеспечение неожиданно начинало взаимодействовать с программным. Порой в череде многочисленных операций было сложно выявить настоящую причину сбоев.
Etsy решила разбить проблемы на более мелкие. Обнаружилось, что при более частом инициировании небольших преобразований легче выявлять и ликвидировать более серьезные проблемы. Однако для смены алгоритма требовалось изменить и привычную схему работы. Раньше любые изменения на сайте производились только с одобрения руководства. Теперь же все протестированные улучшения реализовывались сразу. Сотрудники, предлагающие их, контролировали и процесс их внедрения.
Новая инициатива прижилась. Благодаря ей Etsy превратилась в отлично работающий онлайн-рынок товаров ручной работы и винтажа — равно как и Spotify начала предлагать классный стриминг музыки. В обеих компаниях и им подобных сотрудники могут непрерывно разрабатывать улучшения, совершенствуя работу сайта. Многие из них являются «темными лошадками», то есть пользователи никогда не увидят улучшение, но производительность сайта заметно повысится. Однако основным критерием при внедрении того или иного изменения служит именно степень улучшения жизни потребителей.
Некоторые изменения рождаются в рамках экспериментов. Сотрудники хотят понять, может ли что-то работать лучше. Например, стоит ли включать стоимость отправки в цену товара и затем предлагать «бесплатную» доставку? Проведя соответствующий тест, сотрудники нашли ответ на эту, казалось бы, многообещающую идею: нет, не стоит.
Результатом работы в новых условиях стало не только более быстрое внедрение инноваций, но и снятие стресса у сотрудников. Теперь сотрудники, разрабатывающие улучшения, участвовали и в их релизе, что благотворно сказалось на процессе. Сверхурочные ночные бдения и длительные простои остались в прошлом. Внештатные ситуации возникают гораздо реже, и справиться с ними проще. Команда разработчиков живет по нормальному рабочему графику со свободными вечерами и выходными.
Зато инновации создаются стремительно: число внедренных на сайте изменений доходит до тридцати в день, порой увеличивая продажи на миллионы долларов. Изменения внедряются небольшими инкрементами на безумной скорости в рамках главной стратегии.
Опыт Etsy является наглядным примером внедрения бесстрессовых инноваций на огромной скорости. Разумеется, подобное возможно лишь в атмосфере доверия и сотрудничества.
Рационален ли такой подход? В 2015 году Etsy заявила о своем преобразовании в акционерное общество. Время покажет, поставил ли этот шаг под угрозу корпоративную культуру. Уже сегодня наблюдаются тревожные признаки давления инвесторов, желающих максимизировать акционерную стоимость. Если Etsy не сумеет справиться с этим давлением, ей придется пожертвовать стабильностью в угоду краткосрочной финансовой выгоде. Как и у Spotify, конкурирующей с Apple Music, ее единственный шанс выжить — обгонять конкурентов в плане инноваций, которые приносят радость клиентам.
Сталкиваясь с Agile-командами, традиционные менеджеры часто презрительно фыркают: «Команды? Ничего нового. У нас всегда были команды. Эта идея даже отдаленно не нова».
В какой-то степени они правы. Как отмечалось в , разговоры о пользе командного подхода в науке об управлении ведутся уже практически век. При этом многие команды являются таковыми только на словах. Их лидеры ничем не отличаются от других бюрократических боссов. Стоит ли после этого удивляться низким результатам их деятельности?
Команды обычно занимались решением особых задач, например исследованиями и разработками. Они не были предназначены для повседневного управления. В соответствии с особенностями своего времени компания работала дисциплинированно либо за счет бюрократии, либо посредством инноваций. Третьего не было дано, и приходилось делать мучительный выбор. Аgile-управление позволяет компаниям заниматься и тем и другим одновременно.
Отдавая предпочтение командной работе, менеджеры-гуманисты XX века руководствовались благими намерениями. Эти психологи, социологи и консультанты по вопросам управления исходили из анализа потребностей своих современников. Безусловно, сотрудники, которые чувствуют свою значимость и поддержку компании, будут более продуктивными. Несомненно, менеджеры, которые вдохновляют и доброжелательно направляют своих подчиненных, выигрывают в сравнении с придирчивыми и угрюмыми боссами.
Постепенно командная работа завоевывала популярность. О ней говорили в связи с «самореализацией», «превосходством», «приверженностью цели», «стремлением к совершенству» и так далее.
Но зачастую эти разговоры состояли из пустых клише, представляя собой лишь сказки о волшебной корпорации.
На этом «романтическом» фоне основатели Agile-менеджмента умышленно выбирали приземленные и даже пугающие термины: Scrum, scrum-мастер, владелец продукта, Канбан, графики сгорания, рабочее программное обеспечение, спринты, стендапы. Работа должна была быть не просто «готова», а «готова, готова, готова». В таком языке нет намека на волшебство, сказку или фальшивый братский дух. Он не похож на высокопарный слог демагогов. Приверженцы Agile стремились к решению накопившихся проблем и хотели предоставить людям возможность работать, не отвлекаясь на второстепенные задачи. Внимание уделялось реальному опыту, устранению препятствий и постоянному повышению ценности для клиентов в условиях нарастающей сложности.
Как следствие, работа Agile-команд полностью отличается от работы традиционных команд XX века.
Эти пояснения помогут нам понять, почему Закон микрокоманды — больше, чем просто новый термин. Приняв его в качестве базового метода выполнения практически любой работы, Agile-менеджмент кардинально изменил бизнес-процесс.
Сегодня мы понимаем, почему проблема, которую пытались решить гуманисты, — противоборство боссов и работников — была тупиковой. В этой битве неизбежно побеждали боссы. Но победа не приносила плодов, потому что побежденные работники падали духом.
Голос потребителя зачастую терялся в иерархических противостояниях между соревнующимися подразделениями и различными направлениями менеджмента. Нужно было изменить правила игры: отказаться от вертикальной динамики конфликта с нулевым результатом и перейти к взаимовыгодной горизонтальной динамике — повышению ценности путем сотрудничества и совместного решения проблем. Команды XX века зачастую были сосредоточены на самих себе. Сторонникам Agile предстояло направить свое внимание наружу с помощью постоянного создания ценности для клиента. Как эта задача выполнялась на практике?
Войти с помощью соц. сетей: