Hoće li prodaja ikada biti vještina važna developerima?

Budimo realni, sastanke se uz nešto truda još i da odraditi. I neizbježni su. Međutim, prodaja baš i nije, pa mnogi od nas nemaju previše razloga da se pokušaju s njom upoznati. Zato ni ne stignemo uvidjeti da se radi o vrlo korisnoj vještini. Da, čak i za developere! Ipak, rijetki među nama se njome uspješno služe.

Dosadnjaković s krpama za prašinu…

Prodaju često zamišljamo kao uporne pokušaje nekog dosadnjakovića u odijelu da kupcu-žrtvi proda robu ili uslugu za koju ovaj nema ni interesa ni potrebe. Lonce, brijaće aparate, krpe za prašinu… Prodavač je uporan, rječit i nasrtljiv. Ne odustaje lako i spreman je na sve. A kupac? Od prodavača bi najradije pobjegao glavom bez obzira. Ako stvar i završi kupovinom, kupac ostaje nezadovoljan. Lako moguće da se osjeća izigran. I radije bi da nije popustio prodavaču.

No, jesu li stvari baš takve? U novije vrijeme čujemo nešto drugo. Da se prodaja velikom većinom (80 posto!) sastoji od umijeća slušanja. Zatim, da pravi prodavač vrlo odmjereno priča. A većinu vremena pokušava shvatiti onoga kojem prodaje, bilo da je riječ o proizvodu, usluzi ili ideji. I najvažnije od svega, da je prodaja proces traženja tuđeg benefita.

…ili ipak nešto drugo?

Jedan od najjačih developera u firmi iz koje dolazim, Stipe, je ujedno i najbolji prodavač. Radi POC-ove na tjednoj bazi. Obilazi programerske timove, saznaje što ih muči. Onda sastavlja MVP-jeve (scrum kratica za minimum viable product), predstavlja ih kolegama s puno oduševljenja, prikuplja ideje kako dalje doraditi to što je započeo.

I ti POC-ovi nailaze na adoption. Netko počne koristiti, netko i preuzme projekt. U konačnici, Stipe ima vjerojatno najveći impact u firmi. Vidio sam i more drugih dobrih ideja, dobrih implementacija, ali jednostavno – nisu bile prihvaćene.

Čini se da Stipe uspijeva naći tuđi benefit, i time postići da se njegove ideje i rješenja prihvate. Dakle, imamo i empirijski dokaz da ovakav pristup uspijeva 🙂

Koliko je bitno razumjeti benefite kupca (korisnika, klijenta) vidimo i na primjeru Maxa Howella, autora Homebrewa. Suprotno uvjerenju većine nas programera, Howell kaže da softverska rješenja ne moraju uvijek biti tehnički briljantna, a da bi bila uspješna i prihvaćena. Ključno je nešto drugo – da proizvod donosi benefite onima koji ga koriste, bilo unutar ili izvan organizacije.

Howel je svojedobno napisao “simple package manager”. Ni po čemu izniman, a po mnogočemu loš. Ipak, doživio je ogroman uspjeh. Razlog nije bio u kodu, već u korisničkom iskustvu, i inzistiranju na korisničkom benefitu. (Njegov post možete pročitati ovdje.)

Jeste li pokušali prodati svoju ideju?

Nedavno sam na jednom panelu spominjao kako pomoću “fun daya” nastojim osigurati upliv inovacija u naš developerski tim. Koncept fun daya je jednostavan, na jedan dan prestanemo raditi na “regularnim” projektima i bavimo se nečim po svojoj volji. Novim manjim projektom, ili isprobavamo novu tehnologiju, novi alat…Prvo pitanje iz publike je bilo “Kako vam daju da to radite?”

Međutim, treba li se čuditi što netko “dopušta” fun day, ili je zanimljivije pogledati kako je došlo do toga da ideja bude prihvaćena? Jer, ako na poslu uredno isporučuješ sve što se od tebe očekuje, a uz to znaš i pokazati kako će fun day donijeti novu vrijednost i ljudima i organizaciji – velike su šanse da će biti prihvaćen. Neki su komentirali kako evangeliziranje i “prodaja” ovakvih ideja ne bi trebao biti posao programera, već bi to trebao poticati menadžment unutar svog djelokruga. No, je li baš tako? U srednje velikim i većim organizacijama, uspjeh i promjene često ovise o sposobnosti pojedinaca da okupe ljude oko neke ideje. Često i o njihovoj upornosti. Naravno, treba najprije krenuti, a zatim se i poslužiti umijećem prodaje.

Očekujte i prepreke

Bezbroj puta sam i sam raspravljao s product ownerima, kada ne bih vidio benefit nekog zadatka koji su stavili pred nas. Ili kad nam “iz neba” dođe procedura koja samo troši vrijeme. Mi developeri ćemo se prvi pobuniti na takve nebuloze. Prema tome, zvuči korektno barem prihvatiti da ni naše ideje neće biti odmah prihvaćene, već ih treba približiti, pokazati benefit koji nose organizaciji, pokazati zašto su dobre. Drugim riječima, posegnuti za prodajnim taktikama.

Nekad će na tom putu biti i raznih prepreka. Priznajmo, mi developeri se nerijetko volimo i praviti pametni pa problemi često nastaju u komunikaciji. Spremni smo zakomplicirati s puno detalja, umjesto da pričamo jezik koji svi razumiju. A paralelno štujemo koncepte clean codea i ljutimo se kada netko u istu metodu stavlja različite razine apstrakcije.

A kad smo već kod clean codea, veliki sam pobornik pisanja testova, ali jako testiran kod koji nitko ne koristi – na njega ne želim trošiti vrijeme. Zanimljiva je činjenica da prije spomenuti Stipini projekti nakon nekog vremena postanu najtestiraniji! Objašnjenje za to je vrlo jednostavno. Intenzivno se koriste i intenzivno razvijaju, pa zbog same važnosti koju postignu moraju biti pokriveni testovima.

Više o ovome s Damirom Pruscem

Sve u svemu, mislim da na temu komunikacije i leadershipa u developerskim timovima i organizacijama svi imamo prostora za učenje. Te i takve teme ćemo načeti na prvom Leading in Tech meetupu, 12.6. u zagrebačkom Hubu 385, s čovjekom koji ima više od 20 godina iskustva na velikim softverskim projektima. Damir Prusac, voditelj razvoja u Infobipu, napisao je i knjigu (“On the Trace of Agile Leadership – Principles and Practices for Human Work and Life”) u kojoj se zalaže za agilne prakse, ne samo u radu s tehnologijom, već i s ljudima. Bit će ga zanimljivo poslušati, i upitati o nekima od ovih stvari.

P.S. Još razmišljate o tome je li prodaja developer skill? Pročitajte o Googleovom istraživanju, i o sedam vještina koje su se pokazale najvažnijima kod njihovih najuspješnijih zaposlenika (spoiler alert: soft skillovi :O).