Didelę savo karjeros dalį derinau konsultavimą su darbu įmonių viduje. Į kai kurias organizacijas atėjau kaip žmogus iš šalies. Kitose dirbau pakankamai ilgai, kad pats gyvenčiau su komandos sprendimais, incidentais ir laikinais sprendimais.

Todėl išorės specialistų ir darbuotojų skirtumą mačiau iš abiejų pusių. Pokalbis apie juos dažniausiai prasideda nuo kainos. Konsultanto dienos įkainis dar iki pietų atrodo didelis. Darbuotojo kaina pasislepia atlyginime, atrankoje, mokymuose, įrangoje, vadovų laike ir keliuose skirtinguose biudžetuose. Palyginti lengva. Tikrovė, kaip visada, kiek kitokia.

Tada prasideda stereotipai. Išorės specialistai dirba greitai, kalba tiesiai ir siekia rezultato. Darbuotojai geriau žino veiklos sritį ir lieka pakankamai ilgai, kad gyventų su savo sprendimų pasekmėmis.

Abiejuose teiginiuose yra tiesos. Tačiau nė vienas nepasako visko.

Mano patirtis tokia: išorės specialistai dažnai geriau moka įeiti į sistemą. Darbuotojai – joje gyventi.

Tai nėra žmonių vertinimas. Skirtingos pozicijos tiesiog leidžia matyti skirtingus dalykus. Kaip konsultantas atsinešu kitose organizacijose matytą patirtį. Kaip komandos narys prisimenu būtent šios organizacijos istoriją.

Vieno požiūrio neužtenka.

Ką pamatau atėjęs iš šalies

Atėjęs į naują organizaciją turiu vieną nesąžiningą pranašumą: ji man dar neatrodo normali. Dvylika patvirtinimų, diegimas su šešiais žmonėmis viename skambutyje, paslauga, kurios niekas nenori liesti, ir per tris vadovų grupes keliaujantis sprendimas vis dar atrodo keistai.

Dirbdamas įmonės viduje galiu matyti tas pačias problemas. Tačiau jau žinau, kurias verta kelti, kurios pareikalaus mėnesio pokalbių, o kurias visi išmoko apeiti. Vakarykštis laikinas sprendimas tampa šiandienos procesu. Dar kiek laiko – ir procesas gauna trumpinį bei tampa oficialus.

Darbas skirtinguose projektuose padeda greičiau atpažinti pasikartojančius dalykus. Eiles, neaiškią atsakomybę, architektūros ribas ar procesą, kurio paskirties jau niekas gerai neprisimena.

Žinoma, kiekviena organizacija yra unikali. Tik tas unikalumas stebėtinai dažnai atrodo pažįstamas.

Greitai pastebėti modelį yra naudinga. Bet tada turiu sulėtėti.

Modelis dar nėra paaiškinimas. Keista tikrinimo taisyklė gali saugoti svarbią sutarties išimtį. Rankinis patvirtinimas gali būti atsiradęs iš realios patirties. Paini sistemos riba gali atitikti verslo ribą, kurios kode nesimato.

Galiu greitai atpažinti problemą ir vis tiek nežinoti viso sprendimui reikalingo konteksto.

Su sistema ilgai dirbę žmonės turi tai, ko mano plati patirtis nepakeis. Jie prisimena, kuriam klientui reikia keisto veikimo, kokia migracija jau buvo bandyta ir kodėl gražus techninis pasiūlymas pasikeitė susidūręs su kasdieniu darbu.

Dalis šių žinių vis dar svarbios. Dalis tėra senas įprotis. Sunkiausia atskirti viena nuo kito.

Iš šalies galiu kalbėti tiesiau

Mano komanda vertinama ir už tai, kad kalbame tiesiai. Keliame klausimus, prie kurių kiti jau priprato. Peržiūrime seniai priimtus sprendimus. Pasakome, kai siūloma kryptis neatlaiko susidūrimo su realia sistema.

Iš šalies tai daryti lengviau. Kaip konsultantui man reikia saugoti mažiau karjeros kelių. Turiu mažiau senų konfliktų. Ir mažiau priežasčių apsimesti, kad vadovo mėgstama idėja yra tik „perspektyvi kryptis, kurią dar reikėtų išsamiau patikrinti“.

Kartais naudingiausia tiesiog pasakyti: nemanau, kad ši kryptis duos mums reikiamą rezultatą.

Tai nereiškia, kad konsultantai savaime drąsesni, o darbuotojai atsargesni. Tiesiog skiriasi santykiai. Darbuotojai žino pasiūlymo istoriją. Jie taip pat žino, kad po šiandienos ginčo rytoj vis tiek reikės dirbti kartu.

Išorės specialistas turi daugiau vietos tiesumui. Tačiau vien tiesumo neužtenka. Reikia ir smalsumo. Turiu klausytis žmonių, kurie išmano veiklos sritį, žino jos ribas ir tęs darbą man išėjus.

Mano nepriklausomybė vertingiausia tada, kai po mano darbo organizacija gali daugiau pati.

Šiuo atveju tiesumas nėra charakterio savybė. Tai dalis darbo.

Vienas projektas pakeitė mano požiūrį į tęstinumą

Paprastas darbo su išorės specialistais modelis atrodo taip: komanda ateina, padaro sutartą projektą, pristato rezultatą ir perduoda jį darbuotojams. Projektas baigtas. Gamybinė aplinka, kaip visada nepaisanti plano datų, tik pradeda juo domėtis.

Esu matęs tokį modelį. Tačiau vienas nesenas projektas parodė ir kitą variantą. Mums mokėjo už faktiškai dirbtą laiką, bet atsakomybė buvo ilgalaikė. Likome su savo sprendimais. Matėme jų pasekmes. Keitėme kryptį, kai tikrovė nesutiko su planu.

Popieriuje buvome išorės specialistai. Praktiškai – ilgalaikiai šeimininkai.

