Studi Kasus

Pemilik data yang tidak ditugaskan

Fitur AI gagal pada batas organisasi antara tim yang membangun sistem dan tim yang memiliki data. Batas itu jarang disebutkan dalam rencana proyek, dan itulah tempat jadwal menjadi bermasalah.

Kegagalan yang terlihat seperti masalah teknik

Sistem telah dibangun, pipeline berjalan, dan evaluasi dapat diterima. Kemudian corpus bergeser: sistem sumber mengubah sebuah bidang, sebuah folder diatur ulang, sebuah set dokumen berhenti diperbarui karena orang yang memeliharanya pindah tim. Kualitas jawaban memburuk selama beberapa minggu, dan tim teknik tidak dapat memperbaikinya, karena perbaikan tidak ada di kode.

Tidak ada yang sulit dalam cerita ini. Ini hanya tidak dimiliki.

Mengapa kepemilikan adalah ketergantungan sebenarnya

Fitur AI yang dibangun di atas data perusahaan memiliki ketergantungan pada orang di luar tim pembangun, dan ketergantungan tersebut berperilaku berbeda dari ketergantungan perangkat lunak. Mereka tidak memiliki versi, mereka tidak gagal dengan keras, dan mereka berubah ketika organisasi berubah. Tiga di antaranya menyebabkan sebagian besar risiko jadwal.

Refresh. Siapa yang bertanggung jawab untuk corpus mencerminkan keadaan bisnis saat ini, dengan cadence apa, dan bagaimana seseorang akan memperhatikan jika itu berhenti?

Schema. Bidang mana yang ada, mana yang sudah tidak digunakan, dan siapa yang diberitahu ketika satu berubah makna. Bidang yang berganti nama adalah kegagalan pengambilan yang sunyi, bukan crash.

Entitlement. Pemetaan antara model izin sistem sumber dan daftar kontrol akses indeks harus dipelihara oleh seseorang dengan wewenang atas sumber. Itu jarang seorang insinyur.

Membuatnya eksplisit

  • Sebutkan nama orang, bukan tim, untuk setiap sumber data, dan sebutkan nama cadangan. Kepemilikan yang tidak memiliki staf adalah tidak dimiliki.
  • Tulis cadence refresh ke dalam rencana proyek sebagai ketergantungan dengan tanggal, sehingga refresh yang terhenti menunjukkan di tempat yang sama dengan integrasi API yang terhenti.
  • Setujui saluran peringatan untuk perubahan schema sebelum proses ingestion dimulai, bukan setelah kegagalan sunyi pertama.
  • Letakkan kesegaran corpus pada dashboard yang sama dengan latency dan biaya, sehingga penurunan kualitas terlihat sebelum pengguna melaporkannya sebagai masalah kualitas.
  • Validasi ulang kepemilikan pada setiap reorganisasi. Perjanjian kepemilikan hanya bertahan selama orang yang menandatangani mereka.

Mengapa itu sepadan dengan kertas kerja

Dua dokumen mengubah hasil: satu halaman aliran data yang menyebutkan setiap sumber, pemiliknya, dan cadencenya, dan register risiko yang menyebutkan apa yang sistem dapat lakukan salah dengan mitigasi untuk masing-masing. Keduanya membosankan, keduanya membutuhkan satu sore, dan keduanya mengubah kelas masalah yang akan ditemukan pada bulan keempat menjadi serangkaian keputusan yang dapat dibuat pada minggu pertama.

Yang bisa Anda lakukan sekarang

  • Setiap sumber data memerlukan pemilik yang dinamai dan kesepakatan tentang kapan data diperbarui
  • Pemetaan izin adalah tugas organisasi dengan permukaan teknis
  • Perjanjian tertulis dapat bertahan selama reorganisasi; perjanjian lisan tidak