Hipotezleri ve Öğrenimleri İzleyen Bir Web Uygulaması Nasıl Oluşturulur

Deney İzleme İçin Hedefleri ve Kapsamı Tanımlayın

Bir veritabanı seçmeden veya ekranlar tasarlamadan önce, deney izleme web uygulamanızın hangi problemi çözdüğünü netleştirin. Çoğu ekip fikir eksikliğinden başarısız olmaz—başarısız olmalarının nedeni bağlamın kaybolmasıdır.

Gerçek problemi tanımlayın (semptom değil)

Aşağıdaki işaretler özel bir öğrenme deposuna ihtiyaç duyduğunuzu gösterir:

• Deneyler dağınık notlar, sunumlar veya sohbet dizilerinde dokümante ediliyor.
• İnsanlar önceki öğrenimleri bulamadıkları (veya bulduğuna güvenmedikleri) için testleri tekrar ediyor.
• Kararlar hipotezler, sonuçlar ve "ne öğrendik" izleri olmadan alınıyor.

Basit bir dilde bir paragraf problem ifadesi yazın, örneğin: “Birçok test yapıyoruz ama daha önce ne denediğimizi, neden denediğimizi, ne olduğunu ve bunun kararımızı değiştirip değiştirmediğini güvenilir şekilde cevaplayamıyoruz.” Bu, diğer her şeyi sabitleyecektir.

Gerçekten ölçülebilir başarı kriterleri koyun

Birincil hedef olarak "kayıtlı deney sayısı" gibi gösteriş amaçlı metriklerden kaçının. Bunun yerine davranışlar ve karar kalitesi etrafında başarıyı tanımlayın:

• Benimseme: hangi ekiplerin haftalık kullanacağı ve "aktif kullanım" tanımı (ör. her deneyin lansmandan önce bir girdisi ve sonrasında bir sonucu olur).
• Aranabilirlik: "X başlıklı fiyatlandırma sayfasını test ettik mi?" veya "onboarding sürtünmesi hakkında ne öğrendik?" gibi yaygın soruların yanıt süreleri.
• Karar kalitesi: daha az tekrar eden test, daha net go/no-go kararları ve rol değişikliklerinde daha iyi devir teslim.

Bu kriterler hangi özelliklerin gerekli olduğunu (ve hangilerinin isteğe bağlı olduğunu) yönlendirecektir.

Hedef ekipleri ve temel kullanım durumlarını belirleyin

Deneyim çalışmaları fonksiyonlar arasıdır. V1 için uygulamanın kimin için olduğunu tanımlayın—genellikle ürün, growth, UX araştırma ve data/analytics karışımı olur. Ardından onların temel iş akışlarını eşleyin:

• Ürün: bir hipotez önerir, paydaşları hizalar, sonucu ve kararı kaydeder.
• Growth: sık A/B testleri çalıştırır, varyasyonları karşılaştırır, geçmişi kaybetmeden hızlı hareket eder.
• UX research: nitel çalışmaları "deney" olarak kaydeder, öğrenimler ve güven seviyesi ekler.
• Data: analizleri doğrular, metrik tanımlarını izler, çekinceler hakkında notlar ekler.

Her iş akışını kusursuz desteklemeniz gerekmez—paylaşılan kayıt herkes için mantıklı olmalı.

Uygulamanın v1'de ne yapacağını (ve yapmayacağını) netleştirin

Kapsam kayması MVP'leri öldürür. Sınırlarınızı erken belirleyin.

V1 muhtemelen yapacak: hipotezleri yakalamak, deneyleri sahip ve tarihlerle ilişkilendirmek, öğrenimleri saklamak ve her şeyi kolay aranır hale getirmek.

V1 muhtemelen yapmayacak: analiz araçlarının yerini almak, deneyleri koşturmak, istatistiksel anlamlılık hesaplamak veya tam bir ürün keşif aracına dönüşmek.

Basit bir kural: bir özellik dokümantasyon kalitesini, bulunabilirliği veya karar almayı doğrudan iyileştirmiyorsa, sonraya bırakın.

Kullanıcıları, Rolleri ve Temel İş Akışlarını Belirleyin

