Aveam o discutie cu buna mea prietena SLVC despre pile cunostinte si relatii
Am afirmat ca pile cunostinte si relatii nu este neaparat un lucru rau si ca afara se foloseste pe scara larga si se numeste “Recomandari”.
I-am promis ca povestesc despre asta intr-un articol mai amplu si iata-l.
Puteti sa il cititi si voi ceilalti, e interesant si e de invatat ceva pentru cei care vreti sa va gasiti un loc de munca.
Retea sociala sau social networking
S-au dezvoltat in randul oamenilor o multime de credinte si prejudecati, iar politicienii se folosesc de aceste lucruri pentru a ne manipula.
Ei stiu sigur ce e mai bine, ce e mai rau si ca nu neaparat unele lucruri sunt rele, ci modul de aplicare al lor este rau probabil, dar lor le convine ca noi sa credem ca totul este rau.
Pe o scara mai larga, mai generala, s-a impamantenit si credinta ca tot ce e bogat este rau si ca e naspa sa fi bogat, ca nu “mai bine sarac si cinstit”.
In sociologie, deci intr-un domeniu ridicat la rang de stiinta se studiaza ceea ce se cheama reteaua sociala a unei persoane.
Aceasta retea sociala este formata din persoanele care te cunosc si persoanele pe care le cunosti.
Avem doua tipuri de retele, retele inchise si retele deschise.
Retelele inchise sunt proaste, retelele deschise sunt bune.
Prin retea inchisa se intelege o retea in care oamenii se cunosc toti intre ei, fiecare cu fiecare.
Reteaua aceasta inchisa este proasta deoarece informatia nu circula decat in interiorul retelei, ea nu razbate afara si, mai grav, nicio informatie de afara nu intra inauntru retelei.
Retelele deschise pe de alta parte sunt bune deoarece ele presupun faptul ca nu cunosti direct pe toti cei din reteaua ta si ca unii din membri retelei tale se cunosc si cu membrii altei retele facilitand astfel comunicarea.
Conceptul de retea sociala este unul foarte larg intrebuintat la multe lucruri.
Cand ne reducem insa la domeniul profesional si la cautarea de munca, reteaua sociala se transforma in ceea ce se numeste
retea profesionala.
Sa nu confundam, nu inseamna ca daca un membru al retelei noastre sociale nu activeaza in domeniu nostru profesional, el nu mai face parte din retea.
Mi s-a intimplat adesea ca un economist sa imi aduca comenzi pe it, deci economistul respectiv face parte din reteaua mea profesionala.
Denumirea de “profesionala” arata mai de graba scopul in care folosim la un moment dat reteaua noastra sociala si nu calitatea membrilor din retea.
De asemenea putem vorbi de retele mici si retele mari.
Evident ca o retea mica este mai proasta decat o retea mare.
La ce este buna o astfel de retea?
Pai sa zicem ca Alina lucreaza la Microsoft, ea afla ca e un post disponibil si stie ca cineva din reteaua ei profesionala cauta un post de acel gen.
Atunci ea, stiind ca acea persoana din retea este un bun profesionist il va suna ii va vinde pontu si eventual va actiona ca o punte intre persoana din retea si angajator.
Presupunem ca persoana din retea e ocupata, dar la randul ei stie pe cineva si atunci il introduce pe acel cineva catre Alina, sau pur si simplu actioneaza la randul lui ca o punte intre cineva si Alina.
Deci identificam urmatoarele functii ale unei retele:
- Accesul la o informatie;
- trasmiterea de informatii;
Pentru ca Alina poate doar sa informeze persoana de existenta jobului, fara sa doreasca sa actioneze in sens invers.
Atunci persoana, informata fiind, se va pregati cu documentatia necesara castigarii jobului si se va prezenta la firma in cauza.
Insa Alina poate sa actioneze si in sens invers, sa ia informatia de la persoana din retea, eventual sa adauge o recomandare proprie scrisa sau verbala si sa prezinte la firma sa candidatura persoanei respective.
De ce poate sa functioneze asa ceva?
Foarte simplu, toti ne dorim sa lucram cu persoanele cele mai bune.
Ca sa stii daca o persoana este buna trebuie sa o cunosti.
Cel mai bine e daca cunosti acea persoana direct.
Dar intre oameni functioneaza si sistemul de incredere.
Eu il cunosc pe cutare, cutare este un profesionist bun, daca el cunoaste pe cineva si il apreciaza ca profesionist inseamna ca si acel tert trebuie sa fie o persoana buna in profesia sa.
Acest lucru se bazeaza pe premisa ca niciun profesionist bun nu ar recomanda pe un non-profesionist deoarece e numele si renumele sau la mijloc.
Pentru ca, daca se descopera ca profesionistul a recomandat un non-profesionist, atunci cel ce a fost nevoit sa accepte recomandarea va degrada pe cel ce a facut recomandarea.
Este absolut normal ca eu, daca am de facut un lucru si am nevoie de ajutor sa apelez la oamenii in care am incredere, sa apelez la cei cu care am mai lucrat si eu consider ca sunt buni, decat sa stau sa caut printre necunoscuti pe unii si altii care ar putea sa fie buni, dar ar putea sa nu fie si sa pierd timp.
Mai mult, sistemul nu lucreaza intodeauna pe principiul calitatii maxime.
Uneori prefer sa lucrez cu unu cu care am mai lucrat, chiar daca nu e cel mai b un, dar il cunosc, stiu ce poate si ce nu poate, stiu cum sa comunic cu el, stiu cum sa ma raportez la el, stiu cum sa il motivez ca sa obtin ce e mai bun de la el.
Si s-ar putea ca acest “ce e cel mai bun de la el” sa fie chiar mai mult decat as fi putut obtine cu unul de maxima performanta, dar cu care abia m-am cunoscut.
Si asta deoarece oamenilor le trebuie timp sa se acomodeze unii cu altii, sa se cunoasca, sa capete incredere unii in altii.
Mai intervine aici un factor si anume celelalte abilitati ale persoanei pe care o luam sa lucram cu ea.
Poate fi un bun profesionist in domeniul lui, dar sa fie un om execrabil in rest si atunci, cu toata performanta lui, nu imi doresc sa lucrez cu asa cineva, mai bine iau doi oameni mai neperformanti in locul celui perofrmant, dar execrabil.
Intodeauna in capitalism, angajarile se fac in aceasta ordine:
- Se cauta printre angajatii existenti daca nu poate fi promovat cineva in postul ramas vacant;
- Daca se gaseste, se promoveaza persoana respectiva, sau se muta, iar postul persoanei in cauza este scos la mezat;
- Pentru postul scos la mezat se cauta printre cunostinte, relatii daca exista vreun doritor si i se vinde pontul;
- Eventual daca sunt mai multi doritori se organizeaza o serie de eliminari pentru a alege pe cel mai bun dintre ei;
- Cu cel ramas se merge mai departe cu interviul;
- Daca s-a ajuns la o intelegere individul este angajat;
- Abia dupa ce nu s-a ajuns la o intelegere cu niciunu din cei care au fost doritori din recomandari, postul se scoate la publicitate in marele public;
- Evident ca daca unii dintre doritori la faza de eliminari s-au dovedit chiar praf, nu vor mai fi chemati;
Uneori publicarea in marele public si lucrul pe recomandari se fac in paralel.
Insa unul venit pe recomandari va fi vazut mai bine decat oricare venit prin publicitatea in marele public, pentru ca acel venit pe recomandari are o garantie in plus.
Daca vi la un astfel de job prin publicitatea din marele public, trebuie sa fi al dracu de bun ca sa poti intra.
Aceasta se intimpla atunci cand mergem la interviu si avem impresia “postul era deja dat si au facut concursul de fente”.
Asta se utilizeaza pe scara larga in afara si se utilizeaza si la noi.
Nimeni nu vede acest lucru ca pe ceva rau.
Recunoasteti mai sus descris cu rang de stiinda sistemul de pile cunostinte si relatii.
Sa desprindem o problema totusi
Sistemul de mai sus, asa cum am afirmat, este unul bun.
Insa modul de al aplica este problema, ca peste tot de altfel.
Problema consta in faptul ca unii recomanda pe oricine, nu conteaza cat de competent sau nu.
Iar ceilalti carora li se recomanda, angajeaza fara niciun test doar pe baza recomandarii.
Mai grav, dupa o luna de lucru in care se prind ca cel recomandat e praf, nu iau nicio masura de a se descotorosi de el.
Asta e problema, nu pile, cunostinte si relatii.
Pentru ca pile cunostinte si relatii e un sistem normal de lucru si de bun simt.
CUm am spus, recomandat ca metoda de lucru in sociologie si in psihologie mai ales pe partea de HR.
p.s. Daca sunteti cuminti va voi prezenta zilele urmatoare si cum sa va imbunatatiti reteaua profesionala
Se afișează postările cu eticheta Management methodologies. Afișați toate postările
Se afișează postările cu eticheta Management methodologies. Afișați toate postările
luni, 23 ianuarie 2012
duminică, 17 aprilie 2011
Reinvenţia apei calde
În viaţa mea de zi cu zi, se întâmplă să fac şi pe dezvoltatorul de software.
V-am reliefat acest aspect pentru a înţelege de unde următoarele gânduri.
Deşi ele au fost descoperite de mine în lumea software developing-ului, le-am scos din context (fără a pierde nimic din înţelesul lor) şi vi le prezint şi vouă.
În episodul de astăzi (pentru că aşa cum v-aţi obişnuit,acesta e un blog al serialelor) vorbim despre reinvenţia apei calde.
Aşa cum bine aţi auzit, reinvenţia apei calde.
Citeam zilele acestea, ca un bun profesionist, diverse materiale în domeniul meu de activitate pentru a vedea cum evoluează lucrurile şi tehnic şi non-tehnic.
O mare pasiune a mea este designul în această lume a software-ului. Problema mea de bază este:
Băi nene, vine unu şi îţi cere un software de făcut facturi, cum îl proiectezi? Care sunt obiectele, care sunt relaţiile între ele, dar dacă vrei ca programul acela să îl extinzi ulterior…
Citind eu aşa, pe lângă faptul că am constatat că lumea asta a materialelor despre software developing, e plină de bla, bla, mai mereu acelaşi, dar lipsită de orice exemplu practic, am ajuns la nişte lucruri care m-au lăsat interzis.
Concluzia, ăia ori sunt nişte oameni mult prea deştepţi, ori sunt proşti bâtă!
Tot încercând să găsesc informaţiile care ma interesau, am extins oleacă aria căutărilor sperând că voi găsi într-un cadru mai larg, probleme specifice tratate.
Am ajuns astfel la o serie de cărţi despre cum să organizezi lucrul efectiv şi corespunzător.
Zic:
„stai să vezi mâncaţiaş că descopăr acum adevăru, o să fiu ăl mai tare din parcare, rup piaţa”.
Găsesc mai întâi metodologia „Getting Things Done” a unui nene, metodologie despre care puteti citi aici:
Getting Things Done
Şi citesc marea descoperire…
După ce citesc constat că făceam asta de mulţi ani de zile, oricum, cu mult înainte de a scrie el cartea şi a deveni „părintele” metodologiei aşa cum acum este recunoscut.
Mă duc mai departe şi găsesc metodologia „pomodoro”… Despre care puteti citi aici:
Pomodoro
Pe asta nu o aplicam, dar citind, constaţi că sunt exprimate nişte lucruri simple, de bun simţ şi că nu este vreo mare invenţie, contrazice pe alocuri metodologia anterioară, dar sigur sunt oameni care se comportau conform cu această metodologie înainte de a fi ea „standardizată”, acum şi nenea acesta este „părintele” a ceva.
Au scris cărţi pe domeniu şi cu fiecare carte scrisă au mai câştigat nişte bănuţi. Bravo lor:
Problema majoră rezidă în faptul că există oameni care acordă valoare acestui fel de „descoperiri”.
Mă uit la o bine cunoscută companie de la noi, cunoscută în domeniu software, cum promovează acest getting things done de parcă ar fi a doua renaştere a lui Iisus, descoperirea secolului, faţă de care Einstein poate să îşi bage în cur nenorocita aia de Teorie a relativităţii, Fleming poate să îşi injecteze singur toată penicilina că oricum de la getting things done în coace nu mai avem nevoie de ea.
Stau şi mă întreb, oamenii respectivi cum au reuşit să trăiască până la getting things done, nu le-a fost greu să respire fără să le spună cineva cum să o facă?
Revenind la un cadru general, e fenomenal cum se dă valoare de invenţie, descoperire, unor făcături.
Pot şi eu să preiau modul meu de viaţă, să îl denumesc Rage Technic şi să îl vând.
Dar pe cuvântul meu dacă nu m-aş simţi penibil, chiar dacă, prin ceea ce fac, dobândesc un succes în viaţa de zi cu zi.
Mai frumos însă devine situaţia când, la un interviu eşti întrebat:
„tu lucrezi conform getting things done? Sau conform Pomodoro”!
Şi tu, ignorant ce eşti, nenorocit împuţit, tu care ştii să faci un soft de bună calitate, fără prea multe reclamaţii de la clienţi la activ, tu stai şi te uiţi ca boul că eminamente ţi s-a futut de tehnicile alea până în momentu respectiv şi habar nu ai despre ce e vorba.
Trist, autoflagelându-te, pleci ruşinat de la interviul respectiv pentru că nu ai ştiut ce sunt două rahaturi evidente.
Din fericire, nu mi s-a întâmplat asta la un interviu, iar de acum voi fi avertizat şi voi răspunde în cunoştinţă de cauză:
„Eu ştiu să lucrez cu Getting The Pomodoro done”.
Exemplul mai sus amintit mi-a venit din altă întâmplare cu o altă metodologie.
De data aceasta, nu despre cum să lucrezi productiv, ci despre cum să construieşti o arhitectură software.
Există şi în acest domeniu metodologii similare Getting things done.
Una din ele, este „domain driven design”.
O serie de tehnici şi metodologii extrase din software Engineering şi publicate sub titulatura aceasta de autorul respectiv că aşa îi s-a părut lui interesant.
Întreaga lume a sărit să adopte „noua” metodologie.
Am fost la multe interviuri şi am pierdut multe interviuri pentru că eram întrebat:
„ştii Domain driven design”, iar eu cinstit, necunoscând termenul, am afirmat că nu cunosc.
După al treilea interviu la care am fost şi am pierdut pe acest rahat, am decis să iau o carte să mă pun la punct.
Şi citesc, primul capitol, al doilea capitol şi îmi zic:
„dar asta ştiu”!
Tot eu:
„e, dar poate aşa e la început, e un fel de introducere”!
Citesc mai departe, iar după fiecare capitol al cărţii remarca:
„dar asta ştiu”!
Apărea din ce îîn ce mai insistent.
Acolo unde nu apărea, era înlocuită de replica:
„dar asta e normal”!
Am ajuns într-un final la sfârşitul cărţii fără să fi învăţat nimic nou, nimic senzaţional, nimic decisiv şi schimbător.
Şi per total fraza:
„dar asta ştiam”!
A fost lait motivul parcurgerii acelui material.
Faza mai tristă e că nenea asta a publicat cartea lui prin 2003, iar eu sunt dezvoltator de prin 1999 şi aplicam ce zice el, fără să mă gândesc ce mare scofală fac eu.
Dacă vreţi o comparaţie e ca şi cum cineva v-ar scrie o carte despre legatul şireturilor la pantofi şi v-ar vinde-o ca pe un exemplu de metodologie evoluţionară, revoluţionară şi de ultim moment.
V-am reliefat acest aspect pentru a înţelege de unde următoarele gânduri.
Deşi ele au fost descoperite de mine în lumea software developing-ului, le-am scos din context (fără a pierde nimic din înţelesul lor) şi vi le prezint şi vouă.
În episodul de astăzi (pentru că aşa cum v-aţi obişnuit,acesta e un blog al serialelor) vorbim despre reinvenţia apei calde.
Aşa cum bine aţi auzit, reinvenţia apei calde.
Citeam zilele acestea, ca un bun profesionist, diverse materiale în domeniul meu de activitate pentru a vedea cum evoluează lucrurile şi tehnic şi non-tehnic.
O mare pasiune a mea este designul în această lume a software-ului. Problema mea de bază este:
Băi nene, vine unu şi îţi cere un software de făcut facturi, cum îl proiectezi? Care sunt obiectele, care sunt relaţiile între ele, dar dacă vrei ca programul acela să îl extinzi ulterior…
Citind eu aşa, pe lângă faptul că am constatat că lumea asta a materialelor despre software developing, e plină de bla, bla, mai mereu acelaşi, dar lipsită de orice exemplu practic, am ajuns la nişte lucruri care m-au lăsat interzis.
Concluzia, ăia ori sunt nişte oameni mult prea deştepţi, ori sunt proşti bâtă!
Tot încercând să găsesc informaţiile care ma interesau, am extins oleacă aria căutărilor sperând că voi găsi într-un cadru mai larg, probleme specifice tratate.
Am ajuns astfel la o serie de cărţi despre cum să organizezi lucrul efectiv şi corespunzător.
Zic:
„stai să vezi mâncaţiaş că descopăr acum adevăru, o să fiu ăl mai tare din parcare, rup piaţa”.
Găsesc mai întâi metodologia „Getting Things Done” a unui nene, metodologie despre care puteti citi aici:
Getting Things Done
Şi citesc marea descoperire…
După ce citesc constat că făceam asta de mulţi ani de zile, oricum, cu mult înainte de a scrie el cartea şi a deveni „părintele” metodologiei aşa cum acum este recunoscut.
Mă duc mai departe şi găsesc metodologia „pomodoro”… Despre care puteti citi aici:
Pomodoro
Pe asta nu o aplicam, dar citind, constaţi că sunt exprimate nişte lucruri simple, de bun simţ şi că nu este vreo mare invenţie, contrazice pe alocuri metodologia anterioară, dar sigur sunt oameni care se comportau conform cu această metodologie înainte de a fi ea „standardizată”, acum şi nenea acesta este „părintele” a ceva.
Au scris cărţi pe domeniu şi cu fiecare carte scrisă au mai câştigat nişte bănuţi. Bravo lor:
Problema majoră rezidă în faptul că există oameni care acordă valoare acestui fel de „descoperiri”.
Mă uit la o bine cunoscută companie de la noi, cunoscută în domeniu software, cum promovează acest getting things done de parcă ar fi a doua renaştere a lui Iisus, descoperirea secolului, faţă de care Einstein poate să îşi bage în cur nenorocita aia de Teorie a relativităţii, Fleming poate să îşi injecteze singur toată penicilina că oricum de la getting things done în coace nu mai avem nevoie de ea.
Stau şi mă întreb, oamenii respectivi cum au reuşit să trăiască până la getting things done, nu le-a fost greu să respire fără să le spună cineva cum să o facă?
Revenind la un cadru general, e fenomenal cum se dă valoare de invenţie, descoperire, unor făcături.
Pot şi eu să preiau modul meu de viaţă, să îl denumesc Rage Technic şi să îl vând.
Dar pe cuvântul meu dacă nu m-aş simţi penibil, chiar dacă, prin ceea ce fac, dobândesc un succes în viaţa de zi cu zi.
Mai frumos însă devine situaţia când, la un interviu eşti întrebat:
„tu lucrezi conform getting things done? Sau conform Pomodoro”!
Şi tu, ignorant ce eşti, nenorocit împuţit, tu care ştii să faci un soft de bună calitate, fără prea multe reclamaţii de la clienţi la activ, tu stai şi te uiţi ca boul că eminamente ţi s-a futut de tehnicile alea până în momentu respectiv şi habar nu ai despre ce e vorba.
Trist, autoflagelându-te, pleci ruşinat de la interviul respectiv pentru că nu ai ştiut ce sunt două rahaturi evidente.
Din fericire, nu mi s-a întâmplat asta la un interviu, iar de acum voi fi avertizat şi voi răspunde în cunoştinţă de cauză:
„Eu ştiu să lucrez cu Getting The Pomodoro done”.
Exemplul mai sus amintit mi-a venit din altă întâmplare cu o altă metodologie.
De data aceasta, nu despre cum să lucrezi productiv, ci despre cum să construieşti o arhitectură software.
Există şi în acest domeniu metodologii similare Getting things done.
Una din ele, este „domain driven design”.
O serie de tehnici şi metodologii extrase din software Engineering şi publicate sub titulatura aceasta de autorul respectiv că aşa îi s-a părut lui interesant.
Întreaga lume a sărit să adopte „noua” metodologie.
Am fost la multe interviuri şi am pierdut multe interviuri pentru că eram întrebat:
„ştii Domain driven design”, iar eu cinstit, necunoscând termenul, am afirmat că nu cunosc.
După al treilea interviu la care am fost şi am pierdut pe acest rahat, am decis să iau o carte să mă pun la punct.
Şi citesc, primul capitol, al doilea capitol şi îmi zic:
„dar asta ştiu”!
Tot eu:
„e, dar poate aşa e la început, e un fel de introducere”!
Citesc mai departe, iar după fiecare capitol al cărţii remarca:
„dar asta ştiu”!
Apărea din ce îîn ce mai insistent.
Acolo unde nu apărea, era înlocuită de replica:
„dar asta e normal”!
Am ajuns într-un final la sfârşitul cărţii fără să fi învăţat nimic nou, nimic senzaţional, nimic decisiv şi schimbător.
Şi per total fraza:
„dar asta ştiam”!
A fost lait motivul parcurgerii acelui material.
Faza mai tristă e că nenea asta a publicat cartea lui prin 2003, iar eu sunt dezvoltator de prin 1999 şi aplicam ce zice el, fără să mă gândesc ce mare scofală fac eu.
Dacă vreţi o comparaţie e ca şi cum cineva v-ar scrie o carte despre legatul şireturilor la pantofi şi v-ar vinde-o ca pe un exemplu de metodologie evoluţionară, revoluţionară şi de ultim moment.
Abonați-vă la:
Postări (Atom)