Otvorenost za promjenu preduvjet je

Kako postati okretni - Vodič za agencije

Stvaranje idealnih uvjeta za agilne klijentske projekte

Ovaj je članak dostupan i na njemačkom jeziku.

Tijekom posljednjih nekoliko godina, "agilni" je postao sve popularnija glasina na agencijskoj sceni. Jedva da postoji samo jedna tvrtka koja se ne bavi agilnim radom. Ali što to zapravo znači? Kako se može znati koliko je tvrtka zaista agilna? Ako radite u sprintu, znači li to da ste već okretni? (Odgovor: ne.)

U tvrtki Aperto Move neprestano smo analizirali i usavršavali svoje radne metode u posljednje dvije i pol godine, gurajući našu viziju okretnosti na radnom mjestu naprijed. Jedna od najnepobitnijih spoznaja bila je da prijelaz na agilno zahtijeva i vrijeme i iskustvo. Ne može se jednostavno prebaciti na okretno. Iako još nismo tamo gdje bismo željeli biti, poboljšanja su jasno uočljiva.

Primjena agilnih metoda u agenciji ukupno je teža nego, primjerice, u razvoju proizvoda; kao jedan stvara proizvode za različite klijente, gdje se uvjeti mogu drastično razlikovati između projekata. Stoga je teško vjerovati da se svaka agencija odjednom čini okretnom. Srećom postoje čimbenici koji vam mogu lako odrediti koliko je tvrtka na putu da postane okretna.

Savjet predstavljen u ovom članku temelji se na scenarijima uobičajenim za većinu agencija koji su se pojavili u našem svakodnevnom radu i koji su riješeni, nakon što smo ih identificirali kao probleme. Oni nisu nikakvo rješenje za liječenje, već su to zbirka učenja koja najbolje rade za nas.

1. Razjasniti terminologiju

Prilikom uvođenja okretnosti, ključno je da svi u tvrtki imaju isto razumijevanje izraza, jer u protivnom postoji rizik od opasnih pogrešnih komunikacija. Naišao sam na ljude koji pogrešan pristup prihvaćaju kao odlazak u sve faze koncepta, planiranje i redovite sastanke u korist uranjanja ravno u projekt i gledanja što se događa. Nije teško zamisliti da je takav projekt bio sve samo ne lagan.

Drugi su jednostavno čuli za "Scrum" i izrazili određeni otpor prema njemu, odbacujući to kao "nešto za programere" što guši kreativni proces. Za ovu većinu ovih izjava dolaze ljudi koji sami nisu istraživali Scrum ili agilne metode. Uz to, oni koji to nisu upoznati, često ne mogu prepoznati razliku između agilnog i Scruma i klasificirati ih kao jedno te isto.

Scrum i agilni nisu isto

Scrum je okvir koji definira posebna pravila, uloge i radne procese za razvoj softvera. Jedan primjer je definiranje vremenskih intervala u kojima se isporučuje radni proizvod (tzv. Sprint). Implementacija Scruma doprinosi agilnom razvoju softvera, zbog čega se izrazi često smatraju sinonimima, ali nisu.

S druge strane, "Agile" je način razmišljanja ili kulture, koji sadrži mnogo više od onoga što Scrum radi. Principi koji definiraju agilnu kulturu navedeni su u Agilnom manifestu i prikazani su u sljedećem videu:

Scrum je samo jedan mogući pristup da se slijede agilni principi. Može biti i spretan bez korištenja Scrum-a. S druge strane, samo što se pridržavate pravila Scrum-a, ne znači da jedno djeluje okretno.

2. Oprostite od uloge voditelja projekta (pozdravite agilne uloge)

U Scrumu su definirane sljedeće uloge:

  • Vlasnik proizvoda
  • Voditelj Scruma
  • Razvojni tim
  • Daljnji dionici, poput krajnjeg korisnika ili onih koji su uključeni na strani klijenta

Ne postoje druge uloge, niti su potrebne. Klasični voditelj projekata više nije potreban u ovom postavljanju. Samo bi ometao postupak, jer su svi zadaci koje je prethodno vodio voditelj projekta pokriveni gore navedenim pozicijama. Odgovornost za uspjeh projekta više nije na jednoj osobi, već na cijelom timu.

