Gerçek: Ürün sürüm iletişimi sorunludur

Ürün sürüm notlarının amacı, mühendislikten müşteri destek ekiplerinize ve dış paydaşlarınıza (müşteriler ve ortaklar) ürünle ilgili değişikliklerin olduğunu iletmektir. Teknolojide her şey ışık hızında hareket ederken, ürün güncellemelerini sürüm notları ile iletmek neredeyse eski bir sorundur.

Çalıştığım her şirket, sürüm notlarını "doğru" bir şekilde iletmekte zorlandı. Ancak bu, hakikaten zor bir şeydir; her değişikliğin veya ürün lansmanının önemi, hedef kitleye, bu değişikliğin belirli bir grubun özelliklerle olan etkileşimini nasıl değiştirdiğine ve bu grubun genel ürünü her gün nasıl kullandığına bağlı olarak değişir.

Bu ürün sürüm iletişimleri (yaygın olarak sürüm notları olarak bilinir) farklı şeylerle ilgilenen kitlelere ulaşmalıdır. Guru'da Gelir Güçlendirme yöneticisi olarak benim muhataplarım, işlerini yapma yetilerini etkileyen herkes, yani:

• Ürün/Tasarım/Mühendislik ekipleri
• Satış Ekibi (Satış operasyonları, İç satışlar, Segmentler arasında Hesap Yöneticileri)
• Müşteri Deneyimi (Başarı Yöneticileri ve Destek temsilcileri)
• Pazarlama Ekibi (Ürün Pazarlama, Büyüme Pazarlaması, Marka, İçerik, GTM stratejisi ve basın iletişimi için liderlik edecek)
• İş Geliştirme ve Ortaklar

Tüm bu ortaklar, ürün güncellemelerini sindirmek ve bu güncellemeleri işlerine ne ölçüde uygulamaları gerektiğini hemen anlamalıdır. Ayrıca, her değişikliğin son kullanıcılar üzerinde yaratacağı etkiyi anlamalarına nasıl yardımcı olabileceklerini de düşünmelidirler.

Sürüm iletişimlerini hazırlayan kişi (veya ekip), ürünü bilgilendirecek tüm kitleleri göz önünde bulundurmalıdır. Açıklama: Bir arka uç mühendis için sürümün anlamı ile perakende endüstrisindeki potansiyel bir müşteri için anlamı arasında ne gibi farklılıklar vardır?

Nasıl Yapılmaz Sürüm Notlarına Yaklaşılır

Farklı kitlelerin ihtiyaçlarını göz önünde bulundurmak zor olsa da, bir Ürün Yöneticisi veya Ürün Pazarlama Yöneticisi'nin (PMM) beş farklı versiyon yazması pratikte ölçeklenemez. Deneyimlerime göre, sürüm notları ya çok uzun ve bağlamdan uzak ya da yeterince teknik bilgiye sahip değil. Statik sürüm notları bize bu içgörüyü vermez ve genellikle yazar için değil, değişiklikleri anlaması gereken kişi için yazılır. Açıkça söylemek gerekirse, genellikle kaçırılan fırsatlardır.  

Bir saatlik, haftalık sürüm notları toplantılarında, tekdüze bir sesle ürün yönetimi, slaytlardaki madde işaretlerini okur. Toplantı sona erdikten sonra, aynı ürün yöneticisi, değişikliklerin kendileri, müşterileri ve potansiyel müşteriler için ne anlama geldiğini öğrenmek isteyen herkes tarafından gelen e-postalar, telefonlar (onları hatırlıyor musun?), Slack'ler vb. alır. Eğer toplantıyı kaçırdıysanız, nüans ve bağlamı kaçırdınız ve yalnızca ham değişiklik günlüğünü aldınız.

Ancak bu, ürün yöneticisinin kutsal tercümeyi yapmak görevi değildir; onların görevi, pazardaki bir sorunu çözen bir ürün inşa etmektir. Pazarın, o niyetini anlaması için PMM'nin görevi, onu çevirmektir.

Harika yazılım sürüm notları yazmanın sırrı

Ben büyük bir Müzik Sesleri hayranıyım (şok edici, biliyorum) ve bir yetkilendirme uzmanı olarak, filmdeki zamansız dersler gerçek. "Hadi en baştan başlayalım, çok iyi bir yer!" her hafta aklımda dönüp duruyor. Bir ürün teslimat sürecini şekillendirmek veya yeniden şekillendirmek için, önce konuyu öğreneceğiniz bir dili öğrenmelisiniz.

1. Bir iç sözlük geliştirin

