Mühendislik ve Ürün Arasındaki Veri Siloları
PM'ler ve mühendisler farklı araçlar, farklı dil ve farklı zaman çizelgeleri kullanır. Silo nasıl oluşur – ve gerçekten ne işe yarar?
By Ellis Keane · 2026-03-16
Bir noktada "ürün-mühendislik uyumu", yetkin insanların birlikte çalışırken kendiliğinden gerçekleşen bir şey olmaktan çıkıp bir iş unvanına dönüştü. Şirketler artık tüm amacı; aynı Slack çalışma alanında oturan, aynı standup toplantılarına katılan ve teorik olarak aynı hedeflere doğru çalışan iki zeki grubun birbirinin ne yaptığını gerçekten anlayabilmesini sağlamak olan özel insanlar işe alıyor. Bunu zorunlu kılan mühendislik ve ürün arasındaki veri siloları bir insan sorunu değildir. Bunlar bir araç sorunudur.
PM'ler ve mühendisler zaten yeterince iletişim kuruyor. Sorun, tamamen farklı sistemlerde çalışmaları ve bu sistemler arasında oluşan siloların yapısal olmasıdır – modern ekiplerin araç seçim mimarisine işlenmiş durumdadır. "Daha sık hizalanır" demek, araçların kendisinin birbirinden habersiz olduğu bir sorunu çözmez.
İki Farklı Gerçeklik
Burada kendi Sugarbug'ı oluşturma deneyimimizden yararlanıyorum; çünkü her gün bunu yaşıyoruz ve özgün ayrıntıların soyut versiyondan daha yararlı olduğunu düşünüyorum.
PM tarafı (bizim durumumuzda bu çoğunlukla benim) Notion'da yaşıyor. Teknik özellikler orada yazılıyor, öncelikler izleniyor, müşteri görüşmeleri kayıt altına alınıyor, özellik talepleri haftalık büyüyen listelerde katalogleniyor. Notion, "neden"in yaşadığı yer – bir şeyi neden inşa ettiğimiz, müşterinin aslında ne söylediği, belirli bir kararın arkasındaki stratejik bağlam. Dağınık, geniş ve tek bir kod satırı yazılmadan önce önemli düşüncelerin büyük bölümünün gerçekleştiği yer.
Bu arada mühendislerimiz Linear ve GitHub'da yaşıyor. Linear görevleri, sprint döngülerini, bağımlılık zincirlerini ve bloklayan issues'ları barındırıyor. GitHub ise kodu, pull request'leri ve uygulama ayrıntıları üzerine yapıcı – umarım – tartışmaların yaşandığı inceleme thread'lerini içeriyor. "Nasıl" ve "ne zaman" burada yaşıyor – bir şeyin nasıl inşa edildiği, ne zaman teslim edileceği, önünde ne var.
Her iki gerçeklik de doğru, her ikisi de gerekli; ancak birbirinden tamamen kopuklar. Aralarındaki boşluk, gereksinimlerin eskidiği ve yeniden çalışmanın birikmeye başladığı yerdir.
Mühendislik ve Ürün Arasındaki Veri Siloları Gerçekte Nasıl Oluşuyor
Bunun kasıtlı bir seçim olduğunu – yani birinin bilgileri ayrı tutmaya karar verdiğini – düşünmek cazip geliyor. Pratikte ise silo, kimsenin zarar vermeye niyetlenmediği, tamamen makul davranışlar yoluyla oluşuyor.
Bir PM Notion'da bir teknik özellik yazıyor, Slack'te mühendislik kanalına bağlantı veriyor ve teslimi tamamlanmış sayıyor. Bir mühendis teknik özelliği okuyor, üç Linear issue oluşturuyor ve inşa etmeye başlıyor. Buraya kadar her şey yolunda.
Ama sonra teknik özellik değişiyor – bir müşteri görüşmesi önceliği değiştiriyor ya da iş bağlamı gelişiyor. PM Notion belgesini güncelliyor ve Slack'e değişiklik hakkında bir not bırakıyor. Derin bir kodlama oturumunda olan mühendis saatlerce Slack mesajını görmüyor. O zamana kadar üç özelliğin ikisini eski teknik özelliklere göre inşa etmiş; Linear'daki üçüncü issue ise artık var olmayan gereksinimlere atıfta bulunuyor.
Burada kimse dikkatsiz değildi. Kimse "iletişim kurmayı başaramadı." Bilgi bir sistemde yaşadı ve iş başka bir sistemde gerçekleşti; aralarındaki bağlayıcı doku ise doğru kişi görmeden önce diğer thread'lerin altına gömülen bir Slack mesajıydı.
Bu tekrar tekrar gerçekleşiyor – her teknik özellikte, her sprint'te, her çeyrekte – ve kayma birikmeye devam ediyor. Ürünün olduğunu düşündüğü ile mühendisliğin gerçekte inşa ettiği arasındaki boşluk, doğru zamanda mesajı fark etmeye dayanan her teslimde genişliyor.
Neden "Daha İyi İletişim" Sorunu Çözmüyor
Eylem maddesinin "değişiklikleri daha proaktif şekilde iletmek" olduğu retrospektiflerde oturdum; ve (sevgiyle söylüyorum) bu, birine daha düzenli olmasını söylemenin organizasyonel karşılığıdır. Uygulanabilir görünüyor, Confluence sayfasının üretken göründüğünü sağlıyor ve soruna neden olan sistemle ilgili kesinlikle hiçbir şeyi değiştirmiyor. Aynı retro eylem maddesini şimdiye kadar üç kez çalıştırdık – kontrol ettim.
Daha iyi iletişimin mühendislik ve ürün arasındaki veri silolarını çözememesinin nedeni, iletişimin zaten gerçekleşmesidir – veriler var, kararlar alınıyor ve kayıt altına alınıyor. Yalnızca birbirinden habersiz araçlara kaydediliyor.
Notion, bir teknik özelliğin üç Linear issue'ya ayrıştırıldığını bilmiyor. Linear, bir issue'nun arkasındaki gereksinimlerin iki saat önce Notion'da değiştiğini bilmiyor. GitHub, incelenmekte olan PR'ın PM'in Notion panosunda önceliği yeni düşürülmüş bir özelliği uyguladığından habersiz. Her araç tam olarak tasarlandığı gibi çalışıyor – yalnızca birlikte çalışmak için tasarlanmamış.
"Pazartesi sabahını, ödediğiniz araçların hafta sonu sessizce gerçeklikten sapmadığını doğrulamak için harcamanın belirli bir karanlık komedisi var." attribution: Ellis Keane
Dolayısıyla olan şu: PM'ler teknik özellikler değiştiğinde Notion'daki değişiklikleri Linear'a elle yansıtıyor, mühendisler PM'lere Slack'te "bu hâlâ plan mı?" diye soruyor ve liderler Pazartesi sabahlarını kaymaları tespit etmek için panoları çapraz referanslayarak geçiriyor. Teoride birbirinden zaten haberdar olması gereken araçlar arasında elle veri senkronizasyonuna denk düşen işe haftada birkaç saat harcadığımızı izledik.
Sistematik Bir Çözüm Gerçekte Nasıl Görünür
İki araç arasında boşluk gördüğünüzde içgüdü bir köprü inşa etmektir – Zapier otomasyonu, webhook, senkronizasyon scripti. Basit, öngörülebilir iş akışları için (bir Linear issue "Bitti" durumuna geçtiğinde Notion durumunu güncelle) bu yaklaşım işe yarar.
Ancak mühendislik ve ürün arasındaki veri siloları yalnızca durumu değil, bağlamı içeriyor. PM yalnızca bir durum alanı değiştirmedi; üç Linear issue'dan ikisi için "bitti"nin ne anlama geldiğini değiştiren bir paragrafı yeniden yazdı. Basit durum webhook'ları, çoğu ekibin bir türlü fırsat bulamadığı fark mantığı ve anlamsal eşleme eklenmediği sürece gereksinim düzeyindeki değişiklikleri gözden kaçırır.
Gerçekten ihtiyacınız olan şey, araçlar genelinde veriler arasındaki ilişkileri anlayan bir yapıdır – yalnızca "bu Notion sayfası bu Linear issue'ya bağlı" değil, "teknik özelliğin bu bölümü bu issue'nun gereksinimlerini açıklıyor ve o bölüm az önce değişti." Amaç, birinin değişikliği fark edip yaymasına güvenmek yerine teknik özellik düzenlemelerini otomatik olarak etkilenen issue'larla eşleştirmektir.
Bu, bir senkronizasyon katmanı ile bilgi grafiği arasındaki farktır. Senkronizasyon katmanı araçlar arasında veri kopyalar. Bilgi grafiği, verilerin nasıl ilişkili olduğunu izler, bu ilişkiler değiştiğinde bunu algılar ve değişiklikleri bilmesi gereken kişilere iletir.
Sugarbug'ı bu şekilde çalışacak biçimde inşa ediyoruz – PM'lerin ve mühendislerin zaten kullandığı araçları (Notion, Linear, GitHub, Slack, Figma) teknik özellikler, görevler, kod ve görüşmeler arasındaki ilişkileri koruyan bir bilgi grafiğine bağlayarak. Hâlâ erken aşamadayız (dürüstçe söylemek gerekirse, anlamsal fark algılamasını ölçekte güvenilir kılmak için henüz pek çok şeyi çözemedik), ancak çekirdek grafik çalışıyor ve zaten yeniden çalışmaya dönüşecek teknik özellik kayma durumlarını yakaladı.
Mühendislik ve ürün arasındaki veri siloları, insanlar kötü iletişim kurduğu için değil araçlar yapısal olarak bağlantısız olduğu için oluşur. Çözüm daha fazla iletişim kanalı eklemek değil, verileri ilişki düzeyinde birbirine bağlamaktır.
Bu Hafta Neler Yapabilirsiniz
"Tek cevap Sugarbug kullanmaktır" numarası yapmayacağım. Şu anda kullandığınız araçlarla ürün-mühendislik veri silosunun en kötü etkilerini azaltmak için hemen yapabileceğiniz şeyler var.
Çapraz referansları açık, çift yönlü ve sahipli yapın. Her Notion teknik özelliğinin alt kısmında, onun oluşturduğu issue'lara bağlanan bir "Linear Issues" bölümü olmalı; her Linear issue da kaynak teknik özelliğine geri bağlanmalı. Teknik özellik başına çapraz referansa sahip çıkacak tek bir kişi atayın – tüm ekip değil, adı belli olan bir kişi. "Herkes sorumlu" versiyonunu denedik ve (tahmin edilebileceği üzere) kimse sorumlu olmadı. Bağlantılar zamanla kayacaktır, ancak adı belli bir sahip olması, kayma fark edildiğinde ping atılabilecek birinin var olduğu anlamına gelir.
Hatırlatıcıyla değil, tetikleyiciyle bir "teknik özellik değişikliği" ritüeli oluşturun. Bir teknik özellik önemli ölçüde değiştiğinde (yazım hataları değil – gerçek gereksinim değişiklikleri), PM Notion sekmesini kapatmadan önce bağlantılı Linear issue'larını günceller. Sonra değil, "fırsat bulduğumda" değil – sekme kapanmadan önce. Etkilenen her issue'ya düşülecek yorum tek satır olmalı: ne değişti, güncellenen bölüme bağlantı ve issue'nun kabul kriterlerinin hâlâ geçerli olup olmadığı. Güncellemeyi fiziksel bir eyleme (sekmeyi kapatmak) bağlamanın, herkesin hafızasına güvenmekten daha iyi işlediğini gördük; çünkü hafıza siloyu başta yaratan şeyin ta kendisi.
15 dakikalık Cuma öncelik eşleştirme kontrolü yapın. Bir kişi (haftalık dönüşümlü) PM'in Notion'daki ilk 5 önceliğini ve mühendislik sprint'inin Linear'daki ilk 5'ini yan yana çıkarır. Soru "bunlar aynı mı?" değil – aynı olmayacaklar ve bu gayet normal. Soru şu: "bunlardan herhangi biri aktif olarak diğeriyle çelişiyor mu?" PM'in 1 numaralı önceliği sprint'te hiçbir yerde yer almıyorsa, bu Pazartesi konuşulacak mesele, bir durum güncellemesi değil.
Bunlar elle yapılan süreçlerdir ve raf ömrü sınırlıdır. Beş mühendis ve iki PM ile sıkıcıdır ama işe yarar. On beş mühendis, üç PM ve Figma'yı karışıma katan bir tasarım ekibiyle, araçlar arası ilişkiler kimsenin elle takip edemeyeceği hızla çoğalır. Ama size en kötü ürün-mühendislik uyum boşluklarınızın gerçekte nerede olduğunu öğretirler – ve bu tanısal değer, sonunda her şeyi otomatikleştirseniz bile çabaya değer.
İster uzun vadeli çözüm Sugarbug olsun ister başka bir şey (biz açıkça doğru şeyi inşa ettiğimizi düşünüyoruz, ancak taraflıyım), ürün yönetimi mühendislik işbirliği sorunu ancak araçların kendileri anlamsal düzeyde bağlandığında ve insanlar uygulamalar arasında bağlam taşımak yerine karar vermeye odaklanabildiğinde çözülür.
Elle yapılan çapraz referanslarınız tutuyorsa, olduğu sürece bu yönteme güvenin. İletişim konusunda hep aynı retrospektif eylem maddelerine dönüyorsanız, sorun insanlarınız değildir. Veri mimarinizdir.
Notion, Linear, GitHub ve Slack'i tek bir bilgi grafiğine bağlayın – böylece teknik özellik değişiklikleri doğru mühendislere otomatik olarak ulaşır.
Q: Sugarbug'ı bir ürün-mühendislik ekibi için kurmak ne kadar sürer? A: İlk bağlantı araç başına birkaç dakika alır – Linear, GitHub, Notion, Slack ve Figma'yı OAuth aracılığıyla doğrularsınız ve Sugarbug hemen bilgi grafiği oluşturmaya başlar. Mevcut verilerinizi alıp teknik özellikler, issue'lar ve görüşmeler arasındaki ilişkileri eşleştirmeye başladığında grafik, bir iki gün içinde anlamlı biçimde kullanışlı hâle gelir. Katılım akışını hâlâ iyileştiriyoruz, ancak hedefimiz hesaplarınızı bağlamanın ötesinde herhangi bir yapılandırma gerektirmemesi.
Q: Sugarbug Linear, Notion veya mevcut araçlarımızın herhangi birinin yerini alıyor mu? A: Hayır. Sugarbug mevcut araçlarınızın yanında yer alır ve onları bağlar – hiçbirinin yerini almaz. PM'leriniz Notion'da teknik özellik yazmayı sürdürür, mühendisleriniz Linear ve GitHub'da çalışmayı sürdürür; Sugarbug ise bağlam aktarım sırasında kaybolmayacak biçimde aralarındaki ilişkileri korur. Onu halihazırda kullandığınız araçlar arasındaki bağlayıcı doku olarak düşünebilirsiniz.
Q: Sugarbug bir Notion teknik özelliğinin değiştiğini algılayıp doğru mühendisleri uyarabilir mi? A: Bu, inşa ettiğimizin temel parçası. Notion'da bir teknik özellik değiştiğinde Sugarbug hangi Linear issue'larının ona bağlı olduğunu belirler ve değişikliği bu issue'lar üzerinde çalışan mühendislere iletir. Anlamsal algılama kısmı üzerinde hâlâ yineleme yapıyoruz (hangi değişikliklerin önemli, hangilerinin yalnızca biçimsel olduğunu belirliyoruz), ancak araçlar arası bağlantı ve temel değişiklik algılama çalışıyor.
Q: Bu problem için senkronizasyon aracı ile bilgi grafiği arasındaki fark nedir? A: Senkronizasyon aracı uygulamalar arasında durum değişikliklerini kopyalar – bir Linear issue "Bitti" olduğunda bir Notion onay kutusunu güncelle. Bilgi grafiği verilerin nasıl ilişkili olduğunu izler: bu teknik özellik bu üç issue'nun gereksinimlerini açıklıyor ve kabul kriterleri değişti, bu da henüz teslim edilmemiş iki issue'yu etkiliyor. Fark, değişiklikler yalnızca durum düzeyinde değil anlamsal olduğunda en çok önem taşır.
Q: Ürün-mühendislik uyumu bir iletişim sorunu mu yoksa veri sorunu mu? A: Deneyimimize göre neredeyse her zaman iletişim sorunu olarak yanlış teşhis edilen bir veri sorunudur. Ekipler iletişim kuruyor – yalnızca bunu birbirinden habersiz araçlar aracılığıyla yapıyorlar. Bu araçlar arasındaki veri akışını düzeltmek, hiçbir retro'nun ya da senkronizasyon toplantısının çözemediği uyum sorunlarını çözme eğiliminde.