Her yerde veriler, hiçbir yerde hizalama: hangi gösterge tabloları yanlış oluyor ve neden bir veri ürün yöneticisine ihtiyacınız var

Son on yılda şirketler milyarlarca veri altyapısına harcadı. Petabyte ölçekli depolar. Gerçek zamanlı boru hatları. Makine Öğrenimi (ML) Platformları.

Ve yine de – operasyonlarınıza geçtiğimiz hafta neden arttığını sorun ve muhtemelen üç çelişkili gösterge panosu alacaksınız. Finansta, atıf sistemleri arasında performansı uzlaştırmasını isteyin ve “Kime sorduğunuza bağlı” duyacaksınız.

Gösterge tablolarında boğulan bir dünyada, bir gerçek ortaya çıkmaya devam ediyor: veriler sorun değil – ürün düşüncesi.

“Hizmet Olarak Veri “‘nin sessiz çöküşü

Yıllarca, iç danışmanlıklar gibi faaliyet gösteren veri ekipleri-reaktif, bilet tabanlı, kahraman güdümlü. Bu “hizmet olarak veri” (DAAS) modeli, veri istekleri küçük ve danger düşük olduğunda iyiydi. Ancak şirketler “veri odaklı” hale geldikçe, bu mannequin kendi başarısının ağırlığı altında kırıldı.

Airbnb al. Metrik platformunun piyasaya sürülmesinden önce, ürün, finans ve OPS ekipleri kendi metrik versiyonlarını şunlar aldı:

• Geceler rezerve edildi
• Aktif kullanıcı
• Mevcut liste

Basit KPI’lar bile filtreler, kaynaklar ve kimin sorduğu tarafından değişti. Liderlik incelemelerinde, farklı ekipler farklı sayılar sundu – bu da metriği hangi eylemden ziyade “doğru” olan argümanlarla sonuçlandı.

Bunlar teknoloji başarısızlıkları değil. Bunlar ürün arızaları.

Sonuçlar

• Veri güvensizliği: Analistler ikinci olarak tahmin edilir. Gösterge tabloları terk edilir.
• İnsan yönlendiricileri: Veri bilimcileri, içgörü oluşturmaktan daha fazla tutarsızlık açıklamak için daha fazla zaman harcıyorlar.
• Gereksiz boru hatları: Mühendisler, ekipler arasında benzer veri kümelerini yeniden inşa eder.
• Karar sürükleme: Liderler tutarsız girdiler nedeniyle eylemi geciktirir veya görmezden gelir.

Çünkü veri güveni bir ürün problemidir, teknik değil

Çoğu veri lideri veri kalitesi sorunu olduğunu düşünüyor. Ancak daha yakından bakın ve bir veri güveni sorunu bulacaksınız:

• Deney platformunuz, bir özelliğin elde tutulmasını incittiğini söylüyor – ancak ürün liderleri buna inanmıyor.
• OPS, yaşanmış deneyimleriyle çelişen bir gösterge paneli görür.
• İki takım aynı metrik adını kullanır, ancak farklı mantığı kullanır.

Boru hatları çalışıyor. SQL ses. Ama hiç kimse çıktılara güvenmiyor.

Bu bir ürün hatası, mühendislik değil. Çünkü sistemler kullanılabilirlik, yorumlanabilirlik veya karar verme için tasarlanmamıştı.

Gir: Veri Ürün Yöneticisi

En iyi şirketlerde yeni bir rol ortaya çıktı – Veri Ürün Yöneticisi (DPM). Genelci PMS’den farklı olarak, DPM’ler kırılgan, görünmez, çapraz işlevsel arazide çalışır. İşleri gösterge panolarını göndermek değil. Bu, doğru insanların bir karar vermek için doğru zamanda doğru anlayışa sahip olmasını sağlamaktır.

Ancak DPM’ler boru verilerini gösterge tablolarına veya küratörlük masalarına bırakmaz. En iyileri daha ileri gider: “Bu aslında birisinin işini daha iyi yapmasına yardımcı oluyor mu?” Diye soruyorlar. Başarıyı çıktılar değil, sonuçlar açısından tanımlarlar. “Bu sevk edildi mi?” Ancak “Bu, birinin iş akışını veya karar kalitesini önemli ölçüde iyileştirdi mi?”

Uygulamada, bu şu anlama geliyor:

