Электронная библиотека » Стивен Деннинг » » онлайн чтение - страница 3

Текст книги "Эпоха Agile"


  • Текст добавлен: 11 апреля 2019, 10:40


Автор книги: Стивен Деннинг


Жанр: Управление и подбор персонала, Бизнес-Книги


Возрастные ограничения: +12

сообщить о неприемлемом содержимом

Текущая страница: 3 (всего у книги 17 страниц) [доступный отрывок для чтения: 5 страниц]

Шрифт:
- 100% +

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

В компаниях, принявших Agile, ориентация на клиента означает абсолютно иное. Каждый сотрудник здесь буквально одержим созданием все большей ценности для клиентов. Он имеет четкое представление о конечном потребителе и видит, как его работа повышает – или не повышает – эту пресловутую ценность. В последнем случае возникает немедленный вопрос: зачем вообще выполняется это действие? В результате компания меняет всё – цели, ценности, принципы, процессы, системы, практики, структуры данных и стимулы. Благодаря постоянным преобразованиям она создает ценность для клиентов и беспощадно избавляется от всего, что не приносит пользы.

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

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

Эта проблема широко распространена даже в тех организациях, которые активно вводят Agile на командном уровне. В исследованиях говорится, что 80–90 % таких команд ощущают противоречие между методом управления Agile-команды и методом управления всей организации. В половине случаев напряжение такой ситуацией высокое.

Закон сети представляет собой границу Agile-движения. Он объясняет, как сделать всю структуру гибкой. Это непросто, потому что в Agile абсолютно иные принципы деятельности организации. В центре концепции менеджмента ХХ века лежит идея корпорации как эффективной и устойчивой машины. Ее цель – развивать существующую бизнес-модель. Руководители Google Эрик Шмидт и Джонатан Розенберг писали в своей книге «Как работает Google»[30]30
  Эрик Шмидт, Джонатан Розенберг, Алан Игл. Как работает Google. М.: Эксмо, 2015.


[Закрыть]
: «Традиционное мышление в стиле MBA диктует вам необходимость создавать устойчивое преимущество над конкурентами. Затем вы закрываете свою крепость и защищаетесь кипящим маслом и огненными стрелами»[31]31
  Э. Шмидт, Дж. Розенберг. Как работает Google. М.: Эксмо, 2015.


[Закрыть]
.

«Крепостью» управляют люди сверху – принято считать, что они знают больше. Сама «крепость» построена с целью «минимизировать риск и удерживать людей в своих офисах и подразделениях» (по выражению профессора Гарвардской школы бизнеса Джона Коттера). Сотрудники действуют в «системе, которая требует (обычно доброжелательно) от большинства людей молчать, подчиняться и раз за разом выполнять работу»[32]32
  J. Kotter. Accelerate. Boston: Harvard Business Review Press, 2014.


[Закрыть]
. Существующая бизнес-модель доминирует над развитием новых возможностей.

Изменения, способные компенсировать статичный характер организации, изучались в течение многих десятилетий. В их число входили целевые, оперативные, специальные проектные группы, департаменты планирования, секретные эксперименты, исследования и разработки (R&D), двойственные операционные системы[33]33
  Модель организационной структуры, предназначенная для быстрого развития новых идей и моделей, в то же время максимизирующая операционную эффективность, необходимую для управления бизнесом. Прим. науч. ред.


[Закрыть]
, воронки знаний, дизайн-мышление и многое другое[34]34
  Информацию о двойственных операционных системах см. здесь: Kotter. Accelerate; S. D. Anthony, C. G. Gilbert, M. W. Johnson. Dual Transformation: How to Reposition Today’s Business While Creating the Future. Boston: Harvard Business Review Press, 2017. Информацию о воронке знаний и дизайн-мышлении см. здесь: R. Martin. The Design of Business. Boston: Harvard Business Review Press, 2009. Мартин описывает воронки знаний, с помощью которых организация постепенно решает задачи, что впоследствии превращается в целую совокупность конкретных приемов и методов в бизнесе. Ее можно использовать в дополнение к оценке и в итоге к алгоритмам, которые дают большую точность.


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

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

