Kaj se v resnici dogaja, ko se spremembe začnejo odvijati?

Piše: Miha Medven

Naš hipotetičen primer, ki nima nobene povezave s katerimkoli resničnim projektom v katerem je avtor tega prispevka sodeloval, je v fazi razvoja novega digitalnega orodja. Gre za interno orodje, ki se bo dotikalo večino oddelkov znotraj organizacije, saj se v njem skrivajo tako poslovna analitika, kot tudi upravljanje s strankami in sledenje internih procesov.

Pred to točko so se odvili mnogi sestanki, na eni strani z vodstvom, s katerim se je dogovarjalo o strateških in dolgoročnih ciljih, na drugi strani pa z dejanskimi zaposlenimi, ki bodo to orodje vsakodnevno uporabljali kot del njihovega delovnega procesa.

Začetek

Dan D. Razvojna ekipa začenja z razvojem. Na pladnju ima dolgoročne strateške cilje, ki jih mora združiti z vsakodnevnim delovnim procesom.

Vsak začetek je težak. Upor zaposlenih je visok, saj so se že prevečkrat opekli z novimi orodji, želje vodstva so še večje, saj je prihodnost celotnega podjetja odvisna od implementacije tega orodja.

Zadihamo. In se lotimo dela.

Izbira prave ekipe

Najprej moramo identificirati kdo nam lahko pri razvoju najbolj pomaga. Tukaj je ključna vsebinska pomoč nekoga, ki je izredno domač v delovnem procesu in bo lahko pravi katalizator implementacije. Cilj razvojne ekipe je narediti orodje, ki je boljše od obstoječega procesa. Če to razvojni ekipi uspe, se bo sprememba odvila sama od sebe, ko bodo ljudje ugotovili, da z novim orodjem lahko delajo hitreje in z manj napora.

Zato imamo radi v razvojnih ekipah ljudi “s terena”. Ljudi, ki so blizu problema, saj je vodstvo največkrat preveč oddaljeno od tega kaj se v praksi dogaja. In pri spremembah je praksa edino pomembna.

Prve spremembe

Prve spremembe so najtežje. Prvi prototipi, ki jih razvojna ekipa pripravi, so najbolj na udaru. Sledimo agilnemu razvoju, kar pomeni, da namesto malega števila velikih sprememb raje izvajamo veliko število majhnih sprememb.

To pomeni, da je prva verzija orodja na voljo v kakšnih dveh tednih po začetku razvoja. Seveda ne bo imela vseh funkcionalnosti, bo pa gradila tisto najbolj pomembno.

In ta trenutek je najbolj stresen in čustveno naporen. Ko kažeš okoli delovno verzijo, kjer oblikovanje ni čisto pravo, ko so prisotni hrošči, in deluje le zelo majhen del funkcionalnosti, je zaupanje resnično na preizkušnji.

Vodstvo se začne spraševati, ali se je pravilno odločilo, razvojna ekipa pa dobiva feedback, da smo še daleč od cilja. Na tem delu se predvsem veliko pogovarjamo. Poskušamo pomiriti deležnike, da je to del procesa in da gre le za prvi korak proti cilju.

Gradnja zaupanja

Če je prva različica orodja vedno stresna, je druga različica največkrat uspeh. Razvojna ekipa je prejela feedback, popravila obstoječe funkcionalnosti in dodala nekatere nove. V dveh tednih se je ustvaril napredek. Druga različica orodja je boljša od prve. In to gradi zaupanje.

Kar naenkrat zaposleni ugotovijo, da bolj kot sodelujejo z razvojno ekipo, boljše orodje bodo prejeli. In na tem specifičnem hipotetičnem orodju, se po dobrem mescu dela, zaposleni kar sami javljajo, da bi bili radi del testne skupine. Ker želijo biti uslišani in želijo imeti možnost podajanja svojega feedbacka, saj želijo, da bi orodje olajšalo njihovo delo.

Razvoj dobiva zagon.

Iteracije

In tako se izvajajo nadgradnje različic. V dobrih treh mesecih se najbrž zvrsti 10 – 20 takšnih različic, kjer je vsaka naslednja različica boljša od tiste prejšnje.

In potem se zgodi nekaj kar si želimo vsi implementatorji sprememb. Začne se pojavljati občutek, da je ta proces, orodje, ki še ni dokončano, boljše od obstoječega sistema. In začnejo se debate kako hitro lahko to spravimo v produkcijo.

In ko razvojna ekipa reče, da smo na produkcijo pripravljeni že od tiste prve različice, saj smo sledili agilnemu procesu, dobimo zeleno luč in datum, ko gremo v produkcijo.

Seveda obstaja nervoza, ampak razvojna ekipa se na to pripravlja že od samega začetka.

Prva prava uporaba

In tukaj se delo šele začne. Kljub temu, da smo naredili veliko različic in upoštevali feedback na vsakem koraku, je tista prva uporaba v produkciji popolnoma drugačna. Pojavlja se feedback, ki ga v resnici prej ni bilo možno dobiti. In tako kot je bilo potrebno pri prvi različici graditi,  se enako zgodi s prvo različico v produkciji.

In potem je stvar dogovora koliko časa in kako dolgo se bodo te iteracije še izvajale. Pride trenutek, ko se organizacija odloči, da je to orodje dovolj dobro, in zmanjša razvoj in preide v fazo vzdrževanja.

Veliko majhnih sprememb

In ko naslednjič organizacija dela refleksijo in ugotavlja razloge, zakaj je neko novo orodje bilo uspešno implementirano, je največkrat zaradi tega, ker so se spremembe izvršile organsko. Ker so zaposleni in vodstvo ponotranjili, da izvajamo le tiste spremembe, ki vodijo na boljše. In te so bile v tako majhni obliki, da jih ni bilo težko implementirati.

Čez čas, se zgradi občutek in zavedanje, da so te novi pristopi uspešni, in ko se v praksi pokaže, da smo z novim orodjem hitrejši in lahko bolj kvalitetno opravimo svoje delo, se sprememba implementira sama od sebe. Zato ker je interna želja, da se uporabi boljši način.

 

Kljub temu, da je na poti veliko stresnih in kaotičnih situacij, je smer precej enostavna. Veliko majhnih sprememb, ki pridejo iz prakse in so praksi namenjene.