Как сделать отслеживание событий частью процесса выпуска

Примечание редактора: эта статья была первоначально опубликована в блоге Iteratively 15 марта 2021 года.

При создании новых функций или продуктов очень часто аналитику откладывают на последний момент или даже полностью забывают о ней. Этот сценарий может показаться вам знакомым:

• ПМ работает над релизом
• Выпуск происходит
• Генеральный директор спрашивает премьер-министра, как это работает
• Премьер-министр: Позвольте мне спросить команду данных
• Команда данных: Вы нас не вводили, данных по этой фиче нет
• Премьер-министр возвращается к генеральному директору без ответов
• Команда данных и PM в растерянности

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

Указание на «культуру» как на ключевую часть проблемы может показаться простым, потому что культуру трудно определить. Но очень часто ценности и цели организации не всегда полностью отражаются в поведении членов команды. Например:

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

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

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

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

Интегрируйте аналитику в жизненный цикл разработки программного обеспечения

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

Нет причин не относиться к аналитике таким же образом. Вполне вероятно, что у вас уже есть какой-то план отслеживания (если нет, у нас есть руководство о том, как начать работу с ним), поэтому отличный способ начать его реализацию — разбить его на тикеты Jira, как и любой другой подзадача. Удивительный план отслеживания не будет иметь значения, если он не будет реализован. Вы будете продолжать упускать жизненно важные идеи, если не учтете, что:

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

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

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

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

Установите повторяемый процесс отслеживания аналитики

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

Самый большой враг внедрения нового процесса — это отсутствие заинтересованности . Вы не можете просто сказать: «Вот как мы сейчас делаем нашу аналитику» и ожидать, что все присоединятся к нам. Мы всегда считали, что отслеживание аналитики является совместным; когда вы составляете свой план отслеживания, все соответствующие команды должны принять участие в его формировании.

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

• Каковы ваши бизнес-цели
• Метрики, которые вы будете использовать, чтобы определить, достигнуты ли эти цели
• Какое соглашение об именах вы будете использовать для событий и других подобных таксономий. (например, это 'songPlayed' или 'song_played'? Подробнее об этом в нашей статье о лучших практиках)

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

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

Согласуйте свои цели отслеживания с вашими бизнес-целями

Если вы создаете agile-продукты (например, используя структуру «создать, измерить, изучить»), вы наверняка будете использовать данные для принятия решений. Однако : решая, в каком направлении двигаться дальше, не начинайте с данных — начните с вопроса.

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

• Показатели успеха для намеченных целей или экспериментов
• События, которые необходимо отслеживать, чтобы быть в курсе этих показателей
• Какие действия вы уже предприняли на основе имеющейся информации — сработали ли они?

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

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

Хорошая культура данных и аналитики — это непрерывный процесс

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

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

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

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