Tai pakeitė mano požiūrį į tęstinumą. Jis dažnai siejamas su darbo sutartimi. Tačiau darbuotojas gali pereiti į kitą komandą, būti paaukštintas arba išeiti. Konsultantas gali likti daug metų ir prižiūrėti kelias tos pačios sistemos kartas.

Ženklelis puikiai atidaro biuro duris. Atsakomybę jis prognozuoja prasčiau.

Daugiau pasako darbo modelis. Kas atsako už rezultatą? Kas gauna žinias iš gamybinės aplinkos? Kas gali priimti sprendimus? Kas lieka šalia, kai pirmą prielaidą tenka keisti?

Jei konsultantai laikomi laikinomis rankomis, jų atsakomybė irgi bus laikina. Jei jie gauna kontekstą, pasitikėjimą ir atsakomybę, skirtumas tarp išorinės ir vidinės komandos tampa daug mažesnis.

Greitis veikia geriau, kai yra tęstinumas

Dažniausiai mane kviečia tada, kai organizacijai reikia pajudėti. Migracijai trūksta krypties. Architektūros sprendimas lieka nepriimtas. Komandai reikia gebėjimo, kurio ji negali greitai užsiauginti.

Toks spaudimas gali būti naudingas. Iš šalies dažniau klausiu, kurie apribojimai vis dar tikri. Dirbdamas viduje geriau matau priklausomybes, žmones, istoriją ir galimas sprendimo pasekmes.

Todėl veni, vidi, vici skamba viliojančiai. Be to, lotynų kalba puikiai atrodo vadovų skaidrėse. Tačiau tai nėra visas darbo modelis.

Greitis svarbus, kai reikia sprendimo ar aiškaus rezultato. Tęstinumas svarbus, kai tą rezultatą reikės prižiūrėti, paaiškinti ir vėliau keisti. Geras projektas daro abu: padeda judėti dabar ir palieka komandą pasiruošusią tęsti savarankiškai.

Tokia pusiausvyra padeda ir darbuotojams. Jie saugo kontekstą ir galvoja apie pasekmes. Žmogus iš šalies gali padėti šias žinias paversti laiku priimtu sprendimu.

Viena pusė suteikia greitį. Kita padeda jį išlaikyti.

Geri konsultantai neatmeta rytojaus vien todėl, kad šiandien skubu. Geri darbuotojai neatideda šiandienos vien todėl, kad galvoja apie rytojų.

Šiose pozicijose kitaip matau kainą

Kaip konsultantas žinau, kad mano kainą sunku ignoruoti. Valandos užrašytos. Įkainis matomas. Sąskaita ateina. Joje kiekvienas pokalbis, tyrimas ar padarytas darbas turi savo skaičių.

Darbuotojo kaina ne tokia aiški. Ji mėgsta paskirstytą architektūrą. Atlyginimas yra tik viena dalis. Dar yra atranka, įvedimas į darbą, įranga, vadovų laikas, vidinis derinimas ir laikas, per kurį žmogus pradeda gerai dirbti.

Tačiau į darbuotoją investuojama ilgam. Veiklos srities žinios, pasitikėjimas ir sistemos atmintis auga metų metus. Jų vertė retai matoma vieno projekto biudžete.

Naujas langelis organizacijos schemoje dar nereiškia, kad darbas pajudės. Lygiai taip pat didelis konsultanto įkainis dar nereiškia, kad jis turi reikiamą patirtį.

Darbuotojams reikia teisės veikti ir tinkamos aplinkos. Konsultantams reikia konteksto ir pakankamai laiko, kad jų indėlis išliktų.

Todėl konsultanto dienos įkainio negalima tiesiog lyginti su darbuotojo atlyginimu. Vienoje pusėje yra sąskaita. Kitoje – tik dalis visos kainos.

Svarbiau klausti ne kiek kainuoja viena diena. Reikia klausti, kiek kainuoja pasiekti rezultatą, kiek ilgai jis bus naudingas ir kas liks, kai darbą atlikę žmonės išeis.

Brangus konsultantas, padėjęs greičiau priimti svarbų sprendimą, gali kainuoti mažiau nei ilgas laukimas. Stiprus darbuotojas, kuris saugo žinias ir ilgainiui gerina tą sprendimą, gali būti vertesnis už trumpą projektą.

Kaina matoma. Švaistymas moka palaukti.

Dabar ieškau to, ko organizacijai trūksta

Kartais organizacija samdo išorės specialistus darbui, kuriam reikia nuolatinio šeimininko. Jie gali suteikti trūkstamų rankų, tačiau kiekvienam projektui pasibaigus dalis žinių išeina kartu su jais.

Kartais organizacija samdo darbuotojus, nors jai reikia trumpos, tikslios pagalbos arba naujo požiūrio. Darbuotojas gali tapti ilgalaikiu šeimininku. Tačiau jam reikia laiko suprasti aplinką, žmones ir istoriją.

Todėl pirmiausia klausiu: ko trūksta?

Ar reikia žmogaus, kuris tą patį modelį jau matė kitur? Žmogaus, galinčio tiesiai suabejoti tuo, kas tapo įprasta? Greičio siekiant aiškaus rezultato? O gal reikia gilių veiklos srities žinių, ilgalaikės atsakomybės ir žmogaus, kuris vis dar bus čia priimant penktą to paties sprendimo versiją?

Kartais reikia abiejų. Konsultantai pastebi tai, kas darbuotojams tapo įprasta. Darbuotojai paaiškina, kurios keistos sistemos vietos saugo tikrą verslo istoriją.

Vieni suteikia naują požiūrį. Kiti saugo kontekstą.

Tai veikia, kai nė viena grupė nelaikoma vieninteliu tiesos šaltiniu. Sutarties rūšis savaime negarantuoja gero rezultato. Ir konsultantai, ir darbuotojai gali dalytis žiniomis bei stiprinti atsakomybę, jei jiems leidžiama dirbti kaip vienai komandai.

