İzleme Planınıza Gerçekten Kim Sahip Olmalı?

Editörün notu: Bu makale ilk olarak 11 Ocak 2021'de Iteratively blogunda yayınlandı.

"Veri bir takım sporudur", güçlü bir şekilde inandığımız ve Amplitude'da sık sık bahsettiğimiz bir şeydir. Analitik izleme planları da farklı değildir; izleme planları (ve bunların araçları) doğası gereği işbirliğine dayalıdır. İlgili ekipler bir araya geldiğinde en iyi şekilde çalışırlar.

Yeni bir özellik sürümü örneğini ele alalım. Ürün ekibi, bu yeni özellik için hedefleri ve ölçümleri tanımladı ve bu ölçümleri ölçmek için hangi olay izlemenin gerekli olduğuna dair bir görüşe sahip olacak. iOS, Android ve web geliştirme ekipleri, bu olayları kodda kullanmaktan (ve ideal olarak test etmekten) sorumludur ve neyin mümkün olduğu konusunda fikir sahibi olacaktır. Bir analist veya analitik mühendisi, verilerin modellenmesinden sorumludur ve onun yapısıyla ilgilenir ve raporları oluşturmaktan ve verileri çeşitli araçlarda analiz etmekten sorumlu birkaç ekibiniz olabilir. Kısacası, veriye dayalı şirket analitiğinde neredeyse herkes yer alır.

Örnek, analitik izlemenin gerçekten ne kadar karmaşık olduğunu anlatıyor ve aynı zamanda doğru olayları tanımlayıp yakalarken, bunları doğru şekilde uygularken ve veri tüketicilerinin verileri keşfetmesini kolaylaştırırken işbirliğinin öneminden bahsediyor. Bununla birlikte, işin içinde çok fazla insan olduğu için, analitik izleme kolayca sıcak bir patates haline gelir.

Eğer herkese aitse, hiç kimseye ait değildir.

Bu kadar çok paydaşın dahil olmasıyla, izleme planı genellikle net bir sahibi olmayan, paylaşılan bir sorumluluk haline gelir. Ve paylaşılan sorumluluk, çok az sorumluluk getirir.

Analitik izleme çevresinde süreçler (yeniden) oluşturmak isteyen birçok şirketle görüştük. Genellikle bir elektronik tablo veya bir Confluence veya Notion sayfası etrafında döner. Çoğunlukla manuel olmasına ve izleme planını kodda zorlamanın bir yolu olmamasına rağmen, başlangıçta yararlı olur ve ekipleri olay izleme hakkında daha fazla düşünmeye zorlar.

Ancak, birkaç ay içinde, Notion sayfası veya Google E-tablosu güncelliğini yitiriyor: En son sürümün izlenmesi yalnızca bir Jira hikayesinde belgelendi ve diğer birkaç özellik sürümü için izlemenin uygulanıp uygulanmadığı artık net değil. Hiç kimse izleme planını güncel tutma sorumluluğunu üstlenmiyor.

Peki, bunu daha iyi hale getirmek için nasıl değiştirirsiniz ve analiz izlemenize en iyi kim sahip olur?

Analitiği ön plana ve merkeze koyarak başlayın

Sahiplik konusuna girmeden önce, analitik izleme başarısı için gereken temelden bahsetmeliyiz: olay izleme önemlidir ve bu olmadan karanlıkta kalırsınız. Gerçek şu ki, çoğu ekip için analitik sonradan akla gelen bir şeydir. İşte her zaman gördüğümüz bir örnek:

• PM bir sürüm üzerinde çalışıyor
• Sürüm gerçekleşir
• CEO, Başbakan'a nasıl performans gösterdiğini soruyor
• PM: “Veri ekibine sorayım”
• Veri ekibi: "Bizi asla işe almadın; bu özellikle ilgili veri yok."
• Başbakan cevap vermeden CEO'ya geri döner
• Veri ekibi ve PM perişan durumda

Analitik, her sürümün ayrılmaz bir parçası haline gelmezse, bu tekrar tekrar olacaktır ve izleme planınızın gerçekten şık ve güncel görünüp görünmemesi önemli değildir. Analitik izlemenin özelliğin kendisi kadar önemli olduğu konusunda tüm paydaşların (ve liderlik ekiplerinizin) desteğine ihtiyacınız var. Takip yok, yayın yok.

İlgili ekipleri yetkilendirmek için açık sorumluluk, zaman ve kaynaklara ihtiyacınız var ve ardından olay izleme ve başarı metriklerini Jira bilet düzeyine kadar yerleştirmeniz gerekiyor (yalnızca izleme kodu, kodun geri kalanıyla birlikte gönderildiğinde yapılır ).

Veri ve ürün profesyonelleriyle yapılan 400'den fazla görüşmeden öğrendiklerimiz

İki yılda 400'ün üzerinde ürün yöneticisi, veri ekibi ve mühendisle görüştük. Bazı şeyler gördük.

