Эпоха Agile - [16]

«Model S, по сути, представляет собой очень сложный компьютер на колесах, – рассказывает CEO компании Илон Маск. – Tesla разрабатывает как ПО, так и аппаратное обеспечение. Мы относимся к апгрейду автомобиля так же, как к обновлению телефона или ноутбука»[46].

Четырехколесные «железные кони» все больше напоминают гибкие электронные устройства, а не механические сооружения. Как и iPhone, автомобиль становится платформой для приложений.

В этой связи полезно вспомнить, что Agile-менеджмент начал ассоциироваться с программным обеспечением лишь с 2001 года. Исторические же его корни лежат в сфере производства – в quality movement в Японии, в частности в Toyota Production System. Компания начала с того, что стала экспериментировать с маленькими промышленными сериями и обнаружила, что работа короткими циклами, определяемыми спросом, оказалась более эффективной, чем массовое производство[47].

Такая модель распространилась в Японии в 1970-х годах и в 1980-х добралась до США. Обнаружилось, что при правильном ее применении длительность производственного цикла с учетом мелких партий можно сократить в 10–100 раз, а объем запасов – более чем на 90 %, что высвобождало огромные суммы денег. К «вторичным» эффектам относились повышение качества, ускорение обучения и снижение себестоимости продукта.

Итерационный подход, распространенный затем на другие производственные сферы, описан в статье Хиротаки Такеучи и Икуджиро Нонаки The New New Product Development Game, опубликованной в Harvard Business Review в 1986 году. Авторы писали:

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

Этот целостный подход обладает шестью характеристиками: встроенной нестабильностью, самоорганизующимися проектными командами, параллельными фазами разработки, мультиобучением, неявным контролем и передачей знаний внутри организации. Шесть элементов складываются, словно пазл, в быстрый, гибкий процесс разработки нового продукта. Не менее важен тот факт, что новый подход может инициировать перемены. Это инструмент создания креативных идей и процессов, ориентированных на рынок, внутри существующей организации[48].

В качестве примеров в статье приводятся Fuji-Xerox, Honda и Canon, разрабатывающие аппаратное, а отнюдь не программное обеспечение.

В 1990 году итерационный микрокомандный подход распространился шире. В классической книге «Машина, которая изменила мир»[49] он получил название «бережливое производство»[50]. Однако, зародившись в сфере аппаратного обеспечения, систематическое использование микрокоманд и итерационных подходов получило подлинное признание именно в сфере разработки ПО после публикации Agile-манифеста в 2001 году.

* * *

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

Закон микрокоманды определяет, как должна выполняться сложная работа. Практики возникают как результат сочетания Agile-мышления с особыми организационными условиями. Именно по этой причине сотрудничество с консалтинговой фирмой, сотрудники которой «придут и научат наш персонал инструментам и процессам Agile-управления», редко приводит к успеху.

За последние годы члены SD Learning Consortium обменивались визитами, чтобы понять условия, необходимые для успешного внедрения Agile[51]. В каждом успешном кейсе мы обнаружили, что компания начинала с общих принципов и использовала опыт предшественников, а затем разрабатывала набор практик в соответствии с собственными потребностями (а порой и брендами) и корпоративной культурой. Хотя универсального рецепта успеха не существует, мы заметили поразительное сходство некоторых управленческих практик. Далее описаны главные характеристики.

Общие практики Agile-микрокоманд

1. Работа над мини-блоками. Чтобы справиться со сложностью и непредсказуемостью, задачу по возможности разбивают на блоки. В каждом из них содержится нечто потенциально ценное для потребителя или конечного пользователя. Каждый можно реализовать за короткий цикл; при таком подходе даже в сложных и крупных проектах виден прогресс или его отсутствие. В исключительных случаях компания устанавливает общий темп – обычно одну, две или три недели. В повседневности же каждая команда самостоятельно определяет себе подходящий ритм.