Распространено заблуждение, что Agile-организации обязательно имеют горизонтальную структуру и в них отсутствует иерархия. На самом деле высшее руководство по-прежнему выполняет в них важную функцию – задает вектор движения. Нерадивых сотрудников по-прежнему увольняют за невыполнение работы. Более того, Agile-организации стремятся к высоким результатам даже настойчивее, чем традиционная бюрократия. Абсолютная прозрачность процесса и ответственность перед коллегами не дают возможность пересидеть аврал.

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

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

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

Таким образом, три закона означают следующее. Во-первых, микрокоманды работают над маленькими задачами небольшими итеративными рабочими циклами и поставляют ценность для клиентов. Во-вторых, компания постоянно приумножает ценность для клиентов. Наконец, третий закон предполагает скоординированную работу в интерактивной сети. Именно эти законы позволили Spotify еженедельно создавать персонализированные плейлисты для более чем 100 млн пользователей. Те же принципы превратили Barclays в банк, предоставляющий простые, удобные персонализированные услуги оперативно и в большом масштабе. То же можно сказать и об Ericsson, сетевой менеджмент начал приносить больше ценности своим клиентам в более быстрые сроки.

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

Когда традиционный менеджер сталкивается с такой практикой, он оказывается словно в чужой стране. В ней все устроено по-другому. «Да» может означать «нет», торг не возбраняется, а смех порой означает гнев[35]35
  Элвин Тоффлер. Шок будущего. М.: АСТ, 2008.


[Закрыть]
. Здесь царят новые правила, странные и непонятные. В результате менеджеры испытывают удивление, разочарование и чувствуют себя неспособными справиться с ситуацией. Пока «пришельцы» не изучат правила этой «страны» и не научатся им следовать, они обречены ощущать себя потерянными и некомпетентными.

Вот почему Agile нельзя внедрить с помощью текущей управленческой практики. Agile подразумевает полное принятие сопутствующих принципов. Для традиционных менеджеров оно означает форменную «ломку» стереотипов. Поначалу новый подход кажется в корне неправильным – как непривычная грамматика нового иностранного языка. Лишь спустя время, по мере накопления опыта, Agile станет неотъемлемой частью компании и будет поддерживаться автоматически. Вам не нужно «внедрять инструменты и процессы Agile». Речь идет о том, чтобы полностью перенять Agile-мышление и разработать соответствующую «мышечную память».

Agile предполагает новую стратегию функционирования и взаимодействия с миром. Согласно нашему исследованию, люди, не придерживающиеся Agile-мышления, не добьются успеха, даже если скрупулезно станут внедрять каждый инструмент, процесс и практику в полном соответствии с этой книгой. И наоборот: если сотрудники компании обладают Agile-мышлением, не имеет значения, какие именно инструменты, процессы и практики они применяют, – все идет по плану. В конечном счете Agile – это мышление.

* * *

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

Но второй закон, согласно которому цель компании заключается в том, чтобы приносить ценность клиенту, является самым важным. Именно он объясняет остальные два и дает понять, почему Agile-организации работают именно так, а не иначе.

Впрочем, основой Agile-управления является третий закон. Согласно ему, высокоэффективные команды, ориентированные на клиентов, не добьются успеха, пока вся организация не начнет работать как интерактивная сеть. Именно в этом законе объединяются два других. Они направляют нас к общей внешней цели взрывного роста ценности, которого можно достичь лишь при полном принятии системы Аgile.

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

МАНИФЕСТ ГИБКОЙ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

Мы постоянно открываем новые способы разработки программного обеспечения, занимаясь ею самостоятельно и помогая в этом другим. В процессе мы осознали следующее.


