Luka Ferlež
Autor:
Luka Ferlež

Voditelj razvoja

Guilds vs organizational drift

U većini organizacija isporuka softvera se vrti oko projekata kako bi se omogućio maksimalan fokus na ispunjavanje potreba korisnika i isporuku samog projekta. U takvoj organizaciji veličina, sastav i trajnost tima naravno ovisi o potrebama projekta na kojima tim radi, a tijekom trajanja projekta tim po mogućnosti radi u zajedničkom radnom prostoru fokusirano isključivo na isporuku projekta.

U takvom okruženju članovima tima je prirodno da se maksimalno povežu unutar tima s ljudima s kojima provode većinu svojeg vremena, što i je jedan od osnovnih ciljeva takve organizacije. Naravno ova željena posljedica ovakve organizacije, uzrokuje i svoj neželjeni pandan izolaciju ljudi u timove. Što je veća međusobna povezanost i fokus unutar tima, to su članovi tima manje povezani s članovima drugih timova i općenito imaju manju pripadnost ostatku organizacije.

Problem dijeljenja

U osnovi timovi postaju organizacija unutar organizacije i svaki je izoliran za sebe. Timovi funkcioniraju neovisno, donose samostalne odluke i grade svoj proizvod na način koji misle da je najbolji nesvjesni toga što se događa u ostatku organizacije. Rezultat toga je da timovi rade na različite načine, rješavaju probleme koji su već riješeni negdje drugdje, nemoguće je provesti običnu zamjenu članova timova i u konačnici nemoguće je osigurati konzistentnu kvalitetu isporuke.

Sve već navedeno i drugo nenavedeno je problem protoka i dijeljenja informacija što postaje jedan od velikih izazova takvih organizacija. Tog problema smo u sklopu svoje organizacije svjesni već neko vrijeme i početkom godine smo odlučili da se moramo ozbiljno pozabaviti tim problemom.

Jedan od prvih koraka pri adresiranju navedenih izazova je bilo uvođenje tehnoloških radara prije otprilike dvije godine s kojima smo uveli sustavno upravljanje tehnologijama koje koristimo. Upotrebom tehnoloških radara smo stavili pod kontrolu svoju onda iznimno heterogenu okolinu. Ono što smo naučili kroz to iskustvo je da se u daljnjim koracima moramo paziti prevelike birokratizacije, paralize odlučivanja kao i to da moramo omogućiti uključivanje što više ljudi. Rješenje nam se nametnulo kroz model organizacije Spotify-a koji je uveo cross-cutting strukturu Guild-a kao interesnu skupinu, grupu ljudi koji žele dijeliti znanje iz nekog područja.

Guilds kao dio rješenja

Implementacija guildova koju smo mi usvojili kaže da je to interesna skupina sa dobrovoljnim sudjelovanjem bilo koje osobe u organizaciji na poluformalnom nivou. Cilj guildova je stvaranje jedinstvenih praksi kroz razmjenu mišljenja i znanja proizašlih iz iskustava stečenih na različitim projektima i u različitim dijelovima organizacije.

Organizacijski se radi o određenom poluformalnom obliku, flat-strukturi s koordinatorom umjesto "šefa" i dobrovoljnim članstvom s jedne strane. S druge strane takva organizacija ima jasne zadatke i ciljeve koje si djelomično određuju samostalno, a djelomično iz vanjskih inputa. Svaki guild donosi odluke koje se onda uz podršku ostatka organizacije primjenjuju i propagiraju na cijelu organizaciju. 

Inicijalno smo uspostavili tri guilda System, Practices i Process guild svaki svojim charterom i koordinatorom. Svaki guild u svojem charteru ima svoju interesnu domenu kojom se bavi i to:

  • System - alatima, arhitekturom sustava i tehnologijama
  • Practices - upravljanje znanjem, implementacijske prakse
  • Process - procesi i metodologije isporuke rješenja

Kako bi testirali način rada i svoje pretpostavke pokrenuli smo tihi rad s ograničenim brojem ljudi u Q3 2016. Inicijalno su se guildovi sastojali od 3-5 osoba te smo organizirali tjedne sastanke na kojima bi se odradile rasprave i donijele odluke.

Kako su se stvari razvijale dobro i guildovi su počeli donositi rezultate početkom Q4 2016 pozvali smo ljude iz organizacije da se uključe u rad. S uključivanjem sve većeg broja ljudi u rad guildova odmah su do izražaja došla tri problema, vrijeme koje ljudi moraju izdvojiti, neefikasnost sastanaka s tim brojem ljudi i nemogućnost praćenja odluka i napretka. Ovi problemi su bili predvidi, a isto tako i relativno lako rješivi.

Izazovi uvođenja

Prvo odlučili smo početi pratiti backlog svakog guilda, te smo kreirali backlog za svaki guild. Na taj način možemo povezati svaku aktivnost kojom se guild bavi na razini backlog itema s cijelim epicima koji znače krupne deliverye promjena u načinu rada. Iz toga je vidljivo svim članovima guildova i ostatku organizacije kako rad guildova doprinosi promjenama i utječe na cijelu organizaciju.

