Jinsi ya Kuendesha Timu ya Uhandisi ya Async-First
Mwongozo wa vitendo wa kuendesha timu za uhandisi za async-first – kutoka kanuni za mawasiliano hadi mila ya maamuzi ambayo kweli inashika.
By Ellis Keane · 2026-04-06
Wakati telegrafu ilipomaliza taarifa ya kila siku
Mwaka 1844, Samuel Morse alituma ujumbe wa kwanza wa telegrafu kati ya Washington na Baltimore, na ndani ya muongo mmoja, biashara zilizokuwa zinategemea taarifa za kila siku za wajumbe zilianza kufanya kazi tofauti. Si kwa sababu walitaka kuwa "telegraph-first" (hakuna aliyesema hivyo), bali kwa sababu kizuizi kilibadilika. Habari ingeweza kusafiri haraka kuliko farasi, kwa hivyo mila zilizojengwa kuzunguka farasi zilipotea kimya kimya.
Mlinganisho na kuendesha timu ya uhandisi ya async-first ni wa moja kwa moja kwa njia isiyostarehesha. Tuna Slack, Linear, GitHub, Notion, na zana nyingine kama saba zinazosogeza habari kwa kasi ya webhook, na bado timu nyingi bado zinapanga siku zao kuzunguka mila za ulandanishi zilizoundwa kwa wakati ulipohitajika kuwa chumbani moja kushiriki muktadha – stand-up ya kila siku ambapo kila mtu anasoma tikiti zao za Jira kwa meneja ambaye tayari ana bodi ile ile imefunguliwa kwenye monitora ya pili, "quick sync" inayoendelea dakika 45 kwa sababu watu watatu wanashiriki skrini kwa zamu wakati wengine wote wanakagua simu zao.
Kwa timu ndogo ya uhandisi kama yetu – watu wanne katika maeneo matatu ya saa – kutambua kuwa kizuizi kimebadilika kulikuwa sehemu rahisi. Kujenga upya mila kulichukua muda zaidi.
Timu ya uhandisi ya async-first inavyoonekana kweli
Uhandisi wa async-first unamaanisha hali ya kawaida ya mawasiliano ya timu yako ni ya kiasinkroni. Maamuzi yanaandikwa. Hali inaonekana bila kuuliza. Muktadha umeandikwa mahali ambapo watu wanaweza kuupata kwa ratiba yao wenyewe. Mikutano bado inafanyika, lakini ni ubaguzi unaochaguliwa, si hali ya kawaida ambayo lazima uondoke.
Hii haimaanishi kwamba hakuna mtu anayezungumza kwa wakati halisi kamwe – hiyo ingekuwa ya kipuuzi na, kwa uaminifu, upweke kidogo – ukaguzi wa muundo, utatuzi wa migogoro, vikao vya kufikiria kwa pamoja, na majadiliano ya usanifu ambapo unahitajika kusoma lugha ya mwili na kuchora kwenye ubao nyeupe vyote vinabaki vya ulandanishi, na hiyo ni sawa. Tofauti ni hali gani unayofikia kwanza unapohitaji kuwasilisha kitu, na kwa mambo mengi katika timu ya uhandisi, jibu linapaswa kuwa kuandika badala ya kupanga simu, kwa sababu maoni yaliyoandikwa vizuri kwenye Linear saa 8 jioni huko Brooklyn bado yanasomeka kikamilifu saa 3 asubuhi huko Berlin asubuhi inayofuata.
Async-first haimaanishi async-only. Inamaanisha hali yako ya kawaida ni ya kiasinkroni, na unachagua mawasiliano ya ulandanishi kwa makusudi wakati hali inaidai kweli.
Nguzo nne (ambazo zinasikika dhahiri hadi uzijaribu)
Katika mwaka uliopita, tumekuwa tukijenga Sugarbug kama timu ya watu wanne iliyoenea kati ya Pwani ya Mashariki ya Marekani na Ulaya, na mambo ambayo kweli yalifanya timu yetu ya uhandisi ya async-first kufanya kazi hayakuwa zana au sera – yalikuwa tabia. Hapa kuna nne zilizoshika.
1. Andika maamuzi mahali yalipofanywa
Karibu hakuna mtu anayefanya hivi kwa uthabiti. Uamuzi unafanywa katika thread ya Slack. Mtu anasema "sawa twende na chaguo B." Na kisha... inabaki pale. Katika thread ambayo itakuwa haiwezekani kupata kwa vitendo wiki tatu baadaye.
Suluhisho si logi ya maamuzi (vizuri, si hasa). Suluhisho ni kanuni: yeyote anayefanya uamuzi wa mwisho anaandika muhtasari wa sentensi moja wa kilichoamuliwa na kwa nini, katika zana ambapo kazi inaishi. Ikiwa uliamua kubadilisha muundo wa majibu ya API, muhtasari huo unaenda kwenye issue ya Linear au maelezo ya PR kwenye GitHub, si kwenye thread ya Slack au nakala ya kuandikwa ya rekodi ya mkutano ambayo hakuna mtu atakayeitazama tena.
Tulijifunza hili kwa gharama kubwa: PR ilisimama kwenye ukaguzi kwa siku tatu kwa sababu mkaguzi hakujua kwamba tulikuwa tayari tumeamua kutumia server-side rendering kwa ukurasa huo – uamuzi ulikuwa umezikwa kwenye thread ya Slack kutoka wiki iliyopita, na hakuna mtu aliyekuwa ameandika kwenye issue. Mkaguzi aliacha maoni sita kuhusu mapendekezo ya client-side hydration ambayo tayari yalikuwa yameamuliwa, mwandishi alikasirika, na tulipoteza karibu wiki nzima kwa mazungumzo ambayo yangechukua sekunde kumi ikiwa muktadha ungekuwa umeambatanishwa na kazi tangu mwanzo.
Baada ya hapo, tuliachana na kujaribu kudumisha hati tofauti ya maamuzi (ambayo ilifanya kazi kwa wiki mbili hivi kabla ya kuwa kitu kingine ambacho hakuna mtu aliyesasisha) na tukaanza kuandika maamuzi moja kwa moja kwenye issue yenyewe. Sekunde kumi za juhudi, na inaishi kwa sababu imeambatanishwa na kazi, si inaelea katika hati-meta ambayo hakuna mtu anayeikagua.
2. Fanya hali ionekane, si iripotiwe
Kwa timu yetu, mkutano wa sasisha hali ulikuwa mila ya ulandanishi ya gharama kubwa zaidi – kila mtu akisimulia alichofanya jana na anachofanya leo wakati wengine wote wanasikiliza kwa nusu na kusubiri zamu yao. Katika timu ya async-first, hali inapaswa kuwa kitu unachoweza kuona, si kitu ambacho mtu ana kukuambia.
Hii inamaanisha zana yako ya usimamizi wa mradi inahitaji kuakisi ukweli halisi. Ikiwa issue ya Linear iko "Inaendelea," inapaswa kuwa kwa sababu mtu anafanya kazi juu yake sasa hivi, si kwa sababu aliihamisha huko Jumatatu na hajaigusa tangu wakati huo. PR za GitHub zinapaswa kuwa na vichwa vya maelezo na issue zilizounganishwa. Faili za Figma zinapaswa kuwa na uteuzi wa majina wazi unaokwambia ni nini kinaendelea dhidi ya kilichoidhinishwa.
Kinachofanya hali ionekane
- PR zilizounganishwa na issue – Mtu yeyote anaweza kuona msimbo upi unalingana na kazi ipi
- Uteuzi wazi wa branch –
feat/user-onboarding-flow inakuambia zaidi kuliko fix-stuff
- Hali za issue zilizosasishwa – Sogeza tikiti wakati kazi inasogea kweli, si wakati wa stand-up
- Muhtasari wa kila wiki ulioandikwa – Mtu mmoja anaandika muhtasari, kila mtu anasoma kwa kiasinkroni
Kinachoweka hali isionekane
- Sasisha za maneno tu – Habari inapotea wakati mkutano unaisha
- Mikutano ya hali kama mfumo wa rekodi – Ikiwa haikuwa imesemwa kwenye stand-up, haikutokea
- Bodi zilizochakaa – Bodi ya Kanban ambayo haijaguswa tangu Jumatatu
- Muktadha uliofungwa kwenye DM – Watu wawili wanajua, wengine wote wanakisia
3. Eleza madirisha ya majibu, si nyakati za majibu
Mojawapo ya wasiwasi wa hila zaidi kuhusu mawasiliano ya kiasinkroni ni kusubiri bila mwisho wazi. Unatuma ujumbe, na hujui kama utapata jibu ndani ya dakika ishirini au kesho alasiri. Kutokuwa na uhakika ni mbaya zaidi kuliko ucheleweshaji halisi.
Suluhisho si kudai majibu ya haraka zaidi (hiyo tu inaunda upya utamaduni wa ulandanishi kwa hatua za ziada). Ni kuweka matarajio wazi kuhusu madirisha ya majibu kwa aina tofauti za mawasiliano. Kwa timu yetu, inaonekana takriban hivi:
- Ujumbe wa Slack kwenye chaneli za umma: Ndani ya saa 4 za kazi
- Ukaguzi wa PR: Ndani ya siku moja ya kazi
- Maoni ya issue za Linear: Ndani ya siku moja ya kazi
- DM zilizowekwa alama ya dharura: Ndani ya saa 1 wakati wa saa za kazi
- Kila kitu kingine: Ndani ya siku 2 za kazi
Madirisha mahususi yana umuhimu mdogo kuliko ukweli kwamba yapo na kila mtu amekubaliana nayo. Mara mdundo unapokuwa wazi, wasiwasi wa "je, wameona hii?" unapungua, na watu wanaacha kutuma ping za kufuatilia baada ya dakika thelathini za ukimya.
4. Linda muda wa ulandanishi kwa yale yanayohitaji kweli
Kitu ambacho hatukutarajia: mikutano tuliyoibaki ikawa bora kwa kiasi kikubwa. Wakati mkutano ni ubaguzi badala ya hali ya kawaida, watu wanafika wakiwa wamejiandaa na kushiriki kwa sababu wanajua hii ndiyo dirisha pekee walilonalo kujadiliana kitu pamoja.
Tulibaki na aina tatu za mikutano ya ulandanishi:
- Usawazishaji wa timu wa kila wiki (dakika 30, upeo) – Si sasisha za hali, bali vizuizi, masuala ya msalaba, na mazungumzo ya "je, mtu mwingine anafikiri uamuzi huu wa usanifu utatuuma?"
- Ukaguzi wa muundo – Mambo fulani kweli yanahitaji maoni ya kuona ya ulandanishi
- Vikao vya programu ya jozi – Wakati watu wawili wamekwama, kuzungumza pamoja bado ni haraka zaidi kuliko kubadilishana kwa kiasinkroni
Kila kitu kingine ambacho kilikuwa mkutano kikawa pendekezo la maandishi, video ya Loom, au thread ya maoni kwenye issue husika. Kalenda yetu ilibadilika kutoka kuonekana kama mchezo wa Tetris kuwa kitu ambacho binadamu anaweza kweli kupanga – ambayo, inavyogunduliwa, ndiyo sababu nzima ya kuwa na kalenda.
stat: "Mikutano 3/wiki" headline: "Kutoka 12" source: "Kalenda halisi ya timu yetu baada ya kubadilika kuwa async-first"
Sehemu ambayo hakuna mtu anayekuonya
Sehemu ngumu ya async-first si kanuni za mawasiliano au usanidi wa zana. Ni marekebisho ya kihisia. Tulipoacha stand-up yetu ya kila siku, mmoja wa wahandisi wetu alitaja kujisikia "hatia ya ajabu" kuhusu kuanza kazi ya kina saa 4 asubuhi bila kwanza kukagua na mtu. Mwingine alisema ukimya kwenye Slack kabla ya adhuhuri ulihisi kama hakuna mtu anayefanya kazi, ingawa GitHub ilionyesha commit zinaingia kila saa.
Hii ni sehemu ya asili ya binadamu ya tatizo, na haina suluhisho la kiwango cha mfumo. Kilichotusaidia ni kuwa wazi kuhusu hilo. Tulizungumza kuhusu ukweli kwamba async inaweza kuhisi upweke wakati mwingine, na kwamba ni sawa kuruka kwenye simu tu kwa sababu unataka kuzungumza na binadamu kuhusu tatizo unalolitatua. Kanuni si "usipige simu kamwe," ni "usihitajie simu kwa mambo ambayo hayaihitaji."
Watu fulani kwenye timu kweli wanapendelea mwingiliano zaidi wa ulandanishi, na kukidhi hilo si kushindwa kwa falsafa ya async-first – ni kutambua kwamba mapendeleo ya mawasiliano ni ya kibinafsi, na kushikilia kwa ugumu hali yoyote moja ni aina yake ya kasoro.
Sehemu ngumu si kusanidi mtiririko wa kazi wa kiasinkroni. Ni kuzoea ukimya kati ya ujumbe, na kuamini kwamba wenzako wanafanya kazi hata wakati huwezi kuwaona wakifanya hivyo. attribution: Ellis Keane
Kuifanya ishike: siku 30 za kwanza
Ikiwa unabadilisha timu iliyopo kwenda mfano wa timu ya uhandisi ya async-first, mwezi wa kwanza ndipo ambapo inachukua mizizi au inaanguka kimya kimya kurudi "hebu turuke kwenye simu ya haraka." Hapa kuna kilichofanya kazi kwetu kama ratiba ya takriban:
Wiki 1: Andika kanuni za mawasiliano. Kihalisi – hati ya ukurasa mmoja inayosema "hivi ndivyo tunavyowasiliana, hizi ndizo madirisha ya majibu yanayotarajiwa, hivi ndivyo vinavyohalalisha mkutano." Shiriki, jadili kwa ulandanishi (ndio, kejeli), na pata ridhaa.
Wiki 2: Futa au badilisha mikutano mitatu ya kurudiwa. Chagua ile ambayo kwa wazi zaidi ni sasisha-ya-hali-iliyojificha na ubadilishe na muundo wa maandishi. Usifute kila kitu mara moja – watu wanahitaji mteremko wa taratibu, si mwamba.
Wiki 3: Kagua usafi wa zana. Je, issue za Linear kweli zimesasishwa? Je, maelezo ya PR ni ya manufaa? Je, maamuzi yanaandikwa mahali ambapo kazi inafanyika? Ikiwa hapana, hii ndiyo wiki ya kuanzisha kanuni hizo. Teua mtu kama "bingwa wa async" ambaye anaonyesha kwa upole wakati uamuzi unafanywa kwa maneno lakini hauandikwi.
Wiki 4: Tathmini ya nyuma (kwa kiasinkroni, kwa kawaida). Tuma fomu rahisi: "Nini kinafanya kazi? Nini hakifanyi? Unakosa nini?" Majibu yatakushangaza – watu fulani watapenda utulivu, wengine watakuwa wakitatizika. Rekebisha kanuni kulingana na maoni halisi, si nadharia.
- [x] Andika hati ya kanuni za mawasiliano
- [x] Eleza madirisha ya majibu kwa kila chaneli
- [ ] Futa au badilisha mikutano 3 ya hali
- [ ] Kagua usafi wa zana (issue, PR, hati za maamuzi)
- [ ] Teua bingwa wa async kwa mpito
- [ ] Endesha tathmini ya nyuma ya kiasinkroni baada ya siku 30
- [ ] Rekebisha kanuni kulingana na maoni ya timu
Wakati async-first ni uamuzi mbaya
Async-first ni chaguo mbaya katika hali kadhaa za kawaida. Ikiwa timu yako ni watu watatu walioketi kwenye ofisi moja, mawasiliano ya ulandanishi labda ni sawa na gharama za ziada za kurasimisha kanuni za async zingekuwa kutatua tatizo ambalo huna. Vile vile, ikiwa timu yako iko katika mgogoro wa kweli – uzalishaji umeshuka, uzinduzi muhimu unakaribia, au unabadilisha mwelekeo wa bidhaa – hiyo ni eneo la ulandanishi, na kujifanya vinginevyo kungekuwa ni imani ngumu badala ya vitendo.
Async-first inafanya kazi vizuri zaidi kwa timu zilizosambaa katika maeneo ya saa, timu zenye zaidi ya watu watano (ambapo mlipuko wa mkusanyiko wa uratibu wa ulandanishi unaanza kuumiza), na timu ambazo zinapendelea kutuma msimbo kuliko kusimulia walichotuma kwenye mkutano kuhusu walichotuma. Ikiwa hiyo ni wewe, uwekezaji katika kanuni za async unajilipa ndani ya mwezi wa kwanza, hasa katika masaa ya uhandisi yaliyopatikana tena ambayo hapo awali yalipotea katika tata ya viwanda vya mikutano.
Telegrafu haikumaliza mazungumzo ya ana kwa ana – ilifanya tu safari ya kila siku ya mjumbe kuwa isiyo ya lazima. Hiyo ndiyo yote async-first inayofanya kwa timu ya uhandisi: inastaafu mila ambayo ilikuwepo tu kwa sababu zana zilikuwa bado hazijashika kasi, na inalinda mazungumzo ambayo kweli yana umuhimu.
Maswali Yanayoulizwa Mara kwa Mara
Q: Unashughulikiaje code review katika timu ya uhandisi ya async-first? A: Weka SLA wazi ya ukaguzi (yetu ni siku moja ya kazi) na ufanye maelezo ya PR kubeba mzigo mkubwa – eleza si tu kilichobadilika bali kwa nini, unganisha issue husika, na uweke alama kwenye chochote ambacho mkaguzi anapaswa kukizingatia. Hali mbaya zaidi ya kushindwa kwa ukaguzi wa async ni PR inayokaa siku tatu kwa sababu mkaguzi anahitaji muktadha ambao upo tu kichwani mwa mtu. Andika au lipa baadaye.
Q: Je, Sugarbug inasaidia na mtiririko wa kazi wa async-first? A: Inasaidia na tatizo mahususi la muktadha kugawanyika kati ya zana – uamuzi katika Slack, kazi katika Linear, maoni ya muundo katika Figma. Sugarbug inaunganisha ishara hizo ili hali ionekane bila mtu yeyote kulazimika kuisimulia kwenye mkutano. Si njia pekee ya kutatua tatizo hilo (unaweza pia kuwa na nidhamu sana kuhusu kuunganisha kila kitu kwa mikono), lakini tulijenga kwa sababu tulichoka na toleo la mkono.
Q: Kosa kubwa zaidi timu zinafanya wakati wa kubadilika kuwa async-first ni nini? A: Kuichukulia kama mabadiliko ya sera badala ya mabadiliko ya tabia. Unaweza kuandika hati nzuri ya "kanuni za mawasiliano," lakini ikiwa watu hawasasishi kweli issue zao za Linear au kuandika maamuzi kwenye PR, umekuwa tu umeondoa mikutano bila kubadilisha mtiririko wa habari. Kanuni lazima ziwe kumbukumbu ya misuli, ambayo inachukua takriban mwezi mmoja wa kuonyesha kwa upole na uthabiti.
Q: Unashughulikiaje matatizo ya dharura ya uzalishaji katika timu ya async-first? A: Huyashughulikii kwa kiasinkroni – hiyo ndiyo hoja nzima ya "async-first, si async-only." Eleza njia wazi ya kupandisha: chaneli maalum ya Slack au PagerDuty kwa dharura za kweli, kwa uelewa kwamba kila kitu kingine kinafuata madirisha ya kawaida ya majibu. Tofauti muhimu ni kati ya "dharura" (uzalishaji umeshuka) na "nataka jibu sasa" (ambayo kwa kawaida ni kutokuwa na subira, si dharura).
Q: Je, Sugarbug inaweza kuchukua nafasi ya mikutano ya stand-up kabisa? A: Inaweza kuchukua nafasi ya sehemu ya kukusanya habari – mila ya "kila mtu alifanya nini jana?" – kwa sababu muktadha huo tayari unapita kupitia GitHub, Linear, na Slack. Isiyoweza kuchukua nafasi ni sehemu ya uhusiano wa kibinadamu, ndiyo maana bado tunashika usawazishaji mfupi wa kila wiki kwa mazungumzo ambayo yanafaidika kuwa katika chumba kile kile (cha mtandao).
Pata signal intelligence ikiletwa kwenye kisanduku chako cha barua pepe.