이벤트 추적을 릴리스 프로세스의 일부로 만드는 방법

편집자 주: 이 기사는 원래 2021년 3월 15일 Iteratively 블로그에 게시되었습니다.

새로운 기능이나 제품을 구축할 때 분석을 마지막 순간까지 미루거나 완전히 잊는 경우가 매우 일반적입니다. 이 시나리오는 친숙하게 보일 수 있습니다.

• PM은 릴리스 작업
• 릴리스 발생
• CEO는 PM에게 실적을 묻습니다.
• PM: 데이터 팀에 물어보겠습니다.
• 데이터 팀: 우리를 데려온 적이 없습니다. 이 기능에 대한 데이터가 없습니다.
• PM은 대답없이 CEO에게 돌아갑니다.
• 데이터 팀과 PM은 혼란스러워합니다.

이와 같은 상황은 잠재적으로 매우 자주 발생할 수 있으며 어느 쪽도 이에 대해 책임을 질 수 없다는 점을 기억하는 것이 정말 중요합니다. 그 중 많은 부분이 문화 로 귀결될 수 있습니다.

문화는 정의하기 어렵기 때문에 문제의 핵심 부분으로 "문화"를 지적하는 것이 쉬워 보일 수 있습니다. 그러나 조직의 가치와 목표가 팀 구성원의 행동 방식에 항상 완전히 반영되지 않는 경우가 매우 많습니다. 예를 들어:

귀하의 조직은 사용자에게 최상의 서비스를 제공하기 위해 데이터 기반 의사결정을 내린다고 주장합니다. 이를 위한 좋은 기반은 견고한 데이터 전략이라는 것을 모두가 이해하고 있습니다. 그렇지 않으면 이러한 결정을 내리는 데 사용할 수 있는 신뢰할 수 있는 통찰력을 얻을 수 없습니다.

그러나 실제로는 데이터 및 인사이트 전략에 대한 대화(또는 통합)가 발생하지 않는 것 같습니다. 작업은 밀려나고 잊혀지고 신뢰할 수 있는 분석은 거의 실현되지 않습니다.

이는 조직의 가치와 실제 일상 문화 사이의 간극 때문에 발생합니다. 이 간극에 빠지기가 매우 쉽습니다. 종종 팀은 실제로 데이터를 캡처하는 것과 관련된 모범 사례를 구축하는 것보다 데이터에서 통찰력을 얻는 데 더 집중합니다. 좋은 데이터 문화를 유지하는 것은 어렵습니다!

그러한 문화를 구축하는 것은 단순한 과대 광고 및 축하 극장 그 이상입니다. 이 게시물에서는 간단하고 실행 가능한 프로세스로 시작하여 의도한 데이터 문화를 유지하는 데 어떻게 도움이 되는지에 대한 몇 가지 실용적인 조언을 제공합니다. 고품질 데이터를 캡처하고 이를 유용한 의사 결정으로 이끄는 실행 가능한 통찰력으로 전환하는 데 중점을 둡니다.

분석을 소프트웨어 개발 수명 주기에 통합

엔지니어링 팀이 제품의 일부를 구축하는 작업을 시작하면 코드를 작성하고 일반적인 작업(분기, 커밋, 테스트, 검토, 병합)을 수행합니다. 이는 모든 사람이 빌드와 동일한 페이지에 있고 모든 실수를 쉽게 수정할 수 있도록 하기 위한 것입니다.

분석을 동일한 방식으로 처리하지 않을 이유가 없습니다. 이미 어떤 종류의 추적 계획이 있을 가능성이 높으므로(그렇지 않은 경우 이를 시작하는 방법에 대한 가이드가 있습니다) 구현을 시작하는 좋은 방법은 다른 것과 마찬가지로 Jira 티켓으로 분류하는 것입니다. 하위 작업. 놀라운 추적 계획이 구현되지 않으면 중요하지 않습니다. 다음 사항을 고려하지 않으면 중요한 통찰력을 계속 놓치게 됩니다.

• 분석 추적이 구축 중인 기능만큼 중요하다는 관련 이해 관계자 및 리더십 팀의 승인이 필요합니다.
• 추적 계획을 구현하는 작업은 빌드에 대한 다른 모든 작업과 함께 우선 순위를 지정해야 합니다.
• 추적이 없으면 빌드를 릴리스할 준비가 되지 않은 것입니다.

일련의 Jira 티켓에 있다고 해서 그것이 일어날 것이라는 의미는 아니라는 것을 모두 알고 있습니다. 여기에서 문화 변화가 실제로 발생합니다. 기능이 출시되었다는 사실뿐만 아니라 기능의 성공을 축하함으로써 매번 추적 계획이 소프트웨어 개발 수명 주기의 일부가 되도록 하십시오. 결국 회사에서 디지털 제품을 생산하는 경우 배송 기능이 핵심입니다. 축하 연극을 시도하고 피하십시오. 기능이 잘 작동하는 것을 보았을 때 축하하십시오.

기능이 어떻게 작동하는지 이해하는 유일한 진정한 방법은 분석을 수집하는 것입니다. 추적 계획이 첫 번째 빌드에서 바로 구현된 경우 당연히 수행하게 될 것입니다.

분석의 맥락에서 QA에 대한 참고 사항: 추적 계획을 구현하는 것은 올바른 도구와 문화를 사용하면 충분히 간단하지만 이것이 바로 Amplitude가 CI와 통합되고 단위 테스트 플러그인을 사용하여 기존 테스트에 분석 적용 범위를 추가할 수 있는 이유입니다.

분석 추적을 위한 반복 가능한 프로세스 설정

