Tasarımda Risk Yönetimi: Matristen Karara
Her tasarım kararı bir risk taşır ve neredeyse her ekip bunu aynı şekilde ölçer: olasılık çarpı etki. Formül bir işe yarıyor, ama tek başına sıralama yaptığında düzenli olarak yanlış maddeyi listenin başına koyuyor. Aşağıda süreç kısa hali, matrisin tıkandığı yer ve onun yerine ne yapılacağı var.
Önce cümleye dök, sonra puanla
Tasarım tarafında riskler dört başlıkta toplanır: kullanıcı hatası, güvenlik açığı, maliyet aşımı, mevcut sistemle uyumsuzluk. Puanlamaya geçmeden önce her birini tek cümleyle yazın, cümlede şu üçü geçsin: hangi koşulda, kime, ne oluyor.
"Kullanılabilirlik riski var" yönetilebilir bir cümle değil. "Kayıt formunda telefon alanı maskesiz olduğu için çağrı merkezine hatalı numara düşüyor ve sipariş teyidi yapılamıyor" yönetilebilir. İkincisini okuyan geliştirici ne yapacağını biliyor, birincisini okuyan toplantı ayarlıyor. Riski cümleye dökmeyen ekip onu yönetmiyordur (tabloyu renklendirmek yönetmek sayılmaz).
25 hücre, 14 farklı skor
Olasılık ve etkiyi beşli skalada puanlayıp çarparsanız 25 hücreniz olur. Ama çıkan skor kümesi sadece şu 14 sayıdır: 1, 2, 3, 4, 5, 6, 8, 9, 10, 12, 15, 16, 20, 25. Hücrelerin yarısına yakını bir başkasıyla aynı sayıya düşüyor, yani matris size sandığınız çözünürlükte bir sıralama vermiyor.
Asıl sorun çakışmanın nerede olduğu. 5x1 ile 1x5 aynı skoru üretir: biri neredeyse hiç olmayan ama olduğunda ciddi zarar veren olay, diğeri her gün olan ama küçük rahatsızlık yaratan olay. Bunlar aynı önceliğe konmaz, çünkü çözümleri bile aynı yerde değildir. Nadir ve ağır olan için kurtarma yolu tasarlarsınız: geri alma, yedek, telefonla ulaşılabilen bir insan. Sık ve hafif olan için arayüzü düzeltirsiniz, kurtarma yolu kurmazsınız.
Çarpımı sıralama aracı değil, eleme aracı olarak kullanın. Skoru hesaplayın, eşiğin altında kalanları listeden çıkarın, kalan on beş maddeyi sayıya bakmadan elle sıralayın. Sıra kararı ekibin, sayının değil.
Sürecin kısa hali
- Hedefi ve başarı ölçütünü yazın, risk buna göre tanımlanır.
- Riskleri toplayın: kullanıcı testi kayıtları, destek talepleri, geçmiş sürüm hataları.
- Olasılık ve etkiyi puanlayın, eşiğin altını eleyin.
- Kalanlar için ya olasılığı ya etkiyi düşüren bir önlem tasarlayın, ikisini birden hedeflemeyin.
- Önlemi uygulayın ya da riski açıkça kabul edin.
- Kabul edilenlere ne zaman tekrar bakılacağını takvime yazın.
Tek tıkla satın alma: risk nereden geliyor
Tek tıkla satın alma üç riski birden açar: yanlışlıkla verilen sipariş, sahtecilik, parçalı gönderiden doğan kargo maliyeti. Refleks çözüm araya bir onay adımı koymaktır, ki bu özelliğin kendisini iptal eder.
Yanlış sipariş için doğru hamle onay değil, geri alma penceresi. Siparişi on beş dakika iptal edilebilir durumda tutun, kullanıcıya bunu ekranda gösterin. Uygulama tarafında bu, sipariş kaydına bir durum alanı ve zamanlanmış tek bir iş eklemek demek. Onay diyaloğu yazmaktan daha uzun sürmez, dönüşümü de düşürmez.
Sahtecilikte ilk hamle herkesi doğrulamaya sokmak değil. Yeni cihaz, yeni teslimat adresi ve alışılmışın üstünde tutar aynı anda geldiğinde ek adımı geri koyun, diğer durumlarda koymayın. Kargo maliyetini de tasarımla çözebilirsiniz: aynı gün içindeki siparişleri tek gönderide toplayıp kullanıcıya "bunu da ekle" seçeneği sunmak, kargo başına maliyeti kullanıcının işine yarayan bir şeye çevirir.
Kalan riski kabul etmek de bir karar
Her riski kapatmaya çalışmayın, çoğu dış etkene bağlı ve kapatma maliyeti zararından yüksek. Ama kabul ettiğiniz riski yazın: kimin kabul ettiği ve hangi eşikte tekrar bakılacağı kayıtta yoksa o risk kabul edilmemiş, unutulmuştur. Aradaki farkı genelde altı ay sonra, kimsenin sahiplenmediği bir hata kaydında görürsünüz.