Proje Yönetimi Temelleri: Dinleme, Takip ve Metodoloji Seçimi
Proje yönetimi denince önce araçlar konuşuluyor, oysa bir projenin nerede tökezleyeceği çoğunlukla ilk hafta belli oluyor. Kimin neyi bildiği, müşterinin gerçekte ne istediği, hangi kararın sonradan geri alınamayacağı. Bunlar başta konuşulmazsa sonra çok daha pahalıya konuşuluyor.
İlk haftanın üç sorusu
Uzun bir başlangıç toplantısı yapmak yerine üç soruya net cevap aramak daha iyi sonuç veriyor. Bu proje başarılı sayılırsa bunu nereden anlayacağız? Hangi kararlar sonradan değiştirilemez? Ekipte bu işi daha önce yapmış biri var mı?
Üçüncüsü genellikle atlanıyor. Daha önce yapılmamış bir iş tahmin edilebilir bir iş değildir, süre verirken bunun hesaba katılması gerekiyor. Peki ya cevaplar birbirini tutmazsa? Müşterinin başarı tanımı ile ekibin başarı tanımı ilk hafta ayrışıyorsa, o ayrışma projenin sonunda teslim tartışması olarak geri geliyor. Erken görünmesi iyi haber.
İlerlemeyi kimden, neyle sormalı
Düzenli takip herkesin üzerinde anlaştığı bir ilke, ama takibin de bir maliyeti var. Sekiz kişilik bir ekipte her sabah yapılan yarım saatlik toplantı günde dört kişi-saat, haftada yirmi saat eder. Yirmi saat, küçük bir özelliğin baştan sona yazılabileceği süredir. Toplantı buna değebilir; hesabı hiç yapmadan "nasılsa on beş dakika" demek değmez.
İlerlemeyi ekibe sormak yerine işin kendi bıraktığı izden oku: kapanan issue'lar, commit geçmişi, geçen testler, staging'e çıkan sürümler. Ayrı bir durum raporu doldurtmak aynı bilgiyi ikinci kez üretmek demek, üstelik ikinci sürümü hep daha iyimser çıkıyor.
Toplantıyı büsbütün kaldırmak da gerekmiyor. İzden okunamayan tek şey, kişinin takıldığı yerde ne hissettiği. Onun için kısa ve seyrek bir konuşma yetiyor.
Metodoloji seçimi
Agile, Scrum, Kanban ve Waterfall her rehberde aynı sırayla sıralanıyor, hangisinin ne zaman doğru olduğu söylenmiyor. Söylenebilir.
Kapsamı sözleşmeyle sabitlenmiş, teslim tarihi dışarıdan belirlenmiş işlerde Waterfall'ın kötü şöhreti hak edilmiş değil. Kapsam gerçekten sabitse aşamaları sıraya dizmek en ucuz yol. Buna karşılık arayüz ve ürün işlerinde kapsam baştan bilinmiyor, çalışırken keşfediliyor; orada sabit plan ilk kullanıcı testinde çöpe gidiyor.
Scrum'ın gizli koşulu tahmindir. Ekibin birlikte çalışma geçmişi yoksa ilk sprintlerden çıkan sayılar tahmin değil temenni oluyor, hız verisi birikene kadar sprint hedefini kimseye taahhüt diye sunmamak gerekiyor. Kanban ise işin dışarıdan geldiği, önceliğin ekipte olmadığı yerlerde (bakım, destek, hata giderme) diğerlerinden daha iyi çalışıyor; orada sprint planlamak için ortada plan yok.
Müşteri ile kullanıcı aynı kişi değil
UX projelerinde en sık atlanan ayrım bu. Kullanıcı testi bir sonuç veriyor, müşterinin ürün vizyonu başka bir şey söylüyor ve iki taraf da kendi içinde haklı olabiliyor. Bu çatışmayı toplantı anında çözmeye çalışmak zaman kaybı. Kararın kime ait olduğunu projenin başında yazıya dökmek, sonradan yapılacak tartışmayı kısaltıyor: veri ekibin sorumluluğu, karar müşterinin.
Yardım istemek de aynı yere bakıyor. Takılan kişinin bunu iki gün sonra değil ilk gün söylemesi, ekibin toplam hızını belirleyen birkaç şeyden biri. Bunu mümkün kılan yöntem değil, o kişinin söylediğinde ne olacağını biliyor olması.
Kaynaklar