Startup’ta Veri Ekibi Kurmak

• Yıllık cirosu 10 milyar won ölçeğinde olan, Mid-Stage bir startup’ta yaklaşık 4 kişilik küçük bir veri ekibi büyütmek için katılan birinin hikayesi

• Birkaç deneyime dayanan mecazi bir yazıdır; önyargılı* olabilir, bunu dikkate alarak okuyun

1 Temmuz: Sabah

• Veri ekibi lideri olarak işe başladığım ilk gün

• CMO ile tanışma

(CMO benim geldiğim için çok heyecanlı, arkadaşının şirketinin AI kullanarak müşteri segmentasyonu yaptığını ve bunun çok havalı göründüğünü anlatıyor)

(Kısa bir sohbetten sonra pazarlama ekibinin veri pratiklerini inceliyorum)

DATA: "Müşteri edinme maliyeti (CAC) nasıl?"

CMO: "Hmm... Aslında oldukça harika. Veri bilimcimiz rakamları ölçtü, tıklama başı maliyet giderek düşüyor."

DATA: (Tüm veri bilimcilerin veri ekibine rapor verdiğini duymuştum, ama başka bir organizasyonda veri bilimci mi var?)

CMO: "Asıl sorun, Growth ekibinin bizim siteye getirdiğimiz trafiğin tamamını dönüştürememesi."

DATA: "Conversion funnel’ı görebileceğimiz bir dashboard var mı?"

CMO: "Lead’leri dönüştürmek Growth ekibinin işi değil mi zaten?"

• Product Manager’lardan biriyle sohbet

Açılış sayfasını tamamen yeniden tasarlayan PM, kullanıcı kayıtlarının %14 arttığı için çok heyecanlıydı

DATA: "Bu fark istatistiksel olarak anlamlı mı?"

PM: "O benim işim değil, sizin ekibinizin işi."

PM: "Daha önce sorduğumuzda veri ekibi verinin olmadığını söyledi ve veriyi elde etmenin aylar süreceğini anlattı."

PM: "Şaşırtıcı olan, bunu artımlı olarak değiştirmemiş olmamız. Bu değişiklik için A/B testi yapmamaya karar verdik. Bazen ekstrem değerlerden (Local Maxima) çıkmak için büyük bahisler yapmak gerekir."

PM: "Steve Jobs iPhone’u piyasaya sürerken A/B testi yapmadı. Bizim ekip bunu teslim tarihinden 2 gün önce yayına aldı ve önemli olan da bu!"

DATA: (Meşgulmüş gibi yapıp defterime bir şeyler karalıyorum)

• Yeni ekip üyeleriyle sohbet

→ 3 kişilik ekip ama yıl sonuna kadar 10 kişiye çıkabilecek bütçe verilmiş

→ Ben geldiğim için ekip üyeleri heyecanlı görünüyor

→ Şimdiye kadar yaptıklarını gösteriyorlar. Epey şey var ve bazıları gerçekten etkileyici

✓ Kullanıcı kaybı tahmini (Churn Prediction) için bir sinir ağı

✓ İlgili ürün öneri sistemi uygulanmış bir notebook

→ Kodların çoğu, farklı sistemlerden veri getirmek zorunda olan çok karmaşık bir ön işleme aşamasıyla başlıyor

✓ Bunun bir kısmını yapmak için doğru sırayla elle çalıştırılması gereken birden fazla script var gibi görünüyor

→ Ekip üyelerine neden bunu production’a almadıklarını sorunca

✓ Mühendisler bunun production seviyesine çıkarılmasının çok büyük bir proje olacağını söylüyor

✓ Product Manager bunu backlog’a eklemiş ama sürekli başka işler çıktığı için erteleniyor

✓ Bunun için yönetim desteğine ihtiyaç olduğunu söylüyorlar

1 Temmuz: Öğleden sonra

• Tedarik Zinciri Başkanı ile sohbet (CMO kadar heyecanlı görünmüyor)

"Dürüst olmak gerekirse veri ekibinin yardımına ihtiyacımız olup olmadığını bilmiyorum."