Sutarties rūšis tėra metaduomenys. Atsakomybei vis tiek reikia architektūros.

Darbas abiejose pusėse mane išmokė, kad ateiti ir pasilikti yra skirtingi gebėjimai. Stiprios komandos padeda atėjusiems suprasti, ką reiškia pasilikti. O pasilikusiems – išgirsti, ką gali parodyti naujas žmogus.

Prie komandos prisijungia naujas inžinierius ir susiduria su nepažįstama sistema. Architektūra atrodo pasenusi, o keli sprendimai visiškai neatitinka to, kaip jis tokią sistemą kurtų šiandien.

Paprastai netrunka atsirasti pasiūlymui viską pakeisti švaresniu sprendimu. Sistema per sudėtinga, jos ribos neteisingos, technologijos senos. Nauja architektūra būtų lengviau suprantama ir geriau pasiruošusi ateičiai.

Toks pasiūlymas dažniausiai pristatomas kaip techninis patobulinimas. Kartais taip ir yra. Tačiau kartais tikroji priežastis daug paprastesnė: perkurti sistemą patraukliau nei skirti laiko jai suprasti.

Naujas sprendimas visada atrodo švarus, nes dar nesusidūrė su realybe.

Santechnikas, norintis perstatyti jūsų butą

Įsivaizduokite, kad jūsų bute pradeda varvėti čiaupas. Iškviečiate santechniką ir tikitės, kad jis apžiūrės čiaupą, pakeis susidėvėjusią detalę ir paliks jį veikiantį.

Vietoje to santechnikas paaiškina, kad visa vamzdynų sistema pasenusi. Jis siūlo pakeisti visus vamzdžius, perkelti vonios kambarį, atverti kelias sienas ir sumontuoti modernius įrenginius, apie kuriuos neseniai mokėsi. Tuo pačiu vamzdyną būtų galima padalyti į kelias savarankiškai prižiūrimas dalis.

Daugumai mūsų tai būtų aiškus pavojaus signalas. Paklaustume, kaip varvantis čiaupas virto viso buto rekonstrukcija, suabejotume kaina bei nepatogumais ir tikriausiai išsikviestume kitą santechniką.

Programinės įrangos kūrime panašaus masto pasiūlymai vertinami visiškai rimtai. Vietinė problema tampa įrodymu, kad reikia perrašyti visą programą. Sudėtingas diegimas virsta platformos iniciatyva. Nepatogi riba tampa priežastimi skaidyti sistemą į paslaugas. Siūlomas sprendimas gerokai perauga pradinę problemą, tačiau organizacija vis tiek suburia darbo grupę jam nagrinėti.

Programinėje įrangoje rekonstrukcija atrodo pigi

Fizinės rekonstrukcijos kaina matoma iš karto: medžiagos, leidimai, išgriautos sienos ir kasdieniai nepatogumai. Programinė įranga sukuria pavojingą iliuziją, nes kodas neturi akivaizdžios medžiagų kainos. Gali pasirodyti, kad pakanka paskirti kelis inžinierius ir palaukti keletą mėnesių.

Tačiau programinės įrangos perrašymas neprasideda nuo nulio. Jis prasideda nuo daugybės metų elgsenos, kurią reikia iš naujo atrasti ir atkurti.

Tikroji kaina apima nedokumentuotas taisykles, duomenų migravimą, lygiagretų dviejų sistemų veikimą, integracijas, veiklos procedūras ir elgseną, nuo kurios tyliai priklauso klientai. Šios išlaidos išryškėja tada, kai naujoji sistema susiduria su ta pačia realybe, dėl kurios senoji tapo sudėtinga.

Esama sistema atrodo netvarkinga, nes visi jos kompromisai jau matomi. Siūloma sistema atrodo elegantiška, nes daugumos jos kompromisų dar niekas neatrado.

Veikianti programinė įranga nusipelno pagarbos

Programinės įrangos inžinieriai metų metus kartoja dvi frazes:

“If it works, don’t touch it.”

“Working software is good software.”

Nė viena iš jų nėra teisinga visais atvejais. Programinė įranga gali veikti, bet būti nesaugi, nepakeliamai brangi arba nebegalėti palaikyti tolesnių verslo poreikių. Atsisakyti bet kokio pakeitimo nėra inžinerinė disciplina – kartais tai tiesiog baimė.

Vis dėlto abi frazės perduoda svarbų perspėjimą. Veikianti programinė įranga jau susidūrė su tikrais klientais, duomenimis, gedimais, integracijomis ir organizaciniais apribojimais, kurių joks architektūros pasiūlymas negali iki galo atkartoti.

Tai nereiškia, kad jos negalima liesti. Tai reiškia, kad ji yra įrodymas.

Prieš atsisakydami veikiančios sistemos turime paaiškinti, ką laimėsime ir kuo rizikuosime. „Naujas sprendimas bus švaresnis“ nepakanka. Švara be konteksto dažnai tėra problemos nesupratimas.

Keistame kode gali slypėti pamirštos žinios

Daugelį metų veikiančios sistemos kaupia ne tik techninę skolą. Jos kaupia sprendimus.

Tikrinimo taisyklė gali egzistuoti todėl, kad išorinė sistema kadaise atsiuntė sugadintus duomenis. Besidubliuojanti darbo eiga gali atspindėti skirtingas sutarties sąlygas. Keistas laukas gali išlaikyti suderinamumą, o ne vietoje atrodanti riba – atspindėti atsakomybę už sistemos veikimą.

Kai kurie iš šių sprendimų gali būti nebeaktualūs. Kiti galbūt niekada nebuvo geri. Tačiau vien perskaitę kodą ir pastebėję, kad patys būtume jį parašę kitaip, skirtumo nesužinosime.

