Lean UX Dokümantasyonu: Agile Ekipte Ne Yazılır, Ne Yazılmaz
Agile ekiplerin çoğu dokümantasyonu iki uçta yaşıyor: ya hiç yazmıyor ya da kimsenin açmadığı bir wiki biriktiriyor. Lean UX dokümantasyonu bu ikisinin ortası değil, başka bir soru: hangi bilgi kaybolduğunda ekip aynı tartışmayı ikinci kez yapar? Yazılması gereken şey o. Gerisi arşiv.
Kayda değen tek şey kararın gerekçesi
"Dokümantasyon takım hafızası kurar" cümlesi doğru ama fazla geniş. Pratikte bir ekibin ürettiği belgelerin büyük kısmı hafıza değil, fotoğraf: persona dosyası, akış şeması, test raporu. Bunlar yazıldıkları haftanın durumunu anlatır ve üründe ilk değişiklikte yanlış bilgi haline gelir. Ayakta kalan tek katman gerekçedir. "Kayıt adımını üçe böldük" bilgisi altı ay sonra işe yaramaz; "kayıt adımını üçe böldük çünkü tek ekranda kullanıcılar telefon alanını boş bırakıp geri dönüyordu" bilgisi yararlıdır, çünkü biri bu adımları tekrar tek ekranda birleştirmeyi önerdiğinde tartışma sıfırdan başlamaz.
Bu yüzden ne yazılacağı sorusunun cevabı belge tipi değil: karar, kararın nedeni, kararı bozacak koşul. Üçüncüsü genellikle atlanır ve en kıymetlisidir.
Lean olup olmadığını okunma söyler, hacim söylemez
Dokümantasyonu "kısa tut" tavsiyesi ölçülebilir bir şey söylemiyor. Ölçülebilir olan şu: bir belgenin yazma maliyeti bir kez, güncel tutma maliyeti sürekli. Okunmuyorsa ikinci maliyet karşılıksız ödenir. Confluence, Notion, ne kullanıyorsanız son görüntülenme tarihini gösteriyor; iki ay açılmamış bir sayfa ya silinmeli ya da kimse ona güvenmediği için başka yerde yeniden yazılıyor demektir.
Bir projede persona ve araştırma özetlerini düzenli bir wiki yapısına taşımıştık, birkaç sprint sonra aynı kararları toplantıda yeniden tartıştığımızı görünce sayfaların hiç açılmadığını fark ettik.
İki an: karar verilirken ve karar bozulurken
Yaygın öneri "işe başlamadan önce ve değişiklik anında yaz" şeklinde. İlk yarısı çoğu ekipte çalışmıyor. Başlamadan önce yazılan şey karar değil tahmindir; sprint ortasında arayüz gerçek veriyle karşılaştığında o metin geçersiz olur ve kimse geri dönüp düzeltmez. Kayıt, kararın gerçekten verildiği anda tutulmalı, o an genelde işin ortasıdır.
İkinci an daha da önemli: bir kararı geri aldığınızda. Ekipler yeni kararı yazar, bozulan kararın neden bozulduğunu yazmaz. Sonuç olarak aynı fikir altı ay sonra yeni biri tarafından yeniden önerilir ve kimsede elinde denenmiş olduğuna dair kanıt yoktur.
Dört artefakt üretmek lean değildir
Lean dokümantasyon listeleri genellikle şunu öneriyor: başlangıç planı notları, değişiklik kaydı, haftalık özet rapor, bir de öğrenilen dersler dosyası. Aynı kararı dört yere yazmanın adı lean değil. Üstelik maliyet doğrusal da değil: aynı bilgiyi tutan k kopya arasında tutarlılığı korumak için k(k-1)/2 çift kontrol edilir, dört kopyada altı çift demek bu. Pratikte kimse altı çifti kontrol etmez, kopyalar sessizce birbirinden ayrılır ve ekip hangisinin güncel olduğunu bilmediği için hiçbirine güvenmez.
Tek kaynak seçin, kararı işin kendisine en yakın yere yazın: ilgili ticket'ın içine ya da değişikliği taşıyan pull request'in açıklamasına. Böyle bir kayıt kodla birlikte hareket eder, ayrı bir wiki sayfası etmez. Haftalık rapora ihtiyaç duyarsanız onu bu kayıtlardan üretin, paralel bir yazım işi olarak değil.
Geriye kalan işi bir cümleye indirmek mümkün: tasarım kararını verdiğiniz anda gerekçesini ve onu bozacak koşulu, işin durduğu yere iki satır olarak yazın. Bu kadarı tutulduğunda diğer belgelerin çoğuna ihtiyaç kalmıyor.