"Bizde o tür sorunlar yok. Bizim ihtiyacımız olan şey bir iş analisti."

"Benim koca bir ekibim var ve her gün saatlerini çok karmaşık modeller üzerinde çalışarak geçiriyorlar."

"Sahip olduğum temel sorulara cevap verecek zamanları bile yok."

"Yanıt almak istediğim sorularla dolu bir spreadsheet’im var."

(Spreadsheet’e bakınca şöyle şeyler var)

"Ticket oluşturan ve 1 saat içinde çözülen müşteriler ile 1 saatten sonra çözülen müşterilerin dönüşüm oranını, sipariş tutarını 100 dolar aralıklarında sınıflandırarak karşılaştırmak"

(Modeller hakkında sorunca)

• Sayısız VLOOKUP’tan oluşan Google Sheets dosyasında doğru sekmeye, doğru formatta kopyalanması gerekiyor gibi görünüyor

• Veri her gün güncelleniyor ve modelin çıktısına göre ekibin o günkü öncelikleri belirleniyor

• Tedarikçilere (vendor) yapılan ödemeler de spreadsheet ile hesaplanıyor

(Eve gidip kendime koca bir kadeh viski dolduruyorum.. )

[ Ne olmuş olabilir?]

• Bu, temelde veri olgunluğu aşamasının başındaki birçok şirkette yaşananların (biraz alaycı) bir tasviridir

• Veri eksikliği ve parçalanmış veri

→ Ürün düzgün şekilde instrumented edilmediği için veri çoğu zaman en baştan hiç var olmuyor

→ Verinin birden çok sisteme dağılmış olması nedeniyle veri sistemlerinde parçalanma

→ Veri odaklı yürütülen ama otomasyonun çok az ya da hiç olmadığı kırılgan iş süreçleri

• Veri ekibinin işinin ne olduğuna dair belirsiz beklentiler

→ Ar-Ge yapmak ve AI deploy etmek için işe alınan veri bilimciler; sonuç olarak net bir iş hedefi yok

→ Veri ekibi ML’yi production’a almanın zor olduğundan şikayet ediyor ama ürün ekibi aslında bu özelliği pek umursamıyor

→ "English-to-SQL çevirmeni"ne ihtiyaç duyan insanlar

• Veri odaklı eğitim almamış ürün ekibi

→ Product manager’lar veriyi daha iyi özellikler geliştirmek için bir araç olarak görmüyor

→ Ürün ekibinin yapmak istediği şeylerle veri ekibinin sahip oldukları arasında yeterli alignment yok

• Temelde veri merkezli kültürle çelişen bir kültür

→ Ölçülebilir ilerleme ve öğrenmeyi kutlamak yerine shipping’i kutlayan bir kültür

→ Gerçekten metrik kullanan ekipler bile tutarsız, ölçüm doğru yapılmıyor ve bazı durumlarda diğer ekiplerle çatışıyor

• Veri liderliğinin olmaması

→ Farklı veri çalışanlarının farklı departmanlara (fonksiyonlara) rapor verdiği parçalanmış bir veri organizasyonu

→ Diğer departmanlar ihtiyaç duydukları desteği alamadıkları için veri ekibinin etrafından çok sayıda analist işe alıyor

→ Toolchain ve best practice standardizasyonunun eksikliği

(Vay canına, bu bayağı moral bozucu. Peki bunu çözmek için ne yapmak gerekir?)

8 Temmuz

• Gelecek haftadan itibaren veri ekibi için yeni yönü belirlemeye başlıyorum

• Bir kişinin altyapı deneyimi var gibi görünüyor, bu yüzden ona merkezi bir data warehouse kurduruyorum

• Şimdilik veriyi tek bir yerde toplamak için en hızlı yolun olması yeterli

• Plan temelde production DB’yi her saat başı data warehouse’a dump etmek

• Frontend’de reklam izleme takibi için kullanılan framework’ten de çok büyük event log’ları gönderilebilir ama onu teknik borç olarak şimdilik kenara yazıyoruz

• İşe alım ekibiyle birlikte Generalist Data Role tanımı yapıyorum

