Ürün yöneticileri ve mühendisler arasındaki sürtüşme, yazılım ekiplerindeki en öngörülebilir sorunlardan biri ve sürekli olarak yanlış yönetilen sorunlardan biridir.
Proje Yöneticileri, mühendislerin alternatif sunmadan her şeyi geri çevirdiğini düşünüyor. Mühendisler, PM'lerin teknik karmaşıklığı anlamadan son teslim tarihlerine ve kapsamlara bağlı kaldıklarını düşünüyor. Her iki taraf da genellikle diğer tarafın kör noktaları konusunda haklıdır ve her ikisi de diğer tarafın niyeti konusunda genellikle yanılıyor.
Standart sprint retrospektifleri, takım sınırları içinde kalma eğiliminde oldukları için bunu nadiren düzeltir. Mühendisler mühendislerle retro. PM'ler PM'lerle bilgi alışverişinde bulunur. Fonksiyonlar arası gerginlik, bir planlama toplantısında veya kaçırılan bir teslim tarihi sırasında patlak verene kadar birikir.
Ürün mühendisliğine özel bir retrospektif, konuşmayı kavgacı olmaktan çıkarıp üretken kılan bir yapıyla her iki bakış açısını da aynı odaya yerleştirir.
Tekrarlanan Dört Sürtünme Noktası
Retrospektifi tasarlamadan önce gerilimleri dürüstçe adlandırmak yardımcı olur. Çoğu takımda dört kategoriye ayrılırlar.
1. Açık Görünen Ancak Öyle Olmayan Gereksinimler
Bir Proje Yöneticisi, kapsamlı olduğunu düşündüğü bir spesifikasyon yazar. Bir mühendis bunu okur ve on beş sorusu olur. Başbakan, mühendisin kusurları araştırdığını düşünüyor. Mühendis, Başbakanın uç durumları düşünmediğini düşünüyor.
Asıl sorun her iki tarafta da nadiren tembelliktir. Proje Yöneticileri ve mühendisler ürünler hakkında farklı düşünüyor. Proje Yöneticileri kullanıcı yolculuklarını ve iş sonuçlarını düşünür. Mühendisler veri akışları, durum yönetimi ve arıza modları üzerinde düşünürler. Bir açıdan eksiksiz olan bir spesifikasyon, diğer açıdan boşluklarla doludur.
2. Hız ve Kalite
ÖM'ler zamanında teslimattan sorumludur. Üretimde işler bozulduğunda mühendisler sorumludur. Bu teşvikler birbirini zıt yönlere çekiyor ve ikisi de yanlış değil.
Çatışma, kapsamın daraltılması, test kapsamı, kod incelemesinin kapsamlılığı ve teknik kısayolların kullanılıp kullanılmayacağı konusundaki tartışmalar olarak ortaya çıkıyor. Bu ödünleşimler hakkında açık bir konuşma yapılmazsa, her iki taraf da diğerinin neyin önemli olduğunu umursamadığını varsayar.
3. Teknik Borç
Mühendisler borcun biriktiğini görüyor ve bunu çözmek için zaman istiyor. Proje Yöneticileri, kullanıcılara yönelik özelliklerin biriktiğini görüyor ve müşterilerin göremediği işleri haklı çıkarmakta zorlanıyor. Sonuç: Borç, olaylara neden olmaya başlayıncaya kadar ertelenir ve bu noktada herkes sorunun daha önce halledilmesi gerektiği konusunda hemfikir olur.
4. Tahminler ve Tahmin Edilebilirlik
PM'lerin zaman çizelgelerini paydaşlara iletmesi gerekir. Mühendisler tahminlerde bulunmaktan kaçınırlar çünkü ne kadar belirsizliğin mevcut olduğunu bilirler. Başbakan "taahhüt vermek istemiyorum" ifadesini duyar ve mühendis "sadece bana duymak istediklerimi söyle" ifadesini duyar. Her iki yorum da doğru değil.
Retrospektifi Ayarlama
Bunu üç ayda bir veya büyük sürümlerden sonra çalıştırın. Aylık çok sık; kalıpların gelişmesi için zamana ihtiyaç var.
Kimler katılır: Ürün yöneticileri, teknoloji liderleri ve kıdemli mühendisler. Grubu 6-10 kişiyle tutun. Grup daha büyükse sohbet performansa dayalı hale gelir.
Süre: 90 dakika. İşlevler arası geriye dönük incelemeler, aynı ekiple yapılanlardan daha uzun sürer çünkü yalnızca sorunları yüzeye çıkarmak için değil, ortak anlayış oluşturmak için de zamana ihtiyacınız vardır.
Kolaylaştırma: Tarafsız bir kolaylaştırıcı kullanın; ideal olarak ekipte Başbakan veya mühendis olmayan biri. Bir mühendislik yöneticisi, bir saldırı ustası veya başka bir ekipten biri iyi çalışıyor. Kolaylaştırıcının görevi, konuşmanın tartışmaya dönüşmesini önlemek ve her iki tarafın da dinlendiğini hissetmesini sağlamaktır.
Çalışan Bir Yapı
1. Bölüm: İkili Perspektif Koleksiyonu (20 dakika)
PM'lerin ve mühendislerin bağımsız olarak aynı üç soruyu yanıtlayan kartlar yazmasını sağlayın:
- Bu çeyrekteki işbirliğimizde neler iyi sonuç verdi?
- Sürtünme bizi nerede yavaşlattı?
- Karşı tarafın neyi daha iyi anlamasını istersiniz?
Üçüncü istem önemli olanıdır. Normalde dile getirilmeyen varsayımları ve hayal kırıklıklarını gün yüzüne çıkarıyor.
Tüm kartları anonim olarak toplayın. Bu önemlidir; insanlar, özellikle işlevler arası gerilimler hakkında, adları anılmadığında daha dürüst bir şekilde yazarlar.
Bölüm 2: Tema Tartışması (40 dakika)
Kartları temalara göre gruplayın. Yaygın olanlar şunlardır: gereksinimlerin netliği, tahmin süreci, önceliklendirme kararları, iletişim boşlukları ve teknik borç yönetimi.
Her tema için kimin haklı olduğunu tartışmanın cazibesinden kaçının. Bunun yerine şunu sorun:
- Her iki taraf da ne için optimizasyon yapıyor? (Genellikle her iki tarafın da gerilimli meşru hedefleri vardır.)
- Akt verme işlemi nerede bozuluyor? (Sürtüşmelerin çoğu rollerin içinde değil, aralarındaki sınırlarda meydana gelir.)
- Her iki tarafta hangi bilgiler eksik? (Birçok çatışma aslında gizlenmiş bilgi asimetrileridir.)
Bölüm 3: Özel Anlaşmalar (30 dakika)
Belirsiz niyetlerle ayrılmayın. Her iki tarafın da taahhüt ettiği belirli çalışma anlaşmalarıyla ayrılın.
İyi çalışma anlaşmaları şunlardır:
- Gözlemlenebilir -- Bunların olup olmadığını anlayabilirsiniz.
- İki taraflı -- Yalnızca bir tarafın diğerinden taleplerde bulunması değil, her iki taraf da bir şeyleri değiştirir.
- Zaman sınırlamalı -- Bunları üç ayda bir deneyin ve değerlendirin.
İşe yarama eğiliminde olan anlaşma örnekleri şunlardır:
Gereksinimlerin netliği için: "Özellikle uç durumları ve teknik kısıtlamaları belirlemek amacıyla, herhangi bir özellik spesifikasyonu daha geniş bir ekiple paylaşılmadan önce Proje Yöneticileri ve teknoloji liderleri 30 dakikayı birlikte geçirecek."
Tahmin için: "Mühendisler tek noktalı tahminler yerine aralık tahminleri (en iyi durum / olası / en kötü durum) sağlayacak ve Proje Yöneticileri yalnızca en iyi durum yerine aralığı paydaşlara iletecek."
Teknik borç için: "Her sprint kapasitesinin %20'si mühendislik öncelikli çalışmalara ayrılmıştır. Proje Yöneticileri bu kapasiteyi ayırmaz ve mühendislerin bireysel öğeleri gerekçelendirmeleri gerekmez, ancak mühendisler zamanın neye harcandığına dair üç aylık bir özet paylaşır."
Kapsam tartışmaları için: "Kapsamın daraltılması gerektiğinde, Proje Yöneticisi neyin kesileceğini, mühendis ise nasıl basitleştirileceğini önerir. Karar vermeden önce her iki seçenek de tartışılır."
Zor Konuşmalarla Başa Çıkmak
Bazı konular, işlevler arası retrospektif çalışmaları sürekli olarak raydan çıkarıyor. Bunları nasıl halledeceğiniz aşağıda açıklanmıştır.
"Teknik borç için asla vaktimiz olmuyor." Teknik borcun önemli olup olmadığını tartışmayın. Bunun yerine şunu sorun: Mevcut borcun maliyeti nedir? Mühendisler belirli olaylara, yavaşlamalara veya geliştiricilerin borcun neden olduğu sorunlara işaret edebilirse, konuşma soyuttan somuta doğru kayar. Proje Yöneticileri kod kalitesine yönelik soyut çağrılara değil, etki verilerine yanıt verir.
"Gereksinimler değişmeye devam ediyor." Gereksinimler, pazarın değişmesi, kullanıcı geri bildirimlerinin gelmesi ve paydaşların önceliklerinin değişmesi nedeniyle değişir. Sorun gereksinimlerin değişip değişmeyeceği değil, değişikliklerin nasıl iletildiği ve sürecin ne kadar geç geldiğidir. Sürece odaklanın: Geliştirmenin hangi noktasında kapsamın donmuş olduğu düşünülmelidir? Bu noktadan sonra değişikliklerin iletilme yolu nedir?
"Mühendislik her zaman hafife alır." Bunu tersine çevirin: Ekip tahmin doğruluğunu zaman içinde takip ediyor mu? Değilse başlayın. Birkaç veri akışından sonra konuşma suçlamalardan kalıplara doğru ilerliyor. Belki ekip sürekli olarak belirli bir çalışma türünü (entegrasyonlar, geçişler) hafife alıyor ve diğerleri konusunda doğru davranıyor olabilir. Bu işlem yapılabilir.
"Proje Yöneticileri bunun ne kadar karmaşık olduğunu anlamıyor." Bu genellikle doğrudur ve karmaşıklığı görünür kılmak aynı zamanda mühendisin görevidir. Bir mühendis "bu zor" derse ve Başbakan "bu zor" diye duyarsa hiçbir şey değişmez. Mühendis "bunun için üç hizmette değişiklik yapılması, bir veritabanı geçişi yapılması gerekiyor ve geçişin başarısız olması durumunda kesinti riski var" derse, Başbakan aslında bu ödünleşim hakkında mantık yürütebilir.
Güzellik Zamanla Nasıl Görünür?
Bu retrospektiflerden üç veya dördünün ardından somut değişiklikler görmelisiniz:
- PM'ler ve teknoloji liderlerinin daha erken uyum sağlaması nedeniyle sprint planlamasında daha az sürpriz
- Pasif-agresif karşıtlıklar yerine uzlaşmalar hakkında daha dürüst konuşmalar
- Gereksinimler geliştirme başlamadan önce her iki açıdan da araştırıldığı için yeniden çalışma azaltıldı
- Teknik borç, krize neden olana kadar ertelenmek yerine aşamalı olarak ele alınıyor
- Ekip geçmiş performansa göre ayarlama yaptığı için tahminler daha doğru hale geliyor
Amaç, ürün ile mühendislik arasındaki gerilimi ortadan kaldırmak değildir. Bazı gerginlikler sağlıklıdır; bu, her iki tarafın da önemli olanı savunduğu anlamına gelir. Amaç, bu gerilimi yıpratıcı değil üretken hale getirmektir.
NextRetro'yi ücretsiz deneyin -- Anonim kart toplama ve yapılandırılmış tartışma iş akışlarıyla işlevler arası retrospektifleri kolaylaştırın.
Son Güncelleme: Şubat 2026
Okuma Süresi: 7 dakika