Per daug tobulinimo pasiūlymų kiekvieną esamą apribojimą iš karto laiko klaida. Komanda pašalina nepatogias dalis jų neištyrusi, o vėliau sužino, kad būtent tas nepatogumas saugojo svarbią informaciją.

Brandžios sistemos nelaiko visų žinių viename dokumente. Jos išbarstytos kode, testuose, duomenyse, palaikymo procedūrose, klientų lūkesčiuose ir sistemą prižiūrinčių žmonių atmintyje.

Perrašydami tokią sistemą keičiame ne vien technologiją. Bandome perkelti organizacijos atmintį iš formos, kurios iki galo nesuprantame, į dar neišbandytą sprendimą.

Naujos pradžios patrauklumas

Priežiūrai reikia nuolankumo. Inžinierius turi įžengti į kitų žmonių sukurtą sistemą, pripažinti, kad daugelio sprendimų priežastys nėra akivaizdžios, ir pirmiausia skirti laiko mokymuisi.

Perrašymas siūlo patrauklesnį vaidmenį. Užuot tyrinėjęs esamą sistemą, inžinierius tampa naujosios architektu. Jo mėgstami modeliai tampa standartu, o jo vardas susiejamas su matomu pokyčiu.

Tai nereiškia, kad kiekvienas perrašymas yra sąmoningas pripažinimo siekis. Paskata subtilesnė: organizacijos daug garsiau švenčia paleidimus ir naujas platformas nei dar vienus stabilaus veikimo metus.

Priežiūros pakeitimas gali užkirsti kelią problemai, kurios niekas niekada nepastebės. Perrašymas sukuria diagramas, planus ir naujas repozitorijas. Vienas atrodo kaip smulki užduotis. Kitas – kaip pažanga.

Šis skirtumas veikia mūsų sprendimus. Asmeninis pasirinkimas tampa architektūros principu. Nepatogumas skaitant svetimą kodą tampa įrodymu, kad jo neįmanoma prižiūrėti. Noras dirbti su naujesne technologija pavirsta verslo argumentu apie būsimą mastelį.

Galiausiai mintis „aš taip nekurčiau“ tyliai virsta teiginiu „šios sistemos neturėtų būti“.

Kartais perkurti yra teisinga

Kai kurias sistemas reikia pakeisti. Perrašymas gali būti pagrįstas, kai sistema nebegali patenkinti svarbių poreikių, jos technologijos nebepalaikomos, saugumo rizikos negalima pašalinti saugiai arba prasmingi pakeitimai tapo nepagrįstai brangūs.

Skirtumas tas, kad pagrįstas perrašymas prasideda nuo įrodytos problemos, o ne estetinio nusivylimo. Jis paaiškina, kodėl laipsniško tobulinimo nepakanka, ir palygina visą pakeitimo kainą su tolesniu esamos sistemos vystymu.

Atsakingame pasiūlyme migravimas yra architektūros dalis. Jame numatyta, kaip judės duomenys ir integracijos, kaip bus lyginama elgsena ir kaip pokyčio metu veiks abi sistemos. Nebūtina išsaugoti kiekvieno istorinio sprendimo, tačiau prieš pašalinant svarbią elgseną reikia ją suprasti.

Perrašymas neturėtų būti pabėgimas nuo sudėtingumo. Tai turi būti apgalvotas atsakas į sudėtingumą, kurį suprantame pakankamai gerai, kad galėtume keisti.

Prieš patvirtinant rekonstrukciją

Dideliems kodo pertvarkymams ir perrašymams neužtenka pažadų apie švaresnį kodą bei greitesnį kūrimą. Prieš atveriant sienas komanda turi atsakyti:

• Kokią išmatuojamą problemą sprendžiame?
• Ar galime ją pagerinti palaipsniui?
• Kuriuos esamus apribojimus patikrinome, o kuriuos tik numanome?
• Kokią elgseną naujoji sistema privalo išsaugoti?
• Ar vertinimas apima migravimą, lygiagretų veikimą, veiklos žinių kaupimą ir senosios sistemos išjungimą?
• Ar vis dar palaikytume šį pasiūlymą, jei nuopelnai už jo įgyvendinimą atitektų kitam?

Paskutinis klausimas gali būti nepatogus. Jei dingus pripažinimui pasiūlymas tampa mažiau patrauklus, problema gali būti ne vien techninė.

Programinę įrangą reikia keisti tada, kai to reikalauja problema, o pakeisti visą sistemą – kai įrodymai rodo, kad tai geriau už tolesnį jos vystymą.

Tačiau nesupratimas nėra įrodymas, modernumas nėra verslo rezultatas, o ambicija nėra architektūros strategija.

Prieš perstatydami butą sutaisykite čiaupą – arba bent jau supraskite, kodėl vamzdžiai nutiesti būtent ten.

Prieš dešimt metų dalyvavau Greg Young, Alberto Brandolini ir kitų patyrusių praktikų mokymuose. Vėliau dirbau skirtingose įmonėse, su įvairiais produktais ir komandomis. Technologijos keitėsi, tačiau sudėtingiausios problemos dažnai likdavo stebėtinai panašios.

Vis kartojosi vienas dalykas: dauguma IT problemų nėra vien technologinės.

Parašyti kodą dažnai yra paprastesnė darbo dalis. Sudėtingiausi sprendimai priimami dar iki kodo.

Jie atsiranda bandant suprasti problemą, susitarti dėl bendros kalbos, aiškiai paskirstyti atsakomybes ir nuspręsti, su kokiais kompromisais komanda pasirengusi gyventi.

Tos pačios problemos skirtingose sistemose

Ir augančiose įmonėse, ir didelėse organizacijose ne kartą mačiau situacijas, kai:

• komandos nariai sunkiai susikalba, todėl auga silosai ir priklausomybės;
• architektūra nebeatitinka verslo realybės, sudėtingėja ir nebesukuria pakankamai vertės;
• sprendimų priėmimas užtrunka, o jų įgyvendinimas kainuoja daugiau nei tikėtasi;
• techninės lyderystės trūkumas sudėtingus sistemų pokyčius paverčia pernelyg rizikingais;
• produkto ir inžinerijos kryptys pradeda tolti viena nuo kitos.