• Люди и взаимодействие важнее процессов и инструментов.

• Работающий продукт важнее исчерпывающей документации.

• Сотрудничество с заказчиком важнее согласования условий контракта.

• Готовность к изменениям важнее следования первоначальному плану.


Мы следуем этим принципам:


1. Наивысшим приоритетом для нас является удовлетворение потребностей заказчика благодаря регулярной и ранней поставке ценного программного обеспечения.

2. Изменение требований приветствуется, даже на поздних стадиях разработки. Agile-процессы позволяют использовать изменения для обеспечения заказчику конкурентного преимущества.

3. Работающий продукт следует выпускать как можно чаще, с периодичностью от пары недель до пары месяцев.

4. На протяжении всего проекта разработчики и представители бизнеса должны ежедневно работать вместе.

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

6. Непосредственное общение является наиболее практичным и эффективным способом обмена информацией как с самой командой, так и внутри команды.

7. Работающий продукт – основной показатель прогресса.

8. Инвесторы, разработчики и пользователи должны иметь возможность поддерживать постоянный ритм бесконечно. Agile помогает наладить такой устойчивый процесс разработки.

9. Постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость проекта.

10. Простота – искусство минимизации лишней работы – крайне необходима.

11. Самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд.

12. Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы.


Кент Бек

Майк Бидл

Ари ван Беннекум

Джеймс Греннинг

Джим Хайсмит

Эндрю Хант

Роберт Мартин

Стив Меллор

Кен Швабер

Алистер Кокбёрн

Уорд Каннингем

Мартин Фаулер

Рон Джеффрис

Джон Керн

Брайан Марик

Джефф Сазерленд

Дэйв Томас


© 2001 Вышеупомянутые авторы. Это заявление можно свободно копировать в любой форме, но лишь целиком и с этим заявлением.

ГЛОССАРИЙ: ОПРЕДЕЛЕНИЯ AGILE, SCRUM, DEVOPS, КАНБАН, БЕРЕЖЛИВОГО ПРОИЗВОДСТВА

Agile – это движение, зародившееся в 2001 году в виде набора ценностей и принципов. Они были выражены в Agile-манифесте, подписанном в том же году. У движения были предшественники, например quality movement и «дизайн-мышление». Позже Манифест привел к появлению многочисленных управленческих подходов, включая Scrum, DevOps, бережливое производство и Канбан. Спустя некоторое время они эволюционировали в сообщество людей с особым мышлением, сосредоточенных на постоянном создании ценности для потребителей. Такое мышление подразумевает итеративно-инкрементальный подход к работе в микрокомандах и способствует повышению гибкости внутри компании благодаря внедрению сетевого принципа ее функционирования.


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


DevOps (включает в себя слова development (разработка) и operations (эксплуатация)) – это культура, движение и практика, укрепляющая сотрудничество и коммуникацию между разработчиками ПО и другими профессионалами информационных технологий. При этом DevOps автоматизирует процесс поставки ПО и изменений в инфраструктуре, способствуя очень быстрому осуществлению изменений.


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


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


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


Дизайн-мышление – это подход к инновациям, в центре которого находится человек. Оно направлено на интеграцию потребностей людей, технологических решений и требований для успешного бизнеса. Сегодня дизайн-мышление не ограничивается профессиональной дизайн-практикой и применяется к широкому ряду компаний и социальных проблемI.


I Источники: Херберт Саймон The Sciences of the Artificial (1969); Р. Макким Experiences in Visual Thinking (1973); Б. Лоусон How Designers Think (1980); Р. Бучанан Wicked Problems in Design Thinking, Design Issues 8, № 2 (Spring 1992). Дизайн-мышление было адаптировано к бизнес-целям дизайнерской консалтинговой компанией IDEO.

Глава 2. Закон микрокоманды

Фундаментальная цель – достичь «мелкости» в крупных организациях.

