Eu fiind tanar student am luat decizia de a aplica la o firma pentru un internship.
In cadrul procesului de recrutare am primit si o problema de algoritmica sa zicem, nu foarte grea pe care am rezolvat-o trimitand solutia.
Acuma la interviu din cate am vazut oamenii nu au fost interesati atat de mult de gandirea algoritmica cat de cum ma raportez eu la client , ca in problema se zicea ca cineva imi cere cu x blocuri sa construiesc un triunghi si cum sa fac asta, dar eu am crezut rasfoind si Cracking The Coding Interview ca mi se evalueaza abilitatiile tehnice de a scrie un algoritm eficient da accentul s-a pus mai mult pe cum as comunica cu persoana care-mi da taskul ( practic clientul care ma pune sa fac triunghiul cu blocuri) si de exemplu am fost si intrebat ce as face daca mi se ofera un numar x de blocuri pentru constructie si eu am zis ca daca sunt prea multe n-am sa le folosesc pe toate , dar dupa m-au intrebat ca , cum procedez daca clientul vrea sa le folosesc pe toate si am zis ca i-as explica ca nu are sens sa le folosesc pe toate dar persoana care mi-a adresat intrebarea nu prea a fost multumita de raspuns .
Acuma doresc sa va intreb: voi ce parere aveti si cum ar trebui eu sa ma pregatesc de partea asta de comunicare cu clientii asta pentru viitorul job si viitoarele interviewuri.
Caci eu am crezut ca , ca it-ist eu ma ocup mai mult de scris cod eficient si product ownerul se ocupa sa discute cu clientii si sa organizeze munca in sprinturi da aparent vad ca lucrurile nu stau chiar asa.
Acuma nu cred ca am dat raspunsuri foarte bune la interviu dar pe viitor daca este nevoie as dori sa ma pregatesc si pentru asa ceva si pentru asta va solicit ajutorul.
Multumesc!
Trebuia sa raspunzi “Clientul nostru, stapanul nostru”. 
Acum serios vorbind, in absolut orice domeniu de activitate, comunicarea joaca un rol extrem de important. Modul in care te prezinti si modul in care interactionezi cu ceilalti te pot ajuta sau nu in decizia pe care angajatorii o vor lua. Cand mergi la piata, alegi pepenele cel mai dulce.
Depinde foarte mult de companie.
Din pacate sunt suficiente ca folosesc metoda pe care o mentionezi, dar iti garantez ca acolo vei avea cele mai putine satisfactii legate de ceea ce faci.
In cazul optim product manager vine cu o problema si impreuna cu echipa cauta o solutie (faza asta se numeste discovery) in urma careia vor fi create taskurile pentru implementare si apoi efectiv codul (delivery). Intotdeauna recomand devilor din echipa mea sa petreaca cat mai mult timp cu utilizatorii astfel incat sa le inteleaga problemele astfel incat sa poata propune solutii care utilizatorii nici stiu ca sunt posibile.
Nu pot sa cred ca e pe bune intrebarea cu blocurile in triunghi…
In loc sa fugi de sa rupi pamantul de firma aceeea tu intrebi pe forum :))
Cominicarea nu era cu clientul, ci cu viitorii colegi. Product ownerul e si el om, ii mai scapa lucruri. Requirementul poate fi incomplet.
Cred ca a dat un exemplu. Cam exagerat :))
pai incerc sa aflu si eu de ce alte skiluri mai am nevoie, ca am facut la viata mea doar un internship si atat.
Știu că va suna patronizing, nu este, dar oricum aș zice-o așa va suna, deci: comunicarea este importantă pentru că vei mai apăsa un enter între paragraf, să nu faci propoziții fără sfârșit.
Încearcă să citești cu voce tare ce ai scris mai sus, vezi unde rămâi fără aer 
Cateva reguli pentru comunicare:
- Citeste intrebarea de 2-3 ori inainte sa incerci sa raspunzi, iar daca esti intr-un meeting fa-ti notite. Daca cineva iti vorbeste/ iti explica ceva fii atent, nu fa altceva in acelasi timp.
- Daca nu stii ceva sau nu e absolut clar ce se vrea de la tine intreaba, intreaba inca o data (repeta ce ti s-a scris/spus in alte cuvinte).
- Daca nu stii ceva si trebuie sa stii poti spune ca o sa te documentezi, ca o sa vorbesti cu ceilalti si revii cu un raspuns.
- Vorbitul e mai rapid si usor ca scrisul, poti sa mai zici glume daca e tensiune din ceva cauza (atentie nu fii nici sarcastic, condescent - e foarte periculos daca nu esti fata in fata), daca poti porneste camera ca sa te vada fiindca ai si limbaj corporal si imaginea ta iti da prezenta.
- Cand ai nevoie de ceva de la cineva gandeste-te la ce poti oferi in schimb prima data si cum se simte/unde e/ ce o sa faca omul cu care o sa vorbesti. Prin ce poti oferi nu ma refer la ceva fizic, ma refer la ceva favoare sau la un compliment, la a da ochi la o problema, o parere de bine, o multumire, un truc, un mic secret. O mica atentie te poate duce foarte departe.
- Multumeste mereu cuiva cand ceri ceva, intreaba daca poti ajuta cu altceva, explica clar ce doresti si spune si daca e urgent sau nu.
- De comunicat comunici si prin ce faci, daca faci ceva in bataie de joc si dupa ceri ajutor si omul isi da seama ca nu iti dai interesul sau ca ii dai lui de munca in loc sa faci tu ce ar trebui s-ar putea sa nu te mai ajute in viitor pe tine sau echipa si asta e o problema mare. Prin nu te ajuta nu inseaman ca nu te ajuta, ci doar tot amana sau il face foarte incet pana in ultimul moment si asta nu e bine pentru nimeni.
- Disponbilitatea si punctualitatea e importanta, daca setezi un meeting sa fii acolo la fix sau chiar inainte, nu dupa un minut/doua. Daca intarzii cu 2 minute scrie inainte de meeting ca vei intarzia/a intervenit ceva si anunta toata lumea/organizatorul meetingului ca sa nu astepte dupa tine.
- Pune un meeting in calendar pentru orice poate dura mai mult de 1 minut si chiar nu se poate in scris. Asta inseamna ca intrebi prima data omul/oamenii cand sunt disponibili sa vorbeasca cu tine si nu discuti direct ca sa nu il intrerupi de la ce face, chiar daca poate omul vrea sa fie de treaba si sa te ajute pe loc.
- Niciodata nu mentiona un subiect periculos/sensibil ca religia, politica, daca cineva te atrage spre subiect da-i de inteles ca nu te intereseaza, schimba subiectul spre ceva mai neutru.
- Nu barfi si niciodata nu utiliza expresii precum “Munca de chinez”, in special daca le traduci.
- Daca chiar trebuie sa zici ceva de rau de cineva si nu de ceva ce face gresit mentioneaza ceva rau, dar spune si lucrurile bune despre acel om. (compliment sandwitch)
- Nu te plange, daca ai o problema cu ceva ridica problema si propune si o solutie sau intreaba cu cine ai putea vorbi ca sa imbunatatesti acel ceva.
- Daca ajungi sa te certi din ceva motiv cu cineva tine mereu minte ca nu o sa iasa bine orice ai face si inchide call-ul, pleaca pana se linisteste/te linistesti. Nu te ajuta cu nimic sa ai dreptate, nici sa pui pe celalalt intr-o situatie proasta.
- Vorbeste cu toata lumea, nu ezita sa scrii direct altui coleg daca n-ai mai vorbit niciodata cu el daca crezi ca te poate ajuta, dar nu fa ca indienii cu Hey Sir, please I need help with… thx thx (asta e cazul bun, ca de obicei nu te intreaba de ajutor ci fac de capul lor) Daca chiar nu crezi ca e o idee buna sa vorbesti tu cu cineva cere ajutor de la alti colegi/manager si te pun indirect in contact.
- Grija la ce probleme aduci in atentie fiindca trebuie si rezolvate de cineva si daca nu exista deja cineva care sa le rezolve atunci tu le vei rezolva mai mult ca sigur.
- Daca stii ca cineva are o zi proasta incearca sa il inveselesti sau nu vorbi cu el/ea. Femeile au o perioada in fiecare luna in care trebuie sa le abordezi putin mai indirect.
- Nu spune da la ceva ce nu stii ca poti face, spune ca trebuie sa investighezi prima data sau ca nu e clar ce trebuie facut. Indienii au prostul obicei sa spuna da la tot (la ei e o rusine daca nu stii ceva) si dupa iese o mamaliga.
- O imagine face cat o mie de cuvinte, remote cea mai buna metoda de comunicare e sa desenezi/sa arati in cod, sa arati in aplicatie, sa faci o inregistrare/o poza. Am colegi care folosesc Paint/Word/Powerpoint la nivel de arta ca sa faca diagrame si prezentari.
- Cateodata trebuie sa vorbesti despre ceva ce n-ai facut tu, aici e mult mai dificila treaba fiindca nu stii despre ce vorbesti dar trebuie sa vorbesti. (e foarte frecventa problema in cazul managerilor) Trebuie sa te pregatesti obligatoriu dinainte, sa iti scrii prezentarea, sa ceri feedback de la ceilalti si sa o inveti.
- Trebuie sa adaptezi limbajul in functie de om, nu poti sa spui acelasi lucru in acelasi fel la doi oameni.
- Cand vorbesti pune accent si pauza, nu vorbi monoton. Nu te grabi, cel mai mare secret la vorbit e sa vorbesti mai incet si sa tii ritmul ca sa ai timp de gandire daca te blochezi. Nu te ajuta cu nimic sa spui rapid ceva ca sa scapi rapid si dupa sa nu te inteleaga nimeni sau mai rau sa inteleaga altceva.
- Daca lucrezi de acasa iti trebuie casti si preferabil un microfon chiar dedicat. Microfonul trebuie sa fie cat mai bun posibil, fara zgomote (daca e in laptop si nu e un macbook de multe ori se aude caraitul de la ventilator). Inchide geamul, inchide usa la camera, nu trebuie sa auda colegii ca plang copiii/ca iti merge masina de spalat, daca ai ecou rezolva-l cumva. Daca ai un scaun care scartaie schimba-l. Daca ceilalti iti zic ca te auzi ca un robot nu sta in acelasi loc daca vezi ca n-ai semnal la WiFI, muta-te undeva cu semnal mai bun sau treci pe internet de pe telefon.
In scris ai mereu introducere, continut si incheiere. Ai grija sa pui pauze si sa nu scrii mult fara sa fii sigur ca cineva iti poate citi introducerea, iar daca ai scris mult poti pune un TL;DR (Too long; did not read), adica un rezumat scurt. Gramatica iarasi conteaza, instalezi Grammarly si devine aproape imposibil sa scrii prostii in engleza.
Unul din trucurile mele din pandemie e utilizarea unui microfon dedicat cu o interfata XLR la care poti lega castile. Interfata are o functie ca sa te auzi fara intarziere la fel cum te aud ceilalti si in acest fel nu poti vorbi prea tare/prea incet, auzi orice zgomot, poti ajusta microfonul ca sa te auzi ca la radio si cu cat iti auzi mai mult vocea cu atat devii mai sigur pe tine.
As zice ca tocmai comunicarea face diferenta dintre un dev bun si unul foarte bun. Degeaba esti maestru pe framework-ul tau daca nu stii sa explici unui product owner la ce lucrezi
The Corporate Survival Handbook 
Vorbeste mai putin, asculta mai mult. 
O ratie de 10-20% vorbit, 80-90% ascultat.
E tot timpul tentant sa vorbesti TU, sa explici, sa vorbesti despre problemele tale, etc.
Castigi mai multa insa daca ii asculti pe ceilalti.
BONUS: Pune intrebari open ended - care sa nu aiba ca raspuns DA/NU.
Asa NU: “E ok sa fac X?”
Asa DA: “Vreau sa fac X, ce crezi despre asta?”
Asa NU: “John, mai ai ceva de adaugat?”
Asa DA: “John, ce doresti sa mai adaugi?”
Bine, cateodata e greu sa ai aceasta disciplina. Cateodata chiar n-ai cum sa eviti intrebari care necesita DA/NU. Cateodata intrebarile open ended pot suna fortat. Dar ai prins idea.
+sfaturile foarte faine ale lui @isti37
Ma astept ca un canditat sa vorbeasca mai mult de 10-20% intr-un interviu.
depinde mult de componenta echipei. Daca ti se cere sa povestesti cu clientu si tu esti incepator eu as fugi de firma aia.
Am fost in echipe in care discutia cu clientul se facea prin business analyst si eventual team lead, daca era nevoie de o opinie pe partea tehnica. Daca ti se cere sa vorbesti tu cu ei inseamna ca echipa e foarte mica si n-are oameni cu multa experienta. Asta inseamna si ca e foarte mult de lucru, cel mai probabil, si mult stres.
O sa ai farfuria destul de plina invatand sa scrii cod care nu e bol de spaghete si nu are rost sa te complici cu discutatu cu clienti care de cele mai multe ori sunt habarnisti cand vine vorba de scris cod si vor toate livrate alaltaieri la calitate nemteasca
Desi articolul e din 2016 munca remote cred ca a accentuat punctele precizate.
La inceput de drum fara experienta crezi ca totul e pe merite, well, e multa politica intre meritocratie si rasplata.
Aici pare ca se aplica punctul 1.
Deci trebuia sa fii yes sir, clientul nostru, stapanul nostru ca sa iei toti banii; de fugit din asemenea companii.
1. Că profesionalismul nu contează! Sau mai bine zis contează ceva, dar oricum nu foarte mult! Mult mai mult contează să nu fii onest, să fii gata să lupți cu toate armele, inclusiv acelea pe care ți le-a dat natura, să știi să mângâi orgoliul șefilor și să râzi și să vorbești când trebuie, să știi să bagi fitile acolo unde trebuie și chiar să le dai foc când trebuie! Să renunți la toate principiile și să ai numai unul sus, în frunte: Orice, numai eu să ies deasupra! Am văzut promovați oameni care nu aveau nicio legătură cu ceea ce înseamnă profesionalismul, însă erau maeștrii jocurilor de culise! Alții care numai dădeau impresia că știu, dar totul era la bluf, de fapt habar n-aveau ce spun! Conta însă siguranța cu care vorbeau și faptul că vorbeau în fața unora și mai habarniști!
Interesant, comunicarea la nivel profi, marketing 1:1
Tks!
Intr-o companie mare si echipe sanatoase, nu vad de ce ar trebui sa stea sa comunice devii direct cu clientii.
Ca trebuie sa explice ceva tehnic si sa aiba abilitatea sa o puna in termeni normali, da.
Ca trebuie sa fie la o sedinta la inceput sa monitorizeze si sa intervina atunci cand discutia merge spre tehnic, iar PM abereaza, da.
Dar sa preiei cerintele de la client, sa te gandesti la utilizator in loc sa te axezi pe scris cod, nu vad cum e eficient.
In echipa curenta devii sunt calariti si pusi sa faca client management, sa preia cerintele, treaba de PM pt. unul din ei, in timp ce business analyst din echipa clientului sta la sedinte si asculta cum vorbeste dev-ul.
Ca asa a vrut un lead dev care a ajuns el PM.
Se vede pe devi ca nici acum nu sunt multumiti de treaba asta, dar tac si inghit si au inghitit galusca precum ca nu vrea clientul sa plateasca mai multi oameni, a fost negociat contractul prost, in timp ce cine stie care manager merge cu bonusurile in traista.
Eu am fost intr-o firma de produs in care rolul de scrum master era prin rotatie. Nu exista client management (sau de asta exista rolul de delivery manager, account manager si product manager), ai doar produsul, story-urile din backlog si product ownerul (ownerii) care le prioritizeaza si care ne ajuta sa facem refinementul story-urilor pana puteam ajunge la consens cu estimarea.
Nu vad unde intra cineva cu autoritate mai mare dintre devi, toti sunt egali, toata lumea trebuie sa ridice probleme, sa faca sugestii. N-am inteles niciodata care e rolul business analyst-ului, probabil ca poate raspunde la niste intrebari la care nu poate raspunde PO-ul.
Eu chiar spun ca intr-o companie mare devii trebuie obligatoriu sa comunice cu clientii prin PO (eu inteleg clientul ca product ownerul). In cazul in care nu e disponibil PO-ul poate vorbesti cu clientul, dar e o idee foarte proasta sa ai inca un om intre client si tine care sa nu fie PO-ul. E treaba ta sa intelegi ce se vrea si sa imbunatatesti, nu esti doar un robot care scrie codul dupa ceva story in majoritatea cazurilor prost scris si cu design deficitar. Tu stii ce se poate face si ce nu, daca intra o persoana in plus ala poate promite marea cu sarea ca sa fie promovat si dupa echipa ramane cu munca si face el ce poate ca estimarile tale oricum sa nu mai conteze si sa faci totul.
Cel mai rau caz e cand te calareste un product manager care nu e PO cu cand e gata X in fiecare zi.
Eu chiar azi a trebuit sa formulez un mail clar in care sa spun ca problema nu era de la noi.
Deci skill-uri de comunicare sunt necesare si pentru devi
N-am inteles niciodata care e rolul business analyst-ului
BA extrage de la clienti cerintele de business si le transpune in stories si detaliaza aspectele tehnice pentru a atinge acele obiective. Un BA bun stie si putin backend sau macar poate lucra cu SQL.
Modul in care aceste cerinte vor fi implementate si felul in care se va integra o cerinta in produsul digital (pe partea de front end) tine de UX. UX stabileste de la bun inceput interactiunile necesare pentru a atinge acea cerinta de business fara sa faci compromisuri mari in interfata utilizatorului (asta e valabil in companie care recunoaste valoarea UX si nu crede ca e doar graphic design).
Story-urile de obicei sunt scrise de BA si/sau completate de UX.
La firmele mici se merge pe ideea de dev - client direct din lipsa de oameni sau buget. Oarecum se creeaza iluzia asta cum ca devul stie cel mai bine, deci sa vorbeasca el direct cu clientul, deci de ce sa nu mearga si la companii mari?
Problema intervine cand construiesti un ditai produsul. Nu poti tine evidenta ca dev la fiecare chestie. Un task relativ simplu se poate sparge in o groaza de mini taskuri cu implicari din diferite unghiuri. E treaba BA-ului sa documenteze aceste lucruri, chiar si UX.
Nu poti nici sa ai 30 de devi pe 10 taskuri si sa comunice direct cu clientul. Nu e eficient. Mergi in directia de 9 devi sa faca un copil intr-o luna.
Fiecare domeniu isi are utilitatea lui si tocmai pentru asta a fost inventat. Pentru ca devii sa aiba cerinte cat mai clare si exacte, sa fie constienti de un roadmap.
Ce zici tu e rolul de arhitect, principal developer.
La o companie mare UX-ul e de datoria PO-ului cu designerul si o echipa dedicata care sa realizeze componentele reutilizabile din design system. Din pacate chiar si asa rar va fi ce vei avea nevoie si vor fi necesare schimbari cand se apuca consumer-ul sa implementeze aceste componente.
Din ce inteleg business analyst-ul poate prelua de la PO scrierea de story-uri.
Arhitectul/principal developer-ul( pot fi mai multi, in multe locuri e numit team lead)/managerul pe tot departamentul trebuie sa aiba imaginea de sus din punct de vedere tehnic, un developer cum ai zis nu poate vedea totul din ansamblu.
Probabil ca ai nevoie de acest business analyst unde nu mai exista arhitectul sau a plecat, altfel arhitectul stie ce si cum. El se ocupa de domain model pe backend, nu business analyst-ul.