Elbette izleme planınız ve etrafındaki süreç işinize, ekip yapınıza ve sektörünüze özgüdür (ve muhtemelen bu yüzden doğru olması çok zordur). Bir e-ticaret şirketi için bir izleme planı, bir B2B SaaS şirketi için bir izleme planından çok farklı görünecektir. Dahil olan farklı paydaşları var ve tamamen farklı gerçekler için çözüyorlar. En yaygın olarak, gördüklerimizi şirket büyüklüğüne göre ayırabiliriz.

başlangıçlar

Küçük şirketler için izleme etrafındaki süreç genellikle geçicidir. Çok az kişinin dahil olması doğaldır ve karmaşıklığı yönetmeyi kolaylaştırır(ish). Çoğu zaman, bir şirketin yolculuğunun bu aşamasında bir ürün yöneticisinin veya büyüme yöneticisinin mülkiyeti devraldığını görürüz.

KOBİ'ler

Orta ölçekli bir şirkette, süreç genellikle veri/analitik bölümünün başına geçer. Şu anda dahil olan daha fazla paydaş var ve karmaşıklık kolayca bir sorun haline gelebilir. Bu aşamada, hasarı sınırlamak için kesin bir mülkiyet ihtiyacı vardır ve bu genellikle veri ekibinden birine düşer.

İşletmeler

Daha büyük şirketlerde, izleme planına nihai olarak sahip olan kişi genellikle ürün analitiğinin başı olacaktır. E-ticaret şirketleri için genellikle e-ticaretin başı olacaktır. Çoğu zaman, planı sürdüren veya süreci uygulayan gerçek günlük kişi olmayacaklar, sorumlu olan ekip içindeki biri olacaktır.

Bu tür kurulumlardan çeşitli derecelerde başarı gördük. Peki, en çok neyin işe yaradığını düşünüyoruz?

Ne işe yarar: Ürün ekibi nihai sahiptir

Bildiğimiz şey şu: En iyi sahiplik süreci, ürün ekibi nihai sahip olarak hareket ettiğinde gerçekleşir. Ürün yöneticileri ana itici güç olmalı ve analitik izlemenin her özellik sürümünün bir parçası olmasını sağlamalıdır . Ekibinizin büyüklüğüne bağlı olarak bu, bir veya daha fazla ürün yöneticisi veya özel bir ürün analisti olabilir. Rollerinin ve OKR'lerinin bir parçası olarak analitik takibinden sorumlu tutulmaları gerekir.

Ancak daha önce de belirttiğimiz gibi, veriler bir takım sporudur ve ekiplerin bir araya gelerek etkinlik adlandırma ve taksonomi gibi şeyleri tanımlamasını öneririz. Mühendisler ve veri ekipleri, günlük yaşamlarını da etkilediği için önemli bakış açılarına sahip olacaktır. Ürün ekibi, uygulayıcı ve nihai sahip olmakla birlikte, doğru paydaşları dahil etmeden asla bir siloda çalışmamalı veya önemli kararlar almamalıdır.

İlgili tüm paydaşları temsil eden bir danışma kurulu oluşturmak, birlikte çalıştığımız şirketler için iyi çalıştı. Her karar danışma kuruluna gitmez, ancak başlangıçta itici güç olmaları, sınıflandırmanızı ve sürecinizi tanımlamaları ve zaman içinde kaç tane önemli değişikliğin olduğuna bağlı olarak düzenli olarak toplanmaları gerekir.

Ürün ekiplerinin buna başarılı bir şekilde sahip olması için net bir sürecin yürürlükte olması gerekir:

• Her kullanıcı hikayesinin bir parçası olarak hem nitel hem de nicel metrikler için net başarı kriterlerine sahip olun. Bunlar Proje Yöneticisi tarafından tanımlanmalı ve veri ekibi veya analistlerle tartışılmalıdır.
• İzleme eksik mi? Yapı başarısız. Bitti kavramının, her sürümün bir parçası olarak analitik izlemeyi içerecek şekilde gelişmesi gerekiyor. Bu, lansmandan hemen önce sürümlerin engellenmesi anlamına gelmez, en başından itibaren izleme konularını içeren bir sürecin uygulanması anlamına gelir.
• İşbirliği çok önemlidir. Proje Yöneticisi, olay izleme spesifikasyonunun sahibi olacak olsa da, veri ekibi veya analistlerin müdahale etmesi ve neyin izlenmesi gerektiğine ilişkin ayrıntıları tanımlamaya yardımcı olması gerekir.

Ürün yöneticilerinizi sahiplenme konusunda güçlendirin

Bazı Proje Yöneticileri için izleme planına sahip olmak onlar için doğaldır. Kontrolü istiyorlar ve deneyime sahipler. Ayrıca ihtiyaç duyduklarında yardım istemekten de çekinmezler. Ancak, tüm PM'lere doğal olarak gelmiyor.

İlk olarak, bir kültür değişikliğinin olması gerekir: piyasaya sürüldüğü gerçeğini değil, yeni bir özelliğin veya ürün sürümünün performansını ve başarısını kutlayın! Şaşırtıcı bir şekilde, çoğu kişi için ürünün performans gösterip göstermediği değil, hala nakliyesi övgü alıyor.