Bu sürecin ilk adımı, tüm ekibin aynı dili konuşmasını sağlamaktır. Paylaşılan terminolojiyi sosyalize etmek, bariz görünse de, kuruluşunuzda gerçekleşmiyor olabilir. Kısaltmalara aşina olmamak ve dili yanlış anlamak izole edebilir, ekipler arasında kafa karışıklığı ve bölünmelere neden olabilir.

Örnek: Pazarlama ekibimiz, bir özelliğin ne zaman ve nasıl pazara çıkacağımuzu tanımlamak için "başlatma" terimini kullanır. Mühendislik ekibi ise, "başlatma" kelimesini, bir özelliğin staging ortamımıza ne zaman yayımlandığını tanımlamak için kullanır. Özelliğe özel başlatma, mühendislik için "tamamlandı" olarak kabul edilir, müşterilerimiz onun hakkında bilgi sahibi olmadan önce. Bu kafa karıştırıcıydı ve içsel bir çatışma yarattı.

Kimse, tanımları sormak gibi, bir şeyin ne anlama geldiğini kabul ederek kamuya açıklama yapmak istemez. Çözümümüz: Mühendislik, ürün, ürün pazarlama gibi temsilcilerin olduğu bir işbirlikçi çalışma grubunda, nüansı öne çıkardık ve ürün sürüm tanımlarımızı belgeledik:

Not: Kartlardan herhangi birinin yüklenememesi durumunda, sayfayı yenileyin!

2. Sürüm notlarınızda neleri dahil etmeniz gerektiği

Paylaşılan dil kurulduktan ve ekibiniz sürüm terminolojisini ifade edebildiğinde, notlarınızı yazmaya başlayabilirsiniz. En kolay yol, sürüm notlarını yazmak için tekrar kullanılabilir bir şablon oluşturmaktır. Bu şekilde, paydaşlar birkaç yinelemeden sonra format ile tanışmış olur ve her seferinde jantları yeniden icat etmek zorunda kalmazsınız.

Asgari olarak, iyi sürüm notları şunları içerir:

• Yayın tarihi(leri)
• İç ve dış
• Özelliğin veya hatanın açıklaması
• Etkilenen ürün(ler) (birden fazla ürününüz varsa)
• Birden fazla yazılım ürününüz varsa, sürüm numaralarını da dahil etmek isteyebilirsiniz
• Soruların iç tarafta sorulabileceği yer

Ancak, harika sürüm notları da şunları içermelidir:

• Öngörülen sıkça sorulan sorular (SSS)
• Yeni kamu belgelerine bağlantı, mevcutsa
• Özellikler için:
• Özelliğin adı
• Özelliğin nasıl göründüğüne dair ekran görüntüleri
• Özelliği demo etme videoları
• Özelliğin neden var olduğu
• İlgili alıcı/müşteri kişiliklerini nasıl etkilediği

İşte şablon, dahili olarak kullandığımız (kopyalamaktan çekinmeyin!):

💡Not: Bu görev için doğrudan sorumlu bireyleri atamak yararlıdır (bunu bir grup çalışmasına bırakmak yerine). Mühendislik veya Ürün Yöneticileri, notların teknik kısmını (isim/sürüm/ürün/tarihler/ekran görüntüleri), Ürün Pazarlama Yöneticileri veya Satış Mühendisleri ise bağlamsal bilgiyi (alıcı kişilikleri/neden önemli olduğu) yönetmelidir.

Bir ürün teslimat süreci stratejisi uygulamak

Tutarlı bir iletişim formatı oluşturun

Terminolojiyi birleştirip şablonunuzu yazdıktan sonra, bir sonraki adım tutarlı bir iletim aracı (örneğin Slack, e-posta, Loom, Guru, Google Docs) ve yöntemine anlaşmaya varmaktır. Tutarlı bir iletim aracı, sürüm notu paydaşlarınızın nereye gitmeleri veya bakmaları veya abone olmaları gerektiğini bilmelerini sağlar (çekmek için) ve bir sürümden haberdar olmalarını sağlar.

Bu ayrıca değişim yönetimi için de önemlidir çünkü genellikle birine gerçekleri tam olarak anlaması için birkaç kez bir şeyler söylemelisiniz. Yayın türüne, UI/UX (kullanıcı arayüzü ve kullanıcı deneyimi) üzerindeki değişikliklere ve müşteriye olan etkiye bağlı olarak, sürüm notu kitlelerinizin ürün bilgilerini itmek (itmek için) gerekecektir. Guru'da hem itme hem de çekme metodlarını kullanıyoruz.

Çekme: Bilgi bulma yeri

Bizim için, paydaşlarımız Slack #release-notes kanalımızda takip edebilirler, burada hata düzeltmelerinden yepyeni özelliklere kadar her şey için tutarlı ve sindirilmesi kolay bir format vardır. Unutmayın ki, ilgili kitleleriniz yalnızca sürümlerin gerçekleşmekte olduğunu bilmekle kalmaz (Slack veya e-postadaki çekme yöntemiyle), daha da önemlisi, bu sürümün bağlamda neden önemli olduğunu bilmelidirler.