Svaka dodatna uloga koja postoji u projektu - i stoji između Scrum tima i klijenta - prepreka je izravnoj i učinkovitoj komunikaciji između tima i klijenta.

Shvatajte uloge i odgovornosti ozbiljno

Ako nekom ne treba voditelj projekta, zar ne bi imalo smisla zaposliti prethodne voditelje projekata u kombiniranoj ulozi Scrum Master-a i vlasnika proizvoda?

Ne. S jedne strane, obje uloge Scrum Master-a i vlasnika proizvoda podrazumijevaju dovoljno zadataka koji bi izvršavali obje rezultiralo zanemarivanjem jedne od uloga. U konačnici, dvije uloge imaju oprečne interese. Vlasnik proizvoda ostaje u stalnom kontaktu sa svim dionicima i osigurava isporuku pravog proizvoda u najboljoj kvaliteti. Između ostalog, Scrum Master mora osigurati da tim nije preopterećen ili prekinut. Dakle, Scrum Master nema nikakve veze sa samim proizvodom.

Još gora ideja bila bi potpuno izostaviti Scrum Master-a. Bez glumačkog majstora Scruma, nema uloge koja bi osigurala da tim radi produktivno, ispunjava rokove ili uči kroz retrospektive i postaje učinkovitiji. Ukratko, oni su ti koji jamče da će projekt biti izveden na spretan način. Prema našem iskustvu, to je posebno važna uloga u agencijskom okruženju s promjenom klijenata, dionika i uvjeta, jer Scrum Master također preuzima trenersku ulogu za klijenta.

Ovaj članak objašnjava različite funkcije Scrum Master-a i klasičnog voditelja projekta u smislu lako razumljive prometne analogije:

3. Nema više planiranja resursa (umjesto toga uspostavite načelo potezanja)

U agencijama se istovremeno radi na više projekata za različite klijente, što predstavlja učinkovitu raspodjelu posla među svim zaposlenicima.

Klasični agencijski pristup je planiranje resursa: voditelj projekata kreira planove za nekoliko dana ili tjedana unaprijed i dodjeljuje zaposlenicima projekte ili zadatke. To zahtijeva puno vremena za planiranje i koordinaciju i rezultira nefleksibilnošću, jer funkcionira pod pretpostavkom da su ispunjene sve projekcije i planovi za dodijeljeno vrijeme.

Iskustvo nas uči da se u stvarnosti takvi planovi nikada ne ostvaruju: važna isporuka kasni, zaposlenici se razbole ili nastaju druge nepredviđene okolnosti, što dovodi do toga da pojedinačni zadaci potraju duže nego što se očekuje. Posljedice su neravnomjerna raspodjela posla među kolegama, veći stres i prekovremeni rad.

Ovaj takozvani "princip push" (jer zaposlenici imaju pojedinačne zadatke "gurnuti" na njih) nije stoga optimalan. Dakle, kako se rad raspoređuje bez voditelja projekta u okretnoj konstelaciji? Ovo izdanje zahtijeva drugačiji pristup:

Princip vučenja

Agilni rad zasnovan je na "povuci" mentalitetu. To znači da zaposlenici proaktivno odlučuju koje zadatke žele preuzeti. Da bi to uspjelo, predstojeće zadatke i njihov napredak potrebno je transparentno priopćiti.

U idealnoj se situaciji to ne događa samo na razini projekta, već i za sve predstojeće zadatke unutar tvrtke. To uključuje procjenu opsega, stvaranje prezentacija, pripremu radionica, sudjelovanje u intervjuima ili čak pisanje ovog članka. To se može postići na primjer Kanban ploče:

Princip povlačenja pomaže osigurati ravnomjernu raspodjelu posla među zaposlenicima gdje svi imaju slobodu samostalnog odlučivanja kada mogu raditi na svojim zadacima. To pomaže eliminirati mogućnost prekomjernog zapošljavanja određenih zaposlenika.

