Team Topologies: Recept za timove koji će biti učinkoviti od početka do kraja proizvodnje softvera

Što čini neki tim uspješnim? Prvo što bi čovjeku moglo past na pamet je ostvarivanje prihoda, ali to je prejednostavan odgovor na pitanje koje zapravo uopće nije jednostavno. Uspješni tim je dobro organiziran tim čiji posao glatko teče, ali kako to postići u moru knjiga, modela, alata i hibridnog rada?

Uoči QED 2022, biztech konferencije koju već niz godina organizira hrvatska IT tvrtka CROZ, iskoristili smo priliku predstaviti ideju koja se krije iza knjige Team Topologies, a čiji su autori keynote govornici ovogodišnjeg izdanja konferencije.

Sve o Topologies pristupu predstavit će danas u hotelu Falkensteiner u okolici Zadra, ali mi smo i za vas pred ekranima osigurali da podijelimo najbitnije. Više o topologiji timova otkivaju nam Manuel Pais, suautor knjige Team Topologies i nezavisni IT organizacijski konzultant te Ivan Krnić, Director of Engineering u CROZ-u i Agile Coach.

Kakav je to uopće učinkovit tim?

Ivan tvrdi kako je učinkovit tim onaj kod kojeg posao jednostavno “teče”. Trenja među članovima tima ne postoji ni u različitim fazama proizvodnje, nema uskih grla niti čekanja ili preopterećenja, a dodana vrijednost se kontinuirano isporučuje korisnicima:

Kažemo da takav tim ima uspostavljen “flow”. Zvuči jednostavno, ali zahtijeva dodatne karakteristike tima kao što su dobra komunikacija među članovima i prema korisnicima te posjedovanje svih potrebnih znanja i vještina.

Autonomni timovi danas su osnovne gradbene jedinice organizacija, a najčešće se muče s nebalansiranim kompetencijama unutar tima i lošom usklađenošću s cjelokupnim procesom razvoja softvera:

Nebalansirane kompetencije dovode do toga da tim ne može samostalno odraditi neki posao pa treba vanjsku pomoć što uvodi dodatnu ovisnost. A loša usklađenost s cjelokupnim proizvodnim procesom dovodi do zastoja i nepotrebnih timskih međuovisnosti koje usporavaju proizvodnju.

Prvo – procjena stanja

Na policama knjižara možemo pronaći različite knjige o poboljšanju produktivnosti timova u kojima se nude različite ideje o obrascima i načinima interakcija. Te ideje nisu same sebi svrha, naglašava Ivan. One postoje kao mogući mehanizmi postizanja višeg cilja, a to je uspostava efikasnog cjelokupnog procesa proizvodnje softvera, od ideje na salveti do zadovoljnog korisnika:

Stoga bi se svaki lider prvo trebao zapitati kako taj proizvodni proces izgleda danas, gdje su uska grla, gdje postoje komunikacijski i koordinacijski izazovi, a tek onda posegnuti za obrascima i načinima interakcije kao mogućim alatima za uspostavljanje efikasnog procesa.

Ivanovo bogato iskustvo od šesnaest godina u CROZ-u naučilo ga je podosta o optimizaciji procesa rada pa će za nas predstaviti Team Topologies (TT) pristup organiziranju poslovnih i tehnoloških timova, pružajući praktičan, korak po korak, prilagodljiv model za organizacijski dizajn i interakciju tima.

Koje su četiri osnovne vrste timova prema TT-u?

1) Stream-aligned timovi isporučuju funkcionalnosti korisnicima.

S obzirom na sve veću procesnu i infrastrukturnu kompleksnost u okolinama u kojima radimo, treba nam način kako da dio te kompleksnosti prebacimo na druge timove kako bi stream-aligned timovi bili brži u isporuci prema korisnicima. Tome služe ostale vrste timova.

2) Enabling timovi pomažu stream-aligned timovima u usvajanju novih znanja i vještina.

Naime, stream-aligned tim bi potrošio značajnu količinu vremena usvajajući novi programski model, istražujući dostupne frameworke, birajući odgovarajući framework i učeći kako se koristi, a sve to tijekom isporučivanja novih funkcionalnosti korisnicima, ističe Ivan:

Tu uskaču enabling timovi: oni su poput izvidničkih timova koji istražuju put ispred stream-aligned timova tako da traže primjerenije alate i bolje pristupe te dijele te informacije sa stream-aligned timovima kako bi im pomogli da budu brži.

3) Complicated-subsystems timovi preuzimaju poslove za koje je potrebno vrlo specifično poslovno ili tehničko znanje.

Dobar primjer su složeni algoritmi za prikazivanje feeda na društvenim mrežama ili programiranje sklopovlja.

Takvi poslovi zahtijevaju duboko razumijevanje poslovnih pravila i tehničkih mogućnosti te nema smisla da svi timovi razvijaju te kompetencije. Puno je bolje formirati dedicirane complicated-subsystems timove koji će razviti te module i drugim timovima izložiti jasna sučelja za njihovo korištenje.

4) Platformski timovi grade i održavaju internu platformu koju stream-aligned timovi koriste prilikom isporuke softvera. Kad pričamo o internoj platformi, Ivan navodi kako obično podrazumijevamo tehničku platformu koja uključuje repozitorije koda, automatizaciju build i release procesa te razne Kubernetes poslužitelje.

Ali platforma nije ograničena samo na tehničko rješenje. Kako kaže Matthew Skelton, “platforma je pomno oblikovano iskustvo koje pružamo inženjerima da im pomogne u radu – to može biti i dokumentacija, API sučelja, konfiguracije, odnosno sve ono što ubrzava rad tima”.

Timovi zahtijevaju i različite modele suradnje

Nije svaki posao unutar organizacije isti pa stoga niti ne zahtijeva isti model suradnje među timovima. Koncept Team Topologies prepoznaje tri osnovna modela suradnje.

Kolaboracija je model u kojem timovi rade zajedno na rješavanju nekog problema. Tipično je to povezano s inoviranjem u smislu definiranja API sučelja, pronalaženja boljih praksi, odabira primjerenih tehnologija ili rješavanja problema koji utječu na više timova.

Kolaboracija je dobar model za sagledavanje problema sa svih strana i pronalaženje optimalnog rješenja, ali je kognitivno zahtjevna i traži dosta koordinacije.

Ako je suradnja među timovima takva da je usluga koju jedan tim nudi drugome vrlo jasna, onda je bolji model suradnje X-as-a-Service. Osnovna značajka ove suradnje je da jedan tim pruža uslugu s jasnim uputama o korištenju, a drugi tim je koristi.

Ovakav način suradnje nije kognitivno intenzivan i ne traži koordinaciju jer su očekivanja od usluge jasna. No, upravo zbog tog manjka interakcije, ovo nije dobar model za rješavanje složenih problema već je prikladniji za konzumiranje “uhodanih” usluga, npr. provizioniranje računalnih resursa.

Treći način suradnje je facilitacija gdje jedan tim mentorira i pomaže drugom timu u obavljanju svog posla i najviše ga koriste Enabling timovi.

Što je s remote radom? Mijenja li to pristup?

Kada je rad na daljinu prioretiziran, društvene interakcije i opuštena razmjena informacija koja se događa u uredskom prostoru više ne “prikrivaju” nedostajuće interakcije ističe Manuel. Također, navodi i moguće probleme koji se mogu prikrasti, ako se ne uzmu u obzir na vrijeme:

• buka u komunikaciji – previše kanala za razgovor na koje treba obratiti pažnju, neusklađena očekivanja o tome tko i kada treba odgovoriti na zahtjeve.
• niska razina međusobnog povjerenja – kada se stavi u široki kontekst virtualnih radnih prostora sa stotinama ili tisućama drugih ljudi.
• nedostatak uočljivosti – odnosi se u kontekstu informacija, ali i s kojim drugim timovima moramo komunicirati.

Zbog toga možemo vidjeti kako se Silo Mentality (nevoljkost dijeljenja informacija sa zaposlenicima različitih odjela u istoj tvrtki) učvršćuje, a sukobi intenziviraju. Neke organizacije mogu udvostručiti stroge procese za upravljanje timskim ovisnostima, ali to će doći po cijenu smanjene autonomije i performansi tima, napominje Manuel.

Organizirati remote rad zapravo je jednostavnije od očekivanog, naglašava Manuel.