• Sadece kullanıcıları tanımlamayın; onları gözlemleyin. Ürünün nasıl çalıştığına inandıklarını sorun. Yanlarında otur. İşiniz bir veri kümesi göndermek değil – müşterinizi daha etkili hale getirmektir. Bu, ürünün çalışmalarının gerçek dünya bağlamına nasıl uyduğunu derinden anlamak anlamına gelir.
• Kendi kanonik metriklerine sahip olun ve onlara versiyonlanmış, belgelenmiş, yönetilen API’ler gibi davranın ve 10 milyon dolarlık bütçe kilidi veya Go/Go ürün lansmanları gibi sonuç kararlarına bağlı olduklarından emin olun.
• İç arabirimler oluşturun – özellik mağazaları ve temiz oda API’leri gibi – altyapı olarak değil, sözleşmeler, SLA’lar, kullanıcılar ve geri bildirim döngüleri ile gerçek ürünler olarak.
• Sofistike hisseden ancak önemli olmayan projelere hayır deyin. Hiçbir ekibin kullandığı bir veri boru hattı, ilerleme değil, teknik borçtur.
• Dayanıklılık için tasarım. Birçok veri ürünü kötü modellemeden değil, kırılgan sistemlerden başarısız: belgesiz mantık, lapa boru hatları, gölge sahipliği. Gelecekteki benliğinizin – ya da değiştirilmenizin – measurement teşekkür edeceği varsayımıyla inşa edin.
• Yatay olarak çözün. Alana özgü PM’lerin aksine, DPM’ler sürekli yakınlaştırmalıdır. Bir takımın ömür boyu değeri (LTV) mantığı başka bir takımın bütçe girişidir. Görünüşte küçük bir metrik güncellemenin pazarlama, finans ve operasyonlar arasında ikinci dereceden sonuçları olabilir. Bu karmaşıklığı kabul etmek iştir.

Şirketlerde DPM’ler, dahili veri sistemlerinin nasıl oluşturulduğunu, yönetildiğini ve benimsendiğini sessizce yeniden tanımlıyor. Verileri temizlemek için orada değiller. Organizasyonların tekrar inanmasını sağlamak için oradalar.

Neden bu kadar uzun sürdü

Yıllarca ilerleme için faaliyeti yanlış anladık. Veri mühendisleri boru hatları oluşturdu. Bilim adamları modeller inşa ettiler. Analistler panolar inşa ettiler. Ama kimse sormadı: “Bu içgörü aslında bir iş kararını değiştirecek mi?” Ya da daha kötüsü: sorduk, ama kimse cevaba sahip değildi.

Çünkü yönetici kararları artık veri aracılı

Bugünün işletmesinde, neredeyse her büyük karar – bütçe değişimleri, yeni lansmanlar, org yeniden yapılanmaları – önce bir veri katmanından geçer. Ancak bu katmanlar genellikle sahip değildir:

• Geçen çeyrekte kullanılan metrik versiyon değişti – ama kimse ne zaman veya neden bilmiyor.
• Deney mantığı ekipler arasında farklılık gösterir.
• Atıf modelleri birbirleriyle çelişir, her biri mantıklı mantıkla.

DPM’ler kararın sahibi değil – kararı okunaklı kılan arayüze sahipler.

DPM’ler metriklerin yorumlanabilir olmasını, varsayımların şeffaf olmasını ve araçların gerçek iş akışlarıyla uyumlu olmasını sağlar. Onlar olmadan karar felç norm haline gelir.

AI döneminde bu rol neden hızlanacak

AI DPM’lerin yerini almayacak. Onları zorunlu kılacak:

• AI proje çabasının% 80’i hala Veri Hazırlığına (Forrester) gidiyor.
• Büyük dil modelleri (LLMS) ölçeği olarak, çöp girişlerinin maliyeti bileşikler. AI kötü verileri çözmez – onu güçlendirir.
• Düzenleyici baskı (AB AI Yasası, Kaliforniya Tüketici Gizlilik Yasası), iç veri sistemlerini ürün titizliği ile tedavi etmek için kuruluşları zorluyor.

DPM’ler trafik koordinatörleri değildir. Onlar güven, yorumlanabilirlik ve sorumlu AI temelleri mimarları.

Peki şimdi ne olacak?

CPO, CTO veya veri müdürüyseniz, şunları sorun.

• En büyük kararlarımıza güç veren veri sistemlerinin sahibi kimdir?
• Dahili API’lerimiz ve metriklerimiz sürüm, keşfedilebilir ve yönetilebilir mi?
• Hangi veri ürünlerinin benimsendiğini ve hangilerinin sessizce güvenini baltaladığını biliyor muyuz?

Açıkça cevaplayamıyorsanız, daha fazla gösterge panosuna ihtiyacınız yoktur.

Bir veri ürün yöneticisine ihtiyacınız var.

Seojoon Oh, Uber’de bir veri ürün yöneticisidir.