→ Temel yazılım becerilerini vurguluyoruz ama aynı zamanda generalist (her şeyi yapan) bir tavra ve iş gereksinimlerine derin empati kurabilen kişilere odaklanıyoruz

→ Şimdilik yapay zeka ve makine öğrenimiyle ilgili tüm ifadeleri kaldırıyoruz

• Veri ekibine rapor vermeyen diğer veri çalışanlarıyla zaman geçiriyorum

→ Pazarlama ekibindeki veri bilimci genç biriydi. "Ben hep veri bilimci olmak istemiştim. Sizden çok şey öğrenmek istiyorum."

• Kodlama bootcamp’i işleten bir arkadaşıma iyi bir "SQL eğitim dersi" olup olmadığını sordum, varmış; bu ayın sonunda devreye alacağız

• Ürün ekibi için A/B testinin ne olduğunu ve nasıl çalıştığını anlatan bir sunum hazırlıyorum

→ Beklenmedik sonuçlar veren birçok test örneği gösteriyorum,

→ Hangisinin kazandığını tahmin etmelerini sağlayacak şekilde interaktif hazırlıyorum

• CEO’nun asistanıyla görüşüp "her hafta otomatik gönderilen e-postayla raporlanmasını istediği metriklerin" neler olduğunu öğrenmek

• Supply Chain ekibindeki iş analistleriyle konuşunca, makul insanlar olduklarını ama daha önce veri ekibiyle konuşurken incindiklerini gördüm

• İçlerinden biri geçmişte SQL kullanmıştı. Dönüşüm oranı hakkında soru sorduğunu görünce ona veri ambarı erişimi verdim

• Veriye ihtiyaç duyan organizasyon genelindeki insanlarla haftalık bire bir görüşmeler ayarlamak

→ Amaç, veri boşluklarını (gap) ve fırsatları bulup veri bilimcilere iletmek

→ Veri bilimciler, araştırma öncelikleri geri plana itildiği için hayal kırıklığına uğrayabilir

→ "Mümkün olduğunca hızlı şekilde iş değeri üretmeye odaklanıyoruz" derken bir yandan da "yakında yine makine öğrenmesiyle ilgili işlere dönebiliriz. Önce bir bakalım" diye anlatmak

1 Eylül: sabah

• 3 ay geçti ve artık işlerin yavaş yavaş rayına oturduğu hissi var

• Çeşitli paydaşlarla her hafta bire bir görüşerek verinin değişim yaratabileceği kör noktaları ve fırsatları bulmaya devam etmek

• Bulduklarımı temel platform çalışmalarını zorunlu kılmak için kullanmak

• "Türetilmiş" veri setleri oluşturmak için çok sayıda pipeline kurmak gerekiyor. İlk maliyeti yüksek ama doğru veri seti oluşturulunca sonraki analizler çok daha kolaylaşıyor

• Diğer departmanlara veri ambarı erişimini açmaya başlamak

• İnsanlar doğrudan SQL kullanarak temel analizler yapmaya başlıyor

→ Harika bir örnek: junior bir ürün yöneticisi iOS Safari’de dönüşüm oranının aşırı kötü olduğunu fark etti. Sorun local storage ile ilgili bir frontend bug’ıydı ve tek satırda düzeltildi

• Tedarik zinciri sorumlusu öfkeli bir e-posta gönderiyor

→ Veritabanı değiştiği için 500 satırlık sorgu patlamış...

→ Homurdanan veri bilimcisine düzeltmeyi verip önüne başka bir havuç uzatıyorum: "Bu ayın sonunda sana havalı bir makine öğrenmesi problemi bulacağım"

1 Eylül: öğleden sonra

• Checkout ekibinin ürün yöneticisi hâlâ metrik analizi yapmıyor

• Pazarlama ekibindeki veri bilimci yöneticisiyle konuşup doğrudan bana raporlamaya karar veriyor

[ Neler oluyor? ]

• En acil konuların temelini atıyoruz

→ Önemli verileri tek bir yerde sorgulanabilir hale getiriyoruz

→ SQL erişimini açıp diğer ekiplerin kullanmasını sağlayarak pek çok "SQL çevirisi" işini ortadan kaldırıyoruz

