Silo Data antara Engineering dan Produk
PM dan insinyur menggunakan alat, bahasa, dan jadwal yang berbeda. Inilah cara silo terbentuk – dan apa yang benar-benar memperbaikinya.
By Ellis Keane · 2026-03-16
Suatu saat, «keselarasan produk-engineering» menjadi sebuah jabatan daripada sesuatu yang terjadi begitu saja ketika orang-orang kompeten bekerja bersama. Perusahaan kini mempekerjakan orang-orang khusus yang tujuan satu-satunya adalah memastikan dua kelompok orang cerdas – yang berada di ruang kerja Slack yang sama, menghadiri standup yang sama, dan secara teori bekerja menuju tujuan yang sama – benar-benar dapat memahami apa yang dilakukan kelompok lain. Silo data antara engineering dan produk yang membuat hal ini perlu bukanlah masalah orang. Itu adalah masalah alat.
PM dan insinyur sudah banyak berkomunikasi. Masalahnya adalah mereka bekerja dalam sistem yang sepenuhnya berbeda, dan silo yang terbentuk di antara sistem tersebut bersifat struktural – tertanam dalam arsitektur bagaimana tim modern memilih alat mereka. Tidak ada tingkat «mari lebih sering menyelaraskan» yang memperbaiki masalah di mana alat itu sendiri tidak saling mengenal.
Dua Realitas
Saya mengambil dari pengalaman kami sendiri membangun Sugarbug di sini, karena kami menjalani ini setiap hari dan saya pikir detail spesifiknya lebih berguna daripada versi abstraknya.
Sisi PM (itu sebagian besar saya, dalam kasus kami) hidup di Notion. Spesifikasi ditulis di sana, prioritas dilacak, percakapan pelanggan dicatat, permintaan fitur dikatalogkan dalam daftar yang terus bertambah setiap minggu. Notion adalah tempat «mengapa» hidup – mengapa kami membangun sesuatu, apa yang sebenarnya dikatakan pelanggan, konteks strategis apa yang ada di balik keputusan tertentu. Ini tidak teratur, meluas, dan di sinilah sebagian besar pemikiran penting terjadi sebelum satu baris kode pun ditulis.
Sementara itu, insinyur kami hidup di Linear dan GitHub. Linear menyimpan tugas, siklus sprint, rantai ketergantungan, dan issues yang memblokir. GitHub memiliki kode, pull request, utas tinjauan tempat orang berdebat secara konstruktif (semoga) tentang detail implementasi. Di situlah «bagaimana» dan «kapan» hidup – bagaimana sesuatu dibangun, kapan akan dikirimkan, apa yang menghalangi.
Kedua realitas itu akurat, keduanya penting, dan keduanya sepenuhnya terputus satu sama lain. Kesenjangan di antara mereka adalah tempat di mana persyaratan menjadi usang dan pengerjaan ulang mulai menumpuk.
Bagaimana Silo Data antara Engineering dan Produk Benar-benar Terbentuk
Ada godaan untuk berpikir ini adalah pilihan yang disengaja – bahwa seseorang memutuskan untuk memisahkan informasi. Dalam praktiknya, silo terbentuk melalui perilaku yang sepenuhnya masuk akal yang tidak dimaksudkan siapapun untuk menjadi berbahaya.
Seorang PM menulis spesifikasi di Notion, menautkannya di Slack ke saluran engineering, dan menganggap serah terima selesai. Seorang insinyur membaca spesifikasi, membuat tiga issues Linear darinya, dan mulai membangun. Sejauh ini semuanya berjalan.
Tetapi kemudian spesifikasi berubah – percakapan pelanggan menggeser prioritas, atau konteks bisnis berkembang. PM memperbarui dokumen Notion dan menjatuhkan catatan di Slack tentang perubahan tersebut. Insinyur, yang sedang dalam sesi pengkodean, tidak melihat pesan Slack selama berjam-jam. Pada saat itu dia sudah membangun dua dari tiga fitur berdasarkan spesifikasi lama, dan issues ketiga di Linear masih merujuk persyaratan yang tidak lagi ada.
Tidak ada yang ceroboh di sini. Tidak ada yang «gagal berkomunikasi». Informasi hidup di satu sistem dan pekerjaan terjadi di sistem lain, dan jaringan penghubung di antara mereka adalah pesan Slack yang terkubur di bawah utas lain sebelum orang yang tepat melihatnya.
Ini terjadi berulang kali – di setiap spesifikasi, setiap sprint, setiap kuartal – dan penyimpangan terus bertambah. Kesenjangan antara apa yang produk pikir sedang terjadi dan apa yang sebenarnya dibangun engineering semakin melebar dengan setiap serah terima yang bergantung pada manusia yang memperhatikan pesan pada waktu yang tepat.
Mengapa «Komunikasi yang Lebih Baik» Tidak Memperbaikinya
Saya pernah duduk di retrospektif di mana item tindakannya adalah «komunikasikan perubahan secara lebih proaktif», dan (dengan kasih sayang) itu adalah setara organisasi dengan memberi tahu seseorang untuk menjadi lebih terorganisir saja. Kedengarannya bisa ditindaklanjuti, membuat halaman Confluence terlihat produktif, dan tidak mengubah apa pun tentang sistem yang menyebabkan masalah. Kami telah menjalankan item tindakan retrospektif yang sama tiga kali – saya sudah memeriksa.
Alasan mengapa komunikasi yang lebih baik tidak menyelesaikan silo data antara engineering dan produk adalah bahwa komunikasi sudah terjadi – data ada, keputusan dibuat dan dicatat. Mereka hanya dicatat dalam alat yang tidak saling mengenal satu sama lain.
Notion tidak tahu bahwa spesifikasi telah diuraikan menjadi tiga issues Linear. Linear tidak tahu bahwa persyaratan di balik sebuah issue berubah di Notion dua jam yang lalu. GitHub tidak tahu bahwa PR yang sedang ditinjau mengimplementasikan fitur yang prioritasnya baru saja diturunkan di papan Notion PM. Setiap alat berfungsi persis seperti yang dirancang – mereka hanya tidak dirancang untuk berfungsi bersama.
«Ada komedi gelap tertentu dalam menghabiskan Senin pagi untuk mengonfirmasi bahwa alat yang Anda bayar tidak diam-diam menyimpang dari kenyataan selama akhir pekan.» – Ellis Keane
Jadi yang terjadi adalah PM secara manual mencerminkan perubahan dari Notion ke Linear saat spesifikasi berubah, insinyur menghubungi PM di Slack untuk bertanya «apakah ini masih rencananya?», dan pimpinan menghabiskan Senin pagi mereka untuk merujuk silang papan untuk memeriksa penyimpangan. Kami melihat bagaimana kami membakar beberapa jam seminggu untuk apa yang pada dasarnya adalah sinkronisasi data manual antara alat yang seharusnya, secara teori, sudah saling mengenal.
Seperti Apa Solusi Sistemik Sebenarnya
Naluri saat Anda melihat kesenjangan antara dua alat adalah membangun jembatan – otomatisasi Zapier, webhook, skrip sinkronisasi. Untuk alur kerja yang sederhana dan dapat diprediksi (saat issues Linear berpindah ke «Selesai», perbarui status Notion), itu bekerja dengan baik.
Tetapi silo data antara engineering dan produk melibatkan konteks, bukan hanya status. PM tidak hanya mengubah bidang status; mereka menulis ulang sebuah paragraf dalam spesifikasi yang mengubah arti «selesai» untuk dua dari tiga issues Linear. Webhook status sederhana melewatkan perubahan tingkat persyaratan kecuali Anda menambahkan logika diff dan pemetaan semantik, yang sebagian besar tim tidak pernah sempat membangunnya.
Yang benar-benar Anda butuhkan adalah sesuatu yang memahami hubungan antara data di seluruh alat – bukan hanya «halaman Notion ini terhubung ke issues Linear ini», tetapi «bagian spesifikasi ini menjelaskan persyaratan untuk issues ini, dan bagian itu baru saja berubah». Tujuannya adalah memetakan pengeditan spesifikasi ke issues yang terdampak secara otomatis, daripada mengandalkan seseorang untuk memperhatikan dan menyebarkan perubahan.
Itulah perbedaan antara lapisan sinkronisasi dan grafik pengetahuan. Lapisan sinkronisasi menyalin data antar alat. Grafik pengetahuan melacak bagaimana data berhubungan, mendeteksi saat hubungan tersebut berubah, dan menampilkan perubahan kepada orang-orang yang perlu mengetahuinya.
Kami membangun Sugarbug untuk bekerja dengan cara ini – menghubungkan alat yang sudah digunakan PM dan insinyur (Notion, Linear, GitHub, Slack, Figma) ke dalam grafik pengetahuan yang mempertahankan hubungan antara spesifikasi, tugas, kode, dan percakapan. Kami masih dalam tahap awal (jujurnya, masih banyak yang belum kami cari tahu tentang cara membuat deteksi diff semantik dapat diandalkan pada skala besar), tetapi grafik inti berfungsi dan sudah menangkap situasi penyimpangan spesifikasi yang seharusnya berubah menjadi pengerjaan ulang.
Silo data antara engineering dan produk terbentuk karena alat secara struktural terputus, bukan karena orang berkomunikasi dengan buruk. Perbaikannya adalah menghubungkan data pada tingkat hubungan, bukan menambahkan lebih banyak saluran komunikasi.
Apa yang Dapat Anda Lakukan Minggu Ini
Saya tidak akan berpura-pura bahwa satu-satunya jawaban adalah «gunakan Sugarbug». Ada hal-hal yang dapat Anda lakukan sekarang, dengan alat apa pun yang sudah Anda jalankan, untuk mengurangi efek terburuk dari silo data produk-engineering.
Buat referensi silang eksplisit, dua arah, dan memiliki penanggung jawab. Setiap spesifikasi Notion harus memiliki bagian «Issues Linear» di bagian bawah yang menautkan ke issues yang dihasilkannya, dan setiap issues Linear harus menautkan kembali ke spesifikasi sumbernya. Tetapkan satu orang per spesifikasi untuk memiliki referensi silang – bukan seluruh tim, satu orang, dengan nama mereka tercantum. Kami mencoba versi «semua orang bertanggung jawab» dan (dapat diduga) tidak ada yang bertanggung jawab. Tautan akan tetap menyimpang seiring waktu, tetapi memiliki pemilik yang ditunjuk berarti ada seseorang untuk dihubungi saat penyimpangan terdeteksi.
Tetapkan ritual «perubahan spesifikasi» dengan pemicu, bukan pengingat. Ketika spesifikasi berubah secara signifikan (bukan kesalahan ketik – perubahan persyaratan yang nyata), PM memperbarui issues Linear yang terhubung sebelum menutup tab Notion. Bukan nanti, bukan «saat saya sempat» – sebelum tab ditutup. Komentar pada setiap issues yang terdampak harus satu baris: apa yang berubah, tautan ke bagian yang diperbarui, dan apakah kriteria penerimaan issues masih valid. Kami menemukan bahwa mengaitkan pembaruan ke tindakan fisik (menutup tab) bekerja lebih baik daripada mengandalkan ingatan siapa pun, karena ingatan adalah cara silo terbentuk sejak awal.
Lakukan pemeriksaan kecocokan prioritas 15 menit pada hari Jumat. Satu orang (rotasi mingguan) menampilkan 5 prioritas teratas PM di Notion dan 5 teratas sprint engineering di Linear, berdampingan. Pertanyaannya bukan «apakah ini identik?» – tidak akan, dan itu tidak masalah. Pertanyaannya adalah «apakah ada yang secara aktif bertentangan satu sama lain?» Jika prioritas pertama PM tidak ada di mana pun dalam sprint, itulah percakapan untuk hari Senin, bukan pembaruan status.
Ini adalah proses manual, dan memiliki masa berlaku. Dengan lima insinyur dan dua PM, proses ini membosankan tetapi berhasil. Dengan lima belas insinyur, tiga PM, dan tim desain yang menambahkan Figma ke dalam campuran, hubungan lintas alat bertambah lebih cepat dari yang bisa dilacak siapa pun secara manual. Tetapi mereka akan mengajarkan Anda di mana kesenjangan keselarasan produk-engineering Anda yang terburuk sebenarnya berada – dan nilai diagnostik itu sepadan dengan usahanya bahkan jika Anda akhirnya mengotomatiskan semuanya.
Apakah solusi jangka panjangnya Sugarbug atau sesuatu yang lain (kami jelas berpikir kami membangun hal yang benar, tetapi saya bias), masalah kolaborasi manajemen produk-engineering hanya terselesaikan ketika alat itu sendiri terhubung pada tingkat semantik, dan manusia dapat fokus membuat keputusan daripada memindahkan konteks antar aplikasi.
Jika referensi silang manual Anda bertahan, manfaatkan selama mungkin. Jika Anda terus mendapatkan item tindakan retrospektif yang sama tentang komunikasi, masalahnya bukan orang-orang Anda. Itu adalah arsitektur data Anda.
Hubungkan Notion, Linear, GitHub, dan Slack ke dalam satu grafik pengetahuan – agar perubahan spesifikasi muncul secara otomatis kepada insinyur yang tepat.
Q: Berapa lama waktu yang dibutuhkan untuk menyiapkan Sugarbug bagi tim produk-engineering? A: Koneksi awal membutuhkan beberapa menit per alat – Anda mengautentikasi Linear, GitHub, Notion, Slack, dan Figma melalui OAuth, dan Sugarbug langsung mulai membangun grafik pengetahuan. Grafik menjadi cukup berguna dalam satu atau dua hari karena menyerap data yang ada dan mulai memetakan hubungan antara spesifikasi, issues, dan percakapan. Kami masih menyempurnakan alur orientasi, tetapi tujuannya adalah Anda tidak perlu mengonfigurasi apa pun selain menghubungkan akun Anda.
Q: Apakah Sugarbug menggantikan Linear, Notion, atau salah satu alat yang sudah ada? A: Tidak. Sugarbug bekerja berdampingan dengan alat Anda yang sudah ada dan menghubungkannya – tidak menggantikan salah satunya. PM Anda tetap menulis spesifikasi di Notion, insinyur Anda tetap bekerja di Linear dan GitHub, dan Sugarbug mempertahankan hubungan di antara mereka agar konteks tidak hilang dalam transit. Anggap saja sebagai jaringan penghubung antara alat yang sudah Anda gunakan.
Q: Bisakah Sugarbug mendeteksi saat spesifikasi Notion berubah dan memberi tahu insinyur yang tepat? A: Itu adalah bagian inti dari apa yang kami bangun. Saat spesifikasi berubah di Notion, Sugarbug mengidentifikasi issues Linear mana yang terhubung dengannya dan menampilkan perubahan kepada insinyur yang mengerjakan issues tersebut. Kami masih beriterasi pada bagian deteksi semantik (menentukan perubahan mana yang signifikan versus kosmetik), tetapi tautan lintas alat dan deteksi perubahan dasar sudah berfungsi.
Q: Apa perbedaan antara alat sinkronisasi dan grafik pengetahuan untuk masalah ini? A: Alat sinkronisasi menyalin perubahan status antar aplikasi – saat issues Linear berpindah ke «Selesai», perbarui kotak centang Notion. Grafik pengetahuan melacak bagaimana data berhubungan: spesifikasi ini menjelaskan persyaratan untuk tiga issues ini, dan kriteria penerimaan berubah, yang memengaruhi dua issues yang belum dikirimkan. Perbedaannya paling berarti ketika perubahannya bersifat semantik, bukan hanya pada tingkat status.
Q: Apakah keselarasan produk-engineering adalah masalah komunikasi atau masalah data? A: Dalam pengalaman kami, hampir selalu merupakan masalah data yang salah didiagnosis sebagai masalah komunikasi. Tim-tim berkomunikasi – mereka hanya melakukannya melalui alat yang tidak saling mengenal. Memperbaiki alur kerja data antara alat tersebut cenderung menyelesaikan masalah keselarasan yang tidak dapat diperbaiki oleh retrospektif atau rapat sinkronisasi sebanyak apa pun.