Джез Хамбл
Ускоряйся! Наука DevOps. Как создавать и масштабировать высокопроизводительные цифровые организации
Краткая справка: Возможности управления оптимизацией
Наше исследование выявило 24 ключевые возможности, которые способствуют улучшению эффективности доставки программного обеспечения. Эта справка укажет вам на их расположение по ходу книги. Подробное руководство вы найдете в Приложении А. Возможности представлены в произвольном порядке.
Они подразделяются на пять категорий:
● непрерывная доставка;
● архитектура;
● продукт и процесс;
● бережливое управление и мониторинг;
● культурные возможности.
ВОЗМОЖНОСТИ НЕПРЕРЫВНОЙ ДОСТАВКИ
1. Контроль версий: Глава 4.
2. Автоматизация развертывания: Глава 4.
3. Непрерывная интеграция: Глава 4.
4. Магистральная разработка: Глава 4.
5. Автоматизация тестирования: Глава 4.
6. Управление тестовыми данными: Глава 4.
7. «Сдвиг влево»[2] по безопасности: Глава 6.
8. Непрерывная доставка (НД): Глава 4.
ВОЗМОЖНОСТИ АРХИТЕКТУРЫ
9. Слабосвязанная архитектура: Глава 5.
10. Уполномоченные команды: Глава 5.
ВОЗМОЖНОСТИ ПРОДУКТА И ПРОЦЕССА
11. Обратная связь от клиентов: Глава 8.
12. Поток создания ценности: Глава 8.
13. Работа небольшими партиями: Глава 8.
14. Командные эксперименты: Глава 8.
ВОЗМОЖНОСТИ БЕРЕЖЛИВОГО УПРАВЛЕНИЯ И МОНИТОРИНГА
15. Процесс утверждения изменений: Глава 7.
16. Мониторинг: Глава 7.
17. Упреждающее уведомление: Глава 13.
18. Пределы НЗП (незавершенного производства): Глава 7.
19. Визуализация: Глава 7.
КУЛЬТУРНЫЕ ВОЗМОЖНОСТИ
20. Организационная культура Веструма: Глава 3.
21. Поддерживающее обучение: Глава 10.
22. Взаимодействие между командами: Главы 3 и 5.
23. Удовлетворенность работой: Глава 10.
24. Трансформационное лидерство: Глава 11.
Вступление
В конце 2013 года мы приступили к четырехлетнему научному путешествию, чтобы исследовать, какие возможности и методы важны для ускорения разработки и доставки программного обеспечения и, в свою очередь, какие из них представляют ценность для компаний. Их результативность проявляется в прибыльности компании, ее производительности и доле рынка. Мы видим аналогичный эффект и в некоммерческих результатах, в частности, когда речь идет об удовлетворении клиента.
Это исследование отвечает на потребность, которую в настоящее время не закрывает рынок. Используя строгие методы исследования, которые традиционно встречаются только в академических кругах, и делая их доступными для отрасли, мы преследуем цель продвинуть на новый уровень состояние разработки и доставки программного обеспечения. Помогая отрасли выявлять и понимать возможности, которые на самом деле приводят к повышению эффективности статистически значимым образом, мы выходим за пределы одного эпизода. Основываясь на опыте одной или нескольких команд, мы можем помочь всей отрасли улучшиться.
Для проведения исследований, представленных в этой книге (в дополнение к тем, над которыми мы работаем до сих пор), мы используем перекрестные межгрупповые исследования. Те же методы используются в медицинских исследованиях (например, для изучения взаимосвязи между потреблением пива и ожирением, Бобак и соавторы, 2003), исследованиях рабочей среды (например, для изучения взаимосвязи между рабочей средой и сердечно-сосудистыми заболеваниями, Джонсон и Холл, 1988) и исследованиях памяти (например, для изучения различий в процессах развития и снижения памяти, Алловэй и Алловэй, 2013). Поскольку мы хотим по-настоящему изучить отрасль и понять, что приводит к значительному улучшению программного обеспечения и организационной эффективности, мы используем строгие методы построения научных исследований и публикуем большую часть нашей работы в академических журналах. Дополнительную информацию о методах нашего исследования вы найдете в Части II «Исследование».
ИССЛЕДОВАНИЕ
В рамках исследования мы собрали по нашим опросникам более 23 000 ответов со всего мира. Мы получили обратную связь от более чем 2000 уникальных организаций, от небольших стартапов с количеством сотрудников до пяти человек до крупных предприятий со штатом более 10 000 человек. Мы собрали данные от маленьких стартапов и передовых интернет-компаний, а также организаций, работающих в строго регулируемых отраслях, таких как финансы, здравоохранение и государственные структуры. Наши данные и анализ включают программное обеспечение, разработанное на совершенно новых платформах, так называемых greenfield («зеленое поле» – проекты, созданные с нуля. – Прим. ред.), а также обслуживание и разработку существующего кода ПО.
Выводы, приведенные в этой книге, применимы независимо от того, используете ли вы традиционную каскадную методологию (также известную как закрытая, структурированная или плановая) и только начинаете трансформацию технологии, или же уже много лет внедряете методы Agile и DevOps. Это верно, потому что доставка программного обеспечения – это упражнение в непрерывном улучшении и наше исследование показывает, что год за годом лучшие продолжают достигать новых высот, а те, кто не смог этого сделать, отстают все больше и больше.
Улучшение возможно для всех
Наши поиски понимания того, как оценить и улучшить доставку программного обеспечения, были полны открытий и сюрпризов. Мораль этой истории, подтвержденная данными, заключается в следующем: улучшения в доставке программного обеспечения возможны для каждой команды и в каждой компании, пока руководство обеспечивает последовательную поддержку – включая время, действия и ресурсы – и, разумеется, пока члены команды ответственно выполняют свою работу.
Цель этой книги – поделиться тем, что мы узнали, чтобы помочь организациям преуспевать, вырастить более счастливые команды, которые быстрее доставляют лучшее программное обеспечение, и помочь процветанию организаций и отдельных людей. Остальная часть этого вступления кратко описывает, как началось и как проводилось это исследование. Более подробно о его научной основе вы прочтете в Части II этой книги.
ПРОДЕЛАННАЯ РАБОТА И ДАННЫЕ
Нас часто спрашивают об истории происхождения этого исследования. Оно основано на непреодолимом интересе к тому, что делает лучшие технологические организации великими и как программное обеспечение делает организации лучше. Сначала авторы работали параллельно над пониманием исключительных технических характеристик, прежде чем объединить усилия в конце 2013 года.
● Николь Форсгрен имеет степень доктора философии в области управления информационными системами. До 2013 года она провела несколько лет, исследуя факторы, которые делают технологии эффективными в организациях – особенно среди профессионалов, которые создают программное обеспечение и инфраструктуру поддержки. Она является автором десятков научных статей на эту тему. До получения докторской степени она была инженером программного и аппаратного обеспечения и системным администратором.
● Джез Хамбл – соавтор книг «Непрерывная доставка» (Continuous Delivery), «Бережливое предприятие» (Lean Enterprise) и «Руководство по DevOps» (The DevOps Handbook). Его первой работой после колледжа был стартап в Лондоне в 2000 году, а затем в 2005–2015 годах он провел десять лет в компании ThoughtWorks, занимаясь доставкой программных продуктов и консультируя клиентов в качестве специалиста по инфраструктуре, разработчика и продукт-менеджера.
● Джин Ким изучает высокоэффективные технологические организации с 1999 года. Он был основателем и техническим директором компании Tripwire в течение 13 лет и является соавтором многих книг, включая «Проект Феникс» (The Phoenix Project) и «Руководство по Visible Ops» (The Visible Ops Handbook).
В конце 2013 года Николь, Джез и Джин начали работать вместе с командой компании Puppet Inc. в рамках подготовки «Отчета о состоянии DevOps 2014 года»[3]. Объединив практический опыт и академическую строгость, команда смогла создать нечто уникальное в отрасли: отчет, содержащий информацию о том, как сделать так, чтобы технологии создавали ценность для сотрудников, организаций и клиентов прогнозируемыми способами. В течение следующих четырех отчетов Николь, Джез и Джин продолжали сотрудничать с командой Puppet Inc., чтобы повторно применять методологию данного исследования и постоянно улучшать отраслевое понимание того, что способствует отличной доставке программного обеспечения, позволяет создать выдающиеся технические команды и как компании могут стать высокоэффективными организациями и выигрывать на рынке, используя технологии. Эта книга охватывает четыре года исследований, начиная с отчета (с 2014 по 2017 год).
Чтобы собрать данные, каждый год мы отправляли приглашения по нашим спискам рассылки и использовали социальные сети, включая Twitter, LinkedIn и Facebook. Наши приглашения были адресованы техническим специалистам, особенно тем, кто знаком с парадигмами разработки и доставки ПО, а также с DevOps. Мы призывали наших читателей приглашать друзей и коллег, которые тоже могли быть заняты в области разработки и доставки программного обеспечения, чтобы помочь нам расширить охват аудитории. Это называется «выборка по методу снежного кома», и мы поговорим о том, почему это был подходящий метод сбора данных для этого исследовательского проекта, в Главе 15 «Данные для проекта».
Данные для нашего проекта были получены из опросов. Мы использовали опросы, потому что это лучший способ собрать большой объем данных из тысяч организаций за короткий промежуток времени. Детальное обсуждение того, почему хорошие исследования могут быть проведены на основе опросов, а также шагов, которые мы предприняли для обеспечения достоверности и точности собранных данных, см. в Части II, которая охватывает научную основу и методологию исследования, лежащие в основе книги.
А вот краткий обзор исследования и того, как оно развивалось на протяжении нескольких лет.
2014 ГОД: ЗАКЛАДЫВАЯ ОСНОВЫ. ЭФФЕКТИВНОСТЬ ДОСТАВКИ ПО И ОРГАНИЗАЦИОННАЯ ЭФФЕКТИВНОСТЬ
Наши исследовательские цели в течение первого года состояли в том, чтобы заложить основу для понимания разработки и доставки программного обеспечения в организациях. Вот некоторые ключевые вопросы.
● Что значит доставка программного обеспечения и можно ли ее измерить?
● Влияет ли доставка ПО на организации?
● Имеет ли значение культура и как мы ее измеряем?
● Какие технические практики представляются важными?
Мы были приятно удивлены многими результатами в первый год. Мы обнаружили, что разработка и доставка программного обеспечения могут быть измерены статистически значимым образом и что успешные компании делают это постоянно с помощью методов, которые значительно лучше, чем у многих других компаний. Мы также обнаружили, что скорость и стабильность движутся вместе и способность организации создавать программное обеспечение положительно влияет на прибыльность, производительность и долю рынка. Мы увидели, что культура и технические практики имеют значение, и нашли способ их измерить. Об этом мы расскажем в первой части этой книги.
Группа также пересмотрела способ измерения большинства данных, перейдя от простых вопросов «да/нет» к вопросам по шкале Ликерта (в которых респонденты выбирают из спектра вариантов от «категорически не согласен» до «полностью согласен»). Это простое изменение в вопросах позволило команде собрать больше нюансов – оттенки серого вместо черно-белого. Это позволило провести более детальный анализ. Почему авторы решили использовать опросы для этого исследовательского проекта и почему вы можете доверять их данным, мы обсудим в Главе 14 «Зачем использовать опрос».
2015 ГОД: РАСШИРЕНИЕ РАБОТЫ И УГЛУБЛЕНИЕ АНАЛИЗА
Подобно технологическим преобразованиям и росту бизнеса, проведение исследований – это итерации, постепенные улучшения и переоценка важных результатов. Вооружившись нашими выводами за первый год, мы поставили в качестве целей на второй год пересмотр и подтверждение некоторых ключевых результатов исследования (например, что доставка программного обеспечения может быть определена и измерена статистически значимым образом и что она влияет на эффективность организации), а также расширение модели исследования.
Ниже представлены некоторые из вопросов исследования.
● Можем ли мы повторно подтвердить, что доставка программного обеспечения влияет на эффективность работы организации?
● Влияют ли технические методы и автоматизация на доставку программного обеспечения?
● Влияют ли методы бережливого управления на доставку программного обеспечения?
● Влияют ли технические методы и методы бережливого управления на те аспекты работы, которые оказывают воздействие на человеческие ресурсы, например, беспокойство, связанное с развертыванием кода и профессиональным выгоранием сотрудников?
Еще раз мы получили великолепные подтверждения по некоторым вопросам и ряд сюрпризов. Наши гипотезы подтвердились, расширив рамки работы, проделанной нами в прошлом году. Эти результаты вы можете найти в Части I.
2016 ГОД: РАСШИРЕНИЕ НАШЕГО ВЗГЛЯДА НА ТЕХНИЧЕСКИЕ МЕТОДЫ И ИЗУЧЕНИЕ НЕЧЕТКОГО ВНЕШНЕГО ИНТЕРФЕЙСА
На третьем году мы вновь опирались на основное ядро нашей модели и расширили ее, чтобы изучить значение дополнительных технических методов (таких как безопасность, магистральная разработка и управление тестовыми данными). Вдохновленные беседами с коллегами, работающими в области управления продуктами, мы еще расширили наше исследование, чтобы увидеть, можем ли мы измерить влияние текущего перехода от традиционных методов управления проектами к использованию принципов бережливого производства в управлении продуктами. Мы углубили наши изыскания, чтобы включить качественные измерения, такие как ошибки, доработки и восстановление безопасности. Наконец, мы включили дополнительные вопросы, чтобы попробовать понять, как технические методы влияют на человеческий капитал: индекс чистой лояльности сотрудников (eNPS) и приверженность работе – факторы, которые, как предполагается, должны уменьшать выгорание.
Ниже представлены вопросы нашего исследования.
● Помогает ли интеграция безопасности в разработку и доставку программного обеспечения этому процессу или замедляет его?
● Способствует ли магистральная разработка улучшению доставки программного обеспечения?
● Является ли бережливый подход к управлению продуктами важным аспектом разработки и доставки программного обеспечения?
● Способствуют ли хорошие технические практики повышению лояльности сотрудников?
2017 ГОД: ДОБАВЛЯЕМ АРХИТЕКТУРУ, ИЗУЧЕНИЕ РОЛИ ЛИДЕРОВ И ИЗМЕРЕНИЕ УСПЕХА В НЕКОММЕРЧЕСКИХ ОРГАНИЗАЦИЯХ
На четвертом году исследования мы перешли к вопросам о том, как проектируются системы и как архитектура влияет на способность команд и организаций доставлять программное обеспечение и формировать ценность. Мы также расширили наше исследование, чтобы включить в него измерение ценностей, которые выходят за рамки рентабельности, производительности и доли рынка, что позволяет анализу обращаться к некоммерческой аудитории. В исследовании этого года также изучалась роль лидеров для оценки влияния трансформационного лидерства в организациях.
Ключевые вопросы четвертого года нашего исследования.
● Какие архитектурные практики способствуют повышению эффективности доставки программного обеспечения?
● Как трансформационное лидерство влияет на доставку программного обеспечения?
● Влияет ли доставка программного обеспечения на некоммерческие результаты?
ВЫВОД
Мы надеемся, что, читая эту книгу, вы, как технический специалист и технологический лидер, откроете для себя важные элементы для улучшения своей организации, начиная прежде всего с доставки программного обеспечения. Именно благодаря улучшению нашей способности доставлять программное обеспечение организации могут быстрее предоставлять нужный функционал, при необходимости адаптироваться, реагировать на изменения в требованиях безопасности, а также использовать быструю обратную связь для привлечения новых клиентов и удовлетворения существующих.
В следующих главах мы определим ключевые возможности, определяющие эффективность доставки программного обеспечения (и определим, что такое эта эффективность), и кратко коснемся ключевых моментов каждой из них. Часть I книги представляет результаты наших исследований, Часть II рассматривает научную основу и исследования, стоящие за нашими результатами, и, наконец, в Части III представлен конкретный пример того, что происходит, когда организации принимают и внедряют эти возможности для повышения эффективности.
Часть I
Что мы выяснили
Вооружившись надежными методами сбора данных и статистического анализа (подробно рассмотренными в Части II), мы смогли обнаружить значительные и иногда неожиданные результаты за последние несколько лет, в течение которых мы работали над «Отчетом о состоянии DevOps». Мы смогли измерить и количественно оценить эффективность доставки программного обеспечения, ее влияние на эффективность работы организации и различные возможности, способствующие достижению этих результатов.
Эти возможности делятся на различные категории – технические, технологические и культурные. Мы измерили воздействие технических практик на культуру, а также влияние культуры на доставку и организационную эффективность. Говоря о таких несопоставимых возможностях, как архитектура и управление продуктами, мы рассмотрели их общее влияние на эти и другие важные показатели устойчивого развития, такие, в частности, как профессиональное выгорание и личные мучения при развертывании ПО.
В этой части книги мы представляем наши результаты.
Глава 1
Ускоряйтесь
Вести бизнес как обычно уже недостаточно, чтобы оставаться конкурентоспособным. Это касается организаций во всех отраслях: от финансов и банковского дела до розничной торговли, телекоммуникаций и даже госструктур. Компании отказываются от выпуска новых продуктов и услуг, связанных с реализацией крупных долгосрочных проектов. Вместо этого они используют небольшие проектные команды, которые работают в коротких временных циклах и измеряют обратную связь от пользователей для создания продуктов и услуг, которые радуют клиентов и быстро приносят пользу их организациям. Такие эффективные компании постоянно работают над тем, чтобы стать лучше в своем деле, не позволяя никаким препятствиям стоять у них на пути, даже перед лицом высокого уровня риска и неопределенности в том, как им достичь своих целей.
Чтобы оставаться конкурентоспособными и преуспевать на рынке, организации должны ускорить:
● доставку товаров и услуг, чтобы порадовать своих клиентов;
● взаимодействие с рынком для выявления и понимания потребительского спроса;
● предвидение изменений в области регулирования и соблюдения требований, которые влияют на их системы;
● реакцию на потенциальные риски, такие как угрозы безопасности или изменения в экономике.
В основе этого ускорения лежит программное обеспечение. Это справедливо для организаций любой отрасли. Банки больше не создают ценность, держа золотые слитки в хранилищах, а торгуют быстрее и надежнее, открывая новые каналы и продукты для привлечения клиентов. Компании розничной торговли завоевывают и удерживают клиентов, предлагая им превосходный выбор и обслуживание, причем обслуживание заключается в молниеносной оплате на кассе, рекомендуемых товарах или удобном онлайн/офлайн-шопинге – и все это обеспечивается технологиями. Правительственные организации, будучи традиционно прижимистыми в распределении средств налогоплательщиков, ссылаются на способность использовать технологии в качестве ключа к более успешному и эффективному служению обществу.
Программное обеспечение и технологии являются ключевыми отличительными факторами для организаций при формировании ценности как для клиентов, так и для акционеров. Мы пришли к этому выводу в наших собственных исследованиях, описанных в этой книге, но и другие исследователи тоже пришли к аналогичным результатам. Например, недавнее исследование Джеймса Бессена из Бостонского университета показало, что стратегическое использование технологий объясняет рост доходов и производительности больше, чем слияния и поглощения (M&A) и предпринимательство (2017). Эндрю Макафи и Эрик Бринольфссон также нашли связь между технологиями и рентабельностью (2008).
Программное обеспечение преобразует и ускоряет организации всех видов. Практики и возможности, о которых мы говорим в этой книге, возникли из того, что теперь известно как движение DevOps, и они трансформируют отрасли повсюду. DevOps возникло из небольшого числа организаций, столкнувшихся с серьезной проблемой: как построить безопасные, устойчивые, быстро развивающиеся распределенные и масштабируемые системы. Чтобы оставаться конкурентоспособными, организации должны научиться решать эти проблемы. Мы видим, что крупные предприятия с долгой историей и технологиями десятилетней давности также получают значительные преимущества в виде ускоренной доставки и более низких затрат благодаря использованию возможностей, которые мы описываем в этой книге.
Несмотря на то, что многие организации достигли больших успехов в своих технологических преобразованиях (заметными примерами являются такие интернет-гиганты, как Netflix, Amazon, Google и Facebook, а также более традиционные крупные компании, включая Capital One, Target, Службу технологических преобразований при Правительстве США и Цифровую службу США), впереди еще по-прежнему много работы – как в самой индустрии в широком смысле, так и в отдельных организациях. Согласно недавнему отчету Forrester (Страуд и соавторы, 2017), выяснилось, что 31 % игроков в отрасли не используют практики и принципы, которые широко признаны необходимыми для ускорения технологических преобразований. К ним относятся технологии непрерывной интеграции и непрерывного развертывания ПО, практики бережливого производства и культура сотрудничества при разработке (то есть возможности, отстаиваемые движением DevOps). Тем не менее мы также знаем, что технологические и программные преобразования обязательны к внедрению в организациях сегодня. Недавнее исследование Gartner показало, что 47 % генеральных директоров испытывают давление со стороны членов совета директоров, которые настаивают на внедрении цифровых преобразований (Panetta, 2017).
Внутри самих организаций технологические преобразования находятся на разных стадиях, и отчеты показывают, что еще предстоит проделать гораздо больший объем работы, чем многие из нас сегодня представляют. В другом докладе Forrester говорится, что DevOps ускоряет развитие технологий, но организации часто переоценивают свой прогресс (Клавенс и соавторы, 2017). Кроме того, в докладе отмечается, что особенно склонны переоценивать прогресс руководители – в отличие от тех, кто фактически выполняет работу.
Эти выводы о несоответствии оценок зрелости DevOps со стороны руководителей и исполнителей обращают внимание на два аспекта, которые часто упускаются лидерами. Во-первых, если мы предположим, что оценки зрелости или возможностей DevOps от практиков более точны, потому что они ближе к работе, то потенциал для создания ценности и роста внутри организаций намного выше, чем руководители осознают в настоящее время. Во-вторых, выявленное различие в восприятии ясно показывает необходимость более точной оценки возможностей DevOps и передачи результатов этой оценки лидерам, которые могут использовать их для принятия решений и формирования стратегии в отношении технологического развития своей организации.
СОСРЕДОТОЧЬТЕСЬ НА ВОЗМОЖНОСТЯХ, А НЕ НА ЗРЕЛОСТИ
Технологические лидеры должны доставлять программное обеспечение быстро и надежно, чтобы преуспевать на рынке. Для многих компаний это требует значительных изменений в том, как это осуществляется. Ключами к успешному изменению являются оценка и понимание возможностей, а не зрелости продукта.
Хотя модели зрелости очень популярны в отрасли, мы не можем с уверенностью говорить о том, что они являются подходящим инструментом для использования на практике или в качестве модели мышления. Напротив, переход к модели измерения возможностей очень значим для организаций, желающих ускорить доставку программного обеспечения. Это обусловлено четырьмя факторами.
Во-первых, модели зрелости направлены на то, чтобы помочь организации прийти в зрелое состояние, а затем заявить о завершении своего пути, в то время как технологические преобразования должны следовать парадигме непрерывного улучшения. Кроме того, модели возможностей направлены на то, чтобы помочь организации постоянно совершенствоваться и прогрессировать, с учетом того, что технологический и деловой ландшафты постоянно меняются. Самые инновационные компании и самые эффективные организации всегда стремятся быть лучше и никогда не считают себя зрелыми или закончившими свой путь совершенствования или трансформации, и мы рассмотрим это в нашей работе.
Во-вторых, модели зрелости довольно часто являются жестко регламентированными стоп-шагами или представляют собой линейную формулу, предписывающую аналогичный набор технологий, инструментов или возможностей для каждой группы команд или организаций. Модели зрелости предполагают, что уровень 1 и уровень 2 выглядят одинаково во всех командах и организациях, но те из нас, кто работает в технологиях, знают, что это не так. Напротив, модели возможностей являются многомерными и динамичными, что позволяет различным подразделениям организации применять индивидуальный подход к улучшениям и фокусироваться на возможностях, которые принесут им наибольшую пользу, исходя из их текущего контекста и краткосрочных и долгосрочных целей. Команды имеют свой собственный контекст, свои собственные системы, свои собственные цели и свои собственные ограничения, и от этого зависит то, на чем мы должны сосредоточиться на следующем этапе, чтобы ускорить нашу трансформацию.
В-третьих, модели возможностей фокусируются на ключевых результатах и на том, как возможности способствуют улучшению этих результатов, то есть они основаны на результатах. Это обеспечивает техническое лидерство с четким направлением и стратегией на цели высокого уровня (с акцентом на возможности улучшения ключевых результатов). Это также позволяет руководителям групп и отдельным участникам устанавливать цели, связанные с возможностями, на которых сосредоточена их команда в текущий период времени. Большинство моделей зрелости просто измеряют техническую квалификацию или инструментальную базу в организации, не привязывая их к результатам. Они в конечном итоге являются метриками тщеславия: хотя их можно относительно легко измерить, они ничего не говорят нам о том, какое влияние они оказывают на бизнес.
В-четвертых, модели зрелости определяют статический уровень технологических, производственных и организационных возможностей, который может быть достигнут. Они не учитывают постоянно меняющийся характер технологий и бизнес-ландшафта. Наши собственные исследования и данные подтвердили, что отрасль меняется: то, что достаточно хорошо и даже высокоэффективно сегодня, уже недостаточно хорошо в следующем году. Напротив, модели возможностей позволяют динамично изменять окружающую среду и позволяют командам и организациям сосредоточиться на развитии навыков и возможностей, необходимых для сохранения конкурентоспособности.
Сосредоточившись на парадигме возможностей, организации могут постоянно стимулировать улучшение. А сосредоточившись на правильных возможностях, организации способны добиться улучшения своих результатов, что позволит им разрабатывать и доставлять программное обеспечение с более высокой скоростью и стабильностью. Фактически мы видим, что самые эффективные компании делают именно это, постоянно достигая успехов из года в год и никогда не соглашаясь на вчерашние достижения.
ПРЕОБРАЗОВАНИЯ, ОСНОВАННЫЕ НА ФАКТИЧЕСКИХ ДАННЫХ, СФОКУСИРОВАНЫ НА КЛЮЧЕВЫХ ВОЗМОЖНОСТЯХ
Как в рамках модели возможностей, так и в рамках модели зрелости существуют разногласия относительно того, на каких возможностях следует сосредоточиться. Поставщики продуктов часто предпочитают возможности, которые согласуются с их предложениями. Консультанты предпочитают возможности, которые отвечают их опыту, предложению и их привычным инструментам оценки. Мы видели, как организации пытаются разработать свои собственные модели оценки и выбрать решения, которые соответствуют навыкам внутренних «чемпионов» или поддаются параличу анализа из-за огромного количества областей, которые нуждаются в улучшении.
Необходимо более управляемое, основанное на фактических данных решение. И подход, обсуждаемый в этой книге, описывает именно такое решение.
Наше исследование дало понимание того, что обеспечивает эффективность доставки программного обеспечения и организационную эффективность, которые отражаются на прибыльности, производительности и доле рынка компании. На самом деле наше исследование показывает, что ни один из следующих часто цитируемых факторов не предполагал эффективности:
● время и технологии, используемые для приложения (например, программа «системы записи» против «системы взаимодействия», относящейся к «зеленому полю» разработки);