• Öte yandan diğer ekipler bu özgürlükle daha da ileri gitmek isteyebilir. Veri erişimine yetki koyarak bunu önlemek mümkün ama bunun dezavantajı daha fazla

• Checkout ekibinin veri analizi yapamamasının nedeni kime sorması gerektiğini bilmemesiydi

• Bu esasen bir organizasyon sorunu

→ Ekipler veri ekibiyle nasıl çalışacaklarını bilmiyor

→ Farkında değiller ama darboğaz veri ekibi olabilir

• En makul yaklaşım "raporlamayı merkezileştirip iş yönetimini dağıtmak"

→ Çünkü veri ve kararlar daha sıkı bir geri bildirim döngüsü oluşturuyor

→ Veri ekibi üyelerinin ilgili ekiplerle birlikte çalışıp sadece bana (veri ekibi liderine) rapor vermesini sağlamak

2 Eylül

• Veri ekibi 6 kişiye çıkıyor

→ 1 kişi veri ambarı altyapısı

→ 5 kişi ekip başına atanıyor: onboarding, tedarik zinciri, checkout, pazarlama, CEO desteği ve yatırımcı/yönetim kurulu sunum materyalleri hazırlama

• Şirket genelinde değişikliği anlatıp veri ihtiyaçları için kiminle çalışılması gerektiğini netleştirmek

• Bundan sonra veri tarafında yeni işe alım olsa bile diğer ekiplere atamayı planlamak

3 Ocak

• Veri bilimcilerden biri ayrılmaya karar veriyor. Zaten onu mutlu edecek çok şey olmadığı için kalması konusunda ısrar etmiyorum

• Ekipte yeni insanlar var. Biraz yazılım mühendisliği bilgisi, SQL bilgisi ve veride ilginç şeyler bulma isteği olan insanlar

→ Veride "manşet" arayan kişiler oldukları için onları "veri gazetecileri" gibi düşünüyorum

• Onboarding ekibiyle çalışan üye örneğinde

→ Onboarding akışında müşteri adresi gerekmemesine rağmen adres sorulduğunu fark ediyor

→ Bu kaldırılınca A/B testinde dönüşüm oranı %21 artıyor

→ Veriyi sorgulamayı kolaylaştırmak için ETL işi gerektiğinden kolay değildi ama Python biraz yardımcı oldu ve yapılabildi

• CEO ile çeyreklik değerlendirme

→ Büyüme inisiyatifinde PM, yeni yayına alınan landing page yeniden tasarımını tanıtıyor

→ PM, 20 mühendisin deadline’ı tutturmak için fazla mesai yaptığını özellikle vurguluyor

→ CMO da bu yeniden tasarımın parçası olarak Direct Mail’den büyük beklentisi olduğu için sürece derin şekilde dahil olmuş durumda

→ CEO’nun sorusu: "Şu anki metrikler nasıl? Müşteri edinme maliyeti düştü mü?"

(Bu soruyu CEO’nun soracağını beklediğiniz için tam gelince gülümsüyorsunuz)

→ PM aslında bir A/B testi yaptıklarını söyleyip ekteki sayıları gösteriyor

→ Bazı metrikler yükselmiş, bazıları düşmüş; yani anlamlı bir sonuç yok, müşteri edinme maliyeti rakamı da iyi görünmüyor

→ CMO, sayıların henüz oluşmakta olduğunu ve bu tür kampanyaların birkaç ay sürebileceğini vurguluyor

[ Neler oluyor? ]

• İyi haber, ürün ekibinin A/B testleri yapmaya başlaması

• Kötü haber, sonuçlar görmezden gelinirken projelerin çoğunlukla kilometre taşları ve yapay deadline’lara göre ilerlemesi

• En iyi haber ise CEO’nun her ekibi veriyi gerçeklik kaynağı (truth) olarak kullanmaya zorlaması

• Organizasyon daha veri odaklı olmaya doğru baskı gördükçe, veri ekibinin diğer ekiplerle çalışma biçimini hızlandırması gerekiyor

