Teknik Olmayan Takımlar İçin Veri Sözlüğü Şablonu

Paylaşılan veriler konusunda ekipler neden karışır

Paylaşılan veriler tek bir basit nedenle karışır: insanlar aynı kelimeleri farklı şeyler için kullanır veya farklı kelimeleri aynı şey için kullanır. Bir satış yöneticisi "customer stage" diyebilir, bir destek lideri "account status" diyebilir ve bir geliştirici uygulamada state alanını etiketleyebilir. Bu fikirler ilişkili olabilir ama her zaman aynı değildir.

Ekip büyüdükçe veya araçlar adım adım inşa edildikçe sorun daha da kötüleşir. Bir zamanlar bir elektronik tabloda anlamlı olan bir alan adı, süreç değiştikten sonra bile kalabilir. Ardından aynı değer formlarda, panolarda, dışa aktarımlarda ve uygulama ekranlarında hafifçe farklı adlarla görünür. Paylaşılan bir veri sözlüğü şablonunuz yoksa küçük adlandırma farkları günlük karışıklığa dönüşür.

Çoğu problem birkaç tekrarlayan kalıptan kaynaklanır:

• Aynı alan farklı araçlarda veya ekranlarda yeniden adlandırılır.
• Bir statü satış için bir şey, destek için başka bir şey ifade eder.
• Bir metrik zaman içinde değişir ama kimse kuralını yazmaz.
• İnsanlar bir etiketin gerçekten ne anlama geldiğini sürekli takım arkadaşlarına sorar.

Statüler basit göründüğü için hatalara yol açar. "Open", "Active" veya "Resolved" gibi kelimeler net gelirken, ekipler bunları gerçek işte farklı kullanabilir. Destekte "Resolved" sorunun çözümü anlamına gelirken; satışta müşterinin yanıt vermesi anlamına gelebilir. Aynı raporu okuyan iki ekip farklı sonuçlarla ayrılabilir.

Metrikler farklı bir karışıklık türü yaratır. Bir pano "new customers" veya "monthly revenue" gösterebilir, ama kimse tam kuralı yazmadıysa insanlar boşlukları kendi varsayımlarıyla doldurur. "New customer" ilk kaydı mı, ilk ödemeyi mi, yoksa ilk tamamlanan onboarding'i mi ifade eder? Bir rapordan diğerine cevap değiştiğinde güven hızla düşer.

Gizli maliyet zamandır. İnsanlar durup açıklama ister, toplantılar uzar ve raporlar yeniden çalışılır. Geliştiriciler, etiketler bariz göründüğü için önlenebilir hatalar yapar. Bu, no-code gibi hızlı hareket edilen çalışmalarda daha da önem kazanır. AppMaster gibi formlar, iş mantığı ve raporları hızla oluşturabildiğiniz araçlarda, belirsiz tanımlar aynı hızla yayılır.

Hafif bir veri sözlüğü neler içermeli

İşlevsel bir veri sözlüğünün uzun olması gerekmez. Temel olarak bir alan, bir statü veya bir metriğin ne anlama geldiğini görüp anlamayan kişilerin sorduğu soruları yanıtlaması yeterlidir.

Basit bir veri sözlüğüne başlıyorsanız, günlük hataları önleyen detaylara odaklanın. Bir satış yöneticisi, destek lideri ve geliştirici aynı tanımı okuduğunda aynı anlayışla ayrılmalıdır.

Her alan için şu temel bilgileri kaydedin:

• Alan adı, uygulamada veya raporda göründüğü biçimiyle
• Değerin neyi temsil ettiğini açıklayan sade bir anlam
• Statüler, kategoriler veya evet-hayır seçimleri gibi kontrol edilen alanlar için izin verilen değerler
• Verinin kaynağı: kullanıcı girişi, sistem tarafından oluşturulan değer veya içe aktarılan kayıt gibi
• Değişiklikleri onaylayan ve soruları yanıtlayan bir net sahip

Bu çoğu karışıklığı çözer. Ayrıca değerin ne sıklıkla değiştiğini not etmek yardımcı olur. Bazı alanlar oluşturulduktan sonra sabit kalır, örneğin kayıt tarihi. Diğerleri sık güncellenir, örneğin bilet statüsü veya hesap bakiyesi. Bu küçük satır, biri rapor oluştururken veya otomasyonda veriyi kullanırken bağlam sağlar.