Sadece bir sürümün gerçekten olacağına veya olduğuna dair bilgi alışveriş etmek değerli değildir, ikinci aşamanın gerçekten uygulanabilir hale getirilmesi gerekir. Tutarlı bir bağlam sağlayan bir format geliştirmek için, satış temsilcileri, hesap geliştirme temsilcileri, iş geliştiren personeller (işlerin tamamı) ile anket yaptım ve "Özellik Ayrım Kartı" dediğimiz ürün teslimat şablonumuzu kurduk.

Bir mühendislik yöneticisi, yeni bir özelliğin geliştirilmesine başladığında, doğrudan sorumlu bireyler Asana üzerinden uyarılır ve yayın notları şablonunu kullanarak özelliğe özel Özellik Ayrım Kartı oluşturulmasını sağlar. Yeni Özellik Ayrım kartı, sunduğumuz "özelliğin beyni" olan, sağlam tek bir gerçek kaynağını oluşturur. Konu uzmanları (SME) — PMM ve satış mühendisleri gibi — sürümün değerli olduğuna, kimin en çok önem verdiğine ve geçerli olduğu durumlarda, özelliklerin nasıl sergileneceğine dair bilgileri de kapsar.

Sürüm notları paydaşları, özellikle Hesap Yöneticileri, aynı kartlara defalarca geri dönerler çünkü Özellik Ayrım Kartı'ndaki dinamik bilgiye güvenilir, ilgili ve uygulanabilir bulmuşlardır. Artık kitleler hem aynı dili konuşuyor hem de aynı (dinamik) oyun kitaplarından okuyordur. Özellik Ayrım Kartı'na dönüş, hala bir "çekme" yöntemi parçasıdır çünkü kendi hızında oluyor, bir satış ya da destek çağrısına hazırlık için ya da bir adayın yol haritası hakkında bir sorusu olduğunda yapılır.

İtme: Bilgiyi proaktif bir şekilde sağlamak

İtme yöntemi, sürümle ilgili bilgilerin zaman açısından kritik olduğu ve belirli ekipler için önemli olduğu durumlarda devreye girer. Burada, bu, Guru'nun duyurular işlevselliği ile gerçekleştirilir. İç kitlelerime olan etkiye dayanarak, ben de Guru aracılığıyla ilgili bir gruba duyuru gönderiyorum. O zaman uyarıyı tanımış ya da okumuş olanların raporunu görebilir ve okumayanları kamuya açık bir şekilde utandırabilirim.  

Neden bilgi odaklı kültür anahtardır 🗝

Tüm bunlara rağmen, aslında terminolojiyi kabul etmek, harika sürüm notları yazmak ve dinamik ürün teslimatı için bir mekanizma oluşturmak kadar basit değildir. Ekiplerin zamanla bilgi üzerinde işbirliği yapabilme yeteneği olmalıdır. Geri bildirim sağlamak ve bilgiyi paylaşarak geliştirmek, ekibin herkesinin görev ve sorumlulukları arasındadır.

Bizim için, bilgi alıcıları (bu durumda, sürüm notları paydaşları) yeni bir şey öğrendiklerinde ya da bir soruları olduğunda, Özellik Ayrım Kartı'na yorum yaparlar. Aynı zamanda, Slack’te sorulan ve cevaplanan soruları dahil ediyoruz ve bu, bilgiyi sürekli geliştirmek için bir yol olarak değerlendiriliyor. Konu uzmanı (genellikle PMM) bu yeni bilgiyi veya ilgili soruyu gözden geçirir ve Özellik Ayrım kartındaki bağlama yerleştirir.

Tüm sürüm notları, ya yaklaşan ya da yayımlanmış bölümlerine konularak erişilebilir hale getirilir, burada içsel olarak daha da düzenlenebilirler. Bu şekilde, bir bakışta takip etmek kolaydır. Eğer Guru'yu kullanmıyorsanız, bir sürüm notları sayfası veya bağlantılı değişiklik günlüğü oluşturmaya başlamak için öneriyoruz.

Diğer tüm süreçlerde olduğu gibi, bu süreç de sürekli olarak evrim geçiriyor. Ürün teslimatı ve sürüm notları, asla tek seferlik basit bir mesele değildir. İşletmenizin ihtiyaçları değiştikçe, süreçleriniz, sorumluluklarınız ve şablonlarınız da onlarla birlikte değişmelidir. Ancak kolay bir anlayış, bağlam ve kullanılabilirlik için çabalayarak, kaybetme olasılığınız yok.