- 100’den fazla büyük teknoloji şirketi üzerinde yapılan anketin sonucu
- Büyük teknoloji şirketlerinde proje yönetimi yaklaşımı özetlenirse ⇨ "Duruma göre değişir (It Depends)"
- Çoğunda sabit bir metodoloji ya da çalışma biçimi yok; ekipler kendilerine uyanı seçiyor
- Halka açık ya da yatırım almış şirketlerde özel bir PM bulunmasından duyulan memnuniyet düşüktü; yatırım almamış şirketlerde ise memnuniyet yüksekti
- Ekip özerkliği ile memnuniyet arasında yüksek korelasyon var
- Sorun yaşayan ekiplerde asıl mesele metodoloji değil; vizyonun iyi gösterilememesi, şeffaflık eksikliği ya da araç yetersizliği gibi nedenlerdi
- JIRA için yanıtların çoğu olumsuzdu
- İyi çalışmayan proje yönetimi yaklaşımları
- Mühendisler proje süresinin tahmin edilmesine katılmıyor
- Özel bir PM olsa bile gereksinimler değişiyor
- Başarısız proje yönetimi yaklaşımını değiştirme özerkliği olmayan ekipler düşük memnuniyet bildirdi
- Büyük teknoloji şirketlerinin projeleri yürütme biçimi
- Projelerin çoğuna mühendisler liderlik ediyor
- Sabit bir metodoloji yok ve ekipler özgürce seçim yapabiliyor
- Ekip düzeyindeki projelerde özel bir Project Manager yok. Birden fazla ekibi ya da şirket genelini kapsayan büyük projelerde Technical Program Manager bulunuyor. Uber’de oran yaklaşık 1:50
- Birinci sınıf geliştirici araçları sağlanıyor ve bu, kısa iterasyon döngülerinde büyük etki yaratıyor
Projeleri etkileyen büyük teknoloji şirketlerinin organizasyon yapısı
- Temel ortam
- Mühendisler ve ekipler özerkliğe sahip
- Bilinçsiz kaynaklar (fabrika işçileri) değil, meraklı problem çözücüler
- Şirket içindeki veri, kod ve dokümantasyon şeffaf biçimde açık
- Mühendisler iş tarafına ve iş metriklerine de maruz kalıyor
- Hiyerarşik iletişim yerine mühendisler arası iletişimle daha hızlı hareket ediliyor
- Daha az hayal kırıklığı yaratan bir geliştirici deneyimine yatırım yapılıyor
- Daha yüksek kaldıraçla gerekçelendirilen daha yüksek ücretler
- Daha iyi yetenekleri işe alma imkânı
- Yetkilendirilmiş ve özerk ekipler
- Net sahipliğe sahip ekipler
Product Manager evet, Project Manager hayır
- Ürün yöneticisinin rolü, "What game we're playing" ve "How we're going to play it" konularını belirlemektir
- Birçok durumda, büyük teknoloji şirketlerindeki ürün yöneticileri Project Management yapmaz
- Uygulamadan ekip sorumludur ve çoğu zaman proje yönetimini yürütme sorumluluğu teknik yöneticide (ekip liderinde) olur
- Yetkilendirilmiş ve özerk ekiplerde proje yönetiminin tepeden inme olması nadirdir ⇨ herkes birlikte yapar
- Özel bir Project Manager olmadığında merak edilenler
- Ekip düzeyindeki projeler: süreci basitleştirmek ve kişiler arası ilişkileri güçlendirmek
- Karmaşık projeler: büyük teknoloji şirketleri Technical Program Manager (TPM) kullanır
- Özel Program Manager / Project Manager rolleri gerçekten vardır. Genelde dış paydaşlar, müşteriler ve uzun vadeli yürütme planlarıyla bağlantılıdır
- Ürün odaklı ortamlar ve neden scrum yapılmadığı
- Sprint bazlı yürüyen scrum, hızlı dağıtım yapılan ortamlara pek uymaz
- Altyapı ve geliştirici araçları, scrum aktivitelerinin büyük kısmının yerini alır
- Büyük teknoloji şirketleri, altyapı ve geliştirici araçlarına yapılan yatırımın üretkenliği artırdığını fark etti
- Facebook, Google, Netflix gibi şirketler scrum kullanmıyor. Neden?
- Yetenekli ve özerk insanlar bu tür yapılara daha az ihtiyaç duyar
- Güçlü ekipleri nasıl çalışacakları konusunda serbest bırakırsanız, onlardan daha fazla kaldıraç elde edebilirsiniz
- Mühendislik organizasyonunu ölçeklemek, ekip düzeyi süreçlerin çok ötesine geçer
- Ama bu, herkesin büyük teknolojiyi taklit edip scrum yapmaması gerektiği anlamına gelmez
→ Scrum kullanmanın doğru olduğu durumlar vardır ve daha yüksek üretkenlik de sağlayabilir
- Kitchen sink ekipleri: tek bir ekibin her şeyi çözmek zorunda olduğu durumlar (erken aşama startup’lar)
- Yeni bir ekip oluşturulurken
- Birkaç haftada bir dağıtım yapılıyorsa
- Standart biçimde proje ilerleme raporlamasının zorunlu olduğu durumlar
Ekip nasıl yönetilmeli?
- Tekrarlanan değişiklikler, 'big bang' değişikliklerden her zaman daha iyidir
- Birine balık vermektense balık tutmayı öğretmek daha zordur
- Directing, mentoring ve coaching’in her birinin kendi kullanım alanı vardır
- Directing, onların kendi başlarına yapabilecekleri ama o anda yapamadıkları durumda destekleyici biçimde mikro yönetim uygulamaktır
- Karar vermek için gereken kişi sayısı ne kadar azsa karar o kadar hızlı alınır
- Raporlamaya göre optimize etmek, daha düşük güven ortamına göre optimize etmek demektir
- Danışmanlar ölçülmesi kolay çıktılar sunmaya yatkındır; çünkü kendi değerlerini kanıtlamanın en kolay yolu budur
- Doğrudan rakiplerden öğrenmek yeterince değer görmüyor
- En iyi mühendislerin bazıları mikro yönetilmektense işi bırakmayı tercih eder
8 yorum
"JIRA hakkında verilen yanıtların çoğu olumsuzdu"
Bence herhangi bir formatta issue yönetimi yapmak gerekli; ben de JIRA’ya olumsuz bakıyordum, bu yüzden bilinçli olarak başka araçları denedim (
github issues, trello, asana vb.)Ama eski dostun yerini başkası tutmuyor; sonuçta yine JIRA’ya geri döndüm...
Yine de daha iyi bir yöntem olup olmadığını düşünmeye devam ediyorum.
Hangi açıdan eskilerin daha iyi olduğunu düşünüyorsunuz?
Ben YouTrack'ı seviyorum. JetBrains'in yaptığı bir PM aracı; ihtiyacım olan kadarıyla projeleri yönetebildiğimi gördüm.
Ekibimiz Linear'a geçti ve genel memnuniyetimiz belirgin şekilde arttı. Bir göz atmanızı tavsiye ederim.
Sanırım bu ürün, https://linear.app/. İlgi çekici görünüyor.
Evet, benim avantaj olarak gördüğüm noktalar şunlar:
Benim hissiyatım bu kadar.
Birinci sınıf geliştirici araçları ne yapar?
Orijinal hissiyatı korumak için olduğu gibi aldım.
Şu an itibarıyla bir organizasyonun sunabileceği en iyi geliştirici araçları olarak görülebilir.