Эрнст Фридрих Шумахер[36]36
  Э. Шумахер. Малое прекрасно. Экономика, в которой люди имеют значение. М.: Высшая школа экономики, 2012.


[Закрыть]

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

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

Что в итоге? Спустя многие годы, потратив миллиарды долларов, вы обнаруживаете, что ваше устройство по-прежнему не готово к выходу на рынок. Технические проблемы не устраняются, а, похоже, лишь растут в геометрической прогрессии. Координация работы между подразделениями вызывает огромную головную боль, несмотря на все усилия, приложенные соответствующими комитетами. Идет ожесточенный поиск виноватых в технических проблемах и задержках. Отдельные компоненты кажутся многообещающими, но зачастую несовместимы между собой. Подразделения обвиняют друг друга, но отрицают собственную вину. Устранение проблем занимает вечность: как только найдено решение одной, возникает другая.

Организовав работу подобным образом, вы надеялись достичь эффекта масштаба. Но результаты в корне противоположны. Затраты, связанные с организацией и координированием работы такого большого числа сотрудников, растут гораздо быстрее, чем любая добавочная стоимость, ими же создаваемая. Окончание работы по-прежнему остается под вопросом[37]37
  H. Shaughnessy. The Elastic Enterprise: The New Manifesto for Business Revolution. Dublin, Ohio: Telemachus Press, 2012.


[Закрыть]
.

К сожалению, несмотря на затраченные годы, усилия и финансы, руководство принимает решение прикрыть ваш проект. Дело в том, что конкурент – Apple – к 2007 году разработал схожий продукт «с нуля до выхода на рынок». На это компании понадобилось всего 18 месяцев и гораздо меньшие затраты на традиционный менеджмент.

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

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

* * *

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

История о провальных попытках создать портативное устройство при помощи традиционных управленческих практик, описанная в начале главы, выдумана. Однако некоторые ее детали подозрительно напоминают мытарства Newton, личного цифрового ассистента, за создание которого в 1987 году отвечал Джон Скалли, бывший на тот момент CEO Apple. В 1998 году Стив Джобс прекратил разработки Скалли[38]38
  The Newton относится к серии персональных карманных компьютеров, разработанных Apple Inc. Apple запустила платформу в 1987 году и начала продавать первые устройства в 1993 году. Официально продажи завершились 27 февраля 1998 года. По словам бывшего СЕО Apple Джона Скалли, корпорация инвестировала в разработку Newton около $100 млн.


[Закрыть]
.

То, что попытки решать сложные проблемы в рамках нисходящей бюрократии часто заканчиваются крахом, – это факт. Например, в 2006 году ВВС США запустили проект по модернизации менеджмента логистики. Они заключили контракт на сумму $628 млн с Computer Sciences Corporation, которая выполняла в проекте роль системного интегратора. Компания занималась конфигурацией, разработкой, проведением обучения и управлением преобразованиями перед запуском[39]39
  R. Stross. Billion Dollar Flop: Airforce Stumbles on Software Plan // New York Times. December 9, 2012, http://www.nytimes.com/2012/12/09/technology/air-force-stumbles-over-software-modernizationproject.html. См. также: S. Denning. Reconciling Innovation with Control: A $1.3 Billion Lesson in Agile // Forbes.com. December 11, 2012, https://www.forbes.com/sites/stevedenning/2012/12/11/reconciling-innovation-with-control-the-air-forces-1-3-billion-lesson-in-Agile.


[Закрыть]
.

«Мы никогда не пытались одновременно изменить процессы, инструменты и язык всех 250 тысяч сотрудников нашего бизнеса, – говорил Гровер Данн, директор отдела по преобразованиям ВВС. – Но сейчас мы собираемся сделать именно это»[40]40
  Stross. Billion Dollar Flop.


[Закрыть]
. Элизабет Макграт, заместитель начальника по вопросам управления военного ведомства, поясняла: «Мы начали с одномоментной реорганизации и определили все возможные требования к программе, что сделало ее громоздкой и сложной»[41]41
  Stross, Billion Dollar Flop.


