Kupata Maamuzi ya Zamani katika Slack – Utafutaji Hautoshi
Jinsi ya kupata maamuzi ya zamani katika Slack wakati utafutaji unashindwa. Kwa nini yanapotea, rekodi hazidumu na mfumo unaozingatia maamuzi ni nini.
By Ellis Keane · 2026-03-14
Swali la haraka: timu yako iliamua kutumia webhooks badala ya polling wapi? Si nini uliamua – uamuzi huo umeandikwa sasa hivi wapi, mahali ambapo mtu anayejiunga mwezi ujao angeweza kupata?
Kama nyinyi ni kama sisi, jibu la kweli liko mahali fulani kati ya "katika thread fulani ya Slack, labda" na "nadhani ilikuwa katika #eng-backend, labda wiki tatu zilizopita, na watu wawili au watatu walikuwa wamehusika lakini kweli siwezi kukumbuka ni akina nani." Ambayo ni hali ya kuvutia ukifikiri juu yake – kwa sababu uamuzi wenyewe ulikuwa muhimu vya kutosha kubadilisha jinsi mfumo wote unavyofanya kazi, lakini inaonekana haukuwa muhimu vya kutosha kwa mtu yeyote kuuandika mahali ambapo si mkondo wa mawazo uliofuatana kwa muda. Na hiyo, kwa ufupi, ndiyo tatizo la kujaribu kupata maamuzi ya zamani katika Slack – taarifa zote zipo, zimepangwa tu kwa njia ambayo haifai kupata tena uamuzi.
Nimekuwa nikichunguza jinsi ya kupata maamuzi ya zamani katika Slack kwa muda fulani, na kadiri ninavyochimba zaidi, ndivyo ninavyofikiri tatizo la msingi si nidhamu, tabia, au mambo mengine yoyote ambayo watu hulaumiwa. Ni tatizo la usanifu. Utafutaji wa Slack uliundwa kupata ujumbe, na maamuzi si ujumbe – ni maana ambayo hutokea kuonyeshwa kupitia ujumbe, tofauti ambayo inasikika kama ukweli mdogo – mpaka utumikie dakika ishirini ukipitia matokeo ya utafutaji ukijaribu kugundua ni lipi kati ya kutajwa kwa "webhooks" kumi na saba ambapo timu yako kweli iliamulia kuzitumia.
Jinsi utafutaji wa Slack unavyofanya kazi (na anaposhindwa)
Tuwe wazi kuhusu hili, kwa sababu "utafutaji wa Slack ni mbaya" si utambuzi sahihi – utafutaji wa Slack ni mzuri sana katika kinachofanya. Tatizo ni kwamba kinachofanya na unachohitaji kufanyike unapotafuta uamuzi ni mambo mawili tofauti kabisa.
Slack huorodhesha ujumbe kama maandishi na metadata: muda, mtumaji, kituo, na (ukiwa na mpango wa kulipa) muktadha kamili wa thread. Unapotafuta "webhook", Slack hurudi kwa uaminifu kila ujumbe ulio na neno hilo, ulioorodheshwa kwa mchanganyiko fulani wa hivi karibuni na umuhimu. Unaweza kupunguza matokeo kwa kutumia waendeshaji wa utafutaji – in:#eng-backend from:@sarah before:2026-02-15 – lakini unachofanya ni kuchuja orodha ile ile ya ujumbe kwa metadata. Hii ni urejeshaji wa maneno muhimu, na kwa kupata ujumbe maalum unaokumbuka kidogo, inafanya kazi vizuri.
Lakini uamuzi si neno muhimu. Uamuzi ni uhusiano kati ya swali, mkusanyiko wa chaguzi, mkusanyiko wa watu, na wakati ambapo kikundi kilikusanyikia chaguo moja. Maandishi halisi ya uamuzi yanaweza kuwa "ndiyo, twende webhooks, mbinu ya polling inakula kikomo chetu cha kiwango" – ambayo ni ya mazungumzo, muktadha, na ina maana tu ukijua tayari thread iliyoionekana ndani yake. Au inaweza kuwa "inafanya kazi, nitengeneze mfano" – ambayo haina maneno muhimu yanayohusiana na uamuzi wa kiufundi inaowakilisha.
Hii ndiyo kutofautiana kwa usanifu: Slack huhifadhi ujumbe kwa wakati na kuurudisha kwa maneno muhimu. Maamuzi ni ya kisemantiki (yanazungumzia maana) na ya uhusiano (yanaunganika na kazi, watu, na matokeo). Unauliza mfumo wa kuhifadhi kwa wakati kufanya urejeshaji wa kisemantiki, ambao hauwezi kufanya, kwa sababu haukuundwa kwa hilo. Pengo kati ya "inaweza kutafutwa" na "inaweza kupatikana" inaonekana kuwa kubwa sana – kila ujumbe katika historia yako ya Slack unaweza kutafutwa kwa kiufundi, lakini hiyo haimaanishi kwamba uamuzi unaohitaji unaweza kupatikana kwa njia yoyote ya vitendo.
"Slack imeunda moja ya hazina kubwa zaidi za maamuzi ya shirika katika historia, na karibu hakuna chochote kinachoweza kurejeshwa kama maamuzi – kila neno kimehifadhiwa vizuri na ni vigumu sana kupata." attribution: Ellis Keane
Kinachotokea unapojaribu kupata maamuzi ya zamani katika Slack
Hivi ndivyo kutofautiana kunavyoonekana kwa vitendo. Sema timu yako iliamua wiki tatu zilizopita kubadili kutoka polling kwenda webhooks kwa muunganisho wa GitHub. Unakumbuka kwamba mjadala ulifanyika katika #eng-backend na ulihusisha wahandisi wachache. Kwa hivyo unatafuta "webhook" katika kituo hicho.
Kinachokuja: kila ujumbe ambao umewahi kutaja webhooks katika #eng-backend. Ripoti za hitilafu za miezi sita iliyopita. Mtu anayeuliza swali kuhusu mantiki ya kujaribu tena webhook katika muktadha tofauti kabisa. Kiungo alichoshiriki mtu kwa chapisho la blogu kuhusu mbinu bora za webhook (ambacho, kwa kejeli nzuri, labda kina nafasi ya juu zaidi katika matokeo ya utafutaji kuliko uamuzi halisi ulio karibu nazo). Uamuzi wenyewe – jibu katika thread ambapo mtu alisema mbinu ya polling ilikuwa ikipiga kikomo cha kiwango – umezikwa mahali fulani katika ukurasa wa tatu, ukionekana sawa kabisa na kila ujumbe mwingine unaouzunguka.
Na huo ni hali ambapo unakumbuka takriban maneno yaliyotumiwa. Nusu ya wakati, maamuzi hutumia lugha inayolingana sana na muktadha kiasi kwamba inaweza kuwa imefichwa. "Twende na chaguo B" haina neno "webhook" kabisa, ingawa chaguo B lilikuwa webhooks. "Inafanya kazi, nitengeneze mfano" haina hata neno "chaguo". Wakati halisi wa uamuzi mara nyingi ni ujumbe mfupi zaidi, wenye maneno muhimu machache zaidi katika thread nzima – kwa sababu wakati huo kila mtu katika mazungumzo tayari ana muktadha na wanakubaliana tu.
Napata hii kuvutia sana kama tatizo la usanifu wa habari (vizuri, kuvutia na pia kidogo kusumbua unapokuwa ndiye unayetafuta). Slack imeunda moja ya hazina kubwa zaidi za maamuzi ya shirika katika historia, na karibu hakuna chochote kinachoweza kurejeshwa kama maamuzi – kila neno kimehifadhiwa vizuri na ni vigumu sana kupata.
Kwa nini kumbukumbu za maamuzi ni makaburi yenye alama bora
Ushauri wa kawaida, ukitafuta suluhu, ni kutunza kumbukumbu ya maamuzi. Hifadhidata ya Notion, kituo maalum cha Slack (kejeli ya hii inaonekana kwamba inawakimbia wale wanaopendekeza), ukurasa wa wiki – mahali pamoja ambapo maamuzi hurekodiwa yanapotokea.
Tulijaribu hili. Ilidumu wiki sita takriban. Wiki mbili za kwanza zilikuwa nzuri – kila mtu alikuwa amejitolea, maingizo yalikuwa ya kina, kumbukumbu ilikuwa ya manufaa kweli. Kufikia wiki ya tatu, maingizo yalianza kuwa ya kawaida. Kufikia wiki ya tano, mtu mmoja tu alikuwa bado anaisasisha, akiandika mambo kama "iliamua jambo fulani kuhusu uthibitisho" bila viungo, muktadha, au dalili ya nani alikuwa wamehusika au mbadala zilikuwa nini. Kufikia wiki ya sita tuliachilia kimya kimya.
Tatizo si kwamba timu yetu inakosa nidhamu (labda, lakini hilo si tatizo husika hapa). Tatizo ni kwamba kurekodi maamuzi kunaflisha kodi wakati mbaya kabisa. Umefanya mjadala wa tija, umefika makubaliano, mtu yuko tayari kuanza kujenga – na sasa unahitaji kusimama, kufungua zana nyingine, kuandika muhtasari, kuweka lebo watu husika, na kuunganisha tena mazungumzo ya asili. Hiyo ni dakika tatu hadi tano kwa kila uamuzi, na kwa timu inayofanya maamuzi matano hadi kumi muhimu kwa siku katika vituo na threads, mzigo hujilimbikizia kitu ambacho hakuna anayetaka kumiliki.
Na mfumo unafanya kazi tu kwa uzingativu wa 100%. Kumbukumbu yenye 70% ya maamuzi ni mbaya zaidi kuliko kutokuwa na kumbukumbu kabisa kwa njia fulani, kwa sababu sasa unangalia mahali mawili na hukuamini mojawapo. Unangalia kumbukumbu, uamuzi hauko, kwa hivyo unatafuta Slack hata hivyo – na unarudi ulipoanzia, isipokuwa pia ulipoteza dakika mbili ukiangalia kumbukumbu kwanza.
Maamuzi si matukio – ni mionzi
Sehemu ya sababu uandishi wa mkono unashindwa ni kwamba unachukulia kuwa maamuzi ni matukio ya kipekee, yanayoweza kutambuliwa. Ukweli ni kwamba maamuzi mengi huibuka polepole kupitia mazungumzo, na "wakati wa uamuzi" mara nyingi una utata wa kweli.
Fikiria jinsi uamuzi wa kawaida wa uhandisi unavyoendelea. Mtu anagusa wasiwasi katika maoni ya Figma: "mfumo huu wa mwingiliano unaweza usifanye kazi kwenye simu." Mhandisi anajibu katika thread ya Slack, akitaja maoni ya asili: "ndiyo, nilitazama hili – maktaba ya kipengele haifanyi hivi." Mbuni anapendekeza mbinu mbadala katika thread ile ile. Mhandisi anasema "inafanya kazi, nitengeneze mfano." Siku mbili baadaye, PR inayotekeleza mbadala inawekwa, na suala la Linear linasasishwa.
Uamuzi ulifanywa wapi? Je, ulikuwa ni maoni ya Figma yaliyoleta tatizo? Thread ya Slack ambapo mbadala ilipendekezwa? Wakati mhandisi alisema "inafanya kazi"? PR iliyoitekeleza? Kwa vitendo, uamuzi ulisambazwa kwa wakati hao wote wanne, ukipita kwenye zana mbili na siku tatu. Haukuwa tukio ungeweza kurekodi – ilikuwa mionzi iliyosuluhisha katika matokeo, na sababu pekee tunajua uamuzi ulifanywa ni kwamba msimbo ulibadilika.
Hii ndiyo (nafikiri) sehemu ambayo ushauri mwingi wa "kufuatilia maamuzi" hupotoka. Inashughulikia maamuzi kama vitu unavyonasa, kama kuandika nambari ya simu. Lakini maamuzi mengi ya kweli ni vitu unavyounda tena – unatazama kilichobadilika, unafuatilia nyuma kupitia mazungumzo yaliyokupelekea huko, na unakusanya mantiki baada ya ukweli. Maana mfumo unaohitaji si kumbukumbu. Ni grafu.
Grafu inakupa nini ambacho kumbukumbu haiwezi
Grafu inaunganisha ishara kwenye zana na wakati. Badala ya mtu kuandika kwa mkono "tuliamua kutumia webhooks kwa sababu ya vikomo vya kiwango", grafu inaunganisha thread ya Slack ambapo vikomo vya kiwango vilijadiliwa, suala la Linear lililofuatilia kazi ya muunganisho, PR iliyotekeleza webhooks, na watu waliohusika katika mazungumzo. Uamuzi hurekodiwa – unaweza kuundwa tena kutoka kwa miunganiko kati ya mambo yaliyokuwa yakitokea.
Tofauti ya vitendo inaonekana katika hali maalum. Wiki tatu baada ya uamuzi wa webhook, mhandisi mpya anajiunga na kuuliza: "kwa nini tunatumia webhooks badala ya polling kwa GitHub? Polling inaonekana rahisi zaidi." Bila mfumo uliounganishwa, mtu anasema "oh, tuliamua hivyo muda fulani uliopita", hakuna anayekumbuka kituo, mtu anatumia dakika kumi na tano kutafuta Slack, na wao au wanapata au (uwezekano zaidi) wanaunda tena mantiki kutoka kwa kumbukumbu, ambayo ni hatari kwa sababu kumbukumbu haiaminiki na mantiki ya asili ilikuwa karibu hakika yenye nuance zaidi kuliko mtu yeyote anavyokumbuka wiki tatu baadaye.
Kwa grafu, mhandisi anatazama kazi ya muunganisho wa GitHub. Kila ishara iliyogusa kazi hiyo imeshikamana: mjadala wa asili kuhusu vikomo vya kiwango, thread ambapo polling dhidi ya webhooks ilitathminiwa, PR iliyotekeleza mabadiliko. Mkondo kamili wa uamuzi, kutoka mwanzo hadi mwisho, bila mtu yeyote kutafuta chochote na bila mtu yeyote kurekodi chochote.
Pengo si kati ya "utafutaji mzuri" na "utafutaji mbaya" – liko kati ya urejeshaji kwa maneno muhimu na urejeshaji kwa uhusiano. Maamuzi yanafafanuliwa na miunganiko yao na kazi, watu, na matokeo, si maneno yaliyotumiwa kuyaeleza.
Gharama ambazo hazionyeshwi kwenye dashibodi yoyote
Mimi ni mashaka ya kweli kuhusu mtu yeyote anayedai nambari sahihi kwa gharama laini kama hizi (takwimu za aina ya "timu zinapoteza saa X kwa wiki" daima zinaonekana kuwa zimehesabiwa nyuma kutoka hitimisho linalotakiwa), lakini hapa kuna tulichoona katika timu yetu wenyewe.
Gharama dhahiri zaidi ni majadiliano tena – wakati hakuna anayeweza kupata uamuzi wa asili, timu huufungua tena mara kwa mara, wakati mwingine kwa sababu watu hawakumbuki kweli na wakati mwingine kwa sababu mwanachama mpya wa timu ana maswali halali ambayo hakuna anayeweza kujibu kwa maelezo. Tulikuwa tukijadili tena maswali yaliyoshughulikiwa mara kwa mara kabla ya kupata njia ya kufuatilia maamuzi hadi chanzo chake, na kila majadiliano tena yana mzigo wake: muda wa mkutano, uchovu wa kihisia wa kujadiliana kuhusu kitu ambacho una uhakika ulitatuliwa tayari, mashaka ya kudumu kwamba mantiki ya asili ilikuwa na nuance zaidi kuliko mtu yeyote anavyokumbuka.
Gharama nyepesi zaidi ni inayotokea wakati wa uwezeshaji. Kila swali "kwa nini ilifanywa kwa njia hii?" kutoka kwa mwanachama mpya wa timu hukatiza mtu aliyekuwepo katika uamuzi wa asili, na jibu huundwa tena kutoka kwa kumbukumbu kila wakati mtu anapouliza, likijitenga kidogo zaidi na mantiki ya asili kwa kila upitishaji – kama mchezo wa simu iliyoharibika, isipokuwa simu ni programu ya biashara na ujumbe ni "kwa nini usanifu unafanya kazi kwa njia hii". Na kuna pengo la uaminifu linaloongezeka kwa wakati: "tulienda na webhooks" ina uzito mdogo kuliko "tulienda na webhooks kwa sababu polling ilikuwa ikila 40% ya kikomo cha kiwango cha API ya GitHub na tulikuwa tukipata kizuizi wakati wa masaa ya kilele." Mantiki ndiyo inayoruhusu wahandisi wa baadaye kutathmini kama uamuzi unashikilia chini ya hali zilizobadilika, na mantiki hiyo ipo katika thread fulani ya Slack, imehifadhiwa vizuri na ni vigumu sana kuonekana.
Acha kupoteza maamuzi katika mzunguko wa Slack. Sugarbug hufuatilia mkondo kamili wa uamuzi kiotomatiki – kutoka thread ya Slack hadi suala la Linear hadi PR.
Q: Kwa nini ni vigumu sana kupata maamuzi ya zamani katika Slack? A: Slack huhifadhi ujumbe kwa wakati, si kwa maana. Uamuzi uliozikwa katika thread unaonekana sawa kabisa na jibu lingine lolote – utafutaji wa Slack unaweza kulinganisha maneno muhimu, lakini hauwezi kutofautisha "tuliamua kutumia Redis" na "je, tunapaswa kutumia Redis?" bila kusoma muktadha kamili wa mazungumzo. Kadiri muda unavyopita, ndivyo inavyokuwa ngumu zaidi – kwa sababu unapoteza vidokezo vya muktadha (nani alihusika, kituo kipi, wiki gani) vilivyofanya utafutaji uwezekane mwanzoni.
Q: Je, Sugarbug hufuatilia moja kwa moja maamuzi yaliyofanywa katika Slack? A: Ndiyo. Sugarbug huainisha ishara zinazoingia kutoka Slack na zana zingine zilizounganishwa, ikitambua mifumo inayofanana na maamuzi – threads zinazorejelea kazi, zinazohusisha watu walioteuliwa, na kusababisha mabadiliko ya hali au PRs. Hizi zimeshikamana na kazi husika katika grafu ya maarifa, ili uweze kufuatilia mkondo wa uamuzi kutoka kwa kazi badala ya kutafuta historia ya Slack.
Q: Ni nini tofauti kati ya kumbukumbu ya maamuzi na grafu ya maarifa kwa maamuzi? A: Kumbukumbu ya maamuzi inahitaji mtu kurekodi kila uamuzi kwa mkono unapotokea – uugundua, usimame, umuhtasari, uweke lebo, uunganishe. Grafu ya maarifa hupendekeza maamuzi kutoka ishara zinazopita kwenye zana zako na kuziunganisha na kazi, watu, na mazungumzo kiotomatiki. Moja inategemea nidhamu thabiti ya kila mwanachama wa timu; nyingine inafanya kazi nyuma ya pazia kutoka shughuli inayotokea tayari.
Q: Je, Sugarbug inaweza kutoa maamuzi kutoka kwa zana zingine zaidi ya Slack? A: Sugarbug inaunganishwa na Slack, GitHub, Figma, Linear, Notion, barua pepe, na kalenda. Maamuzi mara nyingi yanahusisha zana nyingi (maoni ya Figma yanasababisha thread ya Slack inayosababisha PR), na grafu ya maarifa inaunganisha ishara kwenye nyuso zote zilizounganishwa. Unaona mkondo kamili bila kujali zana gani mazungumzo yalianza.
Q: Hii ni tofauti vipi na kutumia utafutaji wa ndani wa Slack? A: Utafutaji wa Slack hupata ujumbe unaohusisha maneno muhimu maalum. Grafu ya maarifa hupata uhusiano kati ya ujumbe, kazi, na watu. Unapotafuta uamuzi, mara chache unatafuta neno – unatafuta wakati ambapo timu ilichagua mbinu moja badala ya nyingine, na wakati huo unafafanuliwa na miunganiko yake na ishara zingine, si maneno yaliyotumiwa kuueleza.
---
Ikiwa maamuzi yanaendelea kutoweka katika historia yako ya Slack, tatizo si Slack – ni kwamba hakuna mfumo unaofuatilia wakati muhimu na kuunganisha na kazi iliyoathiriwa. Hiyo ndiyo pengo tunalojenga Sugarbug kulijaza.