Basit bir giriş şöyle görünebilir:

Field: ticket_status
Meaning: Destek biletinin güncel aşaması
Allowed values: New, In Progress, Waiting on Customer, Resolved, Closed
Source: Destek personeli veya otomasyon kuralları tarafından güncellenir
Owner: Destek operasyonları yöneticisi
Change frequency: Biletin ömrü boyunca değişir

Sözlüğü hafif ama belirsiz olmayan tutun. Yeni bir ekip üyesi hâlâ bir alanın ne anlama geldiğini sormak zorunda kalıyorsa, tanım tamamlanmamıştır.

Yeniden çalışmayı önleyen alan adlandırma kuralları

Alan adlarının en iyi haliyle sıkıcı olması gerekir. İnsanlar bir alanı gördüğünde yardım istemeden ne anlama geldiğini bilmelidir.

Önce tek bir adlandırma biçimi seçin ve her yerde onu kullanın. Ekip customer_name kullanıyorsa, bir ekranda CustomerNamea ve diğerinde clientNamea geçmeyin. Tek bir kalıp formları, raporları ve API etiketlerini herkes için okumayı kolaylaştırır.

Kısaltmalar çoğunlukla sorun yaratır. addr, amt veya lvl hızlı yazılıyor gibi görünse de sonra herkesin yavaşlamasına neden olur. Bir kısaltma gerçekten şirket içinde yaygınsa kullanın; değilse tam kelimeyi yazın.

İsimler gerçek iş sürecine uymalı, dahili kısayollara değil. Bir destek uygulamasında ekip her zaman "ticket" diyorsa, ticket_status case_state'den daha açıklayıcıdır. Sistem kelimeleri toplantılarda, belgelerde ve günlük işte kullanılan kelimelerle uyumlu olmalıdır.

Her alan adının yalnızca bir anlamı olmalıdır. Eğer owner bir yerde destek temsilcisini, başka bir yerde hesap yöneticisini ifade ediyorsa karışıklık kaçınılmazdır. Bunları support_agent ve account_manager gibi daha net isimlere bölün.

Bir isim hâlâ iki şekilde okunabiliyorsa, sözlüğe bir örnek değer ekleyin. Bu küçük detay zaman kazandırır. Örneğin:

• customer_type - Örnek: business, individual
• order_total - Örnek: 149.99
• first_response_at - Örnek: 2026-03-08 09:30 UTC

Basit bir alan adlandırma standardı genellikle yeterlidir:

• Mümkünse tam kelimeleri kullanın.
• Aynı şey için her yerde aynı terimi tutun.
• İç jargon yerine iş kelimelerini tercih edin.
• Zaman ve tarih alanlarını belirgin yapın, örn. created_at veya closed_date.
• Bir alan yanlış anlaşılabilecekse örnek değer ekleyin.

Net adlandırma, şaşırtıcı derecede fazla yeniden çalışmayı ortadan kaldırır. İş kullanıcıları ve geliştiriciler raporlar ve panolar karışmadan önce aynı dili konuşur.

Statüleri gerçek işe göre tanımlayın

Statüler basit görünür ama iki kişi aynı kelimeyi farklı kullanırsa sorun çıkar. Birisi "Resolved" dediğinde müşteri için bir çözüm olduğunu kastedebilir; başka biri sadece sebep bulunduğunu kastediyor olabilir. Bu küçük fark kötü raporlara, karışık devirlere ve gereksiz takiplere yol açar.

İyi bir kural: her statüyü belirsiz niyetler yerine gerçek iş açısından tanımlayın. Her statü şu düz bir soruyu yanıtlamalı: şu anda ne doğru? Günlük işten bu cevap kolay çıkmıyorsa, statü daha iyi bir ad veya daha net bir tanım gerektirir.

Her statü için plain bir dilde anlamını, ne zaman kullanılacağını, seçilmeden önce ne olması gerektiğini, bunun final bir statü olup olmadığını ve kimlerin değiştirebileceğini yazın.

En büyük kontrol örtüşmedir. Eğer "In Review" ve "Pending Approval" aynı kaydı aynı anda tanımlayabiliyorsa, insanlar rastgele seçim yapar. Bu da raporları güvenilmez kılar. Her statü sürecin tek bir noktasını işaret etmelidir.