Prvo, potrebno je razmotriti više radnih prostora s većom kohezijom između sudionika i usvojiti jednostavne konvencije imenovanja kanala usklađene sa svrhom tima i interakcijama s drugima. Drugo, timove je potrebno potaknuti da shvate vrijednost:

1. jasno definiranih interakcija s drugima (tj. suradnja vs X-as-a-Service vs facilitiranje);
2. izlaganja i razvoja vlastitog timskog API-ja kako bi se razjasnila komunikacijska svrha i obrasci;
3. praćenja njihove ovisnosti o drugim timovima tijekom vremena kako bi mogli otkriti glavne blokatore i tražiti načine da ih uklone (ili umanje njihov utjecaj na tijek tima).

Također, Manuel je istaknuo nekoliko savjeta u provođenju remote rada. Prije svega potrebno imati jasno definirana očekivanja od timske interakcije tijekom remote rada. Zbog toga odgovori na kada, zašto i koliko dugo postaju ključnim. Iduće, virtualna radna mjesta moraju promovirati jasnoću, transparentnost, uočljivost i poštovanje granica ljudskog povjerenja:

Konačno, praćenje kognitivnog opterećenja timova (uključujući opterećenje zbog nejasne komunikacije s drugima), ovisnosti o drugim timovima i izazova u načinu na koji komuniciraju (ili ne) s tim timovima.

“Danas svjesno formiramo i povezujemo timove takve da sliče proizvodu kojeg gradimo…”

Ako je protok vrijednosti blokiran, softver prevelik za tim ili je organizacijski dizajn zbunjujuć, utoliko je jedno od mogućih rješenja Conwayev zakon.

Conwayev zakon nije novost u IT industriji, pojašnjava nam Ivan. Spoznaja da će arhitektura proizvoda reflektirati arhitekturu organizacije koja ga je izgradila datira još iz 1960-ih. Ono što je svojevrsno prosvjetljenje u modernim organizacijskim praksama je da taj zakon možemo iskoristiti i u obrnutom smjeru:

Odnosno, lakše ćemo postići željenu arhitekturu proizvoda ako prethodno prilagodimo organizacijsku strukturu. Ova je misao poznata i kao inverzni Conwayev manevar i temelj je svake moderne reorganizacije. Danas svjesno formiramo i povezujemo timove takve da sliče proizvodu kojeg gradimo i to bitno olakšava proces proizvodnje.

Koliko dugo traje implementacija TT načina rada?

Reorganizacija se može napraviti vrlo brzo, ali znamo da sama reorganizacija neće dati rezultate ako nisu posloženi i neki drugi preduvjeti, naglašava Ivan. Kaže da prvenstveno tu misli na orijentaciju organizacije prema korisnicima i sagledavanje cjelokupnog procesa razvoja softvera kako bi se uspostavio optimalan tok posla kroz sustav:

I ovdje, kao i kod svih transformacija, vrijedi pravilo da je dobro izbjeći big-bang pristup. Bolje je krenuti s pilotom na manjem broju timova unutar jedne poslovne domene kako bi organizacija svladala osnove, a tek onda krenuti u širenje koncepta na ostatak organizacije.

Sve u svemu, pričamo o nekoliko mjeseci za snimku trenutne situacije i pilot implementaciju, a zatim slijedi iterativno širenje na ostale poslovne domene.

Što Ivan savjetuje prilikom implementacije Team Topologies pristupa?

Prilično je lako formirati timove i podijeliti im neke etikete. Ono što je obično teže je sagledavanje i optimiziranje cjelokupnog procesa razvoja softvera, ističe Ivan.

Knjiga Team Topologies donosi uzorke koji pomažu u rješavanju problema optimizacije procesa, no to ne eliminira činjenicu da problem treba dubinski razumijeti.

Slijepo implementiranje uzoraka ne samo da neće riješiti problem nego će ga i pogoršati. Ta pojava čak ima i svoje ime – The Christopher Alexander Effect, dodaje Ivan.

Postoje neke organizacijske sile koje su jednostavno sveprisutne i vrijede uvijek, baš kao gravitacija u stvarnom svijetu, i jednostavno ih je nemoguće ignorirati ili zaobilaziti, zaključuje Ivan. Moramo ih uzeti u obzir. Knjiga Team Topologies mogla bi pomoći demistificirati te sile i iskoristiti ih u vlastitu korist i na zadovoljstvo cijele organizacije.