Produktai buvo skirtingi. Žmonės buvo skirtingi. Požymiai dažnai buvo tie patys.

Turėjau galimybę ir pasitikėjimą ne tik kurti sistemas kartu su komandomis, bet ir padėti suprasti, kur iš tiesų stringa jų darbas. Kartais apribojimas slypi kode. Tačiau neretai jis atsiranda procesuose, komunikacijoje, neaiškioje atsakomybėje ar neišspręstame pasirinkime tarp kelių pagrįstų variantų.

Technologija neišsprendžia kiekvieno apribojimo

Ne kiekvienai sudėtingai sistemai reikia:

• mikropaslaugų ar įvykių šaltinio modelio;
• DI agentų;
• Kubernetes;
• įmonės masto architektūros programos.

Šie sprendimai savaime nėra blogi. Jie naudingi, kai atitinka problemą. Tačiau pasirinkti dar gerai nesupratus problemos jie gali sukurti dar vieną sudėtingumo sluoksnį ir nepašalinti tikrojo apribojimo.

Kartais geriausias sprendimas yra gerai sukurtas monolitas. Kartais reikia aiškesnės ribos, mažesnio sprendimo arba pokalbio tarp žmonių, kurie iki šiol rėmėsi skirtingomis prielaidomis.

Apie ką rašysiu

Šiame tinklaraštyje nagrinėsiu sudėtingąją programinės įrangos kūrimo dalį, kuri retai telpa į vieną įgyvendinimo užduotį:

• architektūrą ir veiklos sričių ribas;
• paskirstytas sistemas ir realaus laiko duomenis;
• modernizavimą be nereikalingų perrašymų;
• inžinerinę lyderystę ir bendradarbiavimą tarp komandų;
• kur DI padeda inžineriniam darbui, o kur sukuria naujų problemų;
• pamokas iš sprendimų, kurie pasiteisino, ir tų, kurie nepasiteisino.

Pavyzdžiai bus paremti tikromis sistemomis ir realiomis darbo aplinkomis, prireikus pakeičiant atpažįstamas detales. Tikslas nėra propaguoti vieną architektūros stilių. Tikslas – aiškiau parodyti problemą, kompromisus ir sprendimą.

Nuo to ir verta pradėti: pirmiausia suprasti, kas iš tiesų trukdo, ir tik tada rinktis technologiją.

Turbūt apie tokius dalykus artimiausiu metu čia ir rašysiu: apie išspręstas (ir, dėja, neišspręstas) problemas, technologijas, komandas, architektūrą, DI ir pamokas iš realių projektų.

O jus kviečiu sekti, klausti, komentuoti ar tiesiog dalintis savo istorijomis.

Kai kurios rezultatų pristatymo problemos atrodo kaip pajėgumų trūkumas. Komanda negali judėti pirmyn, nes kita komanda dar nepridėjo API metodo, nepaskelbė įvykio ar neatvėrė reikalingo lauko. Antroji komanda užsiėmusi darbais, svarbesniais jos pačios tikslams, todėl prašymas laukia darbų sąraše.

Įprasta reakcija – eskaluoti, derėtis dėl prioritetų arba keisti planą. Kartais tai būtina. Tačiau keliose organizacijose radau kitą būdą, kuris buvo ir greitesnis, ir sveikesnis:

Užuot prašę kitos komandos sukurti trūkstamą dalį, įgyvendinkite pakeitimą jos sistemoje patys ir paprašykite jį peržiūrėti.

Tai nėra istorija apie bendradarbiavimo atsisakymą. Tai istorija apie eilėmis pagrįstų perdavimų pakeitimą bendru prisidėjimu.

Toliau pateikti pavyzdžiai yra sudėtiniai. Industrijos, sistemų ribos, įvykių sekos ir organizacinės detalės sąmoningai sujungtos arba pakeistos. Pats pristatymo modelis yra tikras, tačiau aprašymas nėra skirtas jokiai įmonei ar asmeniui atpažinti.

Priklausomybė buvo eilė

Įsivaizduokite produkto komandą, atsakingą už darbo eigą, kertančią kelias sistemas. Ji valdo orkestravimo sluoksnį, tačiau jai reikia galimybės iš kitos komandos prižiūrimos platformos.

Tokia priklausomybė dažnai atrodo taip:

1. Produkto komanda suformuluoja prašymą.
2. Platformos komanda jį patikslina ir įvertina.
3. Prašymas konkuruoja su platformos komandos prioritetais.
4. Kažkas jį įgyvendina turėdamas tik dalį pradinio poreikio konteksto.
5. Produkto komanda integruoja pakeitimą ir pamato, kas buvo suprasta neteisingai.

Nė vienas šio proceso žingsnis nėra nelogiškas. Kiekviena komanda optimizuoja savo darbo krūvį. Vėlavimas atsiranda tarp komandų: kontekstas perduodamas per užduotis, grįžtamasis ryšys ateina vėlai, o už visą rezultatą neatsako niekas.

Techninė priklausomybė yra reali, tačiau pristatymą labiausiai lėtina prisidėjimo modelis. Tik viena komanda turi teisę – arba jaučiasi turinti teisę – keisti konkretų kodą.

Geležinkelis, optimizuotas jo operatoriams

Įsivaizduokite visą kliento kelią kaip kelionę geležinkelių tinklu.

Keleivis yra kliento siekiamas rezultatas. Kiekviena stotis – sistema arba aiški veiklos srities riba, o skirtingi geležinkelių operatoriai – inžinerijos komandos – valdo skirtingas bėgių atkarpas. Kiekvienas operatorius prižiūri savo infrastruktūrą, nustato veiklos taisykles ir atsako už savo tinklo dalies saugumą.