[Закрыть]
.

На протяжении последующих семи лет проект несколько раз реструктурировался. В 2013 году ВВС подсчитали: на воплощение одной четверти изначально запланированных возможностей потребуется еще $1 млрд, и даже при этих огромных вложениях на запуск системы уйдет еще семь лет. В итоге проект, затраты на который уже составили $1,3 млрд, закрыли.

* * *

Возможно, вы скажете, что разделение работы на микрочасти имеет смысл, лишь когда речь идет о персональных устройствах вроде iPhone. Правомерен ли такой подход в отношении серьезного промышленного проекта, например для создания истребителя нового поколения? Да, правомерен, и тому уже есть подтверждение. Так, шведский производитель воздушных судов Saab разработал истребитель Gripen именно на основе Agile-практик[42]42
  SAAB JAS-39 Sweden (Super Fighter) // YouTube video, 2:51. October 13, 2011, https://www.youtube.com/watch?v=SOw0Og0i8pA.


[Закрыть]
. Каждые полгода Saab объявляет о новом выпуске операционной системы истребителя. Она делает его быстрее, дешевле, легче, эффективнее, мощнее, улучшает электронику и обеспечивает более продвинутые системы наведения. Ведущие эксперты по вопросам обороны назвали Gripen «лучшим малозаметным истребителем в мире»[43]43
  S. Joshi. Gripen Operational Cost Lowest of All Western Fighters: Jane’s // StratPost. July 4, 2012, http://www.stratpost.com/gripen-operational-cost-lowest-of-all-western-fighters-janes.


[Закрыть]
.

Авторитетная международная издательская группа IHS Jane’s, специализирующаяся на военной тематике, провела исследование, сравнив операционные издержки детища Saab с издержками истребителей F-16 и F-35 (Lockheed Martin), F/A-18 Super Hornet (Boeing), Rafale (Dassault) и Typhoon (Eurofighter). И пришла к выводу, что Gripen имел «наименьшие операционные расходы среди всех изученных истребителей». При этом рассматривались такие факторы, как расход топлива, предполетная подготовка и ремонт, а также регулярное аэродромное техобслуживание совместно с сопутствующими затратами на персонал»[44]44
  S. Joshi. Gripen Operational Cost Lowest of All Western Fighters: Jane’s // StratPost. July 4, 2012, http://www.stratpost.com/gripen-operational-cost-lowest-of-all-western-fighters-janes.


[Закрыть]
.

Программное обеспечение играет все более значимую роль в разработке и эволюции Gripen. «Головная боль, с которой сталкиваются производители истребителей, – пишет Билл Свитман в Aviation Week and Space Technology, – заключается в том, что каким бы грамотным ни был ваш проект, разработка и создание этих самолетов ведет к огромным расходам. Кроме того, их жизненный цикл от проектирования до утилизации намного превосходит рамки политического или технологического горизонта». Gripen был разработан с учетом этих особенностей: «Продолжительный срок службы требует гибкости как в отношении боевых миссий, так и на протяжении жизненного цикла»[45]45
  B. Sweetman. Is Saab’s New Gripen the Future of Fighters? // Aviation Week and Space Technology. March 24, 2014, http://aviationweek.com/defense/saab-s-new-gripen-future-fighters.


[Закрыть]
.

Тот же феномен наблюдается в мире автомобилей. На протяжении первого века существования автомобилей человек покупал машину без всякой возможности модифицировать впоследствии свое приобретение, например увеличив его мощность или повысив функциональность. Теперь ситуация изменилась. В частности, Tesla может дополнить новыми функциями – автоматическим торможением при вероятном столкновении, частичной системой автопилота и автоматизированной системой парковки – уже проданные автомобили, загрузив в них новое ПО. Подобные возможности предлагаются и другими производителями автомобилей класса люкс вроде Audi или Mercedes-Benz. Разница лишь в том, что Tesla Model S разработана с возможностью постоянного апгрейда «на лету».

