Руководство для практикующего специалиста: Введение: о чем следует помнить при интерпретации показателей

  • Связанные показатели: Все
  • Аудитория: Руководства для практиков предназначены для специалистов-практиков, которые могут не быть экспертами в анализе данных и которые хотят лучше понять, как интерпретировать данные о проекте с открытым исходным кодом, чтобы получить представление, которое может помочь им улучшить работоспособность проекта с открытым исходным кодом. проект. Эти руководства будут особенно полезны для офисов программ с открытым исходным кодом (OSPO), руководителей проектов, менеджеров сообществ, специалистов по сопровождению и всех, кто хочет лучше понять работоспособность проекта и принять меры в соответствии с тем, что они узнают из своих показателей.

Измерение состояния проекта является сложной задачей, поскольку необходимо учитывать множество потенциальных аспектов (Linåker et al. 2022). Серия «Руководства для практиков» предназначена для того, чтобы разбить состояние проекта на ряд логических тем, которые вы можете использовать для оценки и улучшения состояния ваших проектов с открытым исходным кодом. Это Вводное руководство предназначено для того, чтобы заставить вас задуматься о том, что вы, возможно, захотите измерить и как это измерить, а также дать некоторые общие советы и предостережения. Оно призвано дополнить серию «Руководства для практиков», в которой вы найдете подробную информацию о том, как получить представление о конкретных темах, таких как отзывчивость, устойчивость участников, участие в организации и т. д.

Не существует универсального подхода к использованию показателей для измерения работоспособности проекта. Каждый проект с открытым исходным кодом немного отличается, и показатели всегда следует интерпретировать с учетом потребностей этого проекта и его контекста (Гоггинс и др., 2021). У небольших проектов будут другие потребности, чем у крупных проектов. Проект операционной системы с открытым исходным кодом будет иметь совсем другие характеристики, чем проект, создающий небольшой пакет или библиотеку. Разные сообщества будут использовать разные способы работы над созданием своих проектов программного обеспечения с открытым исходным кодом. Проекты имеют разные методы публикации релизов. Проекты и люди, которые в них участвуют, будут иметь разные потребности и цели.

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

Все это и многое другое повлияет на интерпретацию любых показателей с открытым исходным кодом. Настоящие эксперты — это люди, которые ежедневно участвуют в работе над проектом. Помимо сосредоточения внимания на целях, вам также может потребоваться потратить некоторое время на изучение тенденций, связанных с тем, кто участвует в сообществе и как они участвуют, чтобы получить общее представление о проекте и к кому вы, возможно, захотите обратиться за более подробной информацией. . Вам необходимо привлечь ключевых людей из проекта/сообщества, которое вы измеряете, поскольку они могут помочь вам этически интерпретировать показатели и любые выявленные тенденции способами, которые имеют наибольший смысл для этого конкретного проекта (Casari et al. 2023), как описано в подробнее в разделе «Шаг 2: Диагностика». Если вы еще не прочитали За пределами репозитория Авторы Аманды Казари, Джулии Феррайоли и Джунипер Ловато, я рекомендую сделать паузу и прочитать эту 6-страничную статью прямо сейчас.

В рамках проекта CHAOSS у нас есть программное обеспечение (Augur и GrimoireLab) который можно использовать для сбора данных и выявления тенденций нейтральным способом, который можно легко проверять и отслеживать с течением времени. Однако в этих руководствах для практиков не предполагается, что вы используете какое-либо конкретное программное обеспечение, поскольку у вас могут быть другие инструменты измерения показателей, которые подходят для вашей конкретной ситуации. Независимо от того, как вы собираете показатели, эти руководства помогут вам интерпретировать эти показатели, чтобы получить значимую и полезную информацию, которая поможет улучшить работоспособность проекта.

Шаг 1: Определите тенденции

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

Шаг 2: Диагностика

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

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

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

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

Шаг 3. При необходимости соберите дополнительные данные.

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

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

Шаг 4. Внесите улучшения

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

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

Как и в случае с другими шагами, практические руководства по конкретным темам будут включать более подробную информацию о том, как внести улучшения в эту тему.

Шаг 5: Мониторинг результатов

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

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

Предостережения и соображения

  • При интерпретации показателей и внесении улучшений в ваш проект с открытым исходным кодом вы всегда должны в первую очередь думать о людях, участвующих в вашем проекте, и о том, как эти изменения могут повлиять на них (положительно или отрицательно).
  • Всегда привлекайте людей, работающих над проектом, к сбору и интерпретации показателей, а также к любым возможным действиям по улучшению, которые вы можете предпринять.
  • Каждый проект немного отличается, поэтому важно интерпретировать показатели в свете индивидуальных потребностей проекта и способов его работы.
  • По возможности избегайте использования показателей для сравнения проектов друг с другом, но если вам нужно сравнить проекты, убедитесь, что вы сравниваете только проекты со схожими характеристиками. Вот лишь некоторые из многих примеров: проекты Javascript будут иметь совершенно другие характеристики и шаблоны, чем проекты C/C++; проекты, принадлежащие фондам, будут отличаться от проектов, вытесненных корпорациями; и проект размером с Kubernetes не будет похож на проект по созданию небольшой библиотеки или пакета.
  • Будьте осторожны, никогда не настраивайте людей на использование ваших показателей в качестве оружия, и будьте очень осторожны с показателями, которые могут использоваться для сравнения людей друг с другом способами, которые могут привести к наказанию отдельных лиц.
  • Помните, что автоматизация и активность ботов могут влиять на интерпретацию многих показателей, поэтому важно понимать, как автоматизация и боты могут повлиять на ваши результаты.

Дополнительное чтение

Обратная связь

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

Соавторы

Следующие люди внесли свой вклад в создание этого руководства:

  • Рассвет Фостер
  • Чан Вунг
  • Луис Каньяс Диас

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

Руководства для практиков CHAOSS — это живые документы, лицензированные MIT, и мы будем рады вашим отзывам и вкладу. Вы можете предложить изменения к этому документу на странице https://github.com/chaoss/wg-data-science/blob/main/practitioner-guides/introduction.md