Dabar įsivaizduokite, kad keleivis privalo persėsti kaskart, kai pasikeičia bėgių savininkas. Vienas operatorius nuveža jį iki savo ribos, perduoda kelionę ir laukia, kol kitas operatorius suplanuos kitą traukinį. Bėgiai fiziškai sujungti, tačiau veiklos modelis suskaldo kelionę.

Taip dažnai atrodo tradicinis darbas tarp komandų. Funkcionalumas juda iki vienos komandos sistemos ribos, tuomet tampa prašymu kitos komandos darbų sąraše ir keliauja toliau tik tada, kai ši komanda pasirengusi įgyvendinti savo dalį. Kiekviena vietinė atkarpa gali būti valdoma efektyviai, nors visa kelionė nuo pradžios iki pabaigos lieka lėta.

Prisidėjimo modelis labiau primena galimybę traukiniui tęsti kelionę kelių operatorių bėgiais pagal sutartas taisykles. Bėgių nuosavybė nesikeičia. Kiekvienas operatorius vis dar nustato savo saugumo standartus ir išlaiko sprendimo teisę dėl infrastruktūros. Tačiau kito operatoriaus traukinys gali naudotis bėgiais, jei atitinka šiuos standartus.

Programinėje įrangoje pull request yra prašymas įvažiuoti į bėgius. Automatiniai testai, architektūrinės taisyklės ir prižiūrėtojų peržiūra atlieka veiklos bei saugumo patikrų vaidmenį. Prisidedantis inžinierius perneša kliento rezultatą per ribą, užuot prašęs kitos komandos pradėti atskirą kelionę.

Keleiviui nesvarbu, kam priklauso kiekviena bėgių atkarpa – jam svarbu pasiekti tikslą. Taip pat ir klientui nesvarbu, kiek komandų valdo sistemas, veikiančias už konkrečios galimybės. Nuosavybė gali likti vietinė, net kai atsakomybė už visos kelionės užbaigimą apima kelis savininkus.

Pasikartojantis modelis skirtingomis formomis

Pirmą kartą šį modelį pastebėjau dirbdamas su kelių kanalų turinio platforma. Viena komanda valdė centrą, sinchronizuojantį įrašus su keliomis išorinėmis paskirties sistemomis. Reikėjo prijungti naują vidinę paskirties sistemą, tačiau ją kurianti komanda negalėjo suteikti prioriteto reikalingam API.

Laukiant viena komanda būtų likusi be darbo, o kita būtų turėjusi perprasti reikalavimus, už kuriuos pati neatsakė. Todėl pasiūlėme paprastesnį susitarimą: mūsų komanda įgyvendins API paskirties sistemos kode, o jos prižiūrėtojai paaiškins vietines taisykles ir išlaikys sprendimo teisę per kodo peržiūrą.

Pirmasis pull request užtruko ilgiau nei pakeitimas savo repozitorijoje. Reikėjo perprasti nepažįstamus modelius, reaguoti į peržiūros pastabas ir pataisyti klaidingas veiklos srities prielaidas. Vis dėlto tai buvo greičiau nei laukti kitos komandos eilėje. Dar svarbiau – integraciją įgyvendinantis žmogus galėjo keisti abi jos puses ir patikrinti visą veikimą.

Tokį patį modelį mačiau keičiant seną platformą. Su nauja paslauga besiintegruojanti komanda pastebėjo, kad pakaitiniame modelyje trūksta dalies informacijos, reikalingos esamai darbo eigai. Įprastas sprendimas būtų buvęs registruoti prašymus pakaitinę sistemą kuriančiai komandai.

Mes pasirinkome prisidėti patys. Patvirtinimas nebuvo momentinis – ir neturėjo toks būti. Prižiūrėtojai kėlė klausimus dėl pavadinimų, ribų ir migravimo elgsenos. Šios pastabos pagerino pakeitimą ir kartu padėjo prisidedančiai komandai suprasti, kaip veikia naujoji platforma. Senosios sistemos elgseną išmanantis inžinierius galėjo pernešti šį kontekstą į jos pakaitalą ir prisiimti atsakomybę už visą rezultatą.

Trečią šio modelio versiją sutikau beveik realiuoju laiku veikiančiame duomenų produkte. Vienai klientui matomai galimybei pristatyti reikėjo suderintų pakeitimų duomenų surinkimo, apdorojimo ir peržiūros sistemose. Jos priklausė skirtingoms grupėms, turinčioms skirtingus prioritetus. Kiekvieną ribą traktuojant kaip perdavimą, galutinis terminas priklausė nuo trijų atskirai planuojamų darbų sąrašų.

Pristatanti komanda dirbo peržengdama šias ribas: įgyvendino tiksliai apibrėžtus pakeitimus, kūrė pull request kiekvienoje kodų bazėje ir anksti įtraukė jų prižiūrėtojus. Sistemų nuosavybė nepasikeitė. Pasikeitė atsakomybė už rezultatą.

Nuo perdavimų prie bendro prisidėjimo

Šiuo pokyčiu nesiekėme pašalinti kitų komandų iš proceso. Atskirų įgyvendinimo eilių grandinę pakeitėme tiesioginiu prisidėjimu ir prižiūrėtojų peržiūra.

Esminis pokytis subtilus: kodo bazės nuosavybė nebereiškia išskirtinės teisės joje ką nors įgyvendinti.

Prižiūrėtojai lieka atsakingi už savo sistemos būklę ir kryptį. Prisidedantieji prisiima atsakomybę pakankamai gerai ją suprasti, kad galėtų atlikti saugų pakeitimą. Peržiūra tampa vieta, kurioje keičiamasi veiklos srities ir inžinerinėmis žiniomis, o ne paskutiniu barjeru po kelių laukimo savaičių.

Kas pagerėjo

Atsakomybė už rezultatą nuo pradžios iki pabaigos

