Sürüm Notları ve Paydaş Güncellemesi, Aynı Özellik
4 dk okuma
Yayına alınmış bir özelliği duyurmanın en hızlı yolu, mühendislik değişiklik günlüğünü bir e-postaya kopyalayıp herkese göndermektir. Bu güncellemeyi dışarı çıkarır ama aynı zamanda kullanıcıların ihtiyaç duymadığı uygulama ayrıntılarını almasına ve yönetimin gerçekten istediği iş çerçevesini alamamasına yol açar. Az önce toplu dışa aktarma özelliğini yayına alan bir ürün yöneticisi, API uç noktalarını ve hız sınırlarını anlatan aynı paragrafı hem müşteriye dönük sürüm notlarına hem de yönetimin Slack kanalına gönderebilir ve iki yerde de kötü karşılandığını görebilir.
Dikkat
Her kitleye gönderilen tek bir teknik özet iletişim değil, dağıtımdır. Mühendisler için yazılmış bir değişiklik günlüğü kullanıcılara gürültü, yönetime ise konuyu ıskalamış gibi gelir.
Özellik bir kez yayına alındı. Ne anlama geldiği, onu kimin okuduğuna tamamen bağlıdır.
Tek bir özet neden her okuyucuya yetersiz gelir
Bir değişiklik günlüğü, teknik olarak neyin değiştiği konusunda kesin olmak için yazılır. Bu kesinlik, bir kullanıcının tam olarak ihtiyaç duymadığı ve bir yönetim güncellemesinin uygulama değil sonuç olarak çevrilmesini istediği şeydir. “Dışa aktarma uç noktasına sayfalama desteği eklendi” cümlesini okuyan bir kullanıcı, bunun artık bir seferde 10.000'den fazla satır dışa aktarabileceği anlamına geldiğini bilmez; aynı cümleyi okuyan bir yönetim ekibi de bunun küçük bir teknik temizlik mi yoksa çeyreğin en büyük müşteri şikâyetinin çözümü mü olduğunu bilmez.
Aylardır destek talebi üreten sert 10.000 satırlık bir sınırı kaldırmak için haftalarca süren mühendislik çalışmasından sonra yayına alınan bir toplu dışa aktarma özelliği düşün. Doğru ve kesin olan değişiklik günlüğü girdisi, teknik değişikliği sayfalama ve sorgu optimizasyonu terimleriyle anlatır. Artık tüm veri kümesini dışa aktarabildiğini bilmek isteyen kullanıcı da, bunun tekrarlayan bir müşteri kaybı riski kaynağını kapattığını bilmek isteyen yönetim de aynı cümleden ihtiyaç duyduğunu alamaz.
Önce: mühendislik değişiklik günlüğünü kopyala, bir e-postaya yapıştır, kullanıcılara ve yönetime aynı şekilde gönder.
Sonra: Claude'a teknik özeti bir kez ver ve her kitle için yeniden biçimlendirilmiş bir sürüm iste: ne değişti ve neden özellikle onlar için önemli.
Bir güncellemeyi iki kitle için yeniden biçimlendirmek için bir süreç
- 1
Özelliğin bir hatırasından değil, gerçek değişiklik günlüğünden başla
Değişiklik günlüğü, yayına alınanın gerçek kapsamını içerir. Hafızadan çalışmak, yeniyi abartma ya da kitlelerden biri için önemli bir ayrıntıyı dışarıda bırakma riski taşır.
- 2
Her kitlenin gerçekte neyi önemsediğini adlandır
Açıkça söyle: kullanıcılar kendileri için neyin değiştiğini ve nasıl kullanacaklarını önemser; yönetim neyi hareket ettirdiğini, benimsemeyi, geliri, yol haritası belgesindeki bir metriği önemser. Bunu adlandırmazsan iki sürüm de teknik çerçeveye kayar.
- 3
Her sürüm için gerçek bir uzunluk ver
Belirli bir cümle ya da kelime sayısı, aynı açıklamanın biraz kırpılmış bir sürümü yerine, o kitle için en çok önemli olana doğru sıkıştırmayı zorlar.
- 4
Hiçbir sürümün yayına alınanı abartmadığını kontrol et
Her iki çıktıyı gerçek değişiklik günlüğüyle karşılaştır. Özellikle kullanıcıya dönük bir sürüm notu, gerçekte yayında olandan fazlasını vaat eden pazarlama diline kayabilir.
Yeni toplu dışa aktarma özelliğimizin bu mühendislik değişiklik günlüğünü, kullanıcılar için 3 cümlelik bir sürüm notuna ve yönetim için 100 kelimelik bir durum güncellemesine dönüştür.
”Özellik yönetimin takip ettiği bir metrikle doğrudan bağlantılıysa, destek talebi hacmi, önceki bir yol haritası incelemesinde işaretlenmiş bir müşteri kaybı riski, yönetim sürümünün sonucu gömmek yerine onunla açılması için bu bağlantıyı açıkça adlandırmaya değer.
Bu özellik, geçen çeyreğin yol haritası incelemesinde müşteri kaybı riski olarak işaretlediğimiz dışa aktarma sınırı şikâyetlerini özellikle ele alıyor. Yönetim sürümünün yalnızca özelliğin genel bir tarifiyle değil, bu bağlantıyla açıldığından emin ol.
”
Claude Tutorial içinde
Bir güncellemeyi her okuyucunun gerçekten önemsediği şeye göre yeniden biçimlendirmek aktarılabilir bir beceridir.
Aynı altta yatan bilgiyi herkese tek bir sürüm göndermek yerine farklı okuyucuların gerçek endişelerine uyarlamak, sürüm notlarının çok ötesinde geçerlidir. Uygulamada bu konuda, birden fazla kitlesi olan her güncellemeye taşınan alıştırmalarla tam bir ders var.
Özellik tamamen yayına alınmadığında
Her güncelleme temiz bir lansman değildir. Bir özellik kısmen, bir bayrağın ardında ya da sınırlı bir gruba yayına alındıysa, iki sürüm de genel erişilebilirliği ima etmek yerine bunu dürüstçe söylemelidir. Erişilebilirliği abartan bir sürüm notu belirli, öngörülebilir bir maliyet yaratır: özelliği bulamayıp nereye gittiğini soran bir destek talebi açan kullanıcılar.
İpucu
Claude'a gerçekte neyin canlı olduğunu ve neyin hâlâ kademeli açıldığını açıkça söyle ve iki sürümün de bunu doğru yansıtmasını iste. Erişilebilirliği fazla vaat eden bir sürüm notu, önlediğinden daha fazla destek talebi yaratır.
Bu özellik, bir bayrağın ardında kullanıcıların %20'si için canlı, henüz genel olarak erişilebilir değil. Sürüm notunu ve paydaş güncellemesini bunu doğru yansıtacak şekilde, gerçek bir ilerleme olduğunu küçümsemeden yeniden yaz.
”Bunun gibi kademeli bir yayından önce destek ya da müşteri başarısı ekibi için kısa bir not hazırlamaya da değer; böylece bayrağı olmayan bir kullanıcı başka bir yerde anıldığını gördüğü bir özelliği sorduğunda elinde doğru bir yanıt hazır olur.
Destek ekibi için kademeli yayını açıklayan kısa bir iç not yaz; böylece bayrağı olmayan bir kullanıcı bu özelliği sorarsa elinde doğru bir yanıt hazır olsun.
”Okumaya devam et
- Ödünleşimleri Açıklayan Bir Yol Haritası Belgesi Yazmak: bu yayına alınmış özelliğin, sıralanmış ve gerekçelendirilmiş bir yol haritası maddesi olarak başladığı yer.
- Destek Taleplerini Önceliklendirilmiş Temalara Dönüştürmek: talepleri bu özelliğe duyulan ihtiyacı ilk ortaya çıkaran kullanıcılarla döngüyü kapatmak.
- Bir PRD'yi İncelemeye Göndermeden Önce Keskinleştirmek: aynı disiplin, bağlamına sahip olmayan bir okuyucuyla test etmek, bu özelliğin ömrünün daha erken bir aşamasında uygulanmış.