Menemukan Keputusan Lama di Slack – Saat Pencarian Gagal
Cara menemukan keputusan lama di Slack saat pencarian gagal. Mengapa keputusan hilang, log gagal bertahan, dan seperti apa sistem yang sadar keputusan.
By Ellis Keane · 2026-03-14
Cepat: di mana tim Anda memutuskan untuk menggunakan webhook daripada polling? Bukan apa yang Anda putuskan – di mana keputusan itu tertulis sekarang, di tempat yang bisa ditemukan oleh seseorang yang bergabung bulan depan?
Jika Anda seperti kami, jawaban jujurnya ada di suatu tempat antara "sebuah thread Slack, mungkin" dan "saya pikir itu di #eng-backend, mungkin tiga minggu lalu, dan saya cukup yakin melibatkan dua atau tiga orang tapi saya benar-benar tidak ingat yang mana." Yang merupakan keadaan yang menarik jika Anda memikirkannya, karena keputusan itu sendiri cukup penting untuk mengubah cara kerja seluruh sistem, tetapi tampaknya tidak cukup penting bagi siapa pun untuk menuliskannya di tempat yang bukan arus kesadaran yang diatur berdasarkan timestamp. Dan itulah, singkatnya, masalah ketika mencoba menemukan keputusan lama di Slack – informasinya semua ada, hanya tidak terorganisir dengan cara yang memungkinkan Anda mengambilnya sebagai sebuah keputusan.
Saya sudah menggali cara menemukan keputusan lama di Slack cukup lama, dan semakin dalam saya menyelami, semakin saya berpikir bahwa masalah inti bukan soal disiplin atau kebiasaan atau hal-hal lain yang orang salahkan. Ini bersifat arsitektural. Pencarian Slack dibangun untuk menemukan pesan, dan keputusan bukan pesan – keputusan adalah makna yang kebetulan diekspresikan melalui pesan, sebuah perbedaan yang terdengar pedantis sampai Anda menghabiskan dua puluh menit menggulir hasil pencarian mencoba mencari tahu mana dari tujuh belas penyebutan "webhook" adalah saat tim Anda benar-benar berkomitmen untuk menggunakannya.
Cara kerja pencarian Slack yang sebenarnya (dan di mana ia gagal)
Mari kita tepat tentang ini, karena "pencarian Slack buruk" bukan diagnosis yang tepat – pencarian Slack sebenarnya cukup baik dalam apa yang dilakukannya. Masalahnya adalah apa yang dilakukannya dan apa yang Anda butuhkan ketika mencari sebuah keputusan adalah dua hal yang pada dasarnya berbeda.
Slack mengindeks pesan sebagai teks dengan metadata: timestamp, pengirim, saluran, dan (jika Anda menggunakan paket berbayar) konteks thread lengkap. Saat Anda mencari "webhook," Slack dengan setia mengembalikan setiap pesan yang mengandung kata itu, diurutkan berdasarkan kombinasi kebaruan dan relevansi. Anda dapat mempersempit hasil dengan operator pencarian – in:#eng-backend from:@sarah before:2026-02-15 – tetapi yang Anda lakukan hanyalah memfilter daftar pesan datar yang sama berdasarkan metadata. Ini adalah pengambilan kata kunci, dan untuk menemukan pesan spesifik yang setengah Anda ingat, ini bekerja dengan baik.
Tapi keputusan bukan kata kunci. Keputusan adalah hubungan antara pertanyaan, sekumpulan opsi, sekumpulan orang, dan momen ketika kelompok menyepakati satu opsi. Teks sebenarnya dari keputusan mungkin "ya, mari kita pakai webhook saja, pendekatan polling menghabiskan batas tarif kita" – yang bersifat percakapan, kontekstual, dan hanya bermakna jika Anda sudah mengetahui thread di mana ia muncul. Atau mungkin "itu berhasil, biarkan saya membuat prototipe," yang tidak mengandung kata kunci terkait keputusan teknis yang diwakilinya.
Inilah ketidakcocokan arsitektural: Slack menyimpan pesan secara kronologis dan mengambilnya berdasarkan kata kunci. Keputusan bersifat semantik (tentang makna) dan relasional (terhubung ke tugas, orang, dan hasil). Anda meminta sistem penyimpanan kronologis untuk melakukan pengambilan semantis, dan itu tidak bisa, karena tidak pernah dirancang untuk itu. Kesenjangan antara "dapat dicari" dan "dapat ditemukan" ternyata sangat besar – setiap pesan dalam riwayat Slack Anda secara teknis dapat dicari, tetapi itu tidak berarti keputusan yang Anda butuhkan dapat ditemukan dalam arti praktis apa pun.
"Slack telah menciptakan salah satu repositori pengambilan keputusan organisasi terbesar dalam sejarah, dan hampir tidak ada yang dapat diambil kembali sebagai keputusan – setiap kata tersimpan dengan sempurna dan hampir sepenuhnya tidak dapat ditemukan." – Ellis Keane
Apa yang terjadi saat Anda mencoba menemukan keputusan lama di Slack
Begini tampilan ketidakcocokan dalam praktik. Katakanlah tim Anda memutuskan tiga minggu lalu untuk beralih dari polling ke webhook untuk integrasi GitHub. Anda ingat diskusi terjadi di #eng-backend dan melibatkan beberapa insinyur. Jadi Anda mencari "webhook" di saluran itu.
Yang kembali: setiap pesan yang pernah menyebut webhook di #eng-backend. Laporan bug dari enam bulan lalu. Seseorang mengajukan pertanyaan tentang logika percobaan ulang webhook dalam konteks yang sepenuhnya berbeda. Sebuah tautan yang dibagikan seseorang ke posting blog tentang praktik terbaik webhook (yang, dalam ironi yang indah, mungkin mendapat peringkat lebih tinggi dalam hasil pencarian daripada keputusan sebenarnya yang ada di sampingnya). Keputusan itu sendiri – sebuah balasan dalam thread di mana seseorang mengatakan pendekatan polling mencapai batas tarif – terkubur di suatu tempat di halaman tiga, terlihat persis seperti setiap pesan lain di sekitarnya.
Dan itulah skenario di mana Anda kira-kira ingat kata-kata apa yang digunakan. Separuh waktu, keputusan menggunakan bahasa yang begitu kontekstual sehingga mungkin juga terenkripsi. "Mari kita pilih opsi B" tidak mengandung kata "webhook" sama sekali, meskipun opsi B adalah webhook. "Itu berhasil, biarkan saya membuat prototipe" bahkan tidak mengandung kata "opsi." Momen keputusan yang sebenarnya sering merupakan pesan terpendek dan paling miskin kata kunci di seluruh thread, karena pada saat itu semua orang dalam percakapan sudah memiliki konteks dan mereka hanya mengkonfirmasi kesepakatan.
Saya menemukan ini sangat menarik sebagai masalah arsitektur informasi (baik, menarik dan juga sedikit menjengkelkan saat Anda yang melakukan pencarian). Slack telah menciptakan salah satu repositori pengambilan keputusan organisasi terbesar dalam sejarah, dan hampir tidak ada yang dapat diambil kembali sebagai keputusan – setiap kata tersimpan dengan sempurna, dan hampir sepenuhnya tidak dapat ditemukan.
Mengapa log keputusan adalah kuburan dengan tanda yang lebih baik
Saran standar, jika Anda mencari solusi, adalah menyimpan log keputusan. Database Notion, saluran Slack khusus (ironisnya tampaknya luput dari orang-orang yang merekomendasikannya), halaman wiki – satu tempat di mana keputusan dicatat saat terjadi.
Kami mencoba ini. Berlangsung sekitar enam minggu. Dua minggu pertama sangat bagus – semua orang berkomitmen, entri terperinci, log benar-benar berguna. Pada minggu ketiga, entri mulai tidak teratur. Pada minggu kelima, satu orang masih memperbaruinya, menulis hal-hal seperti "memutuskan sesuatu tentang auth" tanpa tautan, tanpa konteks, dan tanpa indikasi siapa yang terlibat atau apa alternatifnya. Pada minggu keenam kami diam-diam berhenti berpura-pura.
Masalahnya bukan tim kami kurang disiplin (maksudnya, mungkin, tapi itu bukan masalah yang relevan di sini). Masalahnya adalah pencatatan keputusan mengenakan pajak tepat pada momen yang salah. Anda baru saja berdiskusi produktif, mencapai kesepakatan, seseorang siap mulai membangun – dan sekarang Anda perlu berhenti sejenak, membuka alat lain, menulis ringkasan, menandai orang yang relevan, dan menautkan kembali ke percakapan aslinya. Itu tiga hingga lima menit per keputusan, dan untuk tim yang membuat lima hingga sepuluh keputusan bermakna per hari di berbagai saluran dan thread, overhead-nya menumpuk menjadi sesuatu yang tidak ingin dimiliki siapa pun.
Dan sistem hanya bekerja dengan kepatuhan 100%. Log keputusan dengan 70% keputusan dalam beberapa hal lebih buruk dari tidak ada log sama sekali, karena sekarang Anda memeriksa dua tempat dan tidak mempercayai keduanya. Anda melihat di log, keputusan tidak ada, jadi Anda tetap mencari di Slack – dan Anda kembali ke titik awal, kecuali sekarang Anda juga membuang dua menit memeriksa log terlebih dahulu.
Keputusan bukan peristiwa – keputusan adalah gradien
Sebagian alasan pencatatan manual gagal adalah ia mengasumsikan keputusan adalah momen yang diskrit dan dapat diidentifikasi. Kenyataannya, sebagian besar keputusan muncul secara bertahap melalui percakapan, dan "momen keputusan" sering benar-benar ambigu.
Pertimbangkan bagaimana keputusan rekayasa tipikal sebenarnya terungkap. Seseorang mengangkat kekhawatiran dalam komentar Figma: "pola interaksi ini mungkin tidak berfungsi di mobile." Seorang insinyur membalas di thread Slack, menandai komentar aslinya: "ya, saya sudah melihat ini – pustaka komponen tidak mendukungnya." Seorang desainer menyarankan pendekatan alternatif di thread yang sama. Insinyur berkata "itu berhasil, biarkan saya membuat prototipe." Dua hari kemudian, PR dibuka untuk mengimplementasikan alternatif tersebut, dan isu Linear diperbarui.
Di mana keputusan dibuat? Apakah itu komentar Figma yang mengangkat masalah? Thread Slack di mana alternatif diusulkan? Momen insinyur berkata "itu berhasil"? PR yang mengimplementasikannya? Dalam praktiknya, keputusan didistribusikan di keempat momen tersebut, mencakup dua alat dan tiga hari. Itu bukan peristiwa yang bisa Anda catat – itu adalah gradien yang menyelesaikan diri menjadi hasil, dan satu-satunya alasan kami tahu sebuah keputusan dibuat adalah bahwa kode berubah.
Inilah (menurut saya) bagian yang sebagian besar saran "pelacakan keputusan" salahkan. Ia memperlakukan keputusan sebagai hal yang Anda tangkap, seperti menuliskan nomor telepon. Tapi sebagian besar keputusan nyata adalah hal yang Anda rekonstruksi – Anda melihat apa yang berubah, menelusuri mundur percakapan yang mengarah ke sana, dan menyatukan penalaran setelah fakta. Yang berarti sistem yang Anda butuhkan bukan log. Ini adalah grafik.
Apa yang diberikan grafik yang tidak bisa diberikan log
Sebuah grafik menghubungkan sinyal di berbagai alat dan waktu. Alih-alih seseorang secara manual menulis "kami memutuskan untuk menggunakan webhook karena batas tarif," grafik menghubungkan thread Slack di mana batas tarif didiskusikan, isu Linear yang melacak pekerjaan integrasi, PR yang mengimplementasikan webhook, dan orang-orang yang terlibat dalam percakapan. Keputusan tidak dicatat – ia dapat direkonstruksi dari koneksi antara hal-hal yang sudah terjadi.
Perbedaan praktisnya muncul dalam skenario tertentu. Tiga minggu setelah keputusan webhook, insinyur baru bergabung dan bertanya: "mengapa kita menggunakan webhook daripada polling untuk GitHub? Polling tampaknya lebih sederhana." Tanpa sistem yang terhubung, seseorang berkata "oh, kami memutuskan itu beberapa waktu lalu," tidak ada yang ingat saluran mana, seseorang menghabiskan lima belas menit mencari di Slack, dan mereka menemukan atau (lebih mungkin) merekonstruksi penalaran dari ingatan, yang berisiko karena ingatan tidak dapat diandalkan dan penalaran aslinya hampir pasti lebih bernuansa dari yang diingat siapa pun tiga minggu kemudian.
Dengan grafik, insinyur melihat tugas integrasi GitHub. Setiap sinyal yang menyentuh tugas itu terhubung: diskusi asli tentang batas tarif, thread di mana polling vs. webhook dievaluasi, PR yang mengimplementasikan perubahan. Jejak keputusan lengkap, dari awal hingga akhir, tanpa siapa pun mencari apa pun dan tanpa siapa pun mencatat apa pun.
Kesenjangan bukan antara "pencarian bagus" dan "pencarian buruk" – melainkan antara pengambilan berdasarkan kata kunci dan pengambilan berdasarkan hubungan. Keputusan didefinisikan oleh koneksinya ke tugas, orang, dan hasil, bukan oleh kata-kata yang digunakan untuk mengekspresikannya.
Biaya yang tidak muncul di dasbor mana pun
Saya sejujurnya skeptis terhadap siapa pun yang mengklaim angka tepat untuk biaya tak berwujud seperti ini (genre statistik "tim membuang X jam per minggu" selalu terasa seperti dibalik-rekayasa dari kesimpulan yang diinginkan), tetapi inilah yang kami amati di tim kami sendiri.
Biaya paling jelas adalah re-litigasi – ketika tidak ada yang dapat menemukan keputusan asli, tim hanya membukanya kembali, terkadang karena orang benar-benar tidak ingat dan terkadang karena anggota tim baru memiliki pertanyaan sah yang tidak dapat dijawab siapa pun dengan detail. Kami secara rutin membuka kembali pertanyaan yang sudah diselesaikan sebelum kami memiliki cara untuk menelusuri keputusan kembali ke sumbernya, dan setiap re-litigasi membawa overhead-nya sendiri: waktu pertemuan, kelelahan emosional karena berdebat tentang sesuatu yang Anda cukup yakin sudah diselesaikan, kecurigaan yang terus-menerus bahwa penalaran aslinya lebih bernuansa dari yang diingat siapa pun.
Biaya yang lebih halus adalah apa yang terjadi selama orientasi. Setiap pertanyaan "mengapa ini dilakukan seperti ini?" dari anggota tim baru menyela seseorang yang hadir pada keputusan aslinya, dan jawabannya direkonstruksi dari ingatan setiap kali seseorang bertanya, melayang sedikit lebih jauh dari penalaran aslinya dengan setiap penceritaan ulang – seperti permainan telepon rusak, kecuali teleponnya adalah perangkat lunak perusahaan dan pesannya adalah "mengapa arsitektur bekerja seperti ini." Dan ada kesenjangan kredibilitas yang bertambah seiring waktu: "kami memilih webhook" memiliki bobot lebih rendah dari "kami memilih webhook karena polling menghabiskan 40% batas tarif API GitHub kami dan kami mengalami throttling selama jam sibuk." Penalaran itulah yang memungkinkan insinyur di masa depan mengevaluasi apakah sebuah keputusan masih berlaku dalam keadaan yang berubah, dan penalaran itu ada di suatu thread Slack, tersimpan dengan sempurna dan hampir tidak terlihat.
Berhenti kehilangan keputusan ke gulungan Slack. Sugarbug menelusuri jejak keputusan lengkap – dari thread Slack ke isu Linear hingga PR – secara otomatis.
Q: Mengapa sangat sulit menemukan keputusan lama di Slack? A: Slack menyimpan pesan secara kronologis, bukan berdasarkan makna. Keputusan yang terkubur di thread terlihat seperti balasan lainnya – pencarian Slack dapat mencocokkan kata kunci, tetapi tidak dapat membedakan "kami memutuskan untuk menggunakan Redis" dari "haruskah kami menggunakan Redis?" tanpa membaca konteks percakapan lengkap. Semakin lama waktu berlalu, semakin sulit, karena Anda kehilangan petunjuk kontekstual (siapa yang terlibat, saluran apa, minggu apa) yang membuat pencarian layak dilakukan sejak awal.
Q: Apakah Sugarbug melacak keputusan yang dibuat di Slack secara otomatis? A: Ya. Sugarbug mengklasifikasikan sinyal masuk dari Slack dan alat terhubung lainnya, mengidentifikasi pola mirip keputusan – thread yang mereferensikan tugas, melibatkan orang yang ditugaskan, dan menghasilkan perubahan status atau PR. Ini ditautkan ke tugas yang relevan dalam grafik pengetahuan, sehingga Anda dapat menelusuri jejak keputusan dari tugas daripada mencari riwayat Slack.
Q: Apa perbedaan antara log keputusan dan grafik pengetahuan untuk keputusan? A: Log keputusan mengharuskan seseorang untuk mencatat setiap keputusan secara manual saat terjadi – memperhatikannya, berhenti, merangkumnya, menandainya, menautkannya. Grafik pengetahuan menyimpulkan keputusan dari sinyal yang mengalir melalui alat Anda dan menghubungkannya secara otomatis ke tugas, orang, dan percakapan. Satu bergantung pada disiplin konsisten dari setiap anggota tim; yang lain berjalan di latar belakang dari aktivitas yang sudah terjadi.
Q: Bisakah Sugarbug menampilkan keputusan dari alat selain Slack? A: Sugarbug terhubung ke Slack, GitHub, Figma, Linear, Notion, email, dan kalender. Keputusan sering mencakup beberapa alat (komentar Figma mengarah ke thread Slack yang mengarah ke PR), dan grafik pengetahuan menghubungkan sinyal di semua permukaan yang terhubung. Anda melihat jejak lengkap terlepas dari alat mana percakapan dimulai.
Q: Apa bedanya dengan menggunakan pencarian bawaan Slack? A: Pencarian Slack menemukan pesan yang mengandung kata kunci tertentu. Grafik pengetahuan menemukan hubungan antara pesan, tugas, dan orang. Saat Anda mencari sebuah keputusan, Anda jarang mencari sebuah kata – Anda mencari momen di mana tim memilih satu pendekatan daripada yang lain, dan momen itu didefinisikan oleh koneksinya ke sinyal lain, bukan oleh kata-kata yang digunakan untuk mengekspresikannya.
---
Jika keputusan terus menghilang ke dalam riwayat Slack Anda, masalahnya bukan Slack – masalahnya adalah tidak ada sistem yang mengamati momen-momen penting dan menghubungkannya ke pekerjaan yang mereka bentuk. Itulah kesenjangan yang sedang kami bangun Sugarbug untuk mengisinya.