Final statüler ekstra dikkat ister. İşin durduğunu veya bir son durumuna ulaşıldığını herkesin bilmesi için bunları açıkça işaretleyin. Yaygın final statüler arasında "Completed", "Canceled" ve "Rejected" bulunur. Bir kayıt daha sonra yeniden açılabiliyorsa bunu da not edin. Final her zaman kalıcı değildir.

Sahiplik anlam kadar önemlidir. Bazı statüler yalnızca bir yönetici, destek lideri veya sistem kuralı tarafından değiştirilmeli. Herkes her statüyü değiştirebiliyorsa süreç hızla sapar.

Küçük bir örnek yardımcı olur. Bir destek uygulamasında "Waiting for Customer" takımın zaten yanıt verdiği ve müşteri yanıt verene kadar ilerlenemeyeceği anlamına gelmelidir. İçsel incelemenin sürdüğü durum için kullanılmamalıdır; o durum için "In Progress" gibi farklı bir statü gerekir.

Birisi statü tanımını okuyup her seferinde aynı seçimi yapabiliyorsa, statü adlandırma örnekleriniz amacına ulaşmıştır.

Her metriğe sabit bir tanım verin

Bir metrik, iki kişinin okuduğunda aynı anlamı çıkarabilmesi durumunda işe yarar. Satış, destek ve panoyu yapan kişi farklı tanımlıyorsa sayı güvenilir olmaktan çıkar.

İyi bir metrik tanımı şablonu birkaç basit soruyu cevaplamalı: metrik neyi ölçer, nasıl hesaplanır, neler dahil edilir, neler hariç tutulur, hangi zaman dilimini kullanır ve ne zaman güncellenir. Bunlardan herhangi biri eksikse insanlar kendi tahminlerini kullanır.

Basit bir metrik kartı kullanın

Her metrik için her seferinde aynı yapıyı kullanın:

• Metrik adı
• Sade dilde formül
• Dahil olan kayıtlar
• Hariç tutulan kayıtlar
• Zaman periyodu
• Yenileme sıklığı
• Örnek hesaplama

Formülü okunabilir tutun. Sadece Resolved tickets / Total tickets yazmak yerine: "Çözüm oranı, aynı dönemde oluşturulan toplam bilet sayısına bölünen çözümlenmiş bilet sayısıdır." gibi yazın.

Sonra hangi kayıtların sayıldığını tam olarak belirtin. Yeniden açılan biletler çözümlenmiş sayılmıyorsa bunu yazın. Spam, test biletleri veya birleştirilmiş kopyalar sayımdan çıkarılıyorsa bunları da not edin.

Zaman periyodu formül kadar önemlidir. "Monthly resolution rate" takvim ayını mı, son 30 günü mü yoksa özel bir raporlama penceresini mi ifade ediyor, bunu belirtin. Bunlar aynı değildir.

Yenileme sıklığına da kısa bir not ekleyin. Saat başı güncellenen bir pano canlı sayaç gibi okunmamalıdır. "Her 60 dakikada bir yenilenir" gibi kısa bir satır kötü kararları önler.

Destek uygulamasından basit bir örnek:

Metric name: First response rate
Formula: Yeni biletlerden 4 iş saati içinde ilk yanıt alanların sayısı, aynı dönemdeki toplam yeni bilet sayısına bölünür
Included: Yeni müşteri biletleri
Excluded: Spam, dahili test biletleri ve destek gelen kutusu dışında oluşturulan biletler
Time period: Önceki takvim haftası, Pazartesi ile Pazar
Refresh timing: Her gün 08:00'de
Sample calculation: 180 bilet alındı, 135'i 4 iş saati içinde yanıtlandı. İlk yanıt oranı = 135 / 180 = %75

Her metrik aynı desene uyduğunda güven hızla artar. İnsanlar sayılar hakkında tartışmak yerine onları kullanmaya başlar.

İlk sürümü nasıl oluşturursunuz

Bir veri sözlüğü gerçek işten oluşturulduğunda en iyi şekilde çalışır, kuramdan değil. Küçük başlayın. Haftada en çok kullanılan alanları, statüleri ve raporları seçin; çünkü karışıklığın zaman kaybettirdiği yerler bunlardır.

Eğer dahili bir araç, destek portalı veya yönetici paneli inşa ediyorsanız, herkesin bildiği bir iş akışıyla başlayın. Bir müşteri destek süreci iyi bir örnektir: bilet statüsü, öncelik, atanmış temsilci, ilk yanıt süresi ve çözüm süresi.

