Yeni bir özellik nasıl duyurulur (sessizlik olmadan)

Çoğu özellik duyurusu, kimsenin iki kez okumadığı bir kanalda ölür: kayıp giden bir tweet, bir abonenin o hafta aldığı diğer on ikisinin altında gömülü kalan bir sürüm günü e-postası, ekibin yarısının aylar önce sessize aldığı bir kanaldaki bir Slack mesajı. Özellik gönderildi. Onu kullanacak olanların neredeyse hiçbiri fark etmedi. Bunu düzeltmek, daha iyi bir duyuru yazmaktan çok, doğru okuyucu için doğru kanalı seçmekle ve genel bir mesajı fark etmelerine güvenmek yerine tam olarak isteyen kişilere doğrudan ulaşmakla ilgilidir.

Yeni bir özellik gerçekte nerede duyurulmalı?

Birden fazla yerde, çünkü “herkes aynı kanalı okur” hiçbir zaman doğru değildir. Bir changelog veya feed girişi, kendi ritminde kontrol eden ve kalıcı, tarihli kaydı isteyen okuyucuya hizmet eder. Uygulama içi bir bildirim, ürünü zaten kullanan ve varlığından haberdar olsa özelliği bugün kullanacak okuyucuya hizmet eder. E-posta, şu anda üründe olmayan ama doğru güncelleme için geri dönecek okuyucuya hizmet eder. Sosyal medya, hemen hemen hiç hedeflemeyle mevcut kullanıcıların ötesinde erişim sağlar.

Dördünden hiçbiri tek başına yeterli değildir. Changelog, boyutuna bakılmaksızın her sürümü taşıması gereken tek belgedir, çünkü diğer her şeyin geri işaret ettiği kayıttır; diğer üçü, özelliğin gerçekte ne kadar büyük olduğuna göre seçilen, üzerine eklenmiş güçlendirmedir.

Duyuru önce ne söylemeli?

Mekanizma değil, sonuç. “Raporlar endpoint’ine bir önbellek katmanı ekledik”, ekibin ne inşa ettiğini anlatır. “Raporlar artık bir saniyeden kısa sürede yükleniyor”, okuyucu için neyin değiştiğini anlatır, ve tıklamayı sağlayan cümle de budur, çünkü “bundan bana ne” sorusunu üçüncü yerine ilk cümlede yanıtlar. Mekanizma, başlığa değil, changelog girişine veya ayrıntı sayfasına aittir.

Sıfatlardan önce somutluk. “Daha hızlı, daha güçlü bir rapor deneyimi”, okuyucuya üzerinde işlem yapabileceği hiçbir şey söylemez; “raporlar artık bir saniyeden kısa sürede yükleniyor ve duruma göre filtrelenebiliyor” tam olarak neyin değiştiğini ve ne denenmesi gerektiğini söyler. İkinci versiyon aynı zamanda daha inandırıcı da görünür, çünkü belirsiz bir iddia, söylenecek somut bir şey olmadığında pazarlama metninin tam olarak kulağa geldiği gibi gelir.

Bir ürün güncelleme e-postasından nasıl farklıdır?

Örtüşür ama aynı değildir. Ürün güncelleme e-postası, sıklık, konu satırları, ve ne zaman bir özetin tek seferlik bir gönderiyi geçtiği dahil, e-posta kanalını özel olarak ele alır. Yeni bir özellik duyurusu, altta yatan olaydır; e-posta, özellik bir sonraki özette taşınmak yerine özel bir gönderiyi haklı çıkaracak kadar büyük olduğunda seçilen, onu taşıyabilecek yukarıdaki dört kanaldan biridir. Küçük bir özellik bir changelog girişini ve belki bir uygulama içi bildirimi hak eder. Önemli bir özellik, zamanlanmış olarak dört kanalın hepsini hak eder.

Tam olarak isteyen kişilere nasıl ulaşılır?

Bu, çabaya karşı en iyi getiriye sahip duyurudur, ve neredeyse tüm ekipler onu atlar. On müşteri bir özelliği isimle istediyse, o on kişi, çıkan başka herhangi bir daha geniş duyurudan bağımsız olarak, gönderildiği anda doğrudan, kişisel bir not hak eder. Müşteriyle geri bildirim döngüsünü kapatmak mekaniği baştan sona ele alır; buradaki özet, bunun sadece orijinal talep talep edene bağlı kaldığında işe yaramasıdır, ki bu bir duyuru sorunundan çok bir takip sorunudur. changeloop’ta, widget geri bildirimi bir GitHub issue’suna dönüştüğünde ve merge edilen pull request onu kapattığında (fixes #142), changelog girişini onaylamak o issue’ya canlı girişe geri bağlanan tek seferlik bir “Shipped —

Girişin kendisi nasıl yazılır?

Diğer herhangi bir sürüm notu girişiyle aynı disiplin: okuyucunun artık yapabileceğiyle başla, gerekli kurulumla devam et, iç gerekçeyi atla. Sürüm notları nasıl yazılır tam yöntemi ele alır; yeni bir özellik duyurusu en yüksek riskli durumdur, çünkü ekran görüntüsü alınma, iletilme ve ürünün changelog’unu hiç görmemiş biri tarafından okunma olasılığı en yüksek girişdir.

Ne zaman geniş çapta duyurulmamalı?

Özellik hâlâ hesapların bir alt kümesine yayılıyorsa, gerçekten bir beta ise, veya geniş bir duyurunun on okuyucusundan dokuzunun henüz kullanamayacağı şekilde fiyatlandırılmış veya kilitlenmişse. On okuyucusundan dokuzunun kullanamayacağı bir özellik için geniş bir duyuru bir yem gibi okunur, ve bu duyuruda heyecan yaratmaktan çok bir sonraki duyuruya olan güveni yakar. Çözüm sessizlik değil, kapsamdır: uygun hesapları doğrudan bilgilendirin ve kullanılabilirlik duyuruyu yakalayana kadar geniş kanalları bekletin.

FAQ

Her yeni özellik kendi duyurusunu hak eder mi? Her biri bir changelog girişini hak eder. Sadece birinin ürünü kullanma şeklini değiştirecek kadar önemli olanlar, veya isimle açıkça istenenler, e-posta veya sosyal medya gibi daha geniş kanalları hak eder.

Küçük bir özellik için en iyi kanal nedir? Sadece changelog, artı özellik kullanıcının zaten içinde olduğu bir akışta keşfedilebilirse bir uygulama içi bildirim. E-posta ve sosyal medya, dikkat istemeyi haklı çıkaran özellikler için değerlidir.

Bir özellik, tam olarak isteyen kişilere nasıl duyurulur? Talebi kaydedildiği andan itibaren talep edene bağlı tutun, sonra gönderildiğinde herhangi bir daha geniş duyurudan ayrı olarak bireysel olarak bildirin. Talep edenin kendi başına kontrol edebileceği paylaşılan bir durum etiketi de baştan kaç bireysel mesaja ihtiyaç duyulduğunu azaltır.

Bir özellik duyurusunun ekran görüntüsüne ihtiyacı var mı? Görsel olan her şey için evet; anlatılan ama görülmeyen bir özellik, okuyucuların önizlemesini görebildiği bir özellikten çok daha sık atlanır. Bir API veya backend yeteneği için, kısa bir kod örneği, bir UI değişikliği için bir ekran görüntüsüyle aynı işi görür.

Bu yazıdaki teknik iddialar bağımsız olarak kontrol edilmedi. Yanlış bir şey varsa bize söyle, düzeltelim.

changeloop'ta ilgili sayfalar: Changelog örnekleri, Geliştirici dokümantasyonu