Öyleyse, ürün ekibinizin izleme planına sahip olmasını nasıl sağlarsınız? Bu kapsamlı bir liste değildir, ancak umarım insanların başlaması için bir yer vardır:

• Düzenli eğitim : Etkinlik takibini doğru yapmak bir bilim olduğu kadar bir sanattır (yani kolay değildir), bu nedenle ekibinizin rahatça sahiplenilmesi için gereken bilgiyle güçlendirildiğinden emin olun. Eğitim, öğle yemeği ve öğrenme tarzı, atölye çalışmaları veya bire bir oturumlar olabilir (ilerideki işe alımlar için oturumlarınızı kaydetmeyi unutmayın).
• Çalışma saatleri : Veri ekipleri, diğer ekiplerin veri ekibinin uzmanlık ve bilgisinden yararlanmak için düzenli çalışma saatleri düzenlediğinde büyük başarı elde ettik. Ekiplerin bir "destek masası tarzı" toplantıya dönüşmesini önlemek için bir gündemle veya belirli sorularla hazırlıklı gelmelerini sağlayın.
• Net süreç ve kontrol noktaları: Tanımlanmış bir sürecin önemini yeterince vurgulayamayız. Herkesin bildiği, anladığı ve takip ettiği net bir sürece sahip olduğunuzdan emin olun ve kaliteyi sağlamak için yazılım geliştirmedeki kod incelemeleri ve birleştirme istekleri gibi düzenli inceleme noktaları ekleyin.
• Bir analisti dahil edin: Bu her zaman bir seçenek olmayabilir, ancak başarılı ekiplerin bir ürün ekibine kısmen veya tam zamanlı olarak analitik takibine sahip olması ve Koruyucu Yöneticilere veri keşfi ve analizi konusunda yardımcı olması için bir veri analistini yerleştirdiğini gördük.
• Self servis analitik: Proje Yöneticilerini ve kuruluştaki diğer herkesi veri kümelerini kolayca keşfetmeleri ve sorulara hızla yanıt almaları için güçlendirmenin en iyi uygulama olduğunu düşünüyoruz. Genişlik bunun için harikadır ve şirketinizde yüksek düzeyde veri okuryazarlığı sağlar.

Bir hatırlatma: İyi proje yöneticilerinin SQL bilmesi gerekmez

Verileri zaten kendiniz keşfedemiyorsanız, olay izlemeyi neden umursuyorsunuz? Yukarıdaki son noktayı genişletmek için, tüm raporlama ve veri analizinin sahibi olan merkezi veri ekiplerine sahip şirketler gördük. Artıları var, ancak deneyimlerimize göre, PM'leri ve diğerlerini sınırlayabilir ve analitik izleme veya veri kalitesi hakkında daha az umursamazlar.

Özel Yöneticilere ve diğerlerine Redash veya diğer SQL tabanlı araçlara erişim vermenin, Özel Yöneticileri kendi kendine hizmet etmeleri için yetkilendirmekle aynı şey olmadığını unutmayın. Proje Yöneticilerinizin SQL bilmesini (veya öğrenmesini) beklemeyin. Bu onların işi değil. Bunun yerine, onları kullanımı kolay bir kullanıcı arayüzü ve araç ve veri kümeleriyle birlikte devam edecek çok sayıda eğitimle güçlendirin. Elbette, SQL bilgisinin bariz avantajları vardır ve şirket çapında yetenek bulabilir veya eğitebilirseniz (ürün, pazarlama, müşteri başarısı vb. düşünün) onu çalıştırabilirsiniz, ancak bariz dezavantajları ve sınırlamaları vardır.

Proje Yöneticileri kendilerine hizmet edebiliyorsa, örneğin yeni bir yayından verileri keşfetme olasılıkları daha yüksektir. Verileri keşfederken, kalitesine, zenginliğine ve kullanılabilirliğine önem verme olasılıkları daha yüksektir. Bir yetkilendirme kültürü oluşturun ve analitik izleme etrafında sağlam bir süreç oluşturun ve mutlu PM'lere, mutlu analistlere, mutlu bir veri ekibine ve hatta mutlu geliştiricilere sahip olacaksınız.

Amplitude size yardım etmek için burada

Amplitude, veri ekiplerinin, ürün yöneticilerinin ve mühendislerin analitik izlemeyi tanımlamasına, enstrümanlamasına, doğrulamasına ve üzerinde işbirliği yapmasına yardımcı olur. Tutarsız olay adlandırma ve eksik izlemeden kaynaklanan veri kalitesi sorunlarını proaktif olarak çözüyor ve izlemenizin gelişimini yönetmek için bir iş akışı sağlıyoruz.

Ürün yöneticilerine izleme planının sahipliğini alma ve ekipler arasındaki işbirliğini artırma yetkisi veriyoruz . Şirketiniz için Amplitude'u denemekle ilgileniyorsanız, bugün bir hesap oluşturun veya daha fazla bilgi edinmek için ekibimizle bir demo rezervasyonu yapın.