Ekranları tasarlamadan veya veritabanı seçmeden önce kimin uygulamayı kullanacağını ve hangi çıktıları ihtiyaç duyduklarını netleştirin. İyi bir deney izleme uygulaması "açık" hissettirir çünkü gerçek ekip davranışını yansıtır.

Birincil roller (basit tutun)

Çoğu ekip dört rolle başlayabilir:

• Contributor: hipotez ekler, deneyleri çalıştırır, sonuçları kaydeder.
• Reviewer: deney planlarını şekillendirir, kaliteyi kontrol eder, kararları onaylar.
• Admin: çalışma alanı ayarlarını, izinleri, şablonları ve temizlik işlerini yönetir.
• Viewer: geçmiş öğrenimleri okur, arar ve dışa aktarır—düzenleme yok.

Role göre yapılacak işler

Hızlı bir doğrulama yöntemi, her rolün yapması gereken işleri listelemektir:

Mutlu yol (fikir → öğrenim)

Pratik bir "mutlu yol" akışı:

1. Fikir kaydedildi (hızlı not, ürün alanına etiket).
2. Hipotez oluşturuldu (kim/ne/beklenen etki + neden).
3. Deney planlandı (yöntem, kitle, süre, metrikler, riskler).
4. Çalıştırma + güncellemeler (durum değişiklikleri ve eser bağlantıları).
5. Öğrenim kaydedildi (karar + kanıt + sonraki adımlar).

Onay noktaları ve olası darboğazlar

Bir reviewer’ın nerede devreye gireceğini belirleyin:

• Çalıştırmadan önce: hipotez kalitesi ve ölçüm planını onayla.
• Sonuçlardan sonra: sonuca ve karara onay ver.

Tasarım yaparken bekleme süresi, belirsiz sahiplik, eksik veri bağlantıları ve "sonuç" yayınlanmış ama karar yok gibi ortak darboğazları göz önünde bulundurun. İşin ilerlemesini sağlamak için zorunlu alanlar, sahip ataması ve "inceleme gerekiyor" kuyruğu gibi hafif işaretler ekleyin.

Veri Modelini Tasarla: Hipotezler, Deneyler, Öğrenimler

İyi bir veri modeli uygulamayı "açık" hissettirir: insanlar bir fikri bir kez yakalar, üzerinde birden çok test yapar ve daha sonra ne öğrendiklerini dokümanlar içinde aramak zorunda kalmazlar.

Bir “Hipotez” aşağıdakileri içermeli

Gevşek bir fikri test edilebilir hale getiren minimum alanları tanımlayarak başlayın:

• Hipotez ifadesi: net bir "Eğer X yaparsak, Y Z kitlesi için olur." biçimi.
• Gerekçe: bunun doğru olduğunu düşündüğünüz neden (içgörüler, müşteri geri bildirimi, önceki deneyler).
• Beklenen etki: ne değişmeli ve hangi yönde (ör. aktivasyon oranı yükselir, churn azalır).

Bu alanları kısa ve yapılandırılmış tutun; uzun anlatılar ekler veya notlar bölümünde saklansın.

İhtiyacınız olabilecek temel varlıklar

Çoğu ekip küçük bir nesne setine ihtiyaç duyar:

• Experiment: yürüttüğünüz somut test (tarihler, sahip, durum, yöntem).
• Metric: ne ölçtüğünüz (tanım, kaynak, koruyucular).
• Variant: ne değişti (kontrol ve bir veya daha fazla tedavi).
• Decision: verilen karar (ship, iterate, stop) ve onaylayan.
• Learning: tekrar kullanılabilir çıkarım şeklinde ifade edilmiş öğrenim.
• Attachment: ekran görüntüleri, SQL parçaları, tasarımlar, araştırma notları.

Gerçekliğe uyan ilişkiler

Çoğaltmayı önleyecek bağlantıları modelleyin:

• Bir hipotez → birden çok deney (aynı inancı segmentler veya kanallar arasında test edebilirsiniz).
• Bir deney → birçok öğrenim (beklenen ve beklenmeyen sonuçlar).
• Deneyler birçok metrik ve birçok variant ile ilişkilendirilebilir.

Etiketler ve taksonomi (bulunabilirlik kazandırır)

MVP içinde bile hafif etiketleme ekleyin:

• Ürün alanı (Onboarding, Pricing, Search)
• Kanal (Email, Paid, In-app)
• Kitle (Yeni kullanıcılar, SMB, Enterprise)
• Risk ve çaba (basit ölçekler)

Bu taksonomi, karmaşık iş akışı zorlamadan arama ve raporlama için faydalı olacaktır.

Net Bir Durum ve Karar Çerçevesi Oluşturun

Durum çerçevesi deney izleme uygulamasının omurgasıdır. Çalışmayı ilerletir, incelemeleri hızlandırır ve "yarım kalmış" deneylerin öğrenme deposunu kirletmesini engeller.

Küçük, belirsiz olmayan durum seti kullanın

Ekiplerin gerçekten nasıl çalıştığına uyan basit bir akışla başlayın:

• Draft: fikir yakalandı, henüz şekillenmedi
• Planned: çalıştırmaya hazır, zamanlandı, sahipler atandı
• Running: deney yayında ve veri toplanıyor
• Analyzing: sonuçlar değerlendiriliyor
• Decided: karar verildi ve dokümante edildi
• Archived: kapatıldı ve gelecekte arama için dosyalandı

Durum değişikliklerini açık hale getirin (buton veya açılır menü) ve mevcut durumu her yerde gösterin (liste görünümü, detay sayfası, dışa aktarmalar).

Koruyucular ekleyin: durum başına zorunlu alanlar

Durumlar tamlığı zorladığında daha faydalıdır. Örnekler:

• Draft gerektirir: hipotez ifadesi, problem/fırsat, talep eden
• Planned gerektirir: birincil metrik, başarı eşiği, kitle/segment, başlangıç/bitiş tarihleri, sahip, riskler
• Running gerektirir: deney ID/bağlantı, rollout planı, izleme notları
• Analyzing gerektirir: veri kaynağı, sonuç özeti, etki yönü, güven notları
• Decided gerektirir: karar türü, gerekçe, sonraki adımlar

Bu, "Running" durumunda net bir metrik olmamasını ve "Decided" girişi gerekçesiz bırakılmamasını önler.

Kararları kaydedin (rahatsız edici olanlar da dahil)

Kısa serbest metin açıklamasıyla yapılandırılmış bir karar kaydı ekleyin:

• Ship (değişikliği kabul et)
• Iterate (düzelt ve tekrar test et)
• Stop (takip etmeye değmez)
• Rerun (yürütme sorunlarını düzelt ve tekrar et)
• Inconclusive (yetersiz kanıt)

Inconclusive durumlarında ekiplerin bunları gömmesine izin vermeyin. Bir neden (ör. düşük güç, çelişkili sinyaller, ölçüm eksikliği) ve önerilen bir takip (yeniden çalıştırma, nitel veri toplama veya belirli bir tarihte tekrar gözden geçirme) zorunlu olsun. Bu, deney veritabanınızı dürüst tutar ve gelecekteki kararları iyileştirir.

UX Planı: Yakalama, Arama ve İnceleme

Bir izleme uygulaması hızda başarılı olur veya başarısız olur: bir fikri ne kadar çabuk yakalayabildiğiniz ve ekibin bunu aylar sonra ne kadar kolay bulabildiği önemlidir. "Şimdi yaz, sonra düzenle" tasarımını hedefleyin ama veritabanını bir çöp kutusuna dönüştürmeyin.

Önce tasarlamanız gereken ana ekranlar

Tam döngüyü kapsayan küçük bir ekran seti ile başlayın:

• Liste görünümü: varsayılan açılış sayfası, kaydedilmiş filtrelerle (örn. "Benim aktif deneylerim", "Karar bekleyen", "Yayımlanmış öğrenimler").
• Detay görünümü: bir hipotez/deney için okunabilir, paylaşılabilir sayfa; üstte özet, altta kanıt ve sonuçlar olacak şekilde taramaya uygun.
• Editor: detay sayfasında satır içi düzenleme veya odaklanmış bir düzenleme modu; uzun, göz korkutucu formlardan kaçının.
• Dashboard: neyin çalıştığını, neyin bloke olduğunu ve hangi denemelerin sonuçlandığını gösteren hafif bir genel bakış—analitikten ziyade operasyonel.

Girişi hızlı yapın (insanlar gerçekten kullansın diye)

Şablonlar ve varsayılan alanlar kullanarak yazma miktarını azaltın: hipotez ifadesi, beklenen etki, metrik, hedef kitle, rollout planı, karar tarihi.

Zamanla bileşik fayda sağlayan küçük hızlandırıcılar ekleyin: klavye kısayolları (yeni oluştur, etiket ekle, durum değiştir), hızlı sahip ekleme ve mantıklı varsayılanlar (durum = Draft, sahip = oluşturan, tarihler otomatik doldurulur).

Arama ve filtreler bir ürün özelliğidir

Getiriyi birinci sınıf iş akışı olarak ele alın. Küresel arama artı etiket, sahip, tarih aralığı, durum ve birincil metrik için yapılandırılmış filtreler sağlayın. Kullanıcıların filtre kombinasyonları kaydetmesine izin verin. Detay görünümünde etiketleri ve metrikleri tıklanabilir yaparak ilgili öğelere atlayın.

Onboarding ve boş durumlar

Basit bir ilk çalışma deneyimi planlayın: bir örnek deney, "İlk hipotezini oluştur" isteği ve burada neyin yer aldığına dair açıklama içeren boş bir liste. İyi boş durumlar kafa karışıklığını önler ve ekipleri tutarlı dokümantasyona yönlendirir.

Hipotez ve Deney Planları İçin Şablonlar Oluşturun

Şablonlar "iyi niyetleri" tutarlı dokümantasyona dönüştürür. Her deney aynı yapıdan başlarsa incelemeler hızlanır, karşılaştırmalar kolaylaşır ve eski notları çözmek için daha az zaman harcanır.

Hipotez şablonu (netlik zorunlu)

Bir ekranda sığacak kısa bir hipotez şablonu ile başlayın ve insanları test edilebilir ifadeye yönlendirin. Güvenilir bir varsayılan:

If we [change] , then [expected outcome] , because [reason / user insight] .

Birkaç alan ekleyin, belirsiz iddiaları önlemek için:

• Hedef kullanıcı / segment: bunun kim için olduğu (yeni kullanıcılar, güç kullanıcılar, belli bir plan)
• Kanıt: motivasyon kaynağı olan müşteri alıntısı, araştırma notu veya veri noktası (link to /docs or /research)
• Beklenen yön: yukarı/aşağı/değişmez, böylece "başarı" sonra yeniden yazılmaz

Onaylaması kolay bir deney planı şablonu

Plan şablonunuz, testi sorumlu şekilde yürütmek için yeterli detayı yakalamalıdır:

• Kitle: kim uygun ve hariç tutmalar
• Süre: başlangıç/bitiş tarihleri veya karar tarihi
• Numune büyüklüğü notları: kaba rehberlik veya "X dönüşüme kadar çalış" gibi varsayımlar
• Birincil metrik: sonucu belirleyecek tek sayı
• İkincil metrikler: bağlam sağlayan ama karar verici olmayan metrikler
• Koruyucular: bozulmaması gereken metrikler (ör. iadeler, destek talepleri)

Bağlantıları birinci sınıf alanlar olarak tutun ki şablon çalışmaya bağlansın:

• Tasarımlar: /docs/designs/...
• Ticket/PRD'ler: /docs/...
• Panolar: /analytics/...

Şablonları esnek ama serbest form olmadan yapın

Birkaç deney türü ön ayarı (A/B testi, onboarding değişikliği, fiyat testi) sağlayın; her biri tipik metrikleri ve koruyucuları doldursun. Yine de ekipleri yanlış kalıba sokmamak için bir "Özel" seçeneği tutun.

Amaç basit: her deney kısa ve tekrarlanabilir bir hikaye gibi okumalı—neden, ne, nasıl ve nasıl karar verileceği.

Öğrenimleri Yeniden Kullanılabilir, Yapılandırılmış Bir Şekilde Yakalamak

Bir izleme uygulaması gerçekten değerli hale geldiğinde kararları ve gerekçeyi korur; sadece sonuçları değil. Hedef, öğrenimleri taraması, karşılaştırması ve yeniden kullanması kolay hale getirmektir—böylece sonraki deney daha akıllıca başlar.

Tutarlı bir “Learning” kaydı kullanın

Bir deney bittiğinde (veya erken durdurulduğunda) şu alanları zorunlu kılan bir öğrenim girdisi oluşturun:

• Ne oldu: sonuçların düz Türkçe özeti (sürprizler ve kenar durumlar dahil).
• Neden olduğunu düşünüyoruz: kanıta dayalı en iyi açıklama; rekabet eden açıklamalar varsa listeleyin.
• Sonraki adım: şimdi ne yapılacak—ship, iterate, takip testi veya fikirden vazgeçme.

Bu yapı tek seferlik yazıları, ekibin arayıp güvenebileceği bir veritabanına dönüştürür.

Metriklerin yanına nitel bağlam ekleyin

Sayılar nadiren tüm hikayeyi anlatır. Aşağıdaki alanlar için yer ayırın:

• Nitel notlar: kullanılabilirlik gözlemleri, destek tema notları, satış görüşmesi çıkarımları.
• Alıntılar: kısa kullanıcı veya paydaş alıntıları, kaynak ve tarih bağlı.

Bu, ekiplerin metriklerin neden hareket ettiğini (veya etmediğini) anlamasına yardımcı olur ve aynı yanlış yorumları tekrarlamayı önler.

Kanıt olarak ekleri birinci sınıf yapın

Öğrenim girdisine ekler eklemeye izin verin—insanların daha sonra bakacağı yer burasıdır:

• Ekran görüntüleri (ön/son UI, heatmapler)
• Dokümanlar (araştırma özetleri, karar notları)
• SQL parçaları (kullanılan kesin sorgu)
• Grafikler (dışa aktarılmış çizelgeler, deney okumaları)

Eklerin kullanılabilir kalması için sahip, tarih, ilgili metrik gibi hafif meta veriler saklayın.

"Farklı ne yapardık" alanı ekleyin

Süreç yansımaları için ayrılmış bir alan bileşik gelişimi sağlar: katılım boşlukları, ölçüm hataları, kafa karıştıran varyantlar veya uyumsuz başarı kriterleri. Zamanla bu, daha temiz testler yürütme için pratik bir kontrol listesine dönüşür.

Yanıltıcı Olmayan Raporlama Ekleyin

Raporlama ancak ekibe daha iyi karar almada yardımcı oluyorsa faydalıdır. Bir deney izleme uygulaması için bu, analizleri hafif, net tanımlı ve ekibin gerçek çalışma biçimine bağlı tutmak anlamına gelir (gösteriş amaçlı "başarı oranı" değil).

Hafif analitikle başlayın

Basit bir pano pratik soruları yanıtlayabilir:

• Duruma göre sayım (Draft → Planned → Running → Analyzing → Decided). Bu iş miktarını ve darboğazları gösterir.
• Kazanma oranı (çekincelerle). Bunu yönlendirici bir sinyal olarak değerlendirin, performans puanı olarak değil.
• Karar süresi (oluşturulma → karara bağlanma). Bu, süreç sürtünmesini vurgular.

Her metriği tıklanabilir yapın ki insanlar temel deney dokümantasyonuna inebilsin ve toplamlar üzerinde tartışma çıkmasın.

Kararları eşleştiren dilimlemeler ekleyin

Çoğu ekip sonuçları şu şekilde görmek ister:

• Alan (onboarding, pricing, activation, retention)
• Birincil metrik (dönüşüm, gelir, time-to-value)
• Sahip (kimin yürüttüğü)

Bu görünümler hipotez yönetimi için özellikle faydalıdır çünkü tekrarlayan desenleri (ör. sık başarısız olan onboarding hipotezleri) ortaya çıkarır.

Öğrenim akışı ve haftalık özet ekleyin

Bir "öğrenim akışı" öğrenme deposunda neyin değiştiğini vurgulamalı: yeni kararlar, güncellenen varsayımlar ve yeni etiketlenmiş öğrenimler. Bunu bir haftalık özet ile eşleştirin:

• Bu hafta ne kararlaştırdık?
• Ne yapmayı bırakmalıyız, ne yapmaya başlamalıyız, neyi tekrarlamalıyız?
• Hangi hipotezler geçersiz kılındı (ve neden)?

Bu, ürün deneyimini görünür kılar ama herkesi her A/B test detayını okumaya zorlamaz.

Sahip olmadığınız kesinliği ima etmeyin

Varsayılan olarak istatistiksel gerçeklik izlenimi veren grafiklerden ve etiketlerden kaçının. Bunun yerine:

• Anlamlılığı etiket olarak gösterin (örn. "Test edilmedi", "Yönlendirici", "%95 anlamlı") ve varsayımları saklayın (test türü, örnek tanımı, durdurma kuralı).
• Güven notları gösterin ("küçük örnek", "mevsimsellik riski", "koruyucu metrik etkilendi").
• Kararyi ("Ship / Don’t ship / Iterate") sonuçtan (etki büyüklüğü, metrik hareketi) ayırın.

İyi raporlama tartışmayı azaltmalı, yanıltıcı metriklerle yeni tartışmalar üretmemelidir.

Zaman Kazandıran Entegrasyonlar ve Otomasyon

Bir izleme uygulaması ekibin zaten kullandığı araçlara uymazsa tutmaz. Entegrasyonların hedefi "daha çok veri" değil—daha az manuel kopyala/yapıştır ve daha az kaçırılmış güncellemedir.

Kimlik doğrulama ve takım bağlamı

İnsanların diğer iç araçlara eriştiği yönteme uygun girişle başlayın.

Şirketinizde SSO (Google Workspace, Microsoft, Okta) varsa bunu kullanın ki onboarding tek tıkla olsun ve offboarding otomatikleşsin. Ayrıca ekip dizini senkronizasyonu ile deneylerin gerçek sahiplere, ekiplere ve reviewerlara (örn. "Growth / Checkout squad") otomatik atfedilmesini sağlayın, böylece herkes iki yerde profil tutmak zorunda kalmasın.

Analitik bağlantıları (güvenlik baş ağrısı yaratmadan)

Çoğu ekip ham analitik eventlerini izleme uygulamasına koymak istemez. Bunun yerine referanslar saklayın:

• GA4, Amplitude, Mixpanel, Looker vb. panolara bağlantılar
• Değerlendirme için kullanılan metrik ID'leri veya rapor tanımlayıcıları
• Kararın ve yorumun bir anlık görüntüsü (ne değişti, kimin için ve neden)

API'lerle çalışıyorsanız ham secret'ları veritabanında saklamayın. Mümkünse OAuth akışı kullanın veya tokenları özel bir secrets manager'da saklayın, uygulamada yalnızca dahili referans tutun.

Döngüyü kapatan bildirimler

Bildirimler dokümantasyonu canlı bir iş akışına çevirir. Eylemlere odaklı tutun:

• Bir yorum eklendi (açıklama isteği, bir bulgu paylaşıldı)
• Durum değişti (Planned → Running → Analyzing → Decided)
• Bir karar yayımlandı (paydaşların "ne oldu?" sormasını durdurmak için)

Bunları e-posta veya Slack/Teams'e gönderin ve tam deney sayfasına (örn. /experiments/123) derin bağlantı ekleyin.

Göç ve yedeklemeler için import/export

CSV import/export'u erken destekleyin. En hızlı yollarından biridir:

• Tablolardan veya başka bir araçtan göç
• Alanları topluca düzeltme (sahipler, etiketler, durumlar)
• Hafif yedeklemeler ve çevrimdışı paylaşım

İyi bir varsayılan, deneyleri, hipotezleri ve kararları ayrı ayrı dışa aktarmak ve tekrar içe aktarırken çoğaltmayı önleyecek stabil ID'ler sunmaktır.

İzinler, Denetlenebilirlik ve Veri Güvenliği

İnsanların sisteme güvenmesi izleme aracının çalışması için şarttır. Bu güven açık izinler, güvenilir bir denetim izi ve temel veri hijyeni ile inşa edilir—özellikle deneyler müşteri verisi, fiyatlandırma veya ortak bilgileri içeriyorsa.

İzinler: çalışma alanı, proje ve kayıt düzeyi

Ekiplerin gerçekte nasıl çalıştığına uyan üç katmanla başlayın:

• Workspace erişimi: ürüne genel erişim kimde (örn. çalışanlar vs. misafirler).
• Proje erişimi: belirli bir ürün alanını kim görüntüleyip katkıda bulunabilir (Growth, Onboarding, Payments).
• Kayıt-seviyesi kurallar: belirli bir hipotez veya deneyi kim görüntüleyebilir/düzenleyebilir (hukuki incelemeler, hassas ortaklıklar, lansman öncesi özellikler için yararlı).

MVP için rolleri basit tutun: Viewer, Editor, Admin. Gerekirse sonra "Owner" ekleyin.

Denetim izi: düzenlemeler, kararlar, silmeler

Bir metrik tanımı test ortasında değişirse bilmek istersiniz. Aşağıdakilerin değiştirilemez geçmişini saklayın:

• alan değişiklikleri (ne değişti, önce/sonra, kim, ne zaman)
• durum geçişleri ve kararlar (örn. "Shipped", "Stopped", "Inconclusive")
• silmeler (tercihen geri yüklenebilir soft-delete)

Denetim günlüğünü her kayıttan erişilebilir yapın ki reviewer'lar arama yapmak zorunda kalmasın.

Saklama, yedekleme ve kurtarma

Bir saklama temel çizgisi tanımlayın: deneyler ve ekler ne kadar süre tutulur ve biri şirketten ayrıldığında ne olur.

Yedeklemeler gösterişli olmak zorunda değil: günlük snapshot'lar, test edilmiş geri yükleme adımları ve "kimi arayacağın" çalıştırma kitabı yeterlidir. Dışa aktarma özelliği varsa proje izinlerine saygı gösterdiğinden emin olun.

Hassas bilgileri koruyun

PII'yi son çare olarak ele alın. Notlar için bir redaksiyon alanı (veya anahtar) ekleyin ve ham veriyi yapıştırmak yerine onaylı kaynaklara bağlantı vermeyi teşvik edin.

Ekler için adminlerin proje başına yüklemeyi kısıtlamasına (veya tamamen devre dışı bırakmasına) izin verin ve yaygın riskli dosya türlerini engelleyin. Bu, öğrenme deposunu kullanışlı tutarken uyumluluk sorunlarını azaltır.

MVP İçin Pratik Bir Teknoloji Yığını Seçin

MVP'nizin teknoloji yığını, mükemmellikten çok hızlı iterasyona odaklanmalı. Amaç, ekibin gerçekten kullanacağı bir şeyi yayına almak ve iş akışları ile veri ihtiyaçları doğrulanınca geliştirmektir.

Mimari: monolitle başlayın

MVP için basit bir monolit (tek kod tabanı, tek dağıtılabilir uygulama) genellikle en hızlı yoldur. Kimlik doğrulama, deney kayıtları, yorumlar ve bildirimler tek yerde olmak kolay hata ayıklama ve düşük işletme maliyeti sağlar.

Büyümeyi planlayarak tasarlayın: fonksiyonlara göre modülerleştirin (örn. "experiments", "learnings", "search"), temiz bir dahili API katmanı tutun ve UI ile veritabanı sorgularını sıkı bağlamayın. Benimsenme artarsa, daha sonra servisleri (arama, analitik, entegrasyonlar) ayırabilirsiniz.

Depolama: önce ilişkisel, dosyalar ayrı

İlişkisel bir veritabanı (PostgreSQL yaygın bir tercih) deney izleme için uygundur çünkü verileriniz yapılandırılmıştır: sahipler, durumlar, tarihler, hipotez, variantlar, metrikler ve kararlar. İlişkisel şemalar filtreleme ve raporlama işini tahmin edilebilir kılar.

Ekler (ekran görüntüleri, sunumlar, ham dışa aktarımlar) için nesne depolama (S3-uyumlu) kullanın ve veritabanında yalnızca meta verileri ve URL'leri saklayın. Bu yedeklemeleri yönetilebilir tutar ve veritabanınızı bir dosya dolabına çevirmez.

API stili: REST veya GraphQL—sade tutun

Her ikisi de çalışır. MVP için REST genellikle daha basit ve entegrasyonlar için daha anlaşılırdır:

• Hipotezler, deneyler, öğrenimler ve yorumlar için create/read/update endpoint'leri

Frontend çok sayıda "bir sayfa, birçok ilişkili nesne" ihtiyacı varsa GraphQL overfetching'i azaltabilir. Hangi yolu seçerseniz seçin, endpoint'leri ve izinleri basit tutun ki esnek ama güvenilmez bir API ile yayına çıkmayın.

Hızlı bulunurluk: tam metin aramayı erken ekleyin

Arama "öğrenme deposu" ile unutulmuş bir veritabanı arasındaki farktır. İlk günden tam metin araması ekleyin:

• Başlıklar, hipotezler, etiketler ve sonuçlar için native Postgres full-text search ile başlayın

Daha sonra daha iyi alaka sıralaması, yazım hatası toleransı veya alan bazlı ağırlıklandırma gerekirse özel arama servisi ekleyebilirsiniz. Ancak MVP, insanların "geçen çeyrekteki checkout deneyi"ni saniyeler içinde bulmasını sağlamalıdır.

Hızlı prototipleme için Koder.ai (isteğe bağlı)

Ana darboğazınız çalışan bir MVP'yi insanlara göstermekteyse, bu tür iç araçları Koder.ai ile prototiplemek işe yarayabilir. Bu platform chat arayüzüyle web uygulamaları oluşturmayı hızlandırır (genellikle React frontend, Go + PostgreSQL backend), kaynak kod dışa aktarımı, dağıtım/barındırma, özel domain ve snapshot/rollback gibi pratik özellikler sunar. Bu, şablonlar, durumlar, arama ve izinler gibi iş akışlarını doğrulamak için genellikle yeterlidir.

MVP Yol Haritası, Test ve Takım Benimsemesi

Bir deney izleme uygulamasının başarısı özelliklerde değil benimsenmede yatar. MVP'nizi bir ürün gibi planlayın: küçük gönderin, gerçek iş akışlarında test edin, sonra genişletin.

MVP (v1): olmazsa olmazlar

Bir ekibin işi sürtünmesiz dokümante edip geri bulmasını sağlayacak minimum:

• Hipotezler ve deneyler için CRUD (oluştur, düzenle, arşivle)
• Hipotez, deney planı ve sonuç şablonları ile tutarlı girdiler
• Arama + filtreler (durum, sahip, ürün alanı, tarih göre)
• Net durumlar (örn. Draft → Planned → Running → Analyzing → Decided)
• Yorumlar ve @mention ile tartışmayı kayda bağlama

Bir özellik giriş süresini veya bulunma süresini azaltmıyorsa ertelenmelidir.

Önce pilot, sonra yinele

V1'i küçük bir pilot ekibe (5–15 kişi) 2–4 hafta boyunca açın. Her yeni deneyi mutlaka orada kullanmalarını isteyin; sadece birkaç yakın tarihli deneyi geri doldurmalarını sağlayın.

Gerçekçi senaryolarla test edin:

• "Son üç fiyatlandırma deneyini 30 saniye içinde bulabiliyor muyum?"
• "Yeni bir ekip üyesi sahibine sormadan ne olduğunu anlayabiliyor mu?"

Geri bildirimi haftalık toplayın ve kafa karışıklığını gideren düzeltmeleri önceliklendirin: alan adları, varsayılan değerler, boş durumlar ve arama kalitesi.

Eğer platform yaklaşımı kullanıyorsanız (ör. MVP'yi Koder.ai üzerinde inşa edip iş akışları stabil olduğunda kodu dışa aktarmak), pilotu "planlama modu" olarak kullanın: veri modelini ve mutlu yol UX'i kilitleyin, ardından entegrasyonlar ve izin kenarlarını yineleyin.

v2: dikkatli genişletme

Kayıt düzenli hale geldikten sonra yüksek etkili yükseltmeleri ekleyin:

• Hafif panolar (duruma göre hacim, çevrim süresi, karar sonuçları)
• Entegrasyonlar (Slack bildirimleri, Jira/Linear bağlantıları, takvim hatırlatıcıları)
• Gelişmiş izinler (özel deneyler, kısıtlı alanlar)

Benimseme planı: alışkanlık haline getirin

İşleyiş normları belirleyin:

• Sahiplik: her takımda "Experiment Librarian" gibi biri şablonlar ve etiketleri düzenli tutar
• Düzen: yeni deneylerin kaydedildiği ve tamamlananların özetlendiği haftalık gözden geçirme
• Tamamlanma tanımı: bir deney "kapalı" sayılmazsa öğrenimler yazılıp karara bağlanana kadar

Bu normları kısa bir iç sayfada dokümante edin (örn. /playbook/experiments) ve onboarding'e ekleyin.