Da bi princip potezanja funkcionirao, moraju biti ispunjeni sljedeći uvjeti:

  • Stalna komunikacija je presudna. Na Aperto Moveu odbor se tri puta tjedno raspravlja o statusu projekta
  • Zahtijeva ljude sa sposobnošću da preuzmu inicijativu, a ne da čekaju da im drugi kažu što treba učiniti
  • Ona favorizira ravne hijerarhije i zahtijeva spremnost za njihovo provođenje
  • Rukovodstvo tvrtke mora imati povjerenja u svoje zaposlenike kako bi im omogućilo preuzimanje veće odgovornosti
  • Treba postojati jasna razlika između pojedinih zadataka i projekata. Projekte ne povlači jedna osoba, već tim. To ćemo dodatno istražiti u sljedećem odjeljku.

4. Uspostavite stabilne timove

U agencijama je tipično raditi za različite klijente istovremeno, a hitni zadaci (poput procjene opsega, parcele ili ispravci programskih pogrešaka) često se pojavljuju u kratkom roku. Stoga se često stvaraju projektni timovi prema trenutnoj dostupnosti. Ova vrsta planiranja resursa učinkovito sprječava agilne projekte.

Agilni timovi trebaju biti stabilni i idealno bi se našli. Samo se bliski timovi mogu optimalno razvijati i održavati ili čak ubrzati tempo učeći jedan od drugog, koordinirati svoje procese i komunikaciju te identificirati i rješavati probleme retrospektivnom analizom.

Timovi mogu prepoznati i riješiti probleme redovitim retrospektivama (Slika Andreas Plath)

Kako ne bi došlo do ometanja učinkovitih timova kolega koji dobro rade zajedno i time eliminiraju sve efekte učenja i rutine, predstojeće projekte ne treba planirati s obzirom na pojedince, već sa stabilnim timovima.

Međutim, nerealno je misliti da se transformacija cijele agencije sa svim disciplinama u stabilne i uravnotežene timove može dogoditi preko noći. Moguće je da ne žele svi trajno raditi u istom timu. Stoga je ključno pronaći ravnotežu koja će svima dobro odgovarati.

5. Stvorite okretne prijedloge

Klasična, pojednostavljena faza prijedloga između klijenata i agencije obično ima sljedeći oblik: Klijent ima određenu ideju za proizvod i vremensku traku kada ga treba dovršiti.

Klijent zatim upoznaje agenciju sa zahtjevima (možda i visinom glasa) i traži prijedlog koji određuje fiksnu cijenu razvoja ovog proizvoda. Kako bi se zaštitile, obje strane provode znatnu količinu posla kako bi razradile prijedlog kako bi se izbjegle potencijalne nesavjesnosti.

Iz perspektive klijenta ovo se obično čini održivim rješenjem: oni znaju što mogu dobiti i po kojoj cijeni.

Zahtjevi se mijenjaju

Ono što većina klijenata u ovom trenutku ne zna jest da često žele nešto sasvim drugo do kraja projekta kao što su to činili na početku.

Kako je sve konkretno definirano u prijedlogu, tada je gotovo nemoguće nešto promijeniti unutar projekta bez pregovora, poput:

  • druge su značajke u međuvremenu postale važnije
  • željeni projekt više nije tehnički izvediv
  • korisnička ispitivanja otkrila su da je proizvod pogrešno shvaćen ili da nema smisla
  • natjecatelj je kreirao sličan proizvod koji zahtijeva strateško usmjerenje

U ovom slučaju, ponovno određivanje prioriteta nije jednostavno ako je u prijedlogu naveden stari, revidirani opseg.

Ova vrsta prijedloga narušava druge glavne aspekte agilnosti. Kontinuirano, suradničko usavršavanje proizvoda mnogo je teže jer se u početku mora jasno definirati kako bi se prijedlog dovršio. To dovodi do tipičnog tijeka rada za vodopad. Planiranje sprint-a, uključujući planiranje pokera, postaje jednako besmisleno jer su krajnji rok i rezultati već definirani.

Ako su opseg, rok i cijena već postavljeni na početku, više nema smisla pokušati i implementirati agilni okvir kao što je Scrum.

U ovom slučaju više se ne mogu koristiti glavne prednosti okretne isporuke, ali svejedno ima dodatni trošak Scrum sastanaka koji ne pružaju stvarnu vrijednost. Taj se postupak naziva i "pseudo Scrum".