git 프로세스가 잘 작동하는 또 다른 이유는 모든 사람이 이를 일관되게 따르기 때문에 자연스럽게 회사 문화에 포함되기 때문입니다. 일상적인 워크플로의 일부가 될 수 있는 분석 추적을 중심으로 쉽게 프로세스를 구축할 수 있습니다. ‍

새로운 프로세스 도입의 가장 큰 적은 바이 인 부족입니다 . "이것이 지금 우리가 분석을 수행하는 방법입니다"라고 말하고 모든 사람이 참여하기를 기대할 수는 없습니다. 우리는 항상 분석 추적이 공동 작업임을 유지해 왔습니다. 추적 계획을 세울 때 모든 관련 팀이 계획 수립에 참여해야 합니다.

이는 새로운 프로세스를 제시할 때 제품 팀, 데이터/분석 팀 및 엔지니어링 팀과 같은 모든 주요 이해 관계자를 참여시키는 것을 의미합니다. 해당 팀의 고유한 전문 지식은 다음을 결정하는 데 도움이 됩니다.

• 귀하의 비즈니스 목표는 무엇입니까
• 이러한 목표의 달성 여부를 결정하는 데 사용할 지표
• 이벤트 및 기타 분류법에 사용할 명명 규칙. (예: 'songPlayed' 또는 'song_played'입니까? 이에 대한 자세한 내용은 모범 사례에 대한 글을 참조하십시오.)

이러한 프로세스에 대해 함께 동의하는 것은 조직 전체의 동의를 얻고 이를 문화의 일부로 만드는 훌륭한 첫 번째 단계입니다. 추적 계획을 세운 후에는 누가 소유권을 가져가는지 식별하는 것이 중요합니다. "모든 사람"에게 계획을 세우는 것은 효과가 없습니다. 책임을 지고 앞으로 나아가려면 한 사람이 필요합니다.

이러한 프로세스를 다른 프로세스 위에 추가하는 것이 아니라 이와 같은 반복 가능한 프로세스를 조직 문화에 구축하려면 팀이 워크플로우에 이를 채택할 수 있도록 최대한 쉽게 만드십시오. 팀 구성원이 새로운 프로세스를 수용하기 위해 잘 정립된 워크플로를 방해하고 싶어할 것 같지 않습니다. 대신 이러한 프로세스가 기존 프로세스와 원활하게 결합되는 방법을 확인하십시오. 예를 들어, Amplitude는 명령줄 인터페이스를 통해 이 작업을 정말 간단하게 만듭니다. 이를 통해 개발자는 선호하는 환경을 벗어나지 않고도 추적 계획을 쉽고 정확하게 계측할 수 있습니다.

추적 목표를 비즈니스 목표에 맞추십시오.

민첩한 제품을 구축하는 경우(예: 구축, 측정, 학습 프레임워크 사용) 데이터를 사용하여 결정을 내릴 것입니다. 그러나 다음 방향을 결정할 때 데이터로 시작하지 말고 질문으로 시작하십시오.

첫째, 무엇을 성취하려고 하는가? 새로운 기능을 함께 가져오거나 실험을 실행하려고 합니까? 이번 분기에 특정 목표를 설정했을 수도 있습니다. 그것이 무엇이든 데이터 가 당신을 위해 무엇을 할 수 있을지 생각하지 마십시오. 대신 올바른 질문을 하고 이러한 질문에 답할 수 있는 데이터가 있는지 확인하는 문화를 구축하세요. 따라서 다음과 같은 사항에 대해 생각해 보십시오.

• 대략적인 목표 또는 실험의 성공 측정항목
• 이러한 지표에 접근하기 위해 추적해야 하는 이벤트
• 기존 통찰력을 기반으로 이미 수행한 작업은 무엇입니까? 효과가 있었습니까?

수집 중인 데이터로 이러한 질문에 답할 수 없다면 추적 계획을 조정해야 합니다. 더 많은 데이터가 항상 답은 아니지만 가장 확실한 것은 정확한 데이터 입니다.

우수한 데이터 문화 구축의 일부는 팀이 데이터 자체가 아니라 데이터를 사용하는 방식 이 차별화 요소임을 이해하도록 돕는 것입니다. 자연스러운 호기심을 불러일으키고 내부 인사이트를 기반으로 한 결정의 영향을 축하하세요.

우수한 데이터 및 분석 문화는 지속적인 프로세스입니다.

하룻밤 사이에 문화를 만들 수는 없습니다. 새로운 프로세스의 가치를 입증하고 그 결과를 축하함으로써 원하는 문화를 성장시킬 수 있습니다. "있으면 좋기" 때문에 데이터를 수집하기보다는 데이터를 사용하여 직감과 아이디어를 감지하는 태도를 기르도록 노력하십시오.

팀 전체에서 이벤트 추적을 가장 먼저 염두에 두는 것이 처음에는 복잡할 필요가 없습니다. 10개 이상의 질문으로 시작할 필요는 없을 것입니다. 이를 고정하고 팀 간에 이를 반복한 다음 거기서부터 작업합니다. 처음부터 모든 상황에 최적화할 필요가 없습니다.

이 블로그 게시물에 설명된 조언은 시작점에 불과합니다. 이것으로 좋은 리듬에 들어가면 설정한 프로세스가 팀 사이에서 제2의 천성이라는 것을 알게 될 것입니다. 코드 작성과 마찬가지로 추적 분석은 보다 표준화되고 감사 가능한 관행이 될 것입니다.

Amplitude를 사용하면 이 프로세스가 매우 쉬워집니다. 추적 계획은 팀의 워크플로에 원활하게 통합되는 동적 문서로 존재합니다. 회사에서 Amplitude를 사용해 보고 싶다면 지금 계정을 만들거나 당사 팀과 함께 데모를 예약하여 자세한 내용을 알아보십시오.