Джефф снял трубку, вспоминает Ким: «Привет, это Джефф Безос, чем я могу вам помочь?» Клиент не понял, кто на проводе, и начал объяснять, в чем проблема. Кажется, они получили стол и столешница была повреждена. Джефф (с помощью представителя) отправил замену. Когда он повесил трубку, представитель сказал нечто важное: «Столы всегда приходят с повреждениями». Кажется, упаковка была недостаточно надежной, и поэтому во время доставки часто возникали проблемы. Джефф сразу заметил, что у представителей службы поддержки есть информация, которая могла быть полезной для отдела розничной торговли, но они были разобщены. Поэтому он предложил использовать такой механизм, как шнур «Андон», что в конечном итоге и было сделано».
Техника «шнура «Андон» иллюстрирует ключевой принцип ориентированных на перспективу систем. Он посылает простой, недвусмысленный сигнал другим командам, что в корне отличается от традиционного процесса управления. Поскольку каждая команда имеет свою собственную функцию приспособленности, которая, как предполагается, будет неустанно оптимизироваться, эти функции могут конфликтовать; функция приспособленности любой команды может быть проверена при помощи такой же функции другой команды. Искусство управления состоит в том, чтобы выстроить эти функции таким образом, который позволяет вести всю компанию в нужном ей направлении, что представляет собой общую функцию приспособленности организации.
Представители научно-технической культуры с высоким уровнем автономии разработали технику – стендап-митинг, в ходе которого люди и команды должны вместе прорабатывать общие цели и анализировать, как обстоят дела с данными друг другу обещаниями.
В дисфункциональной организации введение стендапов – это отличный способ понять, что пошло не так, и внедрить новые протоколы связи.
Майки Дикерсон, один из инженеров компании Google, приглашенный осенью 2013 года на работу в Белый дом для спасения провального веб-сайта healthcare.gov и ставший позднее руководителем цифровых сервисов США, рассказал мне историю о значении стендап-митингов, которые он проводил в течение ста дней, чтобы связать государственных подрядчиков, построивших неудачный сайт, в единую функционирующую организацию, способную заставить сайт реально работать. Это происходило примерно так:
«Джо, ты обещал получить три новых сервера к этому утру. На какой все стадии?» – «Я еще не получил допуск от Майка». – «Майк, в чем загвоздка?» – «Я не получал никаких запросов на допуск от Джо». – «Что ты имеешь в виду, Майк? Вот он у меня с собой». – «Послушай, Джо. Вот список всех моих рабочих заявок, и от вас ничего нет!»
Только потом «Джо» и «Майк», которые работали на разных подрядчиков (более тридцати трех компаний, участвовавших в разработке первой версии healthcare.gov, работали по шестидесяти различным контрактам), обнаружили, что они пользуются разными системами отслеживания возникающих проблем. Запросы от команд на выполнение работы другими командами уходили буквально в никуда. Поскольку каждый находился в неявной зависимости от всех остальных, работа не могла сдвинуться с мертвой точки, так как каждый ожидал результатов от всех остальных, прежде чем мог продолжить действовать.
Не важно, при помощи веб-служб и API-интерфейсов или посредством таких инструментов, как системы отслеживания возникающих проблем, ориентированная на перспективу модель работает над повышением автономии, поскольку каждый автономный субъект дает документально подтвержденные обещания и несет за них ответственность.
Вы все находитесь внутри приложения
Процесс превращения разработки ПО из модели, целью которой было изготовление артефакта (скажем, GM-версии следующего выпуска Microsoft Windows, которая была результатом многолетних разработок и которую необходимо было записать на миллионы компакт-дисков и в тот же день передать в десятки тысяч предприятий розничной торговли и корпоративным клиентам), в модель, в которой разработка ПО была постоянно совершенствующимся процессом, также являлся процессом организационного открытия.
Я до сих пор помню удивление, с которым Марк Лусавски, бывший старший технический руководитель проекта в Microsoft, рассказывал о том, как изменился процесс его работы, когда он перешел в Google. «Я вношу изменения и сразу же, в режиме реального времени, предоставляю их в пользование миллионам людей». Марк описывал глубокие преобразования, произошедшие в разработке программного обеспечения в облачную эпоху. GM-версий больше нет. Сегодня программное обеспечение стало процессом постоянных, более или менее постепенных улучшений. С точки зрения компании, предлагающей онлайн-услугу, программное обеспечение превратилось из вещи в процесс и в конечном счете в серию бизнес-процессов. Структура этих рабочих процессов должна быть оптимизирована не только для разработчиков программного обеспечения, но и для людей, которые будут пользоваться ими изо дня в день.
Читать дальше