FABLS

SaaS

İki haftada bir sürüm çıkarıyorsunuz ve yılda iki kez yazıyorsunuz

Yazılım ekiplerinin söyleyecek şeyden sıkıntısı yoktur. Söyleyen kişiden sıkıntıları vardır, çünkü yazmak, sürüm geciktiğinde ertelenen görevdir — ve her seferinde ertelenir, ta ki blogun en son gönderisi on bir ay önceki bir "tanıtım" olana kadar.

Hata yapısal, editoryal değil

Her ekip daha çok yazması gerektiğini bilir. Mühendisler yazabilir; kurucu yazabilir; genellikle birileri bundan keyif alır. Sorun, yazmanın kendi son tarihinin olmaması ve son tarihi olmayan her şeyin, olan her şeye kaybetmesidir — iki haftada bir, sonsuza dek.

Plan eksik olan son tarihi sağlar. Teması ve yazarı belirlenmiş tarihli bir alan, sakin bir haftada verilmiş ve sakin olmayan bir haftada uygulanan bir taahhüttür; taslak, kimse hatırlamasa bile ortaya çıkar. Onaylamak dakikalar sürer; sıfırdan yazmak ise hiç gelmeyen bir öğleden sonra sürer.

Bütün argüman budur. Bir modelin sizin ekibinizden daha iyi yazdığı söylenmiyor — yazmıyor. Söylenen, salı günü düzenlediğiniz bir taslağın var olduğu, yazmayı düşündüğünüz bir gönderinin ise var olmadığıdır.

Yol haritası, çoktan yazdığınız bir plandır

Altı ayın çoğu zaten belli. Önümüzdeki iki çeyrekte ne çıkacağını, ürünün hangi kısımlarının yanlış anlaşıldığını, hangi entegrasyonlar için sürekli talep geldiğini ve hangi soruların her hafta desteğe ulaştığını kabaca biliyorsunuz.

Bunların her biri bir temadır. Yol haritası ritmi sağlar — bir sürüm, tek bir değişiklik günlüğü kaydı yerine bir slot dizisi olur — destek ise her mevsim geçerli olan yarısını sağlar, çünkü ayda yirmi kez sorulan bir soru, bir kez yazıp sonsuza dek bağlantı verebileceğiniz bir parçadır.

Boşluk bırakın. Sürümler gecikir ve boş slotu olmayan bir plan, gecikmiş bir sürümü henüz var olmayan bir şey hakkında üç yazıya dönüştürür. Slotların çeyrek kadarının açık bırakılması aksaklık değildir; planın gerçek takviminizle temas ettiğinde ayakta kalan kısmıdır.

Mevsimsellik ve boşluklar nasıl çalışır →

Bir sürüm, üç yazıGörsel
  • 1BlogNe çıktı ve neden var oldu. Önce sorun, sonra özellik.
  • 2Facebook / InstagramDeğişiklik günlüğünü asla açmayacaklar için tek cümlelik sürüm.
  • 3BlogBirinin onu gerçekte nasıl kullandığı. Somut, ve tuhaf kısımları da içinde.
  • ·GecikirseSlotlar sürümle birlikte kayar. Var olmayan bir şeyi duyuran hiçbir şey olmaz.
  • 4BlogBu sürümün nihayet yanıtladığı destek sorusu, bir kez yazılmış haliyle.

Ritmi yol haritası belirlerTemaları destek belirler

Değişiklik günlüğünüz içerik değildir. Bir makbuzdur.

İki yazar, bazen üç

Ürünü açıklayan biri ve şirketten bahseden biri

Bunlar gerçekten farklı seslerdir ve birleştirilmeleri, yazılım bloglarının ünlü olduğu o özellikli tekdüzeliği üretir — ne teknik bir açıklama ne de herhangi bir şeyin insani bir anlatımı olan bir yazı.

Teknik yazar

Bir şeyin ne yaptığını, sıfat kullanmadan, tam olarak açıklar. Ürününüzün ne için olduğunu ve ne için olmadığını bilir ve bunu söyleme izni vardır. Yazıları destek taleplerinden bağlantı verilen yazar budur.

Şirket sesi

Kararlar, ödünleşimler ve neye doğru inşa ettiğiniz hakkında yazar. Ölçmesi zor ama işe alımda, satış görüşmelerinde ve herkesin büyük bir tedarikçi yerine küçük birini seçme nedeninde bariz olan bir şekilde faydalıdır.

Yanıtlayan

Yorumları sizin politikanıza göre yönetir. Yapabildiğini yanıtlar, yapamadığını işaretler ve yol haritası hakkında asla spekülasyon yapmaz. Destek olayına benzeyen her şey anında bir kişiye gider.

Onay kapısı burada gerçek iş görüyor

Bir fırın için onaysız bir yazı küçük bir utançtır. Bir yazılım şirketi için ise bir destek yükü, bir satış itirazı ya da kimsenin onaylamadığı bir taahhüddür. Bir sınırı hafifçe yanlış anlatan bir taslak müşteri tarafından size alıntılanarak geri döndürülür ve bir tarih ima eden bir taslak söz olarak kabul edilir.

Bu yüzden otopilota en çok temkinin gösterilmesi gereken durum budur. Makul bir düzen, zaten yayımlanmış bir şeyi tekrarlayan kısa sosyal slotlarında otopilot, ürün hakkında iddia yapan her şeyde ise onay demektir. Fiyatlandırma, kapasite veya tarihlerle ilgili her şey kalıcı olarak bir kişi tarafından okunmalıdır ve bunu yazarın kurallarına yazmaya değer; böylece bu tür taslaklar kuyruğa alınmak yerine bekletilir ve işaretlenir.

Rapor küçük bir ekibe ne söyler

Planlanan ile yayımlanan, önemi olan sayıdır ve bir yazılım ekibi için ilk çeyrekte genellikle rahatsız edicidir. Aynı zamanda yazının yeniden sürüme yenilip yenilmediğinin tek dürüst ölçüsüdür.

Karşılanma göründüğünden daha az önemlidir. Teknik bir yazı kitlesini günler içinde değil aylar içinde bulur ve ikinci haftada yargılamak, işe yarayacak olan yazıları emekli etmenize yol açar. Erken dönemde tema dengesi daha faydalıdır: yalnızca çıkan şeyler hakkında mı yazıyorsunuz, gösterir; bu standart başarısızlık modudur ve bu kadar çok yazılım blogunun paragraflı bir değişiklik günlüğü gibi okunmasının nedenidir.

Dürüst kısım: ürününüz gerçekten teknikse, en derin yazılar hâlâ bir mühendisin bir öğleden sonrasına ihtiyaç duyar. Bir planın değiştirdiği şey, bu öğleden sonralarının takvime girmesi ve yazının diğer yüzde sekseninin onlarla yarışmayı bırakmasıdır.