Vodič za rad sa developerima za “ne-developere”
Developeri pre 20 godina:
Svi redom su introverti, osobenjaci, čudna i nepristupačna bića koja vrebaju iz senke osvetljena samo svetlom monitora.
Developeri danas:
Sve isto, samo su još nadmeni i teški za saradnju.
❌ Netačno!
Jasno ti je da bilo ko, ko može da izjavi ovako nešto, nikada nije radio sa dev timom ili sa developerom.
Gde nastaju ti problemi i zašto uopšte dolazi do takvih izjava?
Problemi ovog tipa najčešće nastaju u saradnji između timova ili pojedinaca koji se bave potpuno drugačijim oblastima, kao što su:
- HR - IT
- Marketing - IT
- Menadžment - IT
- CEO - IT
A nastaju uglavnom zbog dve osnovne stvari: drugačija perspektiva i neadekvatna komunikacija.
Iliti: nešto što se podrazumeva “ne-developerima”, ne mora da znači da se podrazumeva i developerima.
Toliko je jednostavno.
Svako ima svoj način razmišljanja koji je godinama usavršavao kako bi postao ekspert u svojoj oblasti.
Problemi su razni i drugačiji su za sve timove.
Pošto ne možemo da se bavimo svim problemima sa kojima se timovi susreću, bavićemo se korenom svih problema, a to je – komunikacija.
Kako ostvariti efikasnu komunikaciju sa developerima?
Prvo i osnovno je:
Ništa se ne podrazumeva.
To je zlatno pravilo kojeg svi treba da se pridržavamo – bilo da smo developeri ili “ne-developeri”.
Pored toga, imamo još par saveta koji će ti pomoći da ostvariš efikasnu komunikaciju:
✔️ Nauči izraze koje koriste developeri (npr. ono što znači jedno u marketingu, može značiti nešto potpuno drugo u developmentu)
Radi efikasne komunikacije sa developerima, neophodno je da vladaš izrazima koje developeri koriste iz jednostavnog razloga – da ne bi bilo nesporazuma.
Dešava se da ostali timovi “barataju” dev izrazima, ali da nisu baš tačno sigurni šta koji izraz znači i ono što njima izgleda kao minorna razlika – developeru može da predstavlja ogromnu razliku u kodu.
Zato, ako nailaziš na probleme u komunikaciji tog tipa – napravite zajednički dokument gde ćete napraviti jasnu razliku u izrazima koji se koriste.
Jasniji zahtevi → manje prepravki → brže rešavanje zahteva → svi srećni.
✔️ Nauči kome treba da se obratiš za koji problem (nisu svi developeri zaduženi za sve)
Iako bi većina developera znala da reši probleme i u backend-u i u frontend-u – svako treba da se bavi svojim delom posla.
Zato nauči ko je iz dev tima zadužen za koji deo posla, ali i u koji deo programiranja tvoj zahtev spada.
Npr. ako treba nešto da se izmeni na lending stranici, poput boje button-a – cimaš frontend developera, ako je već nešto vezano za podatke cimaš backend developera.
Tako ćeš skratiti vreme u dobacivanju taskovima, a i nećeš bez razloga prekidati nečiji tok misli sa zahtevom koji nije namenjen za njih.
✔️ Dogovorite se šta je hitno, a šta nije (nemoj da im prekidaš tok misli bez razloga)
Kako god to zvali - “wired in”, “the flow state” – developerima ne treba prekidati tok misli osim ako nije apsolutno neophodno.
Da ne bi dolazilo do bespotrebnog remećenja koncentracije, dogovorite se koje su stvari hitne, a koje nisu – i kako komunicirati koji nivo hitnosti. Na primer:
- Jako hitno - lagano tapšanje po ramenu
- Srednje hitno - poruka na Slack-u
- Nije hitno - task na kojem će se jasno definisati rok i hitnost taska u odnosu na ostale taskove koji su definisani ranije
✔️ Uključi ih u pregovore sa klijentima (nemoj obećavati klijentu ono što nisi siguran da dev tim može da iznese)
Developeri moraju da budu uključeni u proces pregovora sa klijentima.
Ako ne sarađuješ već duže vreme sa developerima i ne poznaješ njihove kapacitete dobro – ili jednostavno ne znaš šta može “lako” da se napravi, a šta ne – sve proveri sa dev timom pre nego što se naprave bilo kakvi finalni dogovori sa klijentom.
Problemi koji se ovde dešavaju mogu biti razni – legacy kod sa kojim je teško raditi, obećavanje feature-a koji će napraviti veliki technical debt da bi se izbacili na vreme, itd.
Zato, nikada ne isključuj developere iz pregovora – oni su ti koji treba da dostave te zahteve, tako da oni moraju da kažu da li je to uopšte moguće i ako jeste, da li je moguće u vremenskom roku koji ste dogovorili sa klijentom.
✔️ Pravi detaljne brief-ove (opet, ništa se ne podrazumeva)
Koliko god dugo da radiš sa jednim developerom ili timom developera – uvek pravi detaljne brief-ove.
Dobar brief treba da sadrži:
- Jasan cilj
- Ko je end user
- Funkcionalnosti
- Primere i skice
- Definisan timeline
- Sve dodatne materijale (npr. logo, slike, brandbook)
Sa jasnim brief-om, koje god izmene da se dogode u timu, svako će znati šta se očekuje da bude urađeno i u kom roku.
Napomena: Da, detaljan brief je neophodan da bi developeri u svakom momentu znali šta treba da rade, ali im ne treba govoriti kako to da postignu. Oni znaju najbolje kako će ispuniti taj zahtev.
✔️ Nauči da daješ koristan feedback (a i da ga prihvatiš)
Ako se i pored svega ovoga niste dobro razumeli – a to je nešto što će se dešavati – nauči kako da daješ koristan feedback:
- Feedback treba da se odnosi na ishod situacije, a ne na osobu
- Ako ste imali nesporazum, jasno reci gde misliš da je došlo do nesporazuma
- Budi asertivan/na, ne pasivno agresivan/na
- Saslušaj i drugu stranu, možda se tebi podrazumevalo nešto, a developeru ne
- Daj svoje predloge kako da izbegnete nesporazum u budućnosti
- Ako je sve prošlo dobro – nemoj zaboraviti da daš pozitivan feedback
✔️ Pričajte i o temama koje nisu vezane direktno za posao (naučite kako da se razumete i izvan posla)
Iako je remote work i dalje “na snazi”, kad god uhvatite priliku – družite se, pričajte i o temama koje nisu direktno vezane za posao.
Možda baš tako pronađete zajednički jezik koji će vam poboljšati komunikaciju kada je posao u pitanju.
Iako većina ljudi sada već okreće očima na tim bildinge – nisu oni nastali bez razloga.
Developeri i “ne-developeri” ili samo tim koji mora da poradi na komunikaciji?
Ne treba postoji podela na developere i “ne-developere”. Vi ste tim.
Kao i u svakom timu, "samo" treba da radite na aktivnoj komunikaciji i slušanju članova svog tima.
To zvuči tako jednostavno – ali zašto onda i dalje nailazimo na prepreke u komunikaciji?
Zato što ne razmišljamo svi na isti način i ne percipiramo sve na isti način – ali to je dobra stvar.
Ako bismo se svi uvek slagali sa svima i savršeno se razumeli, kako bismo onda napredovali kao tim?
Zato – ne podrazumevajte ništa, slušajte jedni druge i radite na tom feedback-u. Tako ćete najbolje raditi kao tim, i prestati da se delite na developere i “ne-developere”.