4 tips terbaik untuk membangun produk data berkualitas tinggi dari SYNQ/Habr

Terkadang obrolan kantor Anda tidak berhenti dibanjiri peringatan, ujian telah berakhir selama sebulan, dan tidak ada yang benar-benar tahu siapa yang bertanggung jawab atas apa – atau bahkan apa yang penting.

Mikkel Dengsø dan Petr Janda, bersama dengan tim data dari ratusan startup dan perusahaan Fortune 500, menyusun sebuah Panduan untuk Membangun Produk Data Berkualitas Tinggi. Ini diperuntukkan bagi mereka yang bosan dengan kekacauan dan ingin menertibkan pengujian, manajemen kualitas, dan respons insiden.

Berikut adalah wawasan utama dan kasus-kasus dunia nyata.

Melarikan diri dari garis keturunan spageti

Aiven memiliki lebih dari 900 model dbt. Karena ketergantungan melingkar, garis keturunan berubah menjadi spageti yang berantakan. Perhitungan penting seperti ARR memiliki ratusan ketergantungan upstream: setiap perubahan akan mengguncang separuh tumpukan.

Kategorinya terlalu luas: Pemasaran, Penjualan, Produk. Ketika data rusak, peringatan hanya akan berbunyi Pemasaran sedang menurun. Tidak ada yang tahu:

Diagnosisnya lambat, perbaikannya bahkan lebih lambat.

Dengan secara metodis memecahkan ember besar seperti itu Pemasaran menjadi produk yang lebih kecil seperti Atribusi PemasaranAiven mempercepat deteksi kesalahan dan memperjelas kepemilikan.

Aturan 1: pikirkan produk, bukan departemen

Pisahkan kategori yang tidak jelas seperti Pemasaran menjadi produk terfokus: Atribusi, CLTV, Riset Pasar. Dengan begitu, ketika ada sesuatu yang gagal, akan terlihat jelas apa yang sebenarnya rusak dan seberapa mendesak perbaikannya (atribusi = segera, penelitian = nanti).

Setiap produk harus memiliki kartu pendek yang disimpan di samping kode: tugas, pemilik (tim dan saluran), prioritas (P1–P4), masukan/keluaran, dan daftar tabel/model utama.

Aturan 2: pertahankan kedalaman yang tepat

Produk yang terlalu besar tidak membantu dalam penentuan prioritas. Di Aiven mereka menelusuri domainnya: di dalam Pemasaran mereka berpisah Atribusi (P1) dan Riset Pasar (P3). Tiba-tiba prioritas tidak lagi bisa diperdebatkan.

Aturan 3: tetapkan kepemilikan seperti orang dewasa

Bukan “seluruh tim data” dan bukan “satu pahlawan”. Ikat kepemilikan ke tim tertentu dan salurannya, simpan dalam metadata (tag pemilik, grup dbt), dan periksa di CI bahwa setiap model memiliki pemilik. Eskalasi kemudian menjadi dapat diprediksi.

Jika semuanya merupakan prioritas utama, tidak ada yang menjadi prioritas utama

Ini seperti torrent: jika Anda menetapkan prioritas tinggi untuk semua unduhan sekaligus, tidak ada yang berubah, karena bobot relatifnya tetap sama.

Itulah yang terjadi di Lunar, di mana setiap tim menganggap data mereka adalah yang paling penting. Dan semuanya benar – tetapi hanya untuk dirinya sendiri. Elemen-elemen dalam sistem tidak dapat menilai seberapa penting elemen-elemen tersebut.

Solusinya sederhana: sekali setiap kuartal, pimpinan seluruh tim mulai bertemu untuk menentukan produk data paling penting untuk periode mendatang dan menetapkan SLA yang jelas, seperti waktu respons terhadap kegagalan.

Aturan 1: tetapkan prioritas dari atas ke bawah

Jika setiap tim menandai datanya sebagai P1, Anda tidak dapat mengatur apa pun: semua yang penting = tidak ada yang penting.

Bagaimana cara melakukannya:

• Seperempat sekali, jalankan “dewan prioritas†(tingkat C + prospek produk dan data).

• Buat daftar 10 produk data penting teratas yang terpadu untuk kuartal ini.

• Putuskan berdasarkan kriteria sederhana: risiko uang, dampak pelanggan, risiko peraturan.

• Selebihnya, tetapkan P2/P3/P4 dengan tingkat kepentingan menurun.

Aturan 2: ikat prioritas pada tindakan dan tenggat waktu

Tag P1 tanpa tenggat waktu hanyalah sebuah label. Setiap level harus memiliki respon dan tujuan pemulihan yang jelas.

Bagaimana cara melakukannya:

• P1 (berhadapan dengan pelanggan): pengakuan – 5 menit, deteksi – dalam 10 menit, pemberitahuan pelanggan – dalam waktu 30 menit, solusi sementara segera, perbaikan pada prioritas utama.

• P2 (ekspor/latar belakang penting): pengakuan — 30 menit, diperbaiki pada hari yang sama.

• P3 (analytics/BI): pada akhir hari kerja berikutnya.

• P4 (risiko rendah): backlog.

Setiap level P memerlukan pemilik yang ditugaskan dan siap dipanggil.

Aturan 3: pertahankan prioritas

Prioritas cenderung menyimpang – semuanya kembali menjadi P1.

Bagaimana cara melakukannya:

• Batasi P1. Misalnya, tidak lebih dari 8 produk P1 di seluruh perusahaan. Untuk menambahkan yang baru, hapus yang lama.

• Tinjauan triwulanan. Segarkan daftar 10 teratas, periksa apa yang benar-benar berdampak pada pendapatan dan pelanggan.

• Tingkatkan filter. Tingkatkan prioritas hanya jika ada kasus bisnis: risiko uang, dampak terhadap pelanggan, dan peraturan.

• Papan publik. Tabel berdasarkan domain: daftar produk, level-P, SLA. Terlihat oleh semua orang.

Jangan menguji semuanya – atau Anda akan tenggelam dalam kebisingan

Di Google dan Monzo, mereka menguji setiap tabel dan kolom sejak awal. Itu berarti ratusan peringatan, sebagian besar tidak relevan.

Pergeseran strategi membantu: menguji sumber-sumber yang menjadi sandaran segalanya. Kebisingan berkurang, keandalan meningkat.

Aturan 1: ikat setiap ujian dengan suatu tindakan

Sebuah ujian tanpa langkah selanjutnya yang jelas adalah sampah. Hanya atur pemeriksaan yang sudah diketahui sebelumnya: siapa yang bereaksi, apa yang mereka lakukan.

Contoh:

Pesanan kemarin tidak sampai pada pukul 08:15 â†' pemilik memulai kembali pekerjaan, jika gagal â†' beralih ke sumber cadangan dan memperbarui status.

Tes buruk:

Harga kolom memiliki nol. Jika tidak ada perbaikan yang dijelaskan, peringatan itu hanyalah suara bising.

Sebuah tes berguna:

Jika, lebih dari seperempat, hal ini menghasilkan setidaknya N perbaikan dan hampir tidak ada positif palsu. Jika tidak, tulis ulang atau hapus.

Aturan 2: uji node berdampak tinggi

Jangan tersebar di ratusan meja. Fokus pada titik pengaruh – titik dimana banyak artefak hilir bergantung: katalog produk, direktori pelanggan, beban pembayaran, gabungan kunci.

Buatlah daftar pendek berisi ~20 node teratas dan perkuat pengujian di sana: format, kelengkapan, duplikat, stabilitas skema, nilai batas.

Bug dalam katalog produk memecah harga, stok, dan margin di sepuluh laporan. Satu pengujian yang solid di sana mengalahkan seratus pengujian di bagian hilir.

Aturan 3: jaga agar pengujian tetap bersih dan ramping

Tes bertambah banyak, menua, dan mulai mengirim spam. Tim tenggelam dalam peringatan dan berhenti bereaksi.

Sebelum menambahkan tes, tulis paspor 3 baris:

Sasaran (apa yang ditangkapnya) â†' Pemilik (siapa yang memperbaiki) â†' Tindakan (apa yang harus dilakukan ketika dipicu). Jika ada yang hilang, jangan tambahkan tes.

Anggaran peringatan:A

Tetapkan batas, misalnya, maksimal 5 peringatan/hari per tim. Jika terlampaui – jeda pengujian baru, bersihkan pengujian yang berisik.

Nilai ulasan bulanan vs. kebisingan:

• Jumlah pemicu.

• Berguna (menyebabkan perbaikan).

• Salah/duplikat.

0 berguna dalam 90 hari â†' hapus/ulangi.

30% positif palsu â†' tulis ulang (ambang batas, jendela, kondisi).

Duplikat â†' digabungkan.

Kalender pengecualian:A

Rencanakan waktu henti vendor, jangka waktu pemeliharaan, hari libur. Sesuaikan ambang batas kesegaran pada waktu tersebut untuk menghindari peringatan “salah” yang direncanakan.

Siklus hidup:A

Draf â†' Aktif â†' Terverifikasi â†' Tidak berlaku lagi â†' Diarsipkan. Tandai sebagai Tidak digunakan lagi setelah 90 hari tidak ada nilainya, Arsip pernah diganti.

Contoh:

Uji “Pesanan hari Senin yang sangat sedikit” memiliki 12 pemicu, 10 salah (hari libur). Menambahkan kalender + jendela tunggu hingga pukul 10:00 — sekarang 3 pemicu, 3 perbaikan, 0 salah. Kegunaan meningkat, kebisingan hilang.

Moral:A

Memperbaiki kesalahan di hilir ibarat memberi air, memperbaiki kesalahan sumber ibarat menambal kebocoran.

Ubah risiko menjadi kepercayaan

Shalion adalah platform analitik e-niaga: klien melihat dasbor dan ekspor yang menjadi dasar keputusan mereka. Produknya adalah data waktu nyata.

Ketika data adalah produknya, kepercayaan pelanggan adalah KPI utamanya. Kesalahan tidak bisa dihindari: jaringan pipa gagal, skema berubah, kelambatan bertambah. Bahayanya bukanlah kesalahan itu sendiri, tapi keheningan, kepemilikan yang kabur, dan membanjirnya peringatan kosong.

Berikut adalah aturan kerja Shalion: bagaimana membuat peringatan dapat ditindaklanjuti, melindungi fokus tim, menyepakati keandalan yang realistis, dan mengukur tidak hanya “apa yang berhasil” tetapi juga “apa yang terkendali.” Dengan cara ini, risiko berubah menjadi kepercayaan.

Aturan 1: setiap peringatan harus mengarah pada tindakan

Setiap notifikasi adalah sebuah rencana kecil, bukan teriakan “Kita dikutuk”. Peringatan harus mencakup: apa yang rusak, di mana, siapa pemiliknya, siapa yang terkena dampaknya, apa yang harus dilakukan (tautan ke instruksi, rantai ketergantungan). Sepakati waktu respons: pengakuan dalam 5 menit, eskalasi dalam 10 menit. Kemudian peringatan diperbaiki, bukan hanya dibaca.

Aturan 2: lindungi perhatian tim

Jangan mengirimkan 150 peringatan “kesegaran menurun” jika satu saluran pipa gagal. Kirimkan satu peringatan akar permasalahan yang mencantumkan semua mart yang terkena dampak dan pemiliknya. Hal-hal yang tidak penting harus dimasukkan ke saluran khusus atau ulasan mingguan.

Aturan 3: sepakati kenyataan sebelumnya

Tidak semuanya membutuhkan 99,9%. Untuk data yang berhubungan langsung dengan pelanggan – ya, Untuk toko internal – sering kali 95% sudah cukup. Itu adalah rekayasa ekonomi yang normal: keandalan yang mahal tidak akan membuahkan hasil jika risikonya rendah. Setuju dengan klien mengenai hal ini sebelum kejadian.

Di Shalion mereka tidak berpura-pura kesalahan tidak pernah terjadi. Mereka menemukannya dengan cepat, memperbaikinya, dan memberi tahu klien secara terbuka. Dengan begitu, ancaman terhadap kepercayaan menjadi sumber kepercayaan. Angkat topi.

Aturan 4: ukur bukan hanya “cara kerjanya” tapi juga “apa yang tercakup”

Dasbor hijau dapat menyembunyikan sumber merah. Jika Anda hanya melihat pemeriksaan yang lewat di data mart, Anda akan kehilangan berapa banyak objek penting yang tidak dipantau sama sekali — kegagalan akan lolos dan mencapai kepercayaan.

Lacak dua metrik:

Cara membacanya:

• Cakupan Rendah, Kualitas Tinggi â†' ilusi stabilitas. Pertama-tama perluas cakupan ke bagian hulu yang penting (konektor, sambungan kunci), jika tidak, Anda akan melewatkan kegagalan berikutnya.

• Cakupan Tinggi, Kualitas Rendah â†' semuanya terlihat, namun berfungsi buruk. Perbaiki akar permasalahan: selaraskan dengan sumbernya, optimalkan pipeline, kurangi MTTR, dan perkuat pengujian jika ada kerusakan.

• Keduanya â†' tinggi menangkap praktik tersebut dan mempertahankan levelnya.

Jika Cakupan = 60% dengan Kualitas = 99%, itu adalah kenyamanan yang berbahaya: 40% dari rantai tidak terlihat. Naikkan Cakupan hingga 90%, lalu tingkatkan Kualitas.

Jika semua data yang diperiksa terlihat baik-baik saja, berarti Anda tidak memeriksa bagian yang rusak.

---

Panduan ini tidak terikat pada alat tertentu – ini tentang prinsip. Dapat digunakan untuk tim yang terdiri dari 5 orang dan departemen besar, terlepas dari skala perusahaan atau kematangan data.

Simpan, bagikan dengan rekan-rekan.