• Özellikle üst yönetim metriklere daha fazla odaklanacak ve veri ekibinin bu metrikler üzerinde çalışmasını sağlamak sizin işiniz

• Bunun en basit yollarından biri, her ekibin önem verdiği metrikler için bir dashboard olduğundan emin olmak

1 Nisan

• Veri ekibinin geçmişte yaptığı makine öğrenmesi işleri hâlâ duruyor

• Envanter ürün ekibinde çalışan veri bilimci, eskiden yapılmış öneri sistemi çalışmalarına ilgi duyuyor

• Yeni alınan üyelerden biri generalist olduğu için öneri sistemi notebook’unu küçük bir Flask uygulamasına çevirip iç kullanım için dağıtmış

• Envanter ekibinin ürün yöneticisi görüp beğeniyor: "Bunu nasıl deploy ederiz?"

• Envanter ekibinin ana metriklerinden biri "ortalama sipariş tutarı" ve bu öneri sisteminin bunu ciddi şekilde iyileştirebileceği düşünülüyor

• Kabaca bakınca geniş çaplı dağıtım zor görünüyor ama "müşterilerin sadece %1’ine açsak nasıl olur?" fikri ortaya atılıyor

• "Biraz ilkel ama Cron Job ile öneri ürünleri önceden üretiriz, birkaç günde de çıkar gibi görünüyor"

• Tedarik zinciri ekibiyle çalışırken daha fazla dev SQL sorgusu keşfediliyor

• Bunlar sürekli bozuluyor ama veri ekibi bunları uygun pipeline’lara dönüştürmek için çalışıyor

• Tedarik zinciri ekibinin başı daha fazla veri bilimci işe alınmasını istiyor

[ Tamam, burada neler oluyor? ]

• Öncelikle havalı makine öğrenmesi işleri için bir umut doğdu

• Ürün ekibi sonunda öneri sistemini küçük bir testle yayına alma fikri konusunda heyecanlı

• Eskiden bu mümkün değildi; çünkü ürün mühendisliği ekibinin işi öngörmesi zordu, doğrudan katkı vermek istemiyordu ve veri ekibinin de bunu production’a taşıyacak yetkinliği yoktu

• Bunu mümkün kılan şey, veri ekibinin gerçekten çalışan bir demo inşa etmiş olması. Bu sayede hem production’a daha çok yaklaşılıyor hem de olasılık çok daha net gösteriliyor

• Bir diğer konu da tedarik zinciri ekibinde olanlar

→ Kendi "iş analistleri" ile başladılar ama veriyi almak için veri ekibinin sorgu çalıştırması gerekiyordu

→ Analistler, veri ekibinin yardımıyla sorguları artık doğrudan kendileri çalıştırmaya başladı

→ Önce veri ekibiyle sürtüşmeye neden olan "gölge teknik borç"u (canavar boyutlarda SQL sorguları) ortadan kaldırmaya başladınız

→ Veri ekibi tedarik zinciri ekibine daha yakından destek vermeye başladı

→ Veri ekibi üyeleri gömülü çalışmaya başlayınca iş analistine olan ihtiyaç azalırken veri bilimcilerin sayısı arttı

• Başta production DB’yi doğrudan data warehouse’a dump etmeye başladığınızda "teknik borç"u üstlendiğinizi unutmayın

• İlk başta pek çok şey bozulur, ama sorguların istikrarlı çalışmasını sağlayacak bir katman eklemeniz gerekir. Bu oldukça büyük bir iş olabilir

1 Temmuz

• 3. çeyrek planlama toplantısı

→ Eskiden şirketin gelecek çeyrekte neye bahis oynayacağını tartışırdınız

→ Bu kez siz şirketin en üst seviye metriklerini sunuyorsunuz ve her ekip alt metrikler üzerinden bu üst seviye metrikleri detaylandırarak sunum yapıyor

• Ürün yönetimi ekibinin çalışmaları sonuç verdi

→ PM, testleri yürütürken öğrendiklerini ve veride bulduğu noktaları anlatarak projeye yatırım yapılmasını gerekçelendirdi

• Büyük başarılardan biri, checkout ekibiyle çalışan veri bilimcinin kullanıcı doğrulama sayfasında geri tuşuna bastığında sepet nesnesinin garip hale geldiğini fark etmesiydi

