Глава 15

Данные для проекта

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

Наш исследовательский проект — поперечный сбор данных на протяжении четырех лет — привлекал профессионалов и организации, знакомых со словом «DevOps» (или хотя бы готовых прочитать электронные письма и сообщения в социальных сетях со словом «DevOps»), которые были нашей целевой аудиторией. Любой хороший исследовательский проект определяет целевую популяцию, и это была наша. Мы выбрали данную стратегию по двум основным причинам.

1. Это позволило нам сфокусироваться на сборе данных. В данном исследовании респондентами стали люди, чья деятельность связана с разработкой и доставкой программного обеспечения, независимо от того, была ли отрасль их материнской организации технологической сама по себе или технологии были ее движущей силой (розничная торговля, банковское дело, телекоммуникации, здравоохранение и ряд других).
2. Это позволило нам сосредоточиться на пользователях, которые были относительно знакомы с идеями DevOps. Наше исследование было нацелено на пользователей, уже знакомых с терминологией технических специалистов и применяющих современные методы разработки и доставки программного обеспечения, независимо от того, считали ли они себя приверженцами DevOps или нет. Это было важно, поскольку время и пространство были ограничены и слишком много времени, затраченного на основные определения и длинные объяснения концепций, таких как непрерывная интеграция и управление конфигурацией, могло создать риск отказа респондентов от участия в исследовании. Если читающий опрос человек должен потратить 15 минут на изучение концепции, чтобы ответить на вопросы о ней, он будет разочарован, раздражен и не завершит опрос.

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

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

Однако, основываясь на предыдущих исследованиях, нашем собственном опыте и опыте тех, кто проводил технологические трансформации на крупных предприятиях, мы считаем, что многие из наших выводов широко применимы к командам и организациям, проходящим через преобразования. Например, использование контроля версий и автоматизированного тестирования с высокой вероятностью даст положительные результаты независимо от того, использует ли команда методы DevOps, методологию Agile или надеется улучшить свои методы синхронной каскадной разработки (lockstep waterfall development). Аналогично наличие организационной культуры, которая ценит прозрачность, доверие и инновации, вероятно, окажет положительное влияние в технологических организациях независимо от парадигмы разработки программного обеспечения — и так в любой отраслевой вертикали, поскольку данная концепция предсказывает результаты работы в различных контекстах, включая здравоохранение и авиацию.

Как только мы определили нашу целевую популяцию, мы приняли решение по методу выборки: как нам пригласить людей принять участие в опросе. Существуют две обширные категории методов выборки: вероятностная выборка и детерминированная выборка. Мы не смогли использовать методы вероятностной выборки, поскольку это потребовало бы, чтобы каждый член целевой аудитории был известен и имел равные шансы на участие в исследовании. Это невозможно, поскольку исчерпывающего списка профессионалов в области DevOps в мире просто не существует. Ниже мы объясним это более подробно.

Чтобы собрать данные для нашего исследования, мы рассылали электронные письма и использовали социальные сети. Электронные письма были отправлены по нашим собственным спискам рассылки, которые состояли из технических специалистов и профессионалов, которые работали в DevOps (например, они находились в наших базах данных, потому что участвовали в исследованиях предыдущих лет, были в маркетинговых базах данных компании Puppet в связи с их работой с управлением конфигурациями, присутствовали в базах данных Джина Кима и Джеза Хамбла из-за своего интереса к их книгам и работе в отрасли). Электронные письма также были отправлены по спискам рассылки для профессиональных групп. Особое внимание также уделялось рассылке приглашений группам, включающим недостаточно представленные группы и меньшинства в области технологии. В дополнение к прямым приглашениям по электронной почте мы использовали социальные сети: авторы и спонсоры опроса публиковали ссылки на опрос в Twitter и LinkedIn. Направляя приглашения к участию в опросе из нескольких источников, мы увеличили наши шансы на контакт с большим количеством профессионалов DevOps, в то же время решая проблему ограничений выборки методом снежного кома, который обсуждается ниже.

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

• Идентификация популяции тех, кто создает ПО с использованием методологии DevOps, затруднена или невозможна. В отличие от профессиональных организаций, например, в области бухгалтерского учета или гражданского строительства, которые в США имеют государственную сертификацию, такую как CPA (Certified Public Accountants) или PE (Practice of Engineering), централизованного аккредитационного совета, который мог бы выдать нам справочный список профессионалов, просто не существует. Кроме того, мы не могли бы просматривать организационные схемы (даже если они находились в открытом доступе) на предмет названий должностей, поскольку не у всех в названии должности имеется «DevOps» или другие важные для нас ключевые слова. Кроме того, многие технические специалисты, особенно в начале исследовательского проекта, имели нестандартные должности. Даже если организационные схемы находились в общем доступе, многие названия должностей являются слишком общими, чтобы быть полезными в привлечении участников в исследование (например, «инженер-программист», что может подразумевать разработчиков, работающих в командах, использующих каскадный метод или методы DevOps). Выборка методом снежного кома хорошо подходит для изучения конкретных групп, популяции которых сложно идентифицировать.
• Популяция традиционно неохотно становится объектом изучения. Существует богатая (и неудачная) история организационных исследований технических работников, которые привели к «бережливым трансформациям», что на самом деле означало просто значительное сокращение рабочих мест. Выборка методом снежного кома — это метод, идеально подходящий для популяций, которые зачастую не хотят быть изученными; отсылая других к исследованию, люди могут поручиться за вопросы (заверяя новых участников, что вопросы не являются пропагандой) или даже за репутацию исследователей.

Существуют некоторые ограничения, присущие выборке методом снежного кома. Первое ограничение — это возможность того, что изначально отобранные пользователи (в нашем случае — приглашенные по электронной почте) не являются представителями сообществ, к которым они принадлежат. Мы компенсировали это наличием начального набора приглашений (или информантов), который был максимально большим и разнообразным. Мы достигли этого, объединив несколько списков рассылки, в том числе наш собственный список рассылки опроса, который содержал разнообразный набор респондентов из разных стран и из компаний разной величины. Мы также связались с недостаточно представленными группами и меньшинствами в области технологий через их собственные списки рассылок и организации.

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

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

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

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