Şirketinizi Dönüştürecek Bir Deney Toplantısı Nasıl Gerçekleştirilir (& Workato'da Nasıl Yapılır)

Çoğunlukla toplantılardan nefret ederim.

Bunu birçok kez makalelerde, Tweetlerde ve meslektaşlarıma söyledim.

Temel olarak, insanların toplantıları iş yapmaktan kaçınmak için koltuk değneği olarak kullanmalarından veya insanların toplantıları kötü yönetmesinden ve herkesin zamanını boşa harcamasından hoşlanmıyorum.

Ancak bir lider olarak bazı toplantıların öneminin farkındayım. Özellikle, benim durumumda, haftalık deney toplantısı.

Bu doğru – Workato'daki deney programının temel taşı sadece bir toplantıdır. Günlük stand-up'lar yapmıyoruz (bunları asenkron olarak Slack'te yapıyoruz); bunun yerine, makinenin hareket etmesini sağlamak için diğer bazı eserler ve ritüeller ile haftanın başında sadece bir toplantı.

Bu, bu toplantıyı nasıl yürüttüğüme, neden bu şekilde yürüttüğüme ve diğer deney programı araçlarıyla (e-postalar, bilgi paylaşım veritabanları ve okumalar gibi) nasıl dengelediğime ilişkin ayrıntılara derinlemesine giren ilk ve tek makalem olacak.

Size tutanakları aktarmadan önce, yüksek seviyeli bir soru sorarak başlamak istiyorum - bu toplantı neden yapılıyor?

Bir deney ekibi toplantısının amacı nedir?

Her toplantının bir amacı vardır. Bir amacı yoksa, olmamalı.

Haftalık deneme toplantımın üç faydası aşağıdaki gibidir:

• Öğrenme ve içgörü paylaşımı
• Girişimlerin önceliklendirilmesi
• Proses darboğazlarının belirlenmesi ve ortadan kaldırılması

Bu, bunları sağlamayan diğer birçok tartışma noktasını toplantıdan çıkardığımız anlamına gelir.

Deney, öğrenerek hızlandırılır

Bir deney programı oluşturmaya başladığınızda, temelleri atmak için çok çalışmanız gerekir.

• Uygun bir test aracı edinme.
• Analitik aracınızla entegre olduğundan ve verileri uygun şekilde izlediğinizden emin olun.
• Deneyim için uygun beklentileri belirlemek için yöneticilerle iletişim kurmak.

Yine de, deneyi ölçeklendirmeye başladığınızda, her deneyde öğrendikleriniz, programınızın geri kalanı için bir güçlendirici olarak hareket edecektir.

Ayda 5-10 deneyi geçerken, kazananlardan, kaybedenlerden ve sonuçsuz kalanlardan ne kadar iyi öğrendiğiniz, yürüttüğünüz bir sonraki deney grubunun başarı oranını etkileyecektir. Ve tüm bunlar, yol haritanıza nasıl öncelik verdiğinizi etkilemede temel olmalıdır.

Zaman kaybı gibi görünebilir, ama değil. Reforge'un kurucusu Brian Balfour da bir büyüme toplantısı düzenlemede öğrenmenin önemini vurguluyor:

Bu nedenle, toplantımızın büyük bir bölümünü öğrenilenler üzerinden geçerek ve içgörüleri paylaşarak geçiriyoruz.

Bu, özellikle toplantınız çapraz işlevliyse veya görüşmede diğer ekiplerden üyelere sahipse, genellikle normalde göremeyeceğiniz bakış açıları elde ettiğiniz için yararlıdır.

Örneğin, ürün pazarlamacılarını sık sık deneme toplantımıza katılmaları ve müşteri araştırmalarından elde edilen son keşifleri paylaşmaları veya yaklaşan stratejik anlatı değişikliklerini paylaşmaları için alacağız.

İşler değişir; önceliklendirme çeviktir

Toplantımda, nereye hedeflediğimizi, oraya ulaşmak için hangi adımları attığımızı ve kimin neyden sorumlu ve sorumlu olduğunu açıkça belirtmek istiyorum.

Bu toplantının sonraki kısmı.

Öğrendiklerimizden yola çıkarak “sırada ne yapacağız?” sorusu geliyor.

Ana sayfa denememiz kayboldu - peki ne öğrendik ve bundan sonra ne yapacağız?

Pek çok önceliklendirme aslında eşzamansız olarak ve üç ayda bir yapılır - en azından projelerimizin en büyük deneyleri ve en geniş tematik grupları.

Ancak stratejik değişikliklere ve geçmiş deneylerden öğrendiklerimize dayalı olarak yol haritasında küçük değişiklikler ve yinelemeler için çok fazla boşluk bırakıyoruz ve bunu yansıtmak için işleri hareket ettirmek için toplantının bir bölümünü kullanıyoruz.

Proses darboğazlarının belirlenmesi ve ortadan kaldırılması

Son olarak, özellikle bir deneme programının ölçeklendirme aşamasındaysanız, süreç darboğazlarını ortaya çıkarmak önemlidir.

Bu, sistem düşüncesini gerektirir ve bu, ekip liderinin veya program yöneticisinin temel işidir. Etkili bir şekilde, fikirden üretime kadar deneme sürecinin her adımını belirlemeniz ve ölçmeniz gerekir.

Hangi adımlar en uzun veya daha doğrusu beklenenden daha fazla zaman alır? Ve sürecin geri kalanının aşırı etkilenmediğinden emin olmak için bu gecikmeleri ve gecikmeleri belirlemek için bu haftalık toplantıyı nasıl kullanabilirsiniz?

Bu, haftalık toplantının kritik bir parçasıdır ve daha genel olarak konuşursak, deney treninizi raylarda tutmak için.

Deney toplantılarında nelerden kaçınılmalıdır?

Toplantılarınızı istediğiniz gibi yönetebilirsiniz, ancak haftalık ekip deneme toplantısı için iki şey büyük bir zaman kaybı olma eğilimindedir.

• Geçici verileri çekmek veya herhangi birinden bunu yapmasını istemek
• Yapılandırılmamış beyin fırtınası ve fikir yürütme

Geçici verileri çektiğinizde veya birinden bunu yapmasını istediğinizde, bunu not edin. Tekrar tekrar biraz veri isterseniz, bunu süreç kontrol listenize ekleyin. Her toplantıda gündeme gelen bir şey olmamalı (çok fazla zaman ve odak kaybı). Gösterge tablolarının ve raporlamanın yararlı olduğu yer burasıdır.

Yapılandırılmamış beyin fırtınasında, aslında genel olarak bundan nefret etmiyorum.

Ama deliliğin bir zamanı ve yeri ve tipik olarak bir yöntemi vardır.

Haftalık toplantınız sırasında fikirleri tartışmak için aşırı miktarda zaman harcadığınızda, süreç darboğazlarını belirlemek ve doğru deneyleri çalıştırdığınızdan emin olmak için harcanan zamanı azaltırsınız.

Rastgele iyi bir fikir gelirse, sorun değil. Gevşek bir şekilde yapılandırılmış bir beyin fırtınası oturumuna dönüşürse, ayağınızı yere koymanız ve çevrimdışına almanız gerekir.

Haftalık deneme ekibi toplantılarımı nasıl yürütürüm

Pekala, haftalık deney ekibi toplantımı gerçekten nasıl yürütebilirim?

Yürüttüğümüz gerçek deneyler ve sonuçlarla ilgili bazı ayrıntıları gizlemem gerekecek elbette, ancak her bölümü elimden geldiğince ayrıntılı bir şekilde ele alacağım.

İnsanlar

İlk olarak, her hafta katılan insanlar temel stratejik deney işlevlerinin bir parçasıdır. Analistler, performans pazarlamacıları, web geliştiricileri ve ürün yöneticilerini içeren küçük bir gruptur. Yöneticim de sık sık geliyor ama her görüşmede değil.

Şirketimizde bir mükemmellik merkezi oldukları için tasarım ekibimizle ayrı toplantılarım var.

Bu insanlar düzenli olarak katılıyor ve ardından tasarım, marka pazarlaması veya ürün pazarlaması gibi bitişik ekiplerden arada bir "misafir" davet ediyorum. Ayrıca, bu misafir çağrıları için, amacı genellikle yeni fikirleri tanıtmak, daha iyi ekip iletişimi veya beyin fırtınası yapmak olduğu için genellikle ayrı bir oturum kurarız.

Bunu daha genel hale getirmek için, çoğu durumda deney toplantınız, strateji hakkında kararlar veren ve bu stratejiyi uygulayan kişileri içermelidir. Tipik olarak, bu:

• Lider / program yöneticisi
• Ürün Müdürü
• geliştiriciler
• tasarımcılar
• Analistler

Program

Bu toplantıyı her pazartesi, merkezi saatle 3'te yönetiyorum. Pazartesi sabahları, hazırlık yapmak ve derin işler yapmak ya da önceki haftanın yarım kalan işlerini bitirmek için harikadır. Öğleden sonra, ekip önümüzdeki haftayı tartışmak için iyi hazırlanmış durumda. Bu aynı zamanda hepimizin hafta boyunca ne üzerinde çalışmamız ve öncelik vermemiz gerektiğini bilmemizi sağlar.

Ardından, hafta boyunca, Pazartesi günkü ekip toplantısında üzerinde çalışmaya karar verdiğimiz şeyin ayrıntılarını tartışmak için eşzamansız kontroller ve 1:1 toplantılarımız olacak.

Şu anda bir slayt destesi kullanmıyoruz, ancak onu dahil edebiliriz. Eğer durum buysa, yukarıda listelenen zaman sınırlarımıza bağlı olarak bireysel bölümleri tutacağım ve deste önceki haftanın Cuma günü gönderilecek (Pazartesi sabahı her kişinin bölümünü bir araya getirmek için 20 dakikadan fazla harcamamak amacıyla) . Şu anda ağırlıklı olarak proje yönetimi için kullandığımız Airtable veri tabanımızı inceliyoruz.

gündem

İşte tam gündemim:

Toplantı süresi: 45 dakika

• Resmi olmayan yakalama: 5-10 dakika
• Sonuçlanan deneylerden/araştırmalardan öğrenilenler: <10 dakika
• Birikmiş iş listesini önceliklendirme/düzenleme: <10 dakika
• Darboğazların / engelleyicilerin belirlenmesi: zamanın geri kalanı (10-15 dakika)

Yukarıdaki bölümlerin her birini ve amaçlarını zaten inceliyoruz.

Size yukarıdakilerin her birinde yardımcı olabilecek birkaç araç ve çerçeve vereceğim.

Sonuçlanan deneylerden/araştırmalardan öğrenilenler.

Burada ihtiyacınız olan en önemli şey iyi bir dokümantasyon sistemidir.

Bir deneme çalıştırılmadan önce, aşağıdaki bölümlerin yer aldığı bir deneme belgesinin doldurulmasını istiyorum:

• Arka fon
• Öğrenme hedefi
• Hipotez
• Tahmin (bir hipotezden farklıdır).
• Deney tasarımı (niceliksel ve yaratıcı)
• Takip (sonuçtan sonra ne olur)

Ardından, deneme çalıştırıldıktan sonra iki bölüm daha doldurulur:

• Sonuçlar
• öğrenmeler

Ve toplantımızda, sonuçları kısaca ele alıyoruz ve öğrenmeler bölümünü daha derinden ele alıyoruz. Deneyin “sahibi” kim ise, öğrenmeleri sunan kişi odur ve ardından bunları nasıl uygulayabileceğimize dair kısa bir tartışma vardır. Bazen bu, daha geniş bir ölçekte test etmek veya öğrenmeleri benzer deneyimlere ölçeklendirmek anlamına gelir. Bazen bu, anlamlı bir şekilde yineleme anlamına gelir.

Bu adımda seçeceğiniz iki araç şunlar olmalıdır:

• Deney belgesi (şablonumu çalmak için buraya tıklayın)
• Deney bilgi paylaşım sistemi / Wiki

Birikmiş iş listesini önceliklendirme/düzenleme: <10 dakika

Bu bölümün faydası hakkında bir tartışma var, ancak bunu bir grup tartışması yapmayı seviyorum çünkü basit web üretimi veya ürün yönetiminin aksine, deneyler birçok dış baskıya, engelleyiciye ve kaprislere tabidir.

Örneğin, planladığımız özellikle büyük bir deney için katılım hakkımız olmayabilir veya tasarım engelimiz olabilir. Ancak yine de test tempomuzu korumak istiyoruz, bu durumda çevik kalabilir ve biriktirme listesinden daha düşük çaba gerektiren bir fikri yukarı taşıyabiliriz.

Bazı kuruluşlarda, bu karar verme yalnızca deney ekibi liderine verilir. Tartışmayı gruba açmayı severim.

Neden? Niye?

Öncelikle, önceliklendirme puanlarımın ağırlığı altında takımı ezmek istemiyorum. Denemenin değerinin bir kısmı, öğrenmeyi beklemediğiniz şeyleri öğrenmektir ve ekipteki diğerlerinden önceliklendirme özerkliğine izin vererek, masaya benim oraya koyamayacağım fikirleri alırız. Bu aynı zamanda genel ekip iletişimini ve uyumunu geliştirmeye yardımcı olur.

İkincisi, insanlar üzerinde çalışmayı seçtikleri şeyler üzerinde çalışmak için daha heyecanlılar. Tüm fikirleri atamaya başlarsam, insanların bireysel deneyler için hissedebilecekleri tutkuyu sınırlamış olurum (ki bu birçok yönden deneyin kazanma potansiyelini sınırlar).

Bu bölümde, temelde iki araçtan çalışıyoruz:

• Proje yönetimi kanbanı (Airtable kullanıyoruz - işte harika bir şablon).
• Önceliklendirme matrisi (PXL kullanıyoruz).

Darboğazların / engelleyicilerin belirlenmesi: zamanın geri kalanı

Son olarak, darboğazların belirlenmesi.

Bu zor. Başlangıçta, iki şey yapıyor:

• Geç teslimatlarda kalıp bulma
• Ekibin nitel ve açık uçlu sorularını sormak

Airtable'ımda (paylaşamayacağımı söylediğim için üzgünüm), her kartta dört sütun var:

• Tasarım zamanı
• Tasarım teslim edildi
• Geliştirme zamanı
• Geliştirme teslim edildi

Bu, izlediğimiz Kanban adımlarına ek olarak:

• Fikir
• Deney belgesi devam ediyor
• İncelemede olan deney belgesi
• Geliştirilmekte
• Kalite güvencesi
• QA'd ve başlatmaya hazır
• Koşma
• Sonuçlandı
• Üretime itildi

Bu, işlerin nerede programın gerisinde kaldığını görmemi sağlıyor. Örneğin, 10 test çalıştırdık ancak hiçbiri uygulanmadıysa, bir üretim sorunumuz var. Ya da belki de deneylerimiz kalite güvencesinde duraksıyor ve yayınlanmayı bekleyen bir yığın yayına hazır deney var.

Geliştirme aşamasında, deneyimi yaratmak için tasarımı mı yoksa geliştiricileri mi beklediğimizi görmek istiyoruz. Tekrar tekrar geride kalırsak, bu ekiplerin önceliklerini yeniden gözden geçirmemiz veya potansiyel olarak çalışan sayısını artırmamız gerektiği anlamına gelir.

Niteliksel sorular kulağa şöyle geliyor:

• Bu hafta benden desteğe ihtiyacı olan var mı?
• Bu hafta hedeflerimize ulaşmak için potansiyel engelleyiciler var mı?

Bunlara verilecek cevaplar hem bu darboğazları kısa vadede düzeltmenize hem de uzun vadede düzeltilmek üzere tekrarlandığında kalıpları belirlemenize izin vermelidir.

Boşlukları doldurma: diğer faydalı deney programı araçları

Deney ekibi toplantısı, yöneticinizin araç setinde olması gereken tek araç değildir.

Aslında, deney yöneticilerinin yaptığını gördüğüm en büyük hata, hepsini tek bir toplantıda yapmaya çalışmaktır.

Bunun yerine, başarmak istediğiniz her iş için en iyi aracı kullanmak için ritüellerinizi ve eserlerinizi yaymak istersiniz.

Deney ekibi toplantısı üç şeyi başarır:

• Öğrenimler ve içgörüler
• Önceliklendirme ve iş tahsisi
• Engelleyici tanımlama ve düzeltmeler.

İlgilenebileceğiniz diğer deneme programı hedefleri şunlardır:

• Diğer takımlardan fikir almak
• Yöneticileri ve paydaşları yatırım getirisi ve sonuçlar konusunda döngüde tutmak
• Bilgileri deney dışında yaymak için sonuçları diğer ekiplerle paylaşmak

Kuruluşunuza bağlı olarak, deney puan tablolarını tutmak veya analiz parçalarını veya platformunuzu otomatikleştirmek için DataOps sürecini uygulamak için veri bilimcileriyle çalışmak gibi üzerinde çalışmanız gereken daha çok şey olabilir.

Ancak yukarıdaki amaçlar için, bu araçları az çaba gerektiren ve oldukça etkili buluyorum:

• Deneme inceleme e-postası
• İşlevler arası deney okuma toplantısı
• Deney arşivi / bilgi paylaşım aracı

Deneme inceleme e-postası

Deney ekibi toplantınız, çoğunlukla sonuçların üzerinden geçmek için harcanmamalıdır. Bu, bir gösterge panosunda ve program yöneticisi olarak size, ekibin geri kalanına ve ilgili taraflara gönderilen haftalık bir e-postada etkili bir şekilde yapılmalıdır.

Şunları içermelidir:

• Sonuçlandırılmış geçmiş deneyler + sonuçlar
• Şu anda çalışan deneyler
• Gelecekteki deneyler

Herhangi bir self servis analiz ve gösterge tablosu da buraya dahil edilebilir. Görsel olarak çekici sonuç çizelgeleri oluşturmayı ve gruptaki inekler için daha fazla ayrıntıya bağlantı vermeyi seviyorum. Ancak genel olarak, VP'niz her bir testin ayrıntılı istatistiklerini pek umursamayacaktır. Dolayısıyla bu e-posta, çabalarınız için görünürlük kazanmak ve üst düzey sonuçları ve öğrenimleri paylaşmak içindir.

İşlevler arası deney okuma toplantısı

Deney ekipleri asla bölgesel bir silo olarak hareket etmemelidir. Ekibinizin kazandığı bilginin yayılmasını ve aynı zamanda rahatsız edici fikirlerin akışını da sınırlandırırsınız.

Bu nedenle, her üç ayda bir, yürüttüğümüz tüm deneyleri ve üst düzey öğrenmeleri gözden geçirdiğimiz ve ardından geri kalan ekiplerin yorum yapması ve fikirlerini sunması için mikrofonu açtığımız, işlevler arası bir deney okuması yapmayı seviyorum.

Bu, diğer ekiplere – benim için genellikle ürün pazarlaması, marka, ürün ve talep oluşturma – öğrendiklerimize bir bakış sağlar. Belki işlerini, mesajlarını ve tasarımlarını etkilemek için kullanabilirler.

Ayrıca yaklaşmakta olan bir kampanya, işe alım akışında yürütülen bir deneme vb. hakkında bilmediğimiz şeyleri radarımıza koymalarına da olanak tanır.

Deney arşivi / bilgi paylaşım aracı

Son olarak, bir deney programında en az kullanılan araç, tüm sonuçlarınızı ve öğrendiklerinizi saklayabileceğiniz bir yerdir. Tercihen bu, iyi arama ve etiketleme işlevine sahip bir araçtır.

Bu, son derece ilgili ve ilgili tarafların, yürütülenlere basitçe bakmalarını sağlar.

Şahsen, Airtable ve Google Dokümanlar'ın bir kombinasyonunu kullanıyorum. Ancak Notion, Confluence veya Etkili Deneyler gibi özel bir A/B testi arşiv aracı kullanabilirsiniz.

Çözüm

Deney ekibi toplantısı, ekibinizin verimliliğini (deney hızı ve kalitesi) ve etkinliğini (takımınızın kuruluşta ne kadar görünür ve saygın olduğunu) sağlayabilecek veya bozabilecek önemli bir ritüeldir.

Toplantıya ve katılımcılara saygılı davranın ve amacına sadık kalın. Dikkat dağıtmaktan ve kapsam kaymasından kaçının - beyin fırtınası ve raporlama için başka araçlar da var. Ve çabucak, başka bir toplantıdan korkmak yerine, bunu dört gözle beklediğinizi göreceksiniz çünkü oldukça üretken. Zaten indiğimiz yer orası.