Problemą sprendžiantis žmogus gali sekti ją per sistemų ribas, išbandyti visą kelią ir reaguoti į naujai atrastus dalykus nepradėdamas dar vieno tarpkomandinio prašymo ciklo. Darbas organizuojamas aplink rezultatą, o ne repozitoriją.

Greitesnis grįžtamasis ryšys

Nedidelis pull request sukuria konkretų pagrindą diskusijai. Prižiūrėtojai gali pataisyti įgyvendinimą, nurodyti esamą abstrakciją arba atmesti klaidingą prielaidą anksčiau, nei galėtų tai padaryti turėdami tik išsamią užduotį.

Bendros veiklos srities žinios

Prisidedantieji sužino, kaip veikia gretimos sistemos ir kodėl jos turi konkrečius apribojimus. Prižiūrėtojai geriau supranta sistemą naudojančią darbo eigą. Šios žinios pagerina būsimus abiejų pusių sprendimus.

Geresnės techninės praktikos

Tarpkomandinės peržiūros supažindina komandas su skirtingomis testavimo strategijomis, diegimo metodais, stebimumo taisyklėmis ir kodo struktūravimo būdais. Naudingos praktikos plinta per realų darbą, o ne standartų dokumentą.

Mažiau koordinavimo eilių

Priklausomybė visiškai neišnyksta. Prisidedančiai komandai vis dar reikia peržiūros, o kartais ir prižiūrėtojų pagalbos. Tačiau didelę priklausomybę – laukimą, kol kita komanda suplanuos ir įgyvendins darbą – pakeičia mažesnė: laiku suteiktos gairės ir peržiūra.

Šiam modeliui reikia saugiklių

Prisidėjimas peržengiant komandų ribas nėra leidimas savavališkai keisti nepažįstamas sistemas. Be kelių sąlygų jis gali sukurti daugiau darbo, nei sutaupo.

• Galutinį sprendimą išlaiko prižiūrėtojai. Jie atsako už sistemos vientisumą ir gali prašyti pataisymų arba atmesti pasirinktą kryptį.
• Prisidedantieji anksti įtraukia prižiūrėtojus. Trumpas pokalbis apie sprendimą prieš jį įgyvendinant apsaugo nuo didelių, klaidinga kryptimi nuėjusių pull request.
• Į kodo bazę saugu įžengti. Vietinės aplinkos paruošimas, testai, informacija apie savininkus ir prisidėjimo gairės turi būti lengvai randamos.
• Peržiūra laikoma suplanuotu darbu. Jei prižiūrėtojai negali skirti laiko gairėms ar peržiūrai, eilė tik pakeitė formą.
• Pakeitimai lieka nedideli. Trūkstamas laukas ar API metodas yra gera pradžia. Platesniam perprojektavimui reikia išsamesnio bendro planavimo.
• Atsakomybė už veikimą yra aiški. Prieš sujungiant pakeitimą reikia sutarti, kas jį diegs, stebės, palaikys ir taisys.

Yra ir atvejų, kai toks prisidėjimas nėra tinkama priemonė: griežtai ribojamos sistemos, itin specializuoti komponentai, aktyvūs incidentai arba pakeitimai, kurių rizikos prisidedanti komanda negali atsakingai įvertinti. Tikslas nėra visuotinė prieiga. Tikslas – padaryti ribas pralaidžias ten, kur tai saugu.

Komandos požiūrio keitimas

Sunkiausia kliūtis retai buvo repozitorijos prieigos teisės. Dažniau tai buvo įsitikinimas, kad „jų sistema“ reiškia „jų darbą“. Komandos buvo išmokusios nuosavybę tapatinti su riba, nurodančia, ką joms leidžiama suprasti ar keisti.

Buvo ir asmeniškesnis rūpestis. Įžengti į kitos komandos sritį reiškia vėl tapti naujoku. Savo sistemoje užtikrintai besijaučiantys inžinieriai nerimavo, kad užduos akivaizdžius klausimus, nesupras vietinių taisyklių arba atrodys mažiau kompetentingi nepažįstamiems vertintojams. Vien pasakymas „tiesiog prisidėkite“ šios socialinės rizikos nepašalino.

Šį įsitikinimą bandžiau pakeisti dviem idėjomis:

1. Jūs atsakote už rezultatą, net kai kelias iki jo kerta kitos komandos kodą.
2. Turėti sistemą reiškia prižiūrėti kitų indėlį, o ne patiems įgyvendinti kiekvieną pakeitimą.

Tačiau pakeisti žodžius nepakako. Žmonės turėjo pamatyti, kad peržengti ribą ir įmanoma, ir saugu.

Kaip padarėme pirmąjį prisidėjimą saugų

Mūsų metodas ilgainiui tapo paprasta mokymosi seka.

1. Parodykite pavyzdį

Pirmąjį pakeitimą atlikau pats. Įžengiau į nepažįstamą kodų bazę, uždaviau paprastus klausimus, mokiausi, kaip veikia jos veiklos sritis ir pristatymo procesas, ir pateikiau savo darbą prižiūrinčios komandos peržiūrai.

Tai buvo svarbu, nes prašiau komandos priimti riziką. Parodydamas tokį elgesį padariau riziką matomą ir parodžiau, kad pradžioje visko nežinoti yra normalu. Peržiūros pastabas traktavome kaip sistemos pažinimo dalį, o ne įrodymą, kad žmogus neturėjo bandyti prisidėti.

2. Kitą pakeitimą atlikite poroje

Kai jau pakankamai gerai supratau kelią, dirbau poroje su vienu komandos inžinieriumi. Kartu tyrinėjome kitą sistemą: radome susijusį kodą, aiškinomės testus, paleidome ją vietinėje aplinkoje ir aptarėme pakeitimą su prižiūrėtojais.

