İHTİYAÇLARIN ÖNCELİKLENDİRİLMESİ: LEGO TIME

İHTİYAÇLARIN ÖNCELİKLENDİRİLMESİ: LEGO TIME

Kapsamlı projelerde hangi ihtiyaçların önce yapılacağı çok önemlidir. Şöyle düşünebiliriz. 300 parçalık bir lego setimiz var ve bu setten bir ev yapmak istiyorsanız sivri parçaları çatı yapmak için sona bırakırsınız. Pencere ve kapı şeklindeki parçaları en başta kullanırsanız evin ortalarına geldiğinizde yerleştirecek kapı bulamazsınız.  Bu yüzden bu parçaları evin  temelini oluşturduktan sonra kullanırsınız.  Bir projenin kapsamı da belli olduktan sonra ihtiyaç listesi (requirements) üzerinden bir önceliklendirme yapılmalı ve bu öneliklendirmeye göre projeye start verilmelidir. Projeye başlandığında özellikle en yüksek öncelikli ihtiyaçların hangileri olduğu belli olmalıdır.

Peki, nasıl önceliklendiririz?  Agile ve Sürekli teslim (Continious Delivery) metodolojileri uygulanan yerlerde bu soru daha da önemlidir. Çünkü belirli dönemlerde ürünün biten kısımları live ortama alınabildiğinden müşteri için öncelikli olan fonksiyonlar belirlenmelidir. Diğer metodlarda da teknik mimarinin doğru kurulması ve sonraki ihtiyaçların daha hızlı deliver edilmesi açısından doğru önceliklendirme yapılmalıdır. Önceliklendirme için birçok teknik olmakla beraber bana göre en efektif yöntemler aşağıdakilerdir.

MoSCoW: Bu yöntemde herbir requirement önemine göre Must, Should, Could, Would modalları ile belirlenir. Buradaki önem, işi isteyen kişinin verdiği önem derecesidir. Teknik ve mimari öncelikler ikinci plandadır. Must olandan başlanır. Should olanlar ardından bitirilir. Could olanlar kaynak ve zaman sorunu yoksa en sonda tamamlanır. Would olanlar yapılmaz fakat bu fonksiyonların ileride olacağı varsayılarak projenin teknik ve iş mimarisi kurgulanır. 

Must Have	Kritik task. Workaroundu olmayan ve proje için kritik task. Yapılmadığında proje tamamlanmış sayılmaz.
Should Have	Yapılması oldukça önemli olan konu. Yapılmadığında proje başarılı sayılmaz.
Could Have	Yapılması istenen fakat kritik olmayan tasklar. Yapılmadığında müşteri memnuniyeti düşebilir. Proje tamamlanmış ve başarılı sayılır.
Would Have (Won’t)	Yapılması planlanan fakat bu aşamada projenin dışına atılan tasklar. Bir anlamda bu faz dışındaki maddeler

HI/LO Etki-Zorluk Düzlemi: Buna Affinity Chart da diyenler vardır. Bu yöntem XY düzleminde Etki ve Zorluk düzeyine göre tüm ihtiyaçların gruplanması esasına dayanır.  Etki iş biriminin önceliği iken, Zorluk ise yazılım sürecinin zorluk derecesini ifade eder. Projelerin kritik parçalarının müşteriye gösterilmesi gereken projelerde oldukça etkin bir yöntemdir.  Düzlemde Yeşil bölge en başta Kırmızı bölge en sonda yapılır. Diğerleri ise tamamen müşterinin isteğine göre önceliklendirilir.

HLO Düzleminde Önceliklendirme

Bu iki yöntem sonunda ortaya aşağıdaki gayet basit bir sıralama listesi ortaya çıkacaktır. Önemli olan bu listenin her an müşteriye göre yeniden düzenlenmesidir. Bir projede belki de en güncel tutulması gereken bilgi “ÖNCELİK” bilgisidir.

Öyle projeler olacaktır ki, müşteri en başta gördüğü ihtiyaçlara göre tüm projeyi şekillendirecektir.

Sonuç olarak; 

ÖNCELİKLENDİRME EN ÖNEMLİ ÖNCELİĞİMİZ ARASINDA OLMALIDIR