Farklı sorunları çözmeyi hedefleyen bir sürü önceliklendirme tekniği var. Muhtemelen RICE gibi değer-emek temelli önceliklendirme tekniklerinden birini zaten kullanmışsındır. Hatta belki hedef kitlenle özel olarak tasarlanmış bir anketle iletişime geçip KANO modeli gibi bir yöntemle onlardan bir şeyler öğrenmişsindir. Her önceliklendirme tekniğinin kendi kullanım alanları var ve belki de sana birçok yararlı karar almanda çoktan yardımcı olmuşlardır.
Ama bu stratejiler daha üst düzey bir önceliklendirme için tasarlanmış — yani A özelliğini mi yoksa B özelliğini mi önce geliştirmeli ya da C özelliği bir sonraki sürümde gerçekten gerekli mi gibi kararlar için. Ancak görevlere ve hatta alt görevlere kadar ölçeklenmiyorlar, dolayısıyla belirli bir özellik içinde gereğinden fazla iş yapmak gayet mümkün. Ayrıca, erken geri bildirim almak için özelliği kullanıcılara ne zaman sunmaya başlayabileceğin konusunda da yardımcı olmuyorlar — örneğin Lean Startup metodolojisi gibi kullanıcı odaklı yaklaşımlar uygulamak için. Tabii ki MoSCoW yöntemi gibi ölçekten bağımsız bir metot da tercih edilebilir, ama kategorileri o kadar soyut ki farklı insanlar her kategori için farklı beklentilere sahip olacağından değerlendirme kolay olmaz.
Laser Focus önceliklendirme stratejisinin amacı, net değerlendirme kategorileri sunmak, görev kapsamlarına yardımcı olmak ve kolay uygulanabilir bir yorumlama yöntemi sağlamaktır. Bu üç yön bir arada odaklanmanı sağlar.
Laser Focus kategorileri
Kategorilerimizle ulaşmak istediğimiz üç hedef var:
Hangi görevlerin mevcut planlanan sürümün kapsamında olduğuna karar vermek.
Alpha veya Beta sürümü için gereken görevleri diğerlerinden daha yüksek öncelikli kılmak.
Kategori isimlerinin eyleme dönüştürülebilir, kendi başına anlamlı bir karşılığı olması.
Tüm gereksinimleri karşılayan şu kategorileri öneriyoruz:
Vital (Hayati)
İlk test turu için gereken mutlak minimum. Çirkin görünebilir.
Bu, ürünü yalnızca “Vital” olarak işaretlenmiş özellikler veya görevler tamamlanmış haliyle küçük bir test grubuna sunarak erken geri bildirim almayı mümkün kılar. Tabii ki bu Alpha testinin kapsamı net olarak belirtilmeli — hangi temel özelliklerin veya görevlerin hâlâ eksik olduğu açıklanmalı ki testçiler bunları gereksiz yere raporlamasın. Ama ürünün veya özelliğin hayati kısımları zaten test edilebilir ve doğru yolda olup olmadığımızı gösteren ilk geri bildirim turunu alırız.
Essential (Temel)
Temel işlevsellik için gerekli ana unsurlar. Pürüzlü olabilir.
Tüm “Essential” özellikler veya görevler tamamlandığında ikinci ve daha büyük bir test turu başlatılabilir. Bu seviyede belirli bir test kapsamı iletmeye gerek yok, sürümü temel özelliklerin mevcut olduğu ama hâlâ birçok şeyin eksik veya tamamlanmamış olduğu bir “Beta” sürüm olarak adlandırmak yeterli olmalı.
Completing (Tamamlayıcı)
Pürüzleri gidermek ve işlevselliğin eksik kalan yönlerini tamamlamak.
“Completing” seviyesi, nihai ürünün yayınlanmaya hazır olduğu kapsamı tanımlar. Bazı durumlarda — örneğin belirli bir tarih için yeni sürüm duyurulduysa — bazı “Completing” görevleri açıkken de ürün yayınlanabilir, ama o zaman herkese açık şekilde “Beta” olarak işaretlenmelidir. Genellikle bu seviye, daha geniş bir kullanıcı kitlesi için önemli olan ama ürünün özünü değerlendirmekle ilgili olmayan her türlü özellik veya görevi içerir.
Optional (İsteğe Bağlı)
Sonraki sürümlere ertelenebilecek veya tamamen atlanabilecek olsa iyi olur şeyler.
“Optional” seviyesi, bu şekilde değerlendirilen özelliklerin veya görevlerin istenilen şeyler olduğunu ama ürünün nihai sürümünün yayınlanması için — uzun vadede bile — hiçbir şekilde gerekli olmadığını ifade eder. Dolayısıyla ekibin kaynaklarına göre kolayca ertelenebilir veya tamamen iptal edilebilirler.
Retracting (Geri Çekilmeli)
İlk bakışta olsa iyi olur gibi görünen ama aslında iyiden çok zarar verebilecek şeyler.
“Optional”dan farklı olarak, “Retracting” olarak değerlendirilen özellikler veya görevler aktif olarak kaçınılmalıdır. Yani bunları neden kaçınılması gerektiğine dair gerekçeleriyle birlikte bir yerde belgelemek mantıklı olabilir — uzun vadeli karar alma için. Bu, aynı fikir gelecekte tekrar ortaya çıktığında zaman kazandırır. Ayrıca, değerlendirmeye birden fazla kişi katılıyorsa, bir görevin ürüne etkisi hakkında tartışmanın gerekli olabileceği noktaları belirlemeye yardımcı olabilir.
Laser Focus matrisi
Laser Focus stratejisinin ikinci ayağı çok boyutlu ölçeklenebilirliğidir. Bunun ne anlama geldiğini ve neden önemli olduğunu açıklamak için, şu ana kadarki kategorileri bir örnekle uygulayalım: Gün boyunca yapılan farklı işlerin süresini takip etmek için bir kronometre uygulaması geliştirelim. İşte Laser Focus kategorileriyle değerlendirilmiş ilk özellik fikri listesi:
Proje oluştur → Essential (uygulama için temel, ama ilk test için önceden doldurulmuş projeler yeterli)
Proje düzenle → Completing (test için zorunlu değil, ama nihai sürüm için gerekli)
Proje sil → Completing (temizlik görevi, test için gerekli değil ama nihai sürüm için gerekli)
Zamanlayıcı başlat/durdur → Vital (uygulamanın temel fikri, hayati parça)
Zamanlayıcı için proje seç → Vital (proje seçmeden uygulamanın fikri gerçekleşmez)
Geçmiş kayıtlı süreleri düzenle → Retracting (V2’de rekabetçi özellik planlanıyor, hile riski var)
Geçmiş kayıtlı süreleri sil → Optional (olsa iyi olur, eklenen süre olmadığı için hile riski yok)
Seçilen projede geçmiş kayıtlı süreleri göster → Essential (uygulamanın temel kullanım senaryosu)
En çok süre kaydedilen projeleri göster → Essential (uygulamanın temel kullanım senaryosu)
Kategorilendirme sayesinde iki özelliği ilk sürümden çıkardık ve muhtemelen hiç uygulanmaması gereken bir özelliği bile fark ettik (6) — bu kalıcı olarak belgelenmeli. Ama daha önemlisi, artık ilk uygulanması gereken “Vital” özelliklerin 4 ve 5 olduğunu biliyoruz.
Hadi alt görevleri üzerinde çalışmaya başlayalım:
4. Zamanlayıcı başlat/durdur: (Vital)
a. Başlat/Durdur düğmesi düzenini tasarla (düşük sadakat) b. Başlat/Durdur düğmesi renklendirme & ikonları tasarla (yüksek sadakat) c. Başlat/Durdur düğmesi titreşen gölge efektini tasarla (animasyonlar) d. Başlat/Durdur düğmesi düzenini uygula (düşük sadakat) e. Başlat/Durdur düğmesi renklendirme & ikonlarını uygula (yüksek sadakat) f. Başlat/Durdur düğmesi titreşen gölge efektini uygula (animasyonlar) g. Temel süre takibi veritabanı modellerini kur h. Başlat/Durdur eylemlerini veritabanına kaydet
5. Zamanlayıcı için proje seç: (Vital)
a. Proje seçici navigasyonu & düzenini tasarla (düşük sadakat) b. Proje seçici şekiller, renkler & ikonları tasarla (yüksek sadakat) c. Proje seçici navigasyonu & düzenini uygula (düşük sadakat) d. Proje seçici şekiller, renkler & ikonlarını uygula (yüksek sadakat) e. Seçilen projeyi süre takibi veritabanı modeline kaydet
Her şey hazır, başlayalım mı? Değil mi?
Hayır. Okurken/göz gezdirirken muhtemelen fark etmişsindir zaten. Bir sorun var. Özellikleri, test edilebilirlik açısından gerçekten neyin gerekli olduğunu düşünerek önceliklendirdik — uygulamayı kullanıcılara ulaştırmak için. Ama şimdi aynı sorunla tekrar karşılaşıyoruz, sadece farklı bir seviyede. Bu görevlerin (ve potansiyel olarak alt görevlerinin) hepsi, kullanıcılara ulaştıracağımız ilk sürüm için “Vital” değil. Bunu nasıl düzeltiriz? Görevler için de ayrı bir değerlendirme yapmalı mıyız?
Evet, kesinlikle! Bu aslında Laser Focus stratejisinde bir gerekliliktir: Değerlendirmeyi tüm seviyelerde aşağıya doğru uygula! Üst seviyelerde alternatif bir önceliklendirme tekniği seçebilirsin. Ama başlamak istediğin seviyeden aşağıdaki tüm seviyeler bu şekilde değerlendirilmeli.
Hadi Laser Focus kategorilerini görevlere de atayalım ve bunun genel öncelik için ne anlama geldiğine bakalım:
4. Zamanlayıcı başlat/durdur: (Vital)
a. Başlat/Durdur düğmesi düzenini tasarla (düşük sadakat) → Vital b. Başlat/Durdur düğmesi renklendirme & ikonları tasarla (yüksek sadakat) → Completing c. Başlat/Durdur düğmesi titreşen gölge efektini tasarla (animasyonlar) → Optional d. Başlat/Durdur düğmesi düzenini uygula (düşük sadakat) → Vital e. Başlat/Durdur düğmesi renklendirme & ikonlarını uygula (yüksek sadakat) → Completing f. Başlat/Durdur düğmesi titreşen gölge efektini uygula (animasyonlar) → Optional g. Temel süre takibi veritabanı modellerini kur → Essential h. Başlat/Durdur eylemlerini veritabanına kaydet → Essential
5. Zamanlayıcı için proje seç: (Vital)
a. Proje seçici navigasyonu & düzenini tasarla (düşük sadakat) → Vital b. Proje seçici şekiller, renkler & ikonları tasarla (yüksek sadakat) → Completing c. Proje seçici navigasyonu & düzenini uygula (düşük sadakat) → Vital d. Proje seçici şekiller, renkler & ikonlarını uygula (yüksek sadakat) → Completing e. Seçilen projeyi süre takibi veritabanı modeline kaydet → Essential
Şunu belirtmek önemli: görevlerin değerlendirmelerinde referans değer, doğrudan üst öğe olan özellikti. Yani kendime “Başlat/Durdur eylemlerini veritabanına kaydetmek, Zamanlayıcı başlat/durdur özelliği için vital mı yoksa essential mı?” diye sordum — uygulama veya başka bir şey için değil. Bu, soruları yanıtlamayı çok daha kolay hale getiriyor.
Hadi bu iki farklı değerlendirme seviyesini basit bir matrisle görselleştirelim. X eksenine özelliklerin değerlendirmelerini koyuyoruz. Y ekseninde görevlerin değerlendirmeleri var. Daireler görevleri temsil ediyor:
Gördüğün gibi, 4a, 4d, 5a ve 5c görevleri sol alt alandaki “Vital-Vital” alanında, kısaca “VV”. Alanın arka planı kırmızıya boyanmış. Önce odaklanılması gereken tüm görevleri içeriyor. Hepsi uygulandığında ilk test turu başlayabilir ve Alpha aşaması başlar.
Sarıya boyalı “Vital-Essential” veya kısaca “VE” alanındaki 4g, 4h ve 5e görevleri sırada. Üç sarı boyalı alandaki (VV, VE, EV) tüm görevler tamamlandığında Beta aşaması başlar.
“VC” alanındaki “Vital” özelliklerin “Completing” görevleri, şu ana kadar tanımladığımız görevler arasında en son ele alınmalı. Yeşile boyalı tüm alanlardaki (VC, CV, EC, CE, CC) görevler bittiğinde, Release zamanı gelir.
Yukarıdaki örnekte, Vital olmayan tüm özelliklerin görevlerini atladık. Onları da değerlendirseydik, “Retracting” değerlendirmesi de dahil olmak üzere tam matris şöyle görünebilirdi:
Alpha, Beta ve Release görevlerinin başlangıç noktası (sol alt köşe) etrafında dairesel katmanlar halinde dizildiğini görebiliyoruz — bu da bize her görev için başlangıç noktasına olan mesafesine göre görsel bir öncelik sırası sunuyor. Bu, örneğin her göreve alt görevler eklendiyse üçüncü bir eksene de kolayca ölçeklenebilir. Formal olarak söylersek, bu herhangi bir sayıda boyuta ölçeklenebilir. Herhangi bir öğenin genel kategorisini hesaplamak için tüm üst öğelere bak ve en düşük önceliği “atomik” (en alt seviye) öğenin genel kategorisi olarak seç. Örneğin, “Essential” kategori değerlendirmesine sahip bir alt görev, “Vital” değerlendirmeli bir üst görev ve “Completing” değerlendirmeli üst özelliği düşün. Genel olarak en düşük öncelik “Completing”, yani bu alt görevin genel kategorisi bu olur.
Tek başına genel kategoriyi hesaplamak, özellikle 5 farklı alanın bulunduğu “Completing”de birçok görevin aynı seviyede olmasına yol açabilir. Aynı kategori içindeki özellikleri veya görevleri önceliklendirmenin bir yolu, kendi kategorisinin tüm üst öğelerinin kategorileriyle ortalamasını hesaplamaktır. Bunun için her kategoriye bir sayı atayalım (1 “Vital”den 5 “Retracting”e), en alt seviye (örneğin bir alt görev) bir tuple ile temsil edilebilir, örneğin yukarıdaki örnekte (2, 1, 3). Bu sayıların ortalaması basitçe (2 + 1 + 3) / 3 = 2.0 olarak hesaplanır. Daha fazla üst öğeye sahip ve aynı genel “Completing” kategorisindeki başka bir görev (3, 2, 3, 1) olarak değerlendirilebilir ve ortalaması (3 + 2 + 3 + 1) / 4 = 2.25 olur, yani daha düşük öncelikli olmalıdır. Genel ortalama ne kadar yüksekse, öncelik o kadar düşük — bu çok mantıklı çünkü ortalama sayı kabaca başlangıç noktasına olan mesafeyi temsil ediyor — mümkün olan en yüksek öncelik.
Ama merak etme, bu ortalamaları gerçekten hesaplamana gerek yok, yukarıda gördüğümüz matrise dayanan daha basit ve yeterli hassasiyette bir yol var:
Yukarıdaki diyagram, başlangıç noktasına olan mesafeye göre alanların hangi sırayla ele alınması gerektiğini gösteriyor. 2., 4. ve 5. sıraya yerleştirilen ikişer alan olduğuna dikkat et. Bu alanlar için duruma göre farklılık gösterebilecek bir seçim yapılmalı: Daha fazla özellik eklemeye mi odaklanmalıyız? Yoksa zaten başlanmış özellikleri iyileştirmeye mi? Önce özellik genişlemesine odaklanmak için “Özellik kategorisi” yönünde devam etmelisin, yani “VE”den önce “EV”. Mevcut özellikleri iyileştirmeye öncelik vermek için ise tam tersi olmalı.
Laser Focus ayrıştırma
Yukarıdaki bölümde, çok seviyeli kategorilendirmenin Laser Focus konseptinin anahtarı olduğunu öğrendik. Bunu projene hemen uygulamaya çalışırsan, birçok veya hatta tüm özelliklerinin ya da görevlerinin aslında “Vital” veya “Essential” olduğunu fark edebilirsin. Bu durumdaysan, görevlerini muhtemelen henüz verimli bir şekilde bölmediğinin bir işaretidir.
Bu yüzden kategorilendirmeden önce görevlerini doğru şekilde ayrıştırmak önemli. Özellikleri görevlere veya görevleri alt görevlere bölerken kendine sorman gereken yol gösterici soru sadece “Bunu bitirmek için hangi adımları atmam gerekiyor” olmamalı. Ayrıca her adımın gerektirdiği emek hakkında da düşünmelisin ve eğer emek ihmal edilebilir ölçüde küçük değilse, onu ayırmayı düşünmekte fayda var. Bazen bunu yapmak zor görünebilir, ama çoğu zaman “önce çalışır hale getir, sonra iyileştir” yaklaşımını takip etmek iyi bir fikirdir.
Örneğin, yukarıdaki “Zamanlayıcı başlat/durdur” özelliği için 3 göreve bölebilirdik: “Başlat/Durdur düğmelerini tasarla”, “Başlat/Durdur düğmelerini uygula” ve “Verileri kaydet”. Bunun sorunu, farklı tamamlanma seviyeleri olmaması. Daha da ayrıntılı bölmek daha iyi. Tabii ki bunları bu görevlerin alt görevleri olarak da yapabilirdik, ama öncelik hesaplamasını kolaylaştırmak için daha az seviyede yapmak önerilir. Bu yüzden bunun yerine “Başlat/Durdur düğmesi düzenini tasarla”, “Başlat/Durdur düğmesi düzenini uygula” ve aynı iki görevi “… renklendirme & ikonlar” ve “… titreşen gölge efekti” için de tercih ettik.
Kendine hangi parçaların kendi emeklerinin olduğunu sor ve her görevi, gereken emek bazında önceliklendirilmeye değer olacak şekilde böl. Mikro görevleri ayırma, bu kadar küçük görevleri önceliklendirmeye değmez, onları başka bir görevin parçası olarak tut.
Düzgün bir ayrıştırma, Laser Focus stratejisinin etkili olması için çok önemli.
Özet
Laser Focus önceliklendirme stratejisini doğru sırayla özetleyelim:
Özelliklerini ve görevlerini farklı tamamlanma seviyelerindeki daha küçük adımlara ayrıştır
Her seviyede “Vital”, “Essential”, “Completing”, “Optional” veya “Retracting” ile değerlendir
En alt seviye için tüm üst öğeleri dikkate alarak genel önceliği görselleştir veya hesapla
Bu adımları projen için herhangi bir zamanda uygula ve önemli şeylere odaklanmana yardımcı olacak, üzerinde çalıştığın sürümleri makul olan en kısa sürede kullanıcıların eline güvenle verecektir.