Ekip liderliğini üstlendiğim dönemde aynı anda devam eden çok sayıda müşteri projesini takip etmekte zorlanıyordum.
Ekip yoğun şekilde çalışıyor, toplantılar yapılıyor ve planlar hazırlanıyordu. Buna rağmen bazı projeler yavaşlıyor, bazı sorunlar geç fark ediliyor ve gün içinde sürekli farklı bir konuya müdahale etmem gerekiyordu.
Bir süre sonra sorunun proje sayısı değil, çalışma biçimimiz olduğunu fark ettim.
Projeleri daha sağlıklı yönetebilmek için önceliklendirme, kaynak planlama, toplantılar, eskalasyon ve raporlama yöntemlerimizi yeniden ele aldım.
1. Her Müşteride Bütün Modüllere Aynı Anda Başlamadım
Hazine Sihirbazı dört farklı modülden oluşuyordu. İlk dönemlerde müşterinin kullanacağı bütün modülleri aynı proje planı içinde başlatmaya çalışıyorduk.
Bu yaklaşım hem ekibin odağını dağıtıyor hem de müşterinin aynı anda çok fazla konuya hazırlanmasını gerektiriyordu.
Öncelikle müşterinin gerçek ihtiyacını anlamaya başladım:
- Müşterinin öncelikli problemi neydi?
- Hangi modül en hızlı değeri üretecekti?
- Diğer modüller için hangi hazırlıkların tamamlanması gerekiyordu?
- Müşteri ekibi hangi aşamaya gerçekten hazırdı?
Bu soruların ardından projeleri fazlara ayırdım. Önce müşterinin en fazla ihtiyaç duyduğu modüle odaklandık, diğer modülleri sonraki aşamalara planladık.
Böylece ekip aynı anda daha az konuya yoğunlaştı, müşteri daha erken sonuç görmeye başladı ve proje planları daha uygulanabilir hâle geldi.
2. Bir Çalışma Gününü Sekiz Saatlik Kesintisiz Zaman Gibi Planlamadım
Kaynak planlamasında yaptığım en önemli hatalardan biri, bir çalışma gününü sekiz saatlik kesintisiz üretim zamanı olarak kabul etmekti.
Plan üzerinde her şey mantıklı görünüyordu. Fakat gerçek hayatta ekip üyelerinin toplantıları, müşteri soruları ve destek talepleri vardı. Ayrıca müşterilerden gelen geliştirme ihtiyaçlarını anlamak, bunları netleştirmek ve ürüne eklenebilmeleri için Jira maddelerini hazırlamak da zaman alıyordu.
Kısacası takvimde bulunan süre ile gerçekten işe ayrılabilecek süre aynı değildi.
Kaynak planlarını hazırlarken şu konuları da dikkate almaya başladım:
- Devam eden destek ve bakım işleri
- Düzenli toplantılar
- Geliştirme taleplerinin analizi ve Jira maddelerinin hazırlanması
- Ekip içi bilgi paylaşımı
- İzinler ve olası kesintiler
- Beklenmedik teknik problemler
Bu değişiklik planların daha gerçekçi olmasını sağladı. Ekip üzerindeki baskı azaldı ve müşterilere verdiğimiz tarihler daha güvenilir hâle geldi.
3. Toplantılarda Her Projeyi Baştan Sona Konuşmayı Bıraktım
Başlangıçta yaptığımız toplantılarda her projeyi tek tek ele alıyor ve yapılan işleri ayrıntılı şekilde konuşuyorduk.
Bu yöntem çok zaman alıyordu. Üstelik toplantının sonunda hangi projenin gerçekten desteğe ihtiyacı olduğu bazen gözden kaçıyordu.
Bunun yerine standart bir durum şablonu oluşturdum. Ekip üyelerinin toplantıdan önce şu bilgileri güncellemesini sağladım:
- Proje hangi aşamada?
- Son toplantıdan sonra ne tamamlandı?
- Bir sonraki adım ne?
- İlerlemeyi engelleyen bir konu var mı?
- Alınması gereken bir karar veya ihtiyaç duyulan bir destek bulunuyor mu?
Toplantılarda artık bütün işleri anlatmak yerine sapmaları, engelleri ve alınması gereken kararları konuşmaya başladık.
Böylece toplantılar kısaldı ve gerçekten müdahale etmemiz gereken konular görünür hâle geldi.
4. Eskalasyon Yollarını Netleştirdim
Bazı sorunlar doğru kişiye ulaşmadığı için gereğinden uzun süre bekliyordu. Ekip içinde bir hata ortaya çıktığında kimin ilgileneceği veya bilgi eksikliği olduğunda kime danışılacağı her zaman net değildi.
Eskalasyon yollarını belirleyerek şu ayrımı yaptım:
- Teknik bir hata varsa ilgili sorumluya iletilecek.
- Bilgi veya deneyim desteği gerekiyorsa konunun uzmanı olan ekip üyesine danışılacak.
- Müşteri tarafında ilerlemeyi durduran bir sorun varsa konu doğrudan bana getirilecek.
- Başka bir projeyi etkileyen risk bekletilmeden görünür hâle getirilecek.
Eskalasyonun bir şikâyet mekanizması değil, işi doğru kişiye hızlı ulaştırma yöntemi olduğunu ekip içinde netleştirdim.
Bu yaklaşım sorun çözme süremizi ciddi şekilde hızlandırdı.
5. İlerleme Oranından Önce Projenin Sağlığına Baktım
Son adım olarak raporlama yöntemimizi değiştirdim.
Yalnızca işlerin yüzde kaçının tamamlandığını görmek yeterli değildi. Projenin neden yavaşladığını, hangi kararın beklendiğini ve önünde hangi risklerin bulunduğunu da bilmem gerekiyordu.
Hazırladığım raporlarda şu soruların cevabını görünür tuttum:
- Proje hangi aşamada?
- Planlanan ilerleme sağlandı mı?
- Hangi projelerde sona yaklaşıyoruz?
- Hangi projeler yavaşladı?
- Yavaşlamanın nedeni nedir?
- Yönetim veya müşteri kararı bekleyen konu var mı?
- Ekibin desteğe ihtiyaç duyduğu alan hangisi?
Bu görünüm sayesinde bütün projelerin sağlığını tek noktadan takip edebildim. Sorunları yalnızca ortaya çıktıklarında değil, ilerleme yavaşlamaya başladığında fark etmeye başladım.
Daha Fazla Çalışmak Yerine Çalışma Biçimini Değiştirmek
Çok sayıda projeyi yönetirken yaşadığım sorun, ekibin yeterince çalışmaması değildi. Sorun; önceliklerin, kapasitenin, kararların ve risklerin yeterince görünür olmamasıydı.
Projeleri kontrol altına almamı sağlayan beş değişiklik şunlardı:
- Müşteri ihtiyacına göre fazlandırma yapmak
- Kaynakları gerçek çalışma kapasitesiyle planlamak
- Toplantılarda detaylar yerine sapmaları konuşmak
- Eskalasyon yollarını netleştirmek
- Bütün projelerin sağlığını birlikte izlemek
Ekip liderliği, herkesin yaptığı her işi ayrıntılı biçimde takip etmek değildir. Ekibin doğru işe odaklanmasını sağlamak ve ilerlemeyi engelleyen konuların zamanında çözülmesine yardımcı olmaktır.