Birden fazla proje üzerinde düşünürken odağı yalnız takvimde ayrılan saatle değerlendirmek istemiyorum. Bir projenin açık kararları, bekleyen bağımlılıkları ve sürekli zihinsel yer tutan belirsizlikleri de kapasite tüketir. Çok sayıda başlığın hareket ediyor görünmesi, her birinin anlamlı biçimde ilerlediğini göstermez.
Kurucu ve proje yöneticisi olarak bu yazıda önerdiğim değerlendirme, projeleri aynı hızda büyütme iddiası taşımıyor. Oryvelon, MerchNivo, Noveniq, Keşif Atlası ve diğer proje başlıkları için gerçekleşmiş kullanım veya gelir sonucu açıklamıyorum. Buradaki amaç, birden fazla fikir arasında karar vermeyi daha görünür hale getirmek.
Her proje için mevcut soruyu yazmak
Bir proje hangi belirsizliği çözmeye çalışıyor? Müşteri problemi mi, uygulanabilirlik mi, dağıtım mı, yoksa operasyon modeli mi? Aynı anda bütün soruları çözmeye çalışmak, küçük işleri çoğaltırken temel kararın ertelenmesine neden olabilir.
Her proje için bir sonraki önemli kararı tek cümlede yazarım. “Siteyi geliştirmek” yerine “bu kullanıcı grubu önerilen görevi tamamlayabiliyor mu?” gibi bir soru daha somut kanıt gerektirir. Yapılacak işin bu soruya katkısı yoksa önceliği yeniden düşünülmelidir.
Kapasiteyi yalnız geliştirme olarak görmemek
| Kapasite türü | Sorulacak soru |
|---|---|
| Üretim | Tasarım, yazılım veya içerik için ne kadar iş var? |
| Karar | Kaç belirsizlik doğrudan dikkat gerektiriyor? |
| Bakım | Mevcut çıktının çalışır kalması ne istiyor? |
| İletişim | Hangi kişi ve süreçlerle koordinasyon gerekiyor? |
| Öğrenme | Yeni kanıtı değerlendirecek zaman var mı? |
Bir proje teknik olarak küçük olsa bile çok sayıda koordinasyon ve karar ihtiyacı yaratabilir. Bu nedenle yalnız yapılacaklar listesindeki madde sayısına bakmak kapasiteyi yanlış gösterebilir.
Aktif, bekleyen ve gözlenen işi ayırmak
Her fikir aynı anda aktif üretimde olmak zorunda değildir. Bir başlık araştırma bekleyebilir, bir başlık sınırlı bakımda kalabilir, başka bir başlık belirli bir karara kadar öne alınabilir. Bu durumlar bir başarı veya başarısızlık etiketi değil, mevcut kaynak seçiminin ifadesidir.
Bekleyen işin yeniden açılma koşulu yazılırsa sürekli zihinsel hatırlatma gerektirmez. Yeni müşteri kanıtı, teknik bağımlılığın çözülmesi veya belirlenen değerlendirme tarihi böyle bir koşul olabilir. Belirsiz “sonra bakarız” kaydı ise gerçek bir sınır oluşturmaz.
Ortak altyapı varsayımını sınamak
Projeler arasında benzer ihtiyaçlar olması, hepsinin tek sistemde birleşmesi gerektiğini göstermez. Ortak parçanın bakımını kim yapacak, bir değişiklik hangi projeleri etkileyecek ve ayrı kalmanın maliyeti ne? Bu sorular paylaşım kararından önce cevaplanmalıdır.
Oryvelon için platform sınırları bu konuya bir uygulama planı olarak bakıyor. Ortaklık, yalnız teknik benzerlik değil, sahiplik ve değişim ritmi açısından da değerlendirilmelidir.
Değerlendirmeyi bir seçimle bitirmek
İnceleme sonunda hangi projenin hangi sorusu için kaynak ayrılacağı, hangisinin bekleyeceği ve neyin yapılmayacağı yazılır. Bütün başlıklara küçük görev eklemek karar vermiş olmak değildir. Gerektiğinde kapsamı daraltmak, bir işi bırakmak veya öğrenme yöntemini değiştirmek gerekir.
Yapılmayacaklar listesi sınırı; karar günlüğü gerekçeyi korumayı tamamlıyor. Benim için odağın ölçüsü aynı anda kaç şeyin açık olduğu değil, seçilen işin hangi belirsizliği azaltarak bir sonraki kararı mümkün kıldığıdır.