Войти в систему
Войти с помощью соц. сетей:
Глава 14
Теперь, когда мы знаем, что данным нашего опроса можно доверять, то есть у нас есть разумная уверенность в том, что данные наших хорошо разработанных и надежно проверенных конструкций, созданных на основе психометрического опроса, говорят нам то, что мы о них думаем, зачем нам использовать опрос? И зачем вообще кому бы то ни было использовать опрос?
Команды, желающие понять эффективность своего процесса доставки программного обеспечения, часто начинают с инструментирования процесса доставки ПО и цепочки инструментов для получения данных (в этой книге собранные таким образом данные мы называем системными данными). Действительно, сегодня несколько представленных на рынке инструментов предлагают анализ такой метрики, как срок выполнения. Так почему же кому-то захочется собирать данные из опросов, а не просто из своего набора инструментов?
Существует несколько причин для использования данных опроса. В этой главе мы кратко представим некоторые из них.
Зачастую самой веской причиной использования опросов является скорость и простота сбора данных. Это особенно актуально для новых или разовых усилий по сбору данных или же для сбора данных, который распространяется или пересекает организационные границы. Данные для исследования в этой книге собирались четыре раза.
Каждый раз на сбор данных у нас уходило от четырех до шести недель, сбор осуществлялся со всего мира и от тысяч респондентов, представляющих тысячи организаций. Представьте себе сложность (на самом деле невозможность) получения системных данных от такого количества команд за тот же период времени. Даже само получение юридических разрешений было бы невозможным, не говоря уже о спецификации и передаче данных.
Но давайте предположим, что у нас получилось собрать системные данные от нескольких тысяч респондентов со всего мира за четыре недели. Следующим шагом будет очистка данных и их анализ. Анализ данных для «Отчетов о состоянии DevOps» обычно занимает 3–4 недели. Многие из вас, вероятно, работали с системными данными; еще больше из вас, вероятно, имели удовольствие (а скорее всего, боль) от объединения и сортировки электронных таблиц Excel. Представьте себе получение приблизительных системных данных (или, возможно, таблиц планирования капиталовложений) от нескольких тысяч команд со всего мира. Представьте себе задачу по очистке, систематизации и последующему анализу таких данных и будьте готовы предоставить результаты для отчетности в течение трех недель.
К основной задаче очистки данных и выполнения анализа добавляется сложная проблема, которая может поставить под сомнение всю вашу работу и, вероятно, стать самым большим ограничением: сами данные, а если более конкретно, то исходное значение самих данных.
Вероятно, вы видели это и в своих собственных организациях: разные команды могут ссылаться на абсолютно разные (или немного разные) показатели под одним и тем же названием. Приведем два примера: «время выполнения» (которое мы определяем как время от коммита до кода в развертываемом состоянии) и «время производственного цикла» (которое некоторые определяют как время от начала разработки до кода в развертываемом состоянии). Однако эти два термина часто используются как взаимозаменяемые и довольно часто с ними возникает путаница, несмотря на то что они измеряют разные параметры.
Что же произойдет, если одна команда пользуется термином «время производственного цикла», а другая — «время выполнения», но обе они измеряют при этом одно и то же? Или если обе команды называют некий процесс «временем выполнения», но измеряют при этом два разных параметра? А потом мы собрали данные и теперь пытаемся провести анализ… Но мы не знаем наверняка, какие из этих переменных какие. Это создает существенные проблемы измерения и анализа.
Тщательно сформулированные и проработанные опросы, которые были проверены, помогают решить эту проблему. Все респонденты теперь работают с одними и теми же элементами, терминами и определениями. Не важно, как они называют что-либо в своей организации, важно то, о чем их спрашивают в данном опросе. Значение имеет то, о чем их спрашивают, и поэтому намного более важными являются качество и ясность элементов опроса. Но, как только завершается работа по составлению опроса, работа по очистке и подготовке данных для анализа выполняется быстрее и проще.
В ходе тщательного исследования дополнительные анализы (например, общий метод проверки смещений) проводятся в целях того, чтобы убедиться, что сам опрос не внес искажений в результаты, и ответы проверяются на предмет смещений в ответах более ранних и более поздних респондентов ().
Даже если ваша система сообщает хорошие и полезные данные (предположение, которое, как мы знаем по опыту, довольно часто бывает неверным и, как правило, должно удостоверяться опытным путем), такие данные редко бывают исчерпывающими. То есть вы действительно можете быть уверены в том, что он на 100% измеряет поведение системы, которая вас интересует?
Давайте проиллюстрируем это на примере. Один из авторов часть своей карьеры проработала в качестве инженера по производительности в компании IBM, работая над корпоративными дисковыми системами хранения данных. Роль ее команды заключалась в диагностике и оптимизации производительности таких устройств, включая операции чтения, записи, кэширования и перестроения RAID-массива в условиях различной рабочей нагрузки. После работы над несколькими инициативами блок работал хорошо и у команды в доказательство этого были метрические показатели со всех уровней системы. Периодически команда все еще получала от клиентов отчеты о том, что блок работал медленно. Команда каждый раз проводила расследование, но первые один-два отчета были отклонены командой, так как у них было подтверждение того, что производительность была хорошей: это демонстрировали все системные журналы!
Однако по мере того, как команда начала получать все больше сообщений о низкой производительности, потребовался более серьезный анализ. Несомненно, и у клиентов, и у филд-инженеров могут быть мотивы лгать, например, для получения скидок исходя из нарушения условий соглашений о качестве предоставления услуг. Но в отчетах клиентов и отчетах филд-инженеров прослеживалась своя закономерность — все ссылались на одинаковую медлительность. Хотя эти данные, полученные от людей, не имели такой же степени точности, как системные журналы (например, минутная точность в сообщаемом времени отклика по сравнению с миллисекундной точностью из файлов системных журналов), это дало команде достаточно данных, чтобы знать, где искать. Они подсказали алгоритмы и подали сигналы, за которыми нужно было следовать в своей работе.
Так что же это было? Оказалось, что сам блок работал очень хорошо. Команда оборудовала каждый уровень стека и охватила все, что можно было охватить… в блоке. Чего команда не охватила, так это интерфейс. То, как клиенты взаимодействовали с блоком, вело к существенному снижению производительности. Команда быстро организовала небольшую группу для управления этой новой областью, и вскоре вся система работала на пике производительности.
Не задавая людям вопросов о производительности системы, команда не поняла бы, что происходит. Уделяя время для проведения периодических оценок, включающих в себя точку зрения технических специалистов, которые занимаются созданием и доставкой вашей технологии, вы сможете обнаружить узкие места и другие ограничения в вашей системе. Опросив всех членов своей команды, вы можете помочь избежать проблем, связанных с наличием ряда излишне позитивных или излишне негативных ответов.
Связанная с этим причина использования опросов заключается в неспособности зафиксировать все, что происходит, посредством системных данных, потому что ваши системы знают только о том, что происходит в границах системы. И наоборот, люди могут наблюдать все, что происходит в системе и вокруг нее, и сообщают об этом. Давайте проиллюстрируем это на примере.
Наше исследование продемонстрировало, что использование контроля версий является ключевой возможностью в эффективности доставки программного обеспечения. Если мы хотим знать, в какой степени команда использует систему контроля версий для всех производственных артефактов, мы можем спросить команду. Участники команды могут рассказать это нам, так как они видят всю рабочую картину. Однако, если мы хотим измерить это через систему, у нас есть существенные ограничения. Система в состоянии сказать нам только о том, что она видит, то есть сколько файлов или репозиториев регистрируется в системе контроля версий. Но это абстрактное число без контекста смысла не имеет.
В идеале мы хотели бы знать процент файлов или репозиториев, которые находятся в управлении версиями, однако этого система сообщить нам не сможет: это потребует подсчета зарегистрированных и незарегистрированных файлов, а система не знает, сколько файлов не находится в системе контроля версий. Система лишь обеспечивает наглядное представление находящихся в ней объектов, и в этом случае использование систем контроля версий — это то, что не поддается точному измерению системными журналами и измерительными приборами.
Люди также не будут обладать совершенными знаниями или абсолютным доступом в системы, однако, если вы полностью игнорируете восприятие и опыт профессионалов, работающих над вашими системами, вы теряете важный взгляд на них.
Нас часто спрашивают, почему можно доверять каким-либо данным, полученным в результате опросов, и, соответственно, результатам опросов. Это можно проиллюстрировать мыслительным упражнением, которое мы иногда используем, обращаясь к группам технических специалистов и задавая им вопросы о работе. Задайте себе (или кому-то из своих знакомых, работающих в области разработки и доставки программного обеспечения) эти вопросы.
Злоумышленники и системные данные
Сюжет ставшего культовой классикой фильма «Офисное пространство» (Office Space) построен на этой теме: злоумышленники вносят изменения в финансовое программное обеспечение, которое депонирует небольшие суммы денег (известные как «ошибка округления») на некий личный счет. Об этой ошибке округления в финансовых отчетах не сообщается. Это яркий пример недостоверных системных данных.
Если мы так хорошо знакомы с недостоверными данными в наших системах, почему мы так им доверяем и при этом все же скептически относимся к данным опроса? Возможно, это связано с тем, что, будучи инженерами и техническими специалистами, мы понимаем, как работают наши системы. Мы полагаем, что сможем обнаружить ошибки в данных, поступающих из этих систем, а затем будем знать, как их исправить.
И наоборот, работа с данными опроса кажется непривычной, особенно для тех, кто не изучал создание опросов и психометрические методы. Но обзор концепций, представленный в Части II, призван продемонстрировать, что есть шаги, которые можно предпринимать, чтобы сделать данные опроса более надежными. Они включают использование тщательно выработанных показателей, скрытых конструкций и статистических методов для подтверждения достоверности и надежности измерений.
Сравните два наших случая: системные данные и данные опроса. В случае с системными данными один или несколько человек могут изменить данные в файлах системного журнала. Это может быть высокомотивированный злоумышленник с корневым доступом (или высоким уровнем системного доступа) или это может быть разработчик, допустивший ошибку, которая не была обнаружена в ходе проверки или тестирования. Они оказывают значительное влияние на качество данных, так как у вас, вероятно, есть только одна или несколько точек данных, на которые бизнес обращает внимание. В этом случае ваши необработанные данные являются неверными, а вы можете не замечать этого месяцами, годами или вообще всегда.
В случае с данными опроса несколько высокомотивированных «злоумышленников» могут лгать, отвечая на вопросы, и их ответы могут исказить результаты всей группы. Их влияние на данные зависит от размера опрашиваемой группы. В исследовании, проведенном для данной книги, у нас было более 23 000 респондентов, чьи ответы мы объединили вместе. Чтобы внести заметные различия, потребовалось бы несколько сотен человек, которые бы скоординированно и организованно лгали, то есть они должны были бы лгать о каждом элементе в скрытой конструкции в одинаковой степени и в одинаковом направлении. В этом случае использование опроса действительно защищает нас от злоумышленников. Для обеспечения сбора достоверных данных предпринимаются дополнительные шаги; например, все ответы являются анонимными, что помогает респондентам чувствовать себя в безопасности и делиться честными отзывами.
Вот почему мы можем доверять данным нашего опроса или, по крайней мере, у нас есть разумная уверенность в том, что данные говорят нам то, о чем мы думаем: мы пользуемся скрытыми конструкциями, а также тщательно и продуманно прописываем критерии нашего опроса, избегая использования любых пропагандистских элементов; мы выполняем ряд статистических тестов, чтобы подтвердить, что наши показатели соответствуют психометрическим стандартам достоверности и надежности; и у нас есть большой набор данных от респондентов со всего мира, что служит защитой от ошибок или злоумышленников.
Некоторые вещи можно измерить только с помощью опросов. Когда мы хотим спросить о восприятии, чувствах и мнениях, опрос зачастую является единственным способом. Мы еще раз укажем на наш предыдущий пример с организационной культурой.
У людей часто будет возникать желание полагаться на объективные данные, чтобы определить что-то вроде организационной культуры. Объективные данные не подвержены влиянию со стороны чувств или эмоций; напротив, субъективные данные отражают восприятие или чувства человека по отношению к ситуации. В случае организационной культуры команды часто обращаются к объективным показателям, потому что они хотят быстрее собрать данные (например, из систем управления персоналом), и все равно еще остается беспокойство по поводу того, что люди лгут о своих чувствах. Проблема с использованием переменных из систем управления персоналом для определения культуры состоит в том, что такие переменные редко являются прямым отображением. Например, распространенным показателем «хорошей» организационной культуры является удержание сотрудников, и, наоборот, показателем «плохой» организационной культуры является текучесть кадров.
С этим определением связано несколько проблем, потому что существует много факторов, влияющих на то, остается ли кто-то или нет в команде или организации. Например:
Текучесть может быть полезным показателем, если мы тщательно продумываем то, что мы собираемся измерять. Однако в представленных выше примерах мы видим, что текучесть и удержание кадров не очень много говорят нам о нашей команде или организационной культуре, или если они и говорят что-то, то это может быть не тем, о чем мы думали. Если мы хотим понять, как люди относятся к риску, обмену информацией и коммуникации через границы, мы должны спросить их об этом. Да, вы можете использовать другие системные индикаторы, чтобы увидеть, как происходит что-то из перечисленного. Например, вы можете наблюдать за сетевым трафиком, чтобы понять, кто из членов команды чаще других общается между собой, и в течение продолжительного времени вы можете наблюдать тенденции к увеличению или снижению командного общения. Вы даже можете провести семантический анализ, чтобы узнать, имеют ли слова в электронных письмах или чатах в целом негативную или позитивную окраску. Но если вы хотите знать, как люди относятся к рабочей среде и насколько благоприятно она влияет на их работу и их цели, если вы хотите знать, почему они ведут себя именно так, как вы это наблюдаете, вы должны спросить их об этом. И лучшим вариантом сделать это систематическим, надежным способом, который поддается сравнению с течением времени, будет проведение опросов. И это стоит спрашивать. Исследования показали, что организационная культура предсказывает технологии, организационную эффективность и результаты работы и что командная работа и психологическая безопасность являются наиболее важными аспектами в понимании эффективности работы команды (Google, 2015).
Войти с помощью соц. сетей: