Playbook'lar Neden Çürür: Tasarım Sisteminin Bıraktığı Boşluk
Tasarım sistemi bir arayüzün nasıl göründüğünü tarif eder. İşin nasıl yürüdüğünü, bir talebin kimden çıkıp kime gittiğini, projenin hangi soruyla başladığını tarif etmez. Playbook denen doküman o boşluğu doldurmak için yazılıyor. Çoğu da altı ay içinde ölüyor, çünkü tasarım sisteminin aksine, playbook eskidiğinde hiçbir şey kırılmıyor.
Boşluk gerçek
Bir düğmenin köşe yarıçapını herkes aynı yerden alıyor. Peki yeni bir sayfa isteği geldiğinde ne oluyor? Kim brief yazıyor, kim onaylıyor, hangi noktada içerik ekibi devreye giriyor, canlıya çıkmadan önce kim bakıyor? Bunlar da tekrar eden kararlar, ama hiçbiri bileşen kütüphanesinde durmuyor.
Ekipler bu soruları her seferinde yeniden konuşuyor. Konuşma da genelde aynı üç kişiyle, aynı sonuçla bitiyor. Playbook'un tek işi var: o konuşmayı bir kere yapıp yazıya geçirmek.
Neden çürüyor
Tasarım sisteminin görünmez bir avantajı var: geri bildirim döngüsü otomatik. Bir bileşeni yanlış kullanırsanız arayüz gözle görülür biçimde bozulur, Storybook'ta fark edilir, kod incelemesinde takılır. Sistem kendi bakımını zorlar.
Playbook'ta böyle bir mekanizma yok. Confluence sayfası altı ay önceki onay akışını anlatıyor olabilir, kimse bunu fark etmez. Yanlış bilgi hiçbir testi düşürmez. Doküman sessizce yanlışlaşır, birkaç kişi ona bakıp yanıldığını görür, sonra bakmayı bırakır. Bu noktadan sonra playbook var ama işlevsiz.
Bakım yükü de küçümseniyor. Kırk süreç yazdıysanız ve her biri yılda ortalama iki kez değişiyorsa, yılda seksen güncelleme olayı üretmişsiniz demektir. Haftada bir buçuk revizyon. Bunun sahibi kimse, playbook o kişinin işinin görünmeyen kısmı haline gelir ve ilk yoğun dönemde düşer.
Kullanım anına iliştir
Playbook'u ayrı bir yerde tutup "ihtiyaç olunca bakılır" demek işe yaramıyor. Kimse ihtiyacı olduğunu o anda bilmiyor zaten. İşleyen tek yöntem, ilgili parçayı insanın zaten durmak zorunda olduğu noktaya yerleştirmek.
- Brief formunun içine, o alanı doldururken görülecek şekilde
- Pull request şablonuna, kontrol listesi maddeleri olarak
- Yeni proje açılışında otomatik oluşan görev kartlarına
- İşe alım ilk hafta programına, tek seferlik okuma değil, ilk gerçek göreve bağlı olarak
Bu yerleştirmenin ikinci faydası bakım tarafında. Şablona gömülü bir madde yanlışsa, onu her hafta birileri okuyor ve yanlış olduğunu söylüyor. Playbook böylece tasarım sisteminde bedava gelen geri bildirim döngüsüne kavuşuyor.
Neyin yazılmaya değeri var
Playbook taslaklarının çoğu keşif, prototip, geliştirme, yayın diye giden bir yaşam döngüsü şemasıyla başlıyor. En çok kopyalanan, en az okunan sayfa odur. Kimse projenin bir noktada geliştirileceğini bilmediği için o sayfaya bakmıyor.
Yazılmaya değer olan şey dar: bir kere tartışılmış, karara bağlanmış ve buna rağmen tekrar tekrar açılan konular. Erişilebilirlik kontrolünün hangi aşamada yapıldığı. Bir metnin son halini kimin onayladığı. Dış ajansa iş verilirken hangi dosyaların hazır olması gerektiği. Acil bir düzeltmenin normal akışı ne zaman atlayabileceği. Bunların ortak özelliği, cevabın kurumunuza özel olması. Genel bilgi zaten internette var, playbook'a girmesi gereken şey sizin kararınız.
Sahiplik: iki uçlu problem
Dokümanı herkese açarsanız içerik birkaç ay içinde kendi içinde çelişmeye başlar, aynı sürecin iki farklı anlatımı iki sayfada durur. Tek bir sahibe bağlarsanız güncel kalması o kişinin zamanına bağımlı hale gelir, o da bir noktada tükenir.
Pratikte işleyeni bölüm bazlı sahiplik. Her bölümün başına bir isim ve son gözden geçirme tarihi koyun. Tarih altı ayı geçmişse sayfanın üstünde bunu görünür yapın. Bu, dokümanın yanlış olduğunu göstermez ama okuyana ne kadar güveneceğini söyler, ki bilmediğiniz tarihli bir yönergeye körlemesine uymaktan iyidir.
Bir de silme alışkanlığı gerekiyor. Playbook'lar hep büyüyor, hiç küçülmüyor. Artık geçerli olmayan bir bölümü güncellemeye çalışmak yerine silmek çoğu zaman doğru hamle. Kısa ve doğru bir playbook, kapsamlı ve yarısı geçersiz olandan daha çok okunuyor.
Kaynak