Potrebna je druga vrsta prijedloga

Ima smisla naplaćivati ​​količinu obavljenog posla (tzv. Vremenski i materijalni ugovori), a ne definirati točne rezultate u prijedlogu. Tek tada je moguće izvršiti projekt na spretan način.

Koliko i što klijent dobiva za svoj novac određuje sam tijekom projekta, ažurnim popisom zahtjeva i postavljanjem prioriteta zajedno s timom.

Izrada okretnih prijedloga zahtijeva praksu (Izvor: https://unsplash.com/?photo=OQMZwNd3ThU)

Da bi klijent dobio ideju o tome što može očekivati, može se dati gruba procjena koliko je moguće postići u određenom vremenskom okviru ili koliko će vremena trebati dok se neki zahtjev ne provede. Što duže tim radi zajedno, to je procjena preciznija jer je lakše mjeriti opći tempo ili "brzinu" tima. To je još jedan razlog zašto je poželjno raditi sa stabilnim timovima.

Kao što je rečeno, sastavljanje prijedloga i dalje je jedan od najtežih elemenata agilne tranzicije. Jedva da jedan klijent koji još nije prikupio iskustvo u okretnom okruženju želi da potpiše otvoren ugovor. Da biste ih uvjerili u njegove zasluge, najvažnije je prije pokazati sposobnost i izgraditi povjerenje sa klijentom.

Prema našem iskustvu, ovaj je izazov lako prevladati čim jedan zajedno napravi agilni projekt. Tada projektni proces govori sam za sebe; dajući brzi i opipljivi rezultati putem iterativnog rada, bliske suradnje i kraćih ciklusa povratnih informacija, koji su mnogo bliži onome što je klijent predvidio nego što bi bilo u tipičnim projektima slapova.

Na temu okretnih prijedloga poput ove knjige, dostupna je mnoštvo korisne literature:

6. Uključite projektni tim u fazu stjecanja što je prije moguće

U agencijama je faza nabave i prijedloga često izolirana od provedbe projekta. Novi poslovni tim odgovoran je za nove projekte, a projektni se tim nije suočio s detaljima do faze provedbe, što povećava vjerojatnost za sukobe.

Faza prijedloga već može biti presudna u utvrđivanju hoće li projekt biti uspješan ili ne. Stoga je vrlo važno da agilni tim bude što prije uključen u komunikaciju.

Kao rezultat, može se procijeniti relativno rano je li okretna provedba održiva i koliko se vremena može očekivati ​​za nju. Vremenski izdaci, npr. broj potrebnih sprintova u scrum projektu može procijeniti samo tim, ako ono zna što više o projektu.

Povremeno će biti više zahtjeva za projekte nego što postoji kapacitet za rad na njima. Za provedbu načela potezanja i odabir najprikladnijeg projekta, tim mora znati što je moguće više o svim projektima koji su u tijeku. Tek tada mogu donijeti informiranu odluku i smisleno uključiti nove projekte u trenutne trenutke.

Kada započne novi projekt, tim bi trebao što prije upoznati sve dionike i njihove zahtjeve kako bi se isporučio pravi proizvod najbolje moguće kvalitete. Jedna učinkovita mjera za postizanje toga je održavanje radionice s timom i dionicima na strani klijenta.

Uz to, važno je prenijeti agilne vrijednosti klijentu, identificirati osobu primarnog kontakta i detaljno objasniti postupak suradnje.

7. Zaboravite na ulogu davatelja usluga (i radite kao tim sa svojim klijentom)

Odnos klijenta / pružatelja usluga je kontraproduktivan jer se uvijek temelji na pretpostavci da je klijent dodijelio ugovor i očekuje konkretan rezultat. Uspješan rezultat projekta, koji zadovoljava sve uključene strane, obično zahtijeva rad sa svih strana, posebno redovitu komunikaciju jedni s drugima.

Bitan preduvjet uspješnog agilnog projekta je komunikacija na istoj razini. To znači da se klijent i agencija međusobno smatraju jedinstvenim timom, radeći zajedno na projektu i identificiraju i uvažavaju prednosti jednih drugih. Agencija je obično stručnjak za strategiju, korisničko iskustvo, dizajn i tehničku implementaciju; klijent je, s druge strane, upoznat sa vlastitim internim procesima i zahtjevima kao i sa svojom ciljanom publikom. Tek kada se podijele ove informacije, može se stvoriti zaista korisnički orijentiran proizvod koji zadovoljava sve dionike.

Ovo zahtijeva da na strani klijenta postoji imenovana kontakt osoba koja je dostupna za odgovaranje na pitanja u vezi s projektom ili može agenciji dostaviti bilo koji nedostajući materijal. Nije svaki klijent može ili želi uložiti toliko vremena u jedan projekt jer mu vlastiti unutarnji radni procesi to ne dopuštaju.

Prema našem iskustvu, klijenti obično u ranoj fazi primjećuju koliko brže dobivaju visokokvalitetne rezultate putem agilne suradnje. To odgovara njihovim očekivanjima i oni su spremni uložiti vrijeme.

8. Osigurajte prostor za timski rad

Biti spretan znači interdisciplinarno i kontinuirano komunicirati. To najbolje funkcionira ako agilni tim sjedi zajedno, što pomaže jednostavnoj koordinaciji njihovog rada. U idealnom slučaju, svaki bi tim trebao imati vlastiti prostor u kojem mogu nesmetano raditi uz minimaliziranje smetnji za druge, npr. kada se raspravlja o dizajnu ili značajkama.

Agile timovi trebali bi moći raditi bez prekida (Izvor: https://unsplash.com/photos/5T6lSk2uI1A)

Agencije često slikaju drugačiju sliku: grupiranje zaposlenika prema njihovim disciplinama. To znači da svi dizajneri sjede u jednom kancelariji, programeri u drugom kutu, a testeri i voditelji računa često su u različitim sobama. Iako bi to moglo imati smisla u smislu razmjene discipline, ona otežava komunikaciju unutar projektnog tima. Pisanje jednih o drugima je mogućnost, ali treba mnogo duže nego da govorite izravno jedni drugima.

Postaje još teže kad svi članovi tima nisu na istoj lokaciji. Svi znaju koliko su loše telefonske ili video konferencije, a ako ih niste morali trpjeti prije, preporučuje se ovaj videozapis:

9. Razmotrite svaku disciplinu i cjelokupni proces projekta

Kako se Scrum rodio iz razvoja softvera, može se činiti prikladnim izvršiti tehnički aspekt projekta samo na agljiv način, ostavljajući kreativnu fazu netaknutom. To se, međutim, postiže relativno malo, jer se struktura vodopada tada rješava tek na kraju projekta.

Klasičan postupak vodopada temelji se na odobrenju specifičnih rezultata

Pretpostavimo da su agilni tim sastavili isključivo programeri; koncept i dizajn web stranice klijenta već je gotov, ali na sredini razvoja postaje očito da važna stanja nisu definirana ili osmišljena te je kreativni tim već uključen u svoj sljedeći projekt. Što sada? Treba li ljude skidati s drugih projekata? Nastaviti razvijati nekompletni proizvod? Nema lakog odgovora osim uključivanja svih relevantnih disciplina u agilni tijek rada od početka.

Redovita razmjena unutar projektnog tima poboljšava kvalitetu proizvoda (Izvor: https://unsplash.com/photos/gN_nIUnjYJI)

Povratne informacije, povratne informacije, povratne informacije

Ogromna snaga i važan razlog zašto je kvaliteta agilno razvijenog softvera bolja od kvalitete projekata slapova u okviru klasičnog upravljanja projektima je interdisciplinarna suradnja i iterativno poboljšavanje proizvoda na temelju ranih i redovitih povratnih informacija među svim dionicima.

Jednostavno, to znači: svi pregledavaju sve u svakoj fazi projekta.

  • Klijent i cijeli tim daju vlasniku proizvoda (PO) povratne informacije o korisničkim pričama
  • Dizajneri korisničkog sučelja daju povratne informacije o žičanim okvirima i tehničkoj izvedbi
  • UX dizajneri daju povratne informacije o dizajnu korisničkog sučelja i tehničkoj izvedbi
  • Prednji programeri daju povratne informacije o žičnim okvirima, dizajnu korisničkog sučelja, pomoćnim sučeljima i, prema potrebi, sigurnosnoj implementaciji
  • Back-end programeri daju povratne informacije o žičanim okvirima, dizajnu korisničkog sučelja i implementaciji
  • Osiguranje kvalitete (QA) daje povratne informacije o žičanim okvirima, dizajnu korisničkog sučelja i tehničkoj izvedbi
  • Korisnici daju povratne informacije putem testova upotrebljivosti tijekom faza projekta (žičani okviri, prototipi dizajna, lutke klikova, implementacija na kraju)
  • Klijent daje povratne informacije o povećanju proizvoda tijekom sastanaka pregleda sprint-a
U okretnom postavljanju, tim djeluje zajedno, a ne uzastopno

Redovne povratne informacije najvažnije su sredstvo u agilnom razvoju i osiguravaju da je proizvod razvijen na razini koja zadovoljava sve dionike. Naravno, ovo funkcionira samo kada su svi uključeni u svaku fazu projekta.

10. Ne očekujte da će sve raditi odmah (pravite pogreške i učite od njih)

Nadamo se da su prethodni odjeljci pokazali da je potrebno na nekoliko razina zauzeti različite pristupe onima koji su vjerojatno razvijeni i uspostavljeni tijekom godina. Zbog toga je sve važnije shvatiti da je prelazak u agilniji proces, a ne nužno lak, niti onaj s definiranim ciljem.

Provedba gore razmotrenih mjera ne jamči automatski prijelaz prema okretnosti. Slično tome, nije dovoljno primijeniti samo "tehničke" aspekte, poput usvajanja Scrum-a. Mnogo je važnije promijeniti kulturu tvrtke i uspostaviti zajednički, okretni sustav vrijednosti na svim hijerarhijskim razinama.

Bilo bi naivno očekivati ​​da bi se takve temeljne promjene mogle provesti odmah i bez problema. Promjene u tvrtkinim procesima mogu se tretirati i kao okretni projekt i izvesti ih iterativno.

U konačnici, to znači da ne treba pokušavati promijeniti sve odjednom, već radije primijeniti jednu po jednu mjeru. Na taj se način čovjek uči što funkcionira, a što ne, a što se može poboljšati. Bilo bi pogrešno držati se jedne mjere koja se ne čini ispravnom, samo zato što je preporučila knjiga ili blog.

Vanjsko podučavanje može biti podjednako korisno u pokretanju ispravnih misaonih procesa, međutim ne može se nadati da će pronaći brzo lijek za ispravljanje, koji će iznenada učiniti okretnim.

Jednako je važno uspostaviti internu razmjenu znanja i iskustava i dogovoriti zajednički pristup. Da biste to postigli, korisno je redovito pogledati dvanaest principa iza Agile Manifesta i preispitati u kojoj mjeri ih je vaša tvrtka već usvojila:

U našem se timu strogo pridržavanje smjernica Scrum okvira pokazalo kao najbolje rješenje. Svaki put kada su se ti procesi odstupili, to je dovodilo do komplikacija i više napora. To ne mora biti slučaj sa svima. Svaka tvrtka mora otkriti za sebe što najbolje funkcionira.

Zaključak

Čak i prije nego što započne projekt klijenta, određeni standardni uvjeti agencije mogu ugroziti ili čak onemogućiti uspjeh agilnih projekata. Tu je potreban novi način razmišljanja na svim razinama i u svim disciplinama, što podrazumijeva promjene koje se ne mogu provesti preko noći.

Točke u ovom članku mogu poslužiti kao smjernica za prepoznavanje i raspravu o situacijama i problemima u planiranju agilnih projekata, prije nego što započnu.

Kakva su vaša iskustva o ovoj temi? Znate li druge okolnosti koje otežavaju agilne procese? Javite nam u dijelu komentara ovog članka.

Daljnje čitanje

Aperto Move - IBM tvrtka je berlinska agencija za digitalne i mobilne usluge s oko 30 zaposlenih. A ti?

Pratite nas: apertomove.com / Facebook / Twitter