Darbas poroje sumažino įstrigimo kainą ir sukūrė saugią erdvę klausimams dar prieš pull request tampant viešu. Tikslas nebuvo man programuoti kitam stebint. Norėjome, kad nepažįstamą darbo eigą galėtų pakartoti dar vienas žmogus.

3. Leiskite inžinieriui prisidėti savarankiškai

Kitą pakeitimą tas pats inžinierius atliko be manęs ir pats sukūrė pull request. Buvau pasirengęs padėti, jei prireiktų, tačiau atsakomybė jau buvo perėjusi jam.

Prižiūrėtojų pastabos vis dar buvo laukiamos. Sėkmės matas nebuvo pull request be komentarų. Svarbu buvo tai, ar inžinierius gali suprasti pastabas, atnaujinti pakeitimą ir nuvesti jį iki integravimo.

4. Paprašykite jo įtraukti kitą žmogų

Vėliau šis inžinierius dirbo poroje su kitu komandos nariu. Žinios nebesklido iš vieno centrinio eksperto – jos judėjo per komandą po vieną darbinį ryšį.

Kartojant šią seką, prieiga tapo gebėjimu:

Parodykite > dirbkite poroje > prisidėkite savarankiškai > išmokykite kitą.

Po kelių ciklų komanda gretimų sistemų nebelaikė svetima teritorija. Ne visi tapo kiekvienos sistemos ekspertais – ir toks nebuvo tikslas. Komanda sukaupė pakankamai bendro konteksto, kad galėtų sekti kliento rezultatą per visą kelią.

Tai investicija, o ne trumpesnis kelias

Prisidėjimo modelis nėra universalus sprendimas ir retai veikia tobulai iš pirmo karto. Pirmasis pakeitimas nepažįstamoje kodų bazėje gali užtrukti ilgiau nei užduoties parašymas. Reikia laiko paruošti aplinką, išmokti taisykles, o pirmiesiems pull request paprastai prireikia daugiau diskusijų ir pataisymų.

Kai terminas itin trumpas, šią mokymosi kainą gali būti sunku pateisinti. Jei patyręs prižiūrėtojas gali padėti iš karto, paprašyti jo atlikti vienkartinį pakeitimą gali būti greičiausias vietinis sprendimas.

Ilgalaikis skaičiavimas kitoks. Užduotis išsprendžia vieną trūkstamą galimybę. Sėkmingas prisidėjimas taip pat sukuria dar vieną žmogų, gebantį orientuotis sistemoje. Kitam pakeitimui reikia mažiau pagalbos, peržiūra tampa tikslesnė, o žinios pradeda sklisti nepriklausydamos nuo pirminio prisidėjusiojo.

Todėl šio modelio nevertinčiau pagal pirmojo pull request greitį. Vertinčiau kelių kitų pakeitimų laikotarpiu: ar eilės trumpėja, ar daugiau inžinierių gali diagnozuoti visą darbo eigą ir ar atsakomybė už rezultatą tampa mažiau suskaidyta.

Optimizuokite srautą, o ne vietinę nuosavybę

Griežtos ribos gali sukurti aiškių atsakomybių įspūdį, kartu paslėpdamos tarp komandų susidarančių eilių kainą. Kai kliento rezultatas kerta šias ribas, vietinės optimizacijos nepakanka. Geležinkelis gali optimizuoti kiekvieną stotį atskirai ir vis tiek suteikti keleiviams siaubingą kelionę.

Prisidėjimo modelis išsaugo sistemų priežiūrą, tačiau leidžia atsakomybei už rezultatą keliauti per architektūrą. Mano patirtis rodo, kad toks pokytis sutrumpino pristatymo kelią, pagerino integracijų kokybę ir suteikė inžinieriams aiškesnį supratimą apie keičiamą veiklos sritį.

Kitą kartą, kai jūsų komandą blokuos kitos komandos darbų sąrašas, nepradėkite nuo eskalavimo. Užduokite kitą klausimą:

Kas turėtų būti tiesa, kad šį pakeitimą galėtume įgyvendinti patys?

Per savo karjerą mačiau bent keturis projektus, kuriuos būtų galima vadinti sėkmingais.

Reikalavimai įgyvendinti. Kokybė gera. UX neblogas. Komanda padarė tai, ką pažadėjo.

Tik nė vienas iš jų netapo sėkmingu produktu.

Visi pasiekė maždaug tą pačią ribą – „Go-Live“ – ir kažkur aplink ją sustojo.

Vienu atveju marketingas ilgai derino, kaip produktą pristatyti rinkai. Kitu projektas įstrigo teisiniuose procesuose. Dar kitur per kūrimo laiką pasikeitė verslo prioritetai, todėl iniciatyva buvo sustabdyta.

Komanda gali nepriekaištingai įgyvendinti projektą, bet tai dar nereiškia, kad produktas pasieks klientą.

Galbūt problema ta, kad produkto kūrimą pernelyg dažnai įsivaizduojame kaip nuoseklią estafetę: product suformuluoja poreikį, engineering parašo kodą, o tuomet prisijungia marketing, sales, legal, finance, operations ir support.

Tik realybėje produktas nėra estafetė. Tai bendras darbas, kuriame visos šios funkcijos turi judėti ta pačia kryptimi gerokai anksčiau nei ateina laikas spausti „Go-Live“.

Todėl didžiausias iššūkis dažnai nėra parašyti kodą. Jis prasideda bandant susitarti, ką statome, kodėl tai darome, kaip produktas pasieks rinką ir kas turi nutikti, kad klientai iš tiesų galėtų juo naudotis.

Dėl to konsultavime nemažai laiko skiriu ne technologijoms. Tenka padėti skirtingoms pusėms susikalbėti, iškelti nutylėtas prielaidas, suderinti lūkesčius ir rasti bendrą kryptį.

Nes geras produktas nėra vien geros inžinerijos rezultatas.

Jis atsiranda tada, kai visa organizacija sugeba kartu nuvesti jį iki kliento.