Basit bir yayılım genellikle şöyle görünür:

1. Formlardan, tablolardan, filtrelerden, panolardan ve dışa aktarılan raporlardan en çok kullanılan alanları çekin.
2. Satış, destek, operasyon ve uygulamayı yapan kişiler arasında zaten kullanılan isimleri toplayın.
3. Farklı versiyonları görünür kılmak için hepsini tek bir taslağa koyun.
4. Kısa bir inceleme toplantısı yapın ve her öğe için onaylanmış bir isim, sade dilde bir tanım ve bir örnek ile ayrılın.
5. Müşteri verisi, destek statüleri veya finans metrikleri gibi her alan için bir sahip atayın.

O toplantıdan sonra sözlüğü hem iş kullanıcılarının hem de geliştiricilerin gerçekten göreceği bir yerde saklayın. Gizli bir dosyada kaldığında insanlar tekrar tahmin etmeye başlar. Ekip zaten uygulamayı planlarken veya güncellerken kullandığı belgelerin yanında tutun.

İlk sürümü hafif tutun. Her öğe için onaylanmış isim, anlam, gerekiyorsa izin verilen değerler, sahip ve son güncelleme tarihini yakalayın. Bu, belgeyi kendi başına bir projeye dönüştürmeden uyumu sağlar.

AppMaster içinde geliştiriyorsanız, bu isimleri erken karara bağlayın. AppMaster backend, web ve mobil parçaları aynı uygulama için üretebildiği için bir belirsiz terim formlara, iş süreçlerine ve panolara aynı anda yayılabilir.

Örnek: basit bir müşteri destek sözlüğü

Küçük bir ekip sözlüğü pek çok karışıklığı ortadan kaldırabilir; özellikle de aynı alanların her yerde göründüğü destek işlerinde.

Uygulama genelinde görünen ticket_status gibi tek bir alanla başlayın. Bu kesin isim veritabanında, formlarda, filtrelerde, panolarda ve devretme notlarında aynı kalmalıdır. Bir ekranda "Resolved" diğerinde "Done" yazarsa insanlar tahmin etmeye başlar.

Temiz bir statü seti şöyle görünebilir:

• Open: Destek ekibinin hâlâ işlem yapması gereken yeni bir bilet
• Waiting: Ekip yanıtladı veya ilerlemek için bir şeye ihtiyaç var
• Resolved: Ekip sorunun çözüldüğüne inanıyor ve şu an için daha fazla aksiyon gerekmiyor
• Closed: Bilet tamamlandı ve normal günlük işten çıkarıldı

Önemli olan etiketin arkasındaki kuraldır. Bir bilet yalnızca ekip bir cevap veya düzeltme sağladıktan sonra Resolved olmalıdır. Closed ise genellikle bekleme süresi veya son inceleme gibi işlemler tamamlandıktan sonra olmalıdır.

Şimdi sık tartışılan bir metriği ekleyin: first_response_time. Bunu bilet oluşturulması ile destek ekibinin ilk insan yanıtı arasındaki süre olarak tanımlayın. Güvenilir tutmak için spam, kopya ve test biletlerini hariç tutun. Otomatik mesajların sayılıp sayılmayacağını da kararlaştırın; çoğu ekipte sayılmazlar.

Öncelik şu kadar basit olmalı ki herkes aynı seçimi yapsın:

• High: Müşteri önemli bir özelliği kullanamıyor
• Medium: İş akışı engellenmiş, ama bir geçici çözüm var
• Low: Genel sorular, küçük sorunlar veya istekler

Bu yaklaşım sadece tüm alanların aynı kelimeleri kullanmasıyla çalışır. Veri modeli, formlar, iş akışları ve raporlar aynı terimleri kullandığında devretmeler kolaylaşır ve raporlama daha güvenilir olur.

Kaymaya neden olan yaygın hatalar

İyi bir veri sözlüğü bile ekiplerin beklediğinden daha hızlı demode olabilir. Kayma genellikle zararsız görünen küçük değişikliklerle başlar ve günlük karışıklığa dönüşür.

Yaygın bir sorun, benzer duyulan ama farklı anlamları olan etiketlerin kullanılmasıdır. Bir destek ekibi "Closed" ile biletin tamamlandığını kastedebilir, başka biri ise aynı fikri "Resolved" ile ifade ediyorsa raporlarda bir arada görünmeleri insanlarin gördüklerine güvenini azaltır.