Drugo nije bilo nikakve potrebe da svi članovi guilda sudjeluju u svim raspravama. Kako je guild prolazio po backlog itemima za svaki item je dogovorena grupa od 2-3 osobe koji su radili na pojedinom itemu. To nam osigurava lakše usklađivanje vremena ljudi unutar pojedine grupe te brže dogovore. Tjedni sastanci guildova su pretvoreni u kraći sastanak s tri faze, status u obliku daily scruma, rasprava o rezultatima pojedinih grupa koje su došle do nekih zaključaka, prolazak po backlogu za daljnje aktivnosti.

Problem vremena se djelomično riješio s ove dvije promjene koje smo uveli, a dodatno smo morali u suradnji s voditeljima projekata osloboditi dio vremena od projekta. Cijela organizacija na to gleda kao na investiciju, oduzimamo malo danas za dobitak kroz koji kvartal. Na sva tri problema ćemo i dalje morati raditi kako bi održali dinamiku i zadovoljstvo radom u guildovima.

Ulaganje u razvoj

Namjena guildova nije samo da bi se ljudi skupili i raspravljali iako je to samo po sebi nama jako vrijedno. Namjena guildova je i da kroz njih mijenjamo organizaciju danas kako bi imali kvalitetniju i bolju budućnost. Odluke o kojima se raspravlja idu od relativno jednostavni poput preporuka oko načina evidentiranja dokumentacije do kompleksnih poput budućeg ALM stacka. I u tom kontekstu sve odluke koje donosimo s jedne strane zahtijevaju od nas dovoljnu investiciju vremena, ali s druge strane ih ne smijemo razvlačiti.

Jedna od stvari koja nam je bila ključna za podržati kroz rad guildova je bolja povezanost različitih disciplina koje sudjeluju u isporuci rješenja i još jače naglasiti međuovisnosti između njih. Prilikom uključivanja ljudi iznimno nam je bitno da u raznim aktivnostima sudjeluju ljudi raznih karakteristika, različitih iskustava, prošlosti i odgovornosti.  Na sastancima nije nimalno neobično vidjeti testere da raspravljaju o praksama pisanja koda ili developere o definiranju korisnički zahtjeva.

Zajedničkim radom i odlučivanjem dolazimo do kvalitetnijih rješenja i gradimo bolje međusobno razumijevanje svih uključenih.

Primjenom ovakvog modela organizacije smo omogućili sebi da povežemo ljude između projekata na dobrovoljnoj razini na lightweight način, a opet da dobijemo da svaki član naše organizacije može utjecati i oblikovati organizaciju kojoj radi.

Popularne teme
.NET ABAP ADFS Agile Always On Anemic Model Angular Azure Backbone benchmark BI BI projekti Bootstrap building people business inteligence Business Intelligence Change Chrome CI CITCON Claims compile Continuous Delivery continuous deployment Continuous Integration CSR d3js data data visualization Data visualization alati DDD dekompozicija dependency injection dinamička forma dinamički parametri dinamički query distribuirani razvoj Domain-Driven design DOP društvena odgovornost edge-based video analytics Eliminating waste enkapsulacija enterprise razvoj softvera ERP ETL Excel FIORI Frontend game Geopackage GPKG GIS Git Groovy heat map HICCUPS Hichert HTML IBCS interoperability invision IoT IPSO izvještavanje java JavaFX Javascript Jazz Build Engine JBE Jenkins jquery jqueryui jsfiddle JVM Kaizen Kanban king KING ICT Kingovci Knockout kvaliteta lambde leadership Lean legacy code M language Management Maven Metodologija microservices Microsoft mobile Mobility mockups moć monday game NetWeaver network nodejs oblikovni obrasci OGC OKR open source optimizacija organizacija organizacijska struktura OutOfMemoryError outsourcing overengineering paginacija Performance performanse PERT PMI PMP; Agile; Project management; Scrum; KING ICT; razvoj; metodologija podatkovni skup pouzdanost Power BI Power Map Power Pivot Power Query Power View pretraga proces procjena Product Owner programming proizvod Project manager projektni plan radar Rational Team Concert razvoj tima refaktoriranje Release resize responsive charts REST retrospektiva Rich-Domain model Roko Roić rolling wave planning RTC SAP scale scatterplot chart Scrum scrum team scrum tim service boundaries single responsibility principle Single Sign-On smart metering SoapUI social responsibility softver Software software prototyping Software Testing Club Spring Boot SQL standard sustav videonadzora svg tdd Team team building team development Team Foundation Server tech tehnologije terminski plan Testing tim timesheet timovi Toggl.com touch transakcijski nadzor tražilica underengineering unit testing Uspjeh Visual Studio vodstvo vodstvo leadership moć društvena odgovornost DOP social responsibility CSR vođenje projekata WBS Web Zagreb STC

PRIJAVA NA NEWSLETTER

Najnovije novosti iz ICT svijeta