Ekip Kurma - Team Building ve Ana Hedef Planlaması

Ana Hedefler
Ana hedefler yani proje takvim hedefleri yönetim tarafından konulur.
Örneğin A işinin 3 ayda bitmesi gerek.

Bu hedeflerin çok net olması gerekir. Hedefler değişirse, neden değiştiği ve yeni hedefin ne olduğunun anlaşılacak bir şekilde tekrarlanması gerekir. Bazı projelerde, ana hedefler değiştirildikten sonra (revize etmek) ekip yeterince bilgilendirilmiyor.

Örneğin kabul testine girecek bir projede, problemlerin çözülmesi için önce Mayıs ayı hedef konulduğunu gördüm. Daha sonra yetişmeyeceği anlaşıldığı için, Temmuz, daha sonra da Ağustos ayına hedef konuldu, ancak ekip yeterince bilgilendirilmediği için işlerin ne zaman bitmesi gerektiği konusu anlaşılmadı.

Planlama ve Tahmin
Planlamanın ilk ayağı tahmin.
Tahmini yapabilmek için işin ne olduğunun detaylarıyla anlaşılması en önemli husus.
Daha sonra işin diğer iş parçacıklarına olan bağımlılıklarına dikkat etmek gerekiyor.
İşi kimin/kimlerin yapacağı ise bence en alt sırada olan husus.

1. Bazı projelerde tahmini, işi yapacak kişinin verdiğini gördüm.
2. Bazı projelerde ise tahmini, takım liderinin yaptığını ve yapacak kişiye uygun olup olmadığını sorduğunu gördüm.

Her iki yöntem de de bence kötü. Planlama oyununda yapılan tahminler ortak akıl ile yapıldığı için çok daha iyi sonuçlar veriyor.

Planlama ile ilgili gördüğüm kötü örnekler şöyle

- İşi yapacak insan takım liderinin neden bahsettiği konusunda fikir sahibi olmadığı için ses çıkaramadı.
- Takım liderinin işi planlarken elinde sadece işin ismi vardı. Her zaman kullandığı şablonu kullanarak plana sadece X Design, X Coding, X Unit Testing, X Bug Fix başlıklarını yazdı ve yanlarına isim + gün bilgisi girdi.
- Takım liderleri işi yeterince küçük parçalara ayırmadığı için işin yetişmediğini gördüm.
- Takım lideri işin bağımlı olduğu diğer iş kırılımlarını hesaba katmadığı için tümleşim bir türlü olmadı ve iş kapanamadı. Bir projede yeni bir API sağlanması gerekiyordu. Takım lideri bu API'yi kendi üzerine aldı ancak kendisine bu işi planlamadı ve bitiremedi.

Yineleme (Iteration) Planı
Tahminler belli bir süre için yapılır. Örneğin 3 hafta. Bazı şirketlerde üst yönetim yineleme planlamasına önem veriyor ve sapmaları (erken bitirme, geç kalma) dahi sorguluyor. Bazı şirketlerde ise bu tür planlara kabaca bakılıyor. Sapmalara ses çıkarılmıyor.

Gördüğüm kötü örnekler şöyle

- Planlama SAP uygulamasına girildi. Yineleme başladıktan sonra tahminin yanlış olduğu ve işin aslında 3 aşamada yapılması gerektiği anlaşıldı. SAP onaylandığı - yani bütçe verildiği - için plan değiştirilemez denildi. Takım lideri işin ismini X Phase 1 olarak değiştirdi. Bir sonraki yinelemeye X Phase 2 ve X Phase 3 ismini verdi.

- Yineleme başladıktan sonra kullanılması düşünülen bir kütüphanenin aslında sadece Linux'ta çalıştığı anlaşılınca iş parçası 3 yineleme sonrasına atıldı. Onun yerine alelacele başka bir şey planlandı.

- Gereksinimleri yazan kişinin aslında işi anlamadığı ve geliştiricinin soruları karşısında yanlış tasarım yaptığı anlaşıldı. İş baştan yapılmak üzere bir sonraki yinelemeye ötelendi.

Planın Uygulanması

Gördüğüm kötü örnekler şöyle

- Takım lideri hiçbir teknik şeye karışmadı ve herkes kendi tasarımını yapıp kendi kodladı. Tümleşim için diğer bileşenlerde yeni API'ler geliştirdi veya mevcut API'leri yine kendine göre değiştirdi. Bu aslında iletişim eksikliği. Yani ekip olamama işareti.