→ Bu sorun çözülünce dönüşüm oranı ciddi şekilde arttı

• Bir başka içgörü de farklı reklam kampanyalarından gelen trafiğin çok farklı dönüşüm profillerine sahip olmasıydı

→ Bazı kampanyalarda tıklama maliyeti düşüktü ama dönüşüm oranı berbattı; diğer kampanyalar pahalıydı ama dönüşüm oranı çok yüksekti

• UTM değişkenlerini takip edip bunları hesap oluşturmayla ilişkilendirerek, reklam tıklamasından satın almaya kadar olan dönüşüm oranını ölçmek mümkün hale geldi

→ Tüm veriyi aynı data warehouse’a getirip kolay sorgulanabilecek şekilde normalize etmeden önce bu mümkün değildi

→ Pazarlamayla iş birliği sayesinde temel KPI’ın tıklama başı maliyet değil, uçtan uca müşteri edinme maliyeti olduğu görüldü

• Bir başka ilginç gelişme ise %1’lik öneri sistemi testinin alışılmadık derecede başarılı olmasıydı

→ Bunu kullanıcıların %100’üne yaymak çok büyük bir proje ama CEO projeyi onayladı

• Üretilen her sonuç olumlu değildi; birçok test başarısız oldu.

→ Slaytlardan biri, kargo ücretinin ayrıca alınmadığı ve fiyata dahil edildiği bir testin açıklamasıydı

→ CEO şöyle dedi: "Buradan ne öğrendik?"

→ Bu da bir dizi takip deneyi planlamaya yönelik yeni bir konuşmaya dönüştü

(Eve gidip şampanya patlatırsınız)

[ Ne oldu? ]

• Başardınız.

• Organizasyonu gerçekten data-native bir yapıya dönüştürdünüz.

• Veri ekibi farklı paydaşlarla çapraz fonksiyonel biçimde çalışıyor.

• Veri ve içgörüler planlamada kullanılıyor; veri, amacı belirsiz araştırmalar için değil, iş değeri üretmek için kullanılıyor.

• Şirket, büyük ölçekli "waterfall" tarzı planlar yerine hızlı veri temelli geri bildirim döngülerinden yararlanarak yinelemeli şekilde çalışıyor.

• Metrikler, iş değeri yaratacak ve buna sahip çıkılabilecek biçimde tanımlanıyor.

• Veri kültürü hem yukarıdan (CEO’nun itmesiyle) hem aşağıdan (çalışanlardan) birlikte yönlendiriliyor.

• En azından bir şey öğrendiyseniz, başarısız olmak sorun değildir.

(Tebrikler. Şampanya kaldırmayı hak ettiniz)

[hangnim]

Başını okurken sanki bizim şirketi anlatıyor sandım,,,, hıçkırık hıçkırık (tabii bizim şirkette veri ekibi bile yok haha)

[dajoa]

Keyifle okudum. Teşekkürler~!

[shawn]

Mühendislerin keyifle izleyebileceği teknoloji startup’larıyla ilgili bir dizinin bir bölümünü izlemişim gibi hissettirdi. Çok eğlenceli! 👍

[hangnim]

22222

[laeyoung]

İnsan çok gibi görünüyor ama demek ki bu kadarı mid-stage içinmiş

[xguru]

Muhtemelen ülke içindekinden bakılan ölçek biraz farklı olacaktır.

[xguru]

Opinionated* için temiz bir çeviri yapmak zor; ben genelde "kişinin kendi görüşünü yansıttığı için taraflı" anlamında "önyargılı" olarak kullanıyorum.

Bununla ilgili başka birinin yazdığı bir metin var, ona da göz atabilirsiniz

• Bilgisayar terimi olarak opinionated(önyargılı) kavramının anlamı https://www.clien.net/service/board/cm_app/13558026

Ayrıca, orijinal yazı açıklayıcı bir üslupla kaleme alınmıştı; ben ise okunmasını biraz daha kolaylaştırmak için konuşma diline yakın şekilde yeniden düzenledim.