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

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

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

Короче, первая статья про тему метрик будет обзорная, но в ней буду искать героя, кто готов будет дать свой кейс, по которому напишем следующую статью - прикладную. Настроим систему сбора метрик и поищем аргументы "за" деврел.

Если тема метрик вам актуальна, поделитесь, пожалуйста:
1. На какие деврельские метрики смотрит ваше руководство? Или на что смотрит, если метрик нет?
2. С какими проблемами сталкиваетесь при сборе метрик/результатов за период времени (например, задачи приходят из разных источников и ведутся в разных системах - почте, экселе, таск-трекере; разным стейкхолдерам интересны разные результаты и т.д.).

Буду благодарна за каждую вашу мысль - хочется вместе с вами внести вклад в наше классное деврельское комьюнити❤️