Jinsi ya Kufuatilia Maamuzi Katika Zana 5 za Timu Yako
Jinsi ya kufuatilia maamuzi yaliyotawanyika kwenye Slack, Notion, Linear na mapitio ya PR – na kwa nini rekodi za maamuzi hazikusaidii.
By Chris Calo · 2026-03-13
"Je, hatukukubaliana hili tayari?"
Watu watano kwenye simu. Hakuna anayejibu. Mtu anaondoa ukimya na kusema anadhani ilijadiliwa kwenye thread ya Slack, labda wiki tatu zilizopita, pengine kwenye #engineering lakini ingeweza kuwa #backend. Mbunifu wetu anakumbuka kidogo maoni kwenye Notion. Mmoja wa wahandisi wetu tayari anatelezesha Linear, akitafuta maoni kwenye suala ambalo labda lilifungwa. Au kuhifadhiwa. Au kuhamishwa kwenye mradi mwingine.
Uamuzi unaozungumziwa: ni mpango gani wa toleo la API tutakaoutumia kuendelea. Si chaguo linaloathiri mustakabali wa kampuni. Si ukingo wa usanifu. Ni mazungumzo tu kuhusu jinsi ya kufuatilia maamuzi katika zana nyingi – au, kwa usahihi zaidi, jinsi ya kupata uamuzi mmoja maalum ambao ulifanywa bila shaka, kwa ushahidi, na ambao sasa umeyeyuka kwenye nafasi kati ya zana tano ambazo hazizungumzani.
Niache nijenga upya eneo la tukio.
Ratiba ya Mahakama ya Uamuzi Uliopotea
Hapa kile kilichotokea kweli kweli, kilichokusanywa baada ya ukweli (kwa sababu bila shaka nilienda kupata kila kitu hatimaye – ilinichukua karibu saa moja, ambayo ilionekana kama matumizi mazuri ya mchana wa Jumatano).
Siku 1, 10:14 – Mmoja wa wahandisi wetu anaweka hati ya Notion yenye kichwa "Chaguo za Toleo la API" kwenye #engineering. Chaguo tatu zilizo na faida na hasara za kila moja. Muundo safi. Mawazo mazuri. Aina ya hati inayokufanya uhisi timu yako ina kila kitu chini ya udhibiti.
Siku 1, 10:22 – Mjadala unaanza kwenye thread ya Slack chini ya kiungo kilichoshirikiwa. Majibu sita katika dakika ishirini za kwanza. Mazungumzo ya kweli, ya manufaa kuhusu uoanifu wa nyuma, athari kwa SDK ya mteja, na kama toleo kwa kichwa cha ombi linastahili maumivu ya utatuzi wa makosa. Pia, karibu na jibu la nne, kulikuwa na upotoshaji mfupi kuhusu mahali pa kula chakula cha mchana (ambayo, kwa kweli, ilifikia makubaliano haraka zaidi kuliko mjadala wa toleo).
Siku 1, 11:47 – Mbunifu wetu, ambaye alikuwa akiangalia, anatoa sentensi moja: "toleo kwa njia linafanya API explorer kusomeka zaidi, na fanyeni /v2/." Majibu mawili ya kidole gumba juu. Bila kupinga. Uamuzi umefanywa.
Siku 1, 14:30 – Mwanatimu anafupisha matokeo kwenye maoni ya Linear kwenye suala la uboreshaji wa API. Angavu nzuri. Ugunduzi mbaya, inavyoonekana, kwa sababu maoni ya Linear yanakuwa yasiyoonekana kivitendo mara suala likifungwa.
Siku 8 – PR inayotekeleza /v2/ inawasili. Maelezo ya PR yanarejelea suala la Linear kwa nambari lakini hayasemi chochote kuhusu uamuzi wa toleo yenyewe au thread ya Slack ambapo hilo lilitokea kweli kweli. Kawaida kabisa. Hakuna anayeandika "kwa njia, hii ndiyo nasaba kamili ya uamuzi huu" kwenye maelezo ya PR, kwa sababu hakuna anayekuwa mwendawazimu.
Siku 43 – Mtu mpya anachukua tikiti inayohusiana na anauliza: "Je, tunafanya toleo kwa njia au toleo kwa kichwa cha ombi?" Hati ya Notion? Haikuwahi kusasishwa na matokeo. Thread ya Slack? Imezikwa chini ya ujumbe wa wiki sita. Maoni ya Linear? Kwenye suala lililofungwa ambalo hakuna anayefikiria kutafuta. PR? Ungejua ilikuwepo ili kuipata.
Na hivyo watu watano wanakaa kwenye simu, wakiangaliana, wakihesabu upya uamuzi ambao ulikwisha tatua wiki sita zilizopita. Maendeleo.
title: "Uamuzi Mmoja, Wiki Sita, Zana Tano" Siku 1, 10:14|ok|Notion doc "API Versioning Options" imeshirikiwa kwenye #engineering; chaguo tatu Siku 1, 10:22|ok|Mjadala wa Slack unaanza; mazungumzo kuhusu uoanifu wa nyuma na SDK Siku 1, 11:47|ok|Uamuzi umefanywa: path versioning, /v2/ Siku 1, 14:30|amber|Matokeo yanafupishwa katika maoni ya Linear; issue iliyofungwa = utafutaji mbaya Siku 8|amber|PR inayotekeleza /v2/ imeunganishwa; maelezo yanarejelea issue si uamuzi Siku 43|missed|Mwanatimu mpya anauliza: "path au header?" – jibu lipo; hakuna anayeweza kulipata
Mahali Ambapo Maamuzi Yanakufa
Jambo ni kwamba hakuna zana zilizoshindwa. Slack ilifanya hasa kile Slack hufanya. Notion ilihifadhi hati vizuri. Linear ilifuatilia suala. GitHub ilichanganya msimbo. Kila zana ilifanya kazi vizuri katika hali ya kutengwa, ambayo ni aina ya uchunguzi unaosikika kama sifa hadi unafahamu kwamba huo kweli ni utambuzi.
| Mahali ilipotokea | Kwa nini haiwezi kupatikana baadaye | |---|---| | Thread ya Slack | Unahitaji kukumbuka maneno halisi ambayo mtu alitumia wiki sita zilizopita. Bahati nzuri. | | Maoni ya Linear | Maoni kwenye masuala yaliyofungwa kama yamechongwa kwenye sakafu ya bahari | | Hati ya Notion | Hati ipo, lakini hakuna aliyeisasisha na matokeo, kwa sababu ni wanadamu | | GitHub PR | Mazungumzo yanafunikwa baada ya kuchanganywa – ungejua PR gani kuchimba | | Mkutano (wa mdomo) | Imepotea kabisa isipokuwa mtu alichukua maelezo NA akayaweka mahali yanayoweza kupatikana | | Thread ya barua pepe | Utafutaji mzuri, lakini tu ikiwa ulikuwa kwenye mnyororo sahihi |
Zana sita. Injini sita za utafutaji. Kumbukumbu ya pamoja sifuri.
Kila zana ilifanya kazi vizuri katika hali ya kutengwa, ambayo ni aina ya uchunguzi unaosikika kama sifa hadi unafahamu kwamba huo kweli ni utambuzi. attribution: Chris Calo
Rekodi ya Maamuzi: Maiti Mzuri
Ikiwa umekuwa ukitikisa kichwa ukisoma, labda tayari umepata Msukumo Ule. Ule unaofikiria: "Sawa, nitaunda Rekodi ya Maamuzi." R kubwa, M kubwa. Hifadhidata nzuri ya Notion yenye safu wima za Tarehe, Uamuzi, Muktadha, Wadau, na Hali. Unatangaza kwenye kituo cha timu. Wewe mwenyewe unaorodhesha maingizo matatu ya kwanza kwa undani wa kina, na hujisikia vizuri kweli kweli.
Nimejenga hasa kitu hiki katika makampuni matatu (na ndiyo, ninajua kurudia jaribio moja lililoshindwa na kutarajia matokeo tofauti kuna jina la kliniki). Kila wakati, nilikuwa na uhakika kabisa kwamba sasa itafanya kazi. "Wakati huu tutakuwa na nidhamu!" Hatukuwa. Wewe pia hutakuwa. Sisemi hivi kuwa mkatili – ninasema kwa sababu njia ya kushindwa imejengwa ndani ya muundo.
Hivi ndivyo inavyotokea. Wiki moja: nzuri. Wiki mbili: imejazwa kwa kiasi kikubwa. Wiki tatu: mtu anafanya uamuzi wa haraka kwenye DM ya Slack, na rekodi haisikii. Wiki nne: PR yenye uamuzi wa usanifu uliofichwa kwenye maoni ya ukaguzi inachanganywa, na hakuna anayefikiria kuiandika. Wiki tano: mtu yuko likizoni, timu iliyobaki inaamua kitu wakati wa chakula cha mchana (upotoshaji wa chakula cha mchana unarudi), na rekodi inakimya.
Wiki ya sita, Rekodi ya Maamuzi yako ni ukumbusho. Mnara wa heshima wa nia njema, ukikaa kwenye upande wa Notion, ukikusanya vumbi la kidijitali. Nina tatu kama hizi. Ni nzuri. Pia hazina manufaa kabisa.
Rekodi za maamuzi zinashindwa si kwa sababu timu hazina nidhamu, bali kwa sababu zinaomba wanadamu kutambua wakati kama muhimu unapo tokea, kusimama, kubadilisha muktadha hadi zana ya nyaraka, na kuandika kwa undani wa kutosha ili kuwa na manufaa wiki sita baadaye. Hiyo ni jambo lisilo na mantiki kuomba watu wanaoshughulika na kazi halisi.
Jinsi ya Kufuatilia Maamuzi Katika Zana Nyingi kwa Kweli
Rekodi za mkono zinashindwa kwa sababu ya hali ya kibinadamu. Utafutaji kwa zana moja moja unashindwa kwa sababu ya mgawanyiko. Kinachofanya kazi kweli kweli ni kitu kinachofuatilia uso wote wa zana zako na kuunganisha pointi bila yeyote kuhitaji kusimama kile anachoenda.
Kwa vitendo, hiyo inamaanisha mambo manne:
Ukusanyaji wa otomatiki. Kila ishara kutoka kwa zana zako – ujumbe wa Slack, maoni ya Linear, ukaguzi wa PR, masasisho ya Notion, maandishi ya mkutano – inakusanywa bila mtu yeyote kuinua kidole. Unaendelea kufanya kazi. Mfumo unaendelea kufuatilia. Hakuna haja ya kukatiza mawazo ili kufungua lahajedwali na kurekodi kilichotokea tu (ambacho, kama tulivyoamua, hakuna anayefanya hivyo hata hivyo).
Uainishaji. Si kila ujumbe ni uamuzi. Wengi ni masasisho ya hali, maswali, au kelele. Mfumo unahitaji kutofautisha kati ya "tunapaswa kutumia toleo kwa njia au kwa kichwa cha ombi?" (swali), "na fanyeni /v2/" (uamuzi), na "mwisho wa /v2/ umewekwa" (sasisha hali). Hapa ndipo kifikio cha LLM kinapata thamani yake – ingawa si kamilifu. Tulikuwa na kipindi cha kukumbukwa ambapo "yeah let's just do that" kiliendelea kuwekwa alama kama uamuzi mkubwa wakati mtu alikuwa tu anakubaliana kwenda kunywa kahawa. Inabidi muktadha wa wakati na uzito wa jukumu la mtumaji ili kupata alama ya kuamini kwa usahihi.
Kuunganisha. Hii ndiyo inayotofautisha "utafutaji bora" na ufuatiliaji wa kweli wa maamuzi. Uamuzi kwenye thread ya Slack unapohusiana na suala la Linear ambalo lilizalisha PR ya GitHub – muunganisho huo unahitaji kuwepo kwa sababu mfumo ulifuatilia marejeleo (vitambulisho vya masuala, nambari za PR, URL za threads, ukaribu wa wakati), si kwa sababu mtu alivizora kwa mkono kwa makini. Hati ya Notion, thread ya Slack, maoni ya Linear, na PR zinapaswa zote kuashiria moja nyingine, otomatiki, kwa sababu ndiyo kilichotokea.
Upatikanaji. Unapotafuta "uamuzi wa toleo la API", unapata njia nzima – si tu zana uliyotafuta kwanza. Hati ya Notion yenye chaguo, thread ya Slack ambapo uamuzi ulifanywa, maoni ya Linear yaliyoufupisha, na PR iliyoutekeleza. Yote yameunganishwa. Yote bila mtu yeyote kuingiza ingizo moja kwenye rekodi yoyote.
Mambo mawili unayoweza kujaribu sasa hivi (kweli kweli, bila masharti):
- Kituo cha
#decisions. Unda moja kwenye Slack na uombe timu yako kuweka sentensi moja pale kila wakati kitu kinapoamuliwa mahali pengine. Ni mkono, na itashuka ndani ya mwezi (nimeshajenga sifa yangu katika hili), lakini hata rekodi inayoshuka kiasi fulani inafanya muundo wa mawasiliano yaliyogawanyika uonekane wazi kwa maumivu.
- Tabia ya maelezo ya PR. Unapofungua PR inayotekeleza uamuzi, ongeza mstari mmoja kwenye maelezo: "Uamuzi: [kilichoamuliwa] – angalia [kiungo cha thread/hati]." Hii inachukua sekunde kumi, inaishi kwenye ukaguzi wa msimbo, na inakupa wewe wa baadaye kitu unachoweza kutafuta kweli kweli. Haitakusanya maamuzi yanayotokea kwenye DM za Slack au wakati wa chakula cha mchana, lakini zile inazokusanya ndizo muhimu zaidi – zile zinazobadilisha msingi wa msimbo.
Kile Ambacho Ufuatiliaji Uliounganishwa wa Maamuzi Hubadilisha Kweli Kweli
Uchimbuzi unakuwa hoja. Uwindaji ule wa toleo kutoka mwanzo? Kwa faharasa ya zana za msalaba, inakuwa utafutaji wa sekunde tano unaorejesha kila kitu katika mnyororo, kimeunganishwa. Ambayo ingeokoa mchana wa Jumatano wa aibu. This is what visibility across your engineering tools actually means in practice. It’s closely related to a semantic approach to finding past Slack decisions and a connected view of tasks that span three or more tools – all three problems stem from the same fragmented-tools root cause.
Muktadha wa kuanzisha kazi ambao haushauki. Wanachama wapya wa timu wanapata njia iliyounganishwa ya kwa nini mambo yako jinsi yalivyo, badala ya ukurasa wa wiki uliosasishwa mara ya mwisho miezi mitatu iliyopita ambao kila mtu anajua kwa ujumla ni makosa lakini hakuna aliyejali kurekebisha. (Una moja kama hiyo. Kila mtu ana.)
Midadisi michache ya mjadala ule ule. Hii ilinishangaza. Maamuzi yakiwa yanaweza kupatikana, "je, hatukukubaliana hili tayari?" inaweza kujibiwa kwa sekunde badala ya kuyeyuka kwenye ndoto ya pamoja ya dakika kumi ambapo kila mtu anakumbuka kujadili lakini hakuna anayeweza kuthibitisha kilichohitimishwa kweli kweli.
Mifumo ambayo haikuweza kuonekana awali. Maamuzi yakiwa wazi kwa pamoja, unaanza kuona mada zipi zinazozalisha midadisi ndefu zaidi na wapi maamuzi yanasimama. Akili ya mtiririko wa kazi ambayo hakuna zana moja inayoweza kukupa, kwa sababu hakuna zana moja ina picha nzima.
Jinsi Sugarbug Inavyoshughulikia Hili
Uwindaji wa toleo ulikuwa takriban tone la mwisho lililonifanya nianze kujenga Sugarbug (naam, pamoja na Rekodi tatu za Maamuzi zilizokufa zikibana dhamiri yangu). Ni mfumo niliouelezea hapo juu – unaunganishwa na zana zako zilizopo kupitia API, unalisha kila ishara kwenye grafu ya maarifa, unaainisha na kuunganisha otomatiki. Grafu inajijengea yenyewe timu yako ikifanya kazi. Hakuna anayeandika nyaraka yoyote, kwa sababu kukusanya ni athari ya kazi yenyewe.
Bado tuko mapema (katika uzalishaji, kabla ya uzinduzi), na kuna matatizo magumu ambayo hatujamaliza – maamuzi yanayotokea kwa maneno kwenye mikutano ambapo hakuna aliyechukua maelezo, au kutofautisha "yeah, let's do that" na ahadi halisi (tukio la kahawa lilitufundisha mengi kuhusu viwango vya kuamini). Lakini muda ninaoitumia kutafuta maamuzi ya zamani umeshuka kutoka "inakasirisha mara kwa mara" hadi "mara kwa mara kidogo," ambayo inaonekana kama mwelekeo wa busara.
Pata akili ya ishara kwenye kisanduku chako cha barua.
Maswali Yanayoulizwa Mara Kwa Mara
Ninawezaje kupata uamuzi uliofanywa kwenye thread ya Slack wiki chache zilizopita?
Bila faharasa ya zana za msalaba, unafanya nilivyofanya – ukitelezesha, ukijaribu maneno tofauti ya utafutaji, ukitumainia kukumbuka takriban lini mazungumzo yalitokea. Sugarbug inachukua ujumbe wa Slack pamoja na vyanzo vingine kwenye grafu ya maarifa, ili uweze kutafuta kwa dhana badala ya neno maalum la utafutaji. Si uchawi – mazungumzo bado yalihitaji kutokea kwa maandishi – lakini ni bora kuliko uchimbuzi wa kiakiolojia.
Je, Sugarbug inafuatilia maamuzi katika zana nyingi kwa njia ya kiotomatiki?
Ndiyo. Kila ishara kutoka kwa zana zilizounganishwa inaainishwa – maamuzi, masasisho ya hali, maswali, vizuizi – na kuunganishwa na watu na kazi zinazohusika. Uamuzi unapoonekana kwenye thread ya Slack inayohusiana na suala la Linear, grafu inaunganisha bila mtu yeyote kuhitaji nakili-bandika kiungo au kusasisha rekodi.
Ni nini tofauti kati ya rekodi ya maamuzi na grafu ya maarifa?
Rekodi ya maamuzi inahitaji mtu kuandika kilichoamuliwa, lini, na na nani. Grafu ya maarifa inajenga muunganisho huo otomatiki kutoka kwa ishara ambazo zana zako tayari zinazalisha – thread ya Slack, suala la Linear, PR iliyoutekeleza. Moja inahitaji nidhamu (ambayo, kama nimedhihirisha kwa kina, tunafanya vibaya sana); nyingine inahitaji mfumo.
Kwa nini rekodi za maamuzi daima zinashindwa?
Kwa sababu gharama huibuka wakati mbaya zaidi. Unahitaji kutambua uamuzi kama muhimu unapo tokea, kusimama, kubadilisha zana nyingine, kuandika kwa muktadha wa kutosha ili kuwa na manufaa wiki kadhaa baadaye, kisha kurudi kazini bila kupoteza mfuatano wako. Kila timu niliyoona ikijaribu hili inaacha ndani ya wiki sita – si kwa uvivu, bali kwa sababu mchakato unapingana na jinsi watu wanavyofanya kazi kweli kweli.
Je, timu ndogo zinaweza kufaidika, au ni kwa mashirika makubwa tu?
Timu ndogo zinaumia zaidi, kwa uzoefu wangu. Hakuna PM aliyewekwa kudumisha nyaraka, na "kumbukumbu ya taasisi" ni mtu mmoja au wawili ambao kwa bahati wana kumbukumbu nzuri. Startup ya watu watano inayofanya maamuzi madogo madogo kumi au zaidi kwa wiki kwenye Slack, GitHub, na Notion ina tatizo moja la mgawanyiko na shirika la watu hamsini – ni watu wachache tu wanaochukua gharama wakati kitu kinapotea.
---
Ikiwa umewahi kukaa kwenye simu watu watano wakijaribu kujenga upya uamuzi ambao ulikwisha kutatuliwa wiki kadhaa zilizopita, hiyo ndiyo hasa tatizo ambalo tulijenga Sugarbug kulishinda. Jiunge na orodha ya kusubiri.