«Model S, по сути, представляет собой очень сложный компьютер на колесах, – рассказывает CEO компании Илон Маск. – Tesla разрабатывает как ПО, так и аппаратное обеспечение. Мы относимся к апгрейду автомобиля так же, как к обновлению телефона или ноутбука»[46]46
  J. Hirsch. Elon Musk: Model S Not a Car but a ‘Sophisticated Computer on Wheels // LA Times. March 19, 2015, http://www.latimes.com/business/autos/la-fi-hy-musk-computer-on-wheels-20150319story.html.


[Закрыть]
.

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

В этой связи полезно вспомнить, что Agile-менеджмент начал ассоциироваться с программным обеспечением лишь с 2001 года. Исторические же его корни лежат в сфере производства – в quality movement в Японии, в частности в Toyota Production System. Компания начала с того, что стала экспериментировать с маленькими промышленными сериями и обнаружила, что работа короткими циклами, определяемыми спросом, оказалась более эффективной, чем массовое производство[47]47
  S. Denning. The Leader’s Guide to Radical Management. San Francisco: Jossey-Bass, 2010. P. 118–121.


[Закрыть]
.

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

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

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

Этот целостный подход обладает шестью характеристиками: встроенной нестабильностью, самоорганизующимися проектными командами, параллельными фазами разработки, мультиобучением, неявным контролем и передачей знаний внутри организации. Шесть элементов складываются, словно пазл, в быстрый, гибкий процесс разработки нового продукта. Не менее важен тот факт, что новый подход может инициировать перемены. Это инструмент создания креативных идей и процессов, ориентированных на рынок, внутри существующей организации[48]48
  H. Takeuchi, I. Nonaka. The New New Product Development Game // Harvard Business Review. January 1986, https://hbr.org/1986/01/the-new-new-product-development-game.


[Закрыть]
.

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

В 1990 году итерационный микрокомандный подход распространился шире. В классической книге «Машина, которая изменила мир»[49]49
  Джеймс П. Вумек, Дэниел Т. Джонс, Дэниел Рус. Машина, которая изменила мир. М.: Попурри, 2007. Прим. ред.


[Закрыть]
он получил название «бережливое производство»[50]50
  J. P. Womack, D. T. Jones. The Machine That Changed the World: The Story of Lean Production – Toyota’s Secret Weapon in the Global Car Wars That Is Now Revolutionizing World Industry. New York: Free Press, 1990. Авторы книги отмечали колоссальную разницу в результатах компаний, применяющих метод Toyota (его еще называют бережливым производством) и работающих по традиционной схеме (названной в книге массовым производством). С точки зрения разработки бережливый подход был более производителен для каждого измеряемого аспекта. Речь не шла о разнице между заводами в Японии и в США. На деле некоторые из лучших предприятий находились в США, а некоторые из худших – в Японии. Разница заключалась в способе управления, при этом не имело значения, кто управлял предприятием. Согласно исследованию, наивысший рейтинг в отношении качества и производительности был отнюдь не у японских предприятий, а у завода Ford в Эрмосильо (Мексика).


[Закрыть]
. Однако, зародившись в сфере аппаратного обеспечения, систематическое использование микрокоманд и итерационных подходов получило подлинное признание именно в сфере разработки ПО после публикации Agile-манифеста в 2001 году.

* * *

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


Страницы книги >> Предыдущая | 1 2 3 4 5 | Следующая
  • 0 Оценок: 0

Правообладателям!

Данное произведение размещено по согласованию с ООО "ЛитРес" (20% исходного текста). Если размещение книги нарушает чьи-либо права, то сообщите об этом.

Читателям!

Оплатили, но не знаете что делать дальше?


Популярные книги за неделю


Рекомендации