Bir diğer sorun formüllerin yarım tanımlanmasıdır. "Active customers" gibi bir metrik, son 7 gün mü, 30 gün mü yoksa bu ay mı gibi sorulara açık kalırsa, her pano sahibi bunu biraz farklı hesaplayabilir.

Kenar durumları genellikle nadir göründüğü için atlanır, ancak tartışmalar ilk olarak nadir durumlarda ortaya çıkar. Bir iade satıştan sonra gerçekleşirse gelir metriği orijinal ayı mı yoksa güncel ayı mı etkiler? Sözlüğe kısa bir örnek eklemek uzun tartışmaları önler.

Çok pratik bir hata, uygulamada bir ismi değiştirip belgeyi güncellememektir. Bir geliştirici "Client Type"ı "Account Segment"e güncellediğinde, sözlüğün de hemen güncellenmesi gerekir.

Sahiplik başka bir zayıf nokta. Herkes belgeyi düzenleyebiliyorsa ama kimse açıkça sorumlu değilse belge yavaşça çoğaltmalar, eski terimler ve çelişen notlarla dolar. İnsanlar özel kopyalar yapmaya başlar ve kayma kötüleşir.

Kısa bir sağlık kontrolü yardımcı olabilir: Herhangi iki terim benzer mi ama farklı mı anlaşılıyor? İki kişi aynı metriği hesaplayıp farklı sonuç alabilir mi? Kenar durumlar belgelenmiş mi? Uygulama etiketleri hâlâ sözlükle uyumlu mu? Bunlardan herhangi birine hayır cevabı veriyorsanız kayma başlamıştır.

Paylaşmadan önce gözden geçirin

Belgeyi yayınlamadan önce hızlı bir gözden geçirme yapın. Paylaşılan bir referans ancak insanlar onu aynı şekilde okuyup ondan aynı seçimleri yapabiliyorsa işe yarar.

Paylaşmadan önce şu noktaları kontrol edin:

• Her alan adı net ve spesifik mi?
• Her statü sade bir dilde anlam taşıyor mu?
• Her metrik nasıl hesaplandığını, nelerin sayıldığını ve hangi zaman aralığını kullandığını gösteriyor mu?
• Her öğenin belirli bir sahibi var mı?
• Güncelleme tetikleyicisi yazılı mı (ör. yeni özellik, statü değişikliği, yeni rapor veya iş akışı güncellemesi)?

Bu inceleme özellikle rollout öncesinde önemlidir. Tek bir belirsiz alan bile formlara, panolara ve otomasyonlara karışıklık sokabilir.

Basit bir kural: Bir ekip üyesi belgeyi açıp toplantı olmadan doğru şekilde kullanabiliyorsa paylaşmaya hazırdır. Değilse, önce belirsiz kısımları düzeltin.

Rollout sonrası kullanışlı tutmak

Bir veri sözlüğü şablonu, ilk taslaktan sonra da insanlar kullandıkça yardımcı olur. Bunu sağlamak için sözlüğü tek seferlik bir görev olarak değil, ekip için çalışan bir belge olarak ele alın.

Bir süreç değiştiğinde gözden geçirin. Destek ekibiniz yeni bir bilet adımı eklediyse veya satış ekibi nitelikli lead tanımını değiştirdiyse tanımı hemen güncelleyin. Küçük süreç değişiklikleri genellikle daha sonra büyük raporlama sorunları yaratır.

Yeni bir proje başladığında sözlüğü ilk günden itibaren dahil etmek de yardımcı olur. Bir ekip yeni bir uygulama, pano veya rapor başlattığında ilk birkaç alan adı, statü ve metrik belgeye fazla inşa edilmeden önce girilmelidir.

Güncellemeleri küçük ve düzenli tutun. Çoğu ekip büyük aylık temizlik toplantısına ihtiyaç duymaz. Planlama, sürüm incelemesi veya rapor kurulumu sırasında kısa bir kontrol genellikle yeterlidir.

İnsanlar hâlâ "Bu alan ne anlama geliyor?" veya "Neden bu sayı farklı görünüyor?" diye soruyorsa sözlük güncellenmeli demektir. Bu her araçta geçerlidir ve özellikle AppMaster gibi ekiplerin üretime hazır uygulamaları hızlıca oluşturabildiği araçlarda önemlidir. Net adlar ve net tanımlar, hızın karışıklığa dönüşmesini önler.