Opt reguli pentru o producție eficientă de software

De-a lungul carierei mele, am participat la mai multe proiecte software din viața reală și am observat cum se fac lucrurile la toate nivelurile: luarea deciziilor, adoptarea practicilor, team building, recrutarea, distribuirea competențelor etc. Evident, abordările diferite au dat rezultate diferite. . Fiind un tip de persoană orientat spre îmbunătățire, am observat și adunat cele mai eficiente practici și cele mai bune trucuri practice care să mă ajute să mă ridic în muncă.

Învățarea din observație este o modalitate grea și lungă de a o face. Aș fi extrem de bucuros să aleg aceste cunoștințe mai devreme din cărți. Din pacate nu am gasit niciunul pe subiect. Așa că am decis să împărtășesc experiența mea cu alți căutători ai acestui gen de cunoștințe. Sperăm că le va economisi câțiva ani de cercetări personale.

În acest articol, veți afla cum puteți depăși performanța medie a industriei producând produse software robuste și fiabile, care necesită întreținere de 5-10 ori mai puțină. Pot spune fără falsă modestie că în ultimii 10-15 ani, eu (personal, precum și echipele mele) am depășit toate așteptările, lăsând în urmă o urmă de succese. Managerii nu pot fi mai fericiți.

Odată, echipa mea a realizat un proiect important într-un interval de timp incredibil de scurt, pentru care am primit un premiu „Echipă de înaltă performanță” de la conducerea superioară. Toate acestea fără să stăm nopți și weekendul să ne epuizăm. Doar muncă normală.

Vedeți, cunoștințele eficiente despre producția de software în sine sunt o putere. De fapt, este un fel de magie neagră pe care nu mulți oameni o pot înțelege chiar și atunci când este explicată în cuvinte simple. Îl vei primi gratuit. Citiți mai departe dacă doriți să fiți perceput ca un magician al producției de software.

Pentru cine este asta?

Permiteți-mi să fac o declinare importantă, importantă, importantă aici.

Mă adresez celor care au nevoie de un spor de productivitate. Nu totul în viață ține de productivitate. Nu toate proiectele software. Există cazuri când nu ești judecat după performanța ta. Evident, aceste practici nu ar ajuta atunci.

Aceste tehnici vor fi cele mai utile pentru liderii de echipă, arhitecți și managerii de proiect, deși dezvoltatorii de software senior pot beneficia și de ele.

Regula nr. 1: Înțelegeți mentalitatea IT

Industria IT este un amestec de știință, tehnologie, artă și afaceri. Este destul de dificil să navighezi acolo fără a înțelege aceste aspecte la un nivel suficient de bun. Cea mai mare problemă este că industria în sine este destul de complexă; prin urmare, cele mai bune practici sunt și ele complexe. Trebuie să înveți multe și să-ți verifici cunoștințele exersând mult pentru a reuși.

Rata incredibilă de actualizare a tehnologiei o face de două ori dură. Nu mai este nevoie de nimic din ce ai învățat acum zece ani. Deci trebuie să înveți într-un ritm accelerat.

Rezumând toate cele de mai sus, putem spune că succesul în domeniul IT nu se bazează pe aptitudini sau sentimente înnăscute, ci pe exemple practice dure. Niciodată să nu „urmăriți intestinul” și să nu credeți exclusiv pe baza sentimentelor, inclusiv pe ale dvs.

Dacă da, ideea merită luată în considerare. În caz contrar, cere o explicație foarte bună și foarte detaliată cu privire la modul în care alegerea acestei căi face viața echipei tale mai bună. Dacă trece acest test, programați un proiect ușor de demonstrare a conceptelor care să demonstreze experimental că se potrivește în mediul dvs.

Lucrul important de înțeles aici este că nu există soluții corecte și greșite, deoarece există multe modalități de a rezolva problemele software. Cu toate acestea, există înțelegeri bune și proaste ale soluției.

Dacă o persoană poate articula clar ideea în detaliu sau poate crea o legătură din adoptarea acestei soluții cu succesul echipei de a convinge alți membri ai echipei, atunci ne putem baza pe viziunea acestei persoane și ne putem spera în șansa mare de succes.

Regula nr. 2: Nu amestecați metodologiile de producție și dezvoltare software

Producția de software se bazează pe dezvoltarea de software. Cu toate acestea, acești doi au obiective, mentalități și practici complet diferite. Încercarea de a rezolva o problemă dintr-unul din aceste tărâmuri cu metodele din altul produce rezultate ridicole. Este important să înțelegem distincția și să folosim metode adecvate pentru fiecare dintre aceste lumi.

Dezvoltarea software este o combinație de artă și meșteșug. Componenta de artă va fi întotdeauna acolo, indiferent de instrumentele de automatizare și metodologiile de dezvoltare software existente. Prin urmare, rezolvarea sarcinilor de dezvoltare necesită concentrare maximă și protejare de toate celelalte semnale care distrag atenția.

Cea mai bună modalitate de a motiva un dezvoltator cu experiență este de a le prezenta o sarcină în forma sa tehnică pură, excluzând toți factorii umani. Toate cerințele ar trebui să fie, de asemenea, exprimate în limbaj tehnic. Ar trebui să fie ușor de verificat, pentru a le permite să navigheze către obiectiv în timpul fazei de cercetare solo.

Producția de software, în schimb, este mai mult în domeniul administrării afacerilor. Știi de ce are nevoie clientul tău dintr-o parte și știi ce resurse de echipă ai la dispoziție din alta. Așa că acum încercați să vă direcționați eforturile echipei pentru a atinge obiectivul. Între timp, puteți, de asemenea, să estimați viteza de progres și să prezentați un plan bine versat șefului. Abilitățile importante de acolo sunt înțelegerea dorințelor clienților dvs., înțelegerea punctelor forte ale echipei și comunicarea planurilor și programelor formale.

Acestea fiind spuse, aș dori să subliniez faptul că multe roluri în dezvoltarea de software funcționează în ambele lumi - în construirea unei punți între afaceri și tehnologie - cum ar fi liderii de echipă, arhitecții, analiștii și managerii de proiect. Oamenii în aceste roluri ar trebui să poată merge cu ușurință între două planuri ale realității și să înțeleagă când este timpul să vorbim despre afaceri și când este timpul pentru artă.

Regula nr. 3: Utilizați stocarea persistentă ca o extensie a memoriei umane

Memoria umană, deși uimitoare ca capacitate, are limitele ei. Îți amintești lucrurile cu o acuratețe și o durată imprevizibile, iar când uiți, nu există nicio modalitate de a le aminti după bunul plac.

De aceea, folosim stocarea de memorie persistentă pentru a ne deplasa la o viteză previzibilă. Nu este vorba despre documentație formală, cum ar fi manualele utilizatorului, pe care le creați mult timp după fapt și pentru a fi folosite de alte persoane. Este vorba despre utilizarea documentelor ca extensie externă a memoriei în timpul lucrului, care vă ajută să treceți prin procesul de dezvoltare a software-ului.

Vă recomand să vă documentați gândurile și planurile pe parcurs ori de câte ori vă confruntați cu sarcini non-triviale sau sarcini care implică mai mult de o persoană. Încearcă să-l faci cât mai ieftin. Nu creați documente formale cu sigla companiei pe el. Un instrument bun ar fi un wiki al companiei cu spațiul dvs. de proiect în el. Creați pagini dedicate sarcinilor sau problemelor (30 de secunde). Apoi actualizați-o de fiecare dată când aveți o idee sau o discutați cu alții.

Într-o întâlnire, spuneți „stați, lăsați-mă să pun asta jos” și petreceți 10-30 de secunde pentru a o exprima în scris. Scrisul nu ar trebui să fie extins, dar ar trebui să fie complet și coerent, ca și cum ai transfera ideea în întregime pe hârtie. Mai târziu, tu sau oricine altcineva care citește pasajul tău ar trebui să-l înțeleagă la fel de clar pe cât îl înțelegi tu acum. Acest truc economisește mult timp, dar vă permite să vă documentați din mers.

Această tehnică are două scopuri.

În primul rând, vă blochează progresul pe drumul spre succes apăsând-o puternic în piatră. Nu mai există riscuri ca cineva să uite ceva, să reitereze același lucru din nou și din nou sau să renegocieze același lucru care a fost deja negociat.

În al doilea rând, îți limpezești mintea, eliminând problema care te sâcâia. Acum mintea ta este flămândă de următoarea provocare. Ce spor de productivitate!

Acest lucru se aplică pentru orice dimensiune a proiectului sau sarcinii. Pentru cele mai mari, veți avea doar spații mai mari cu o ierarhie de pagini care crește treptat pe măsură ce proiectul dumneavoastră evoluează. Conceptul important aici este să pregătiți un spațiu de documentare și o structură înainte de a vă începe sarcina de a stabili un protocol rapid de descărcare a memoriei!

Pentru cei care preferă analogiile tehnologice, aș compara mintea noastră cu un procesor cu o putere de procesare imensă, dar cu memorie operațională limitată. În esență, te poți gândi la un singur lucru la un moment dat. În această analogie, documentația ta servește ca stocare persistentă, în timp ce mintea ta rezolvă probleme complexe într-o abordare iterativă. La un moment dat, decideți să începeți următoarea iterație, să citiți documentația anterioară și să încărcați starea curentă în memoria operativă, gândindu-vă un timp la asta și actualizați codul și documentația cu noile descoperiri. Pas cu pas până când este complet.

Toate acestea fiind spuse mai sus, nu încurajez oamenii să proceseze o mulțime de sarcini deodată. Dimpotrivă, cu cât aveți mai puține sarcini, cu atât mai bine. Nu multe situații de lucru sunt cu adevărat optimizate pentru oameni, iar multitasking-ul poate fi necesar și trebuie să o gestionați într-un fel. Trucul de mai sus vă ajută să o gestionați mai bine.

Regula nr. 4: Nu mai pierdeți timpul cu estimarea formală a timpului

Nu există două proiecte la fel. Data viitoare când vei face un proiect similar, vei avea clienți diferiți, obiective diferite, o echipă diferită; poate chiar tehnologii diferite. Chiar și folosind instrumente și componente standard, va trebui totuși să le personalizați configurația și arhitectura. Când vă ocupați de proiecte software, rețineți că acestea implică între 50% și 100% lucru personalizat. Acestea necesită cercetări, discuții, gândire, încercări și alte activități extrem de imprevizibile. În practică, este posibil să întâmpinați o diferență enormă în ceea ce pare la suprafață a fi exact același tip de proiect și ceea ce ați făcut înainte. Un nou tip de proiect, prin extensie, este aproape imposibil de estimat cu exactitate.

Dacă este atât de imprevizibil, atunci cum ar trebui managerii de proiect să prezinte un program de proiect și să-l respecte?

Există o metodă formală de a face acest lucru descrisă în literatură; și anume, pentru a împărți întregul proiect în pași mai mici, estimați cât durează fiecare pas și apoi calculați lungimea totală a proiectului combinând lungimea de lucru a pieselor individuale. Există o mulțime de teorie în spatele acestei metode predate în cursurile de MBA.

Din păcate, însă, nicio cantitate de matematică nu o poate salva. Această metodă este notoriu de inexactă, în măsura în care este complet inutilizabilă și nepractică, ca să nu mai vorbim de cât de incredibil de consumatoare de timp este. Nu am văzut niciodată un manager de proiect care să folosească metode formale de calcul fără nicio ajustări, nici măcar printre fanaticii metodologiei. Nici măcar atunci când compania a impus cu strictețe utilizarea unei astfel de metode! De fapt, cei mai performanti manageri folosesc metode alternative complet diferite, așa cum este descris mai jos:

Un bun manager de proiect ia în considerare tipul de proiect, mediul, resursele implicate, tipul de organizație și toate celelalte aspecte de lucru care influențează durata reală a proiectului. Desigur, nimeni nu trebuie să învețe doar din propriile greșeli. Astfel de observații pot fi făcute atât direct, cât și indirect; de exemplu, prin cărți sau prin studierea proiectelor realizate de alți oameni sau chiar prin simpla transmitere a cunoștințelor de la persoană la persoană. Astfel de cunoștințe statistice de nivel superior îmbunătățesc navigarea personală în programul proiectului.

Aș dori să subliniez două consecințe importante ale metodei descrise mai sus.

În primul rând, acuratețea estimărilor se îmbunătățește odată cu experiența. Nu există nici un mod posibil ca o persoană fără experiență, înarmată cu orice metodologie puternică pe care o are, să fie bun la asta. În al doilea rând, chiar și cea mai bună estimare este încă bună doar în termeni statistici. Adică, se poate spune că un anumit proiect poate dura undeva între patru și douăsprezece luni. Presupunând că acest lucru este corect, ar trebui să înțelegem că există o șansă de 50% ca proiectul să se deruleze pe durata medie de opt luni.

Înțelegerea predicției statistice are un efect atât de incredibil. Un manager înțelept ar pune doar o estimare de douăsprezece luni pentru un astfel de proiect și apoi ar uimi pe toată lumea terminând-o devreme. Cu alte cuvinte, nimeni nu s-ar aștepta ca o echipă să urmeze programul proiectului până la o zi.

Sfatul general pentru managerii de proiect și șefii lor ar fi să nu mai piardă timpul cu metodologii formale de estimare a timpului. În schimb, încurajați colectarea de informații statistice despre durata proiectului și partajați aceste informații în întreaga companie. Cunosc companii în care o astfel de abordare a fost implementată la nivel de companie, rezultând o precizie predictivă miraculoasă.

Regula nr. 5: Înțelegeți costul comutării sarcinilor și al jonglarii cu prioritățile

Mintea umană este uimitor de concepută de natură. Chiar dacă este incredibil, are limitările sale. Cu alte cuvinte, este conceput pentru a excela în anumite domenii și într-un anumit tip de sarcină.

Mintea unui dezvoltator este cu siguranță un mare atu în dezvoltarea de software. Ați fi, în calitate de manager de proiect, interesat să îl înțelegeți mai bine și să îl puneți într-o poziție în care are cele mai bune performanțe?

Să o punem în termeni simpli, evitând prea multă teorie. Ține minte, teoria te duce atât de departe înainte de a avea nevoie să înveți din experiență, fie a ta, fie a altora.

Mintea umană are un potențial puternic de rezolvare a problemelor și de generare de idei. Din păcate, nu este întotdeauna posibil să exploatezi acest potențial, în principal pentru că pentru a sprijini generarea de idei, trebuie să păstrezi toate părțile problemei împreună în memoria ta activă în același timp. De aceea rezolvarea problemelor complexe trece printr-o etapă de simplificare când o sarcină este generalizată sau reformulată pentru a decupa piese neimportante și pentru a scădea simultan numărul de elemente păstrate în memorie. Cu alte cuvinte, putem rezolva fie o problemă complexă foarte restrânsă, fie mai multe probleme simple.

Raportul nu este liniar, totuși. Creșterea numărului de lucruri pe care le faci simultan îți afectează drastic abilitățile de rezolvare a problemelor. De aceea, omenirea a folosit întotdeauna și va folosi separarea rolurilor ca o optimizare a vieții. Doi oameni care lucrează separat la două sarcini vor face o descoperire mai rapidă decât dacă ar lucra amândoi la ambele sarcini în același timp.

O altă trăsătură importantă a minții umane este incapacitatea sa de a comuta imediat între sarcini, așa cum o fac computerele. Într-adevăr, nu poți înceta să te gândești la ceva după bunul plac. Nici nu poți începe imediat să te gândești la un nou concept la viteza maximă. Acest tip de inerție mentală este perfect ilustrată de operatorii de control al traficului aerian. Chiar dacă se uită la radar și văd întreaga imagine, totuși trebuie să-l încarce în memoria lor pentru a funcționa rapid. Este nevoie de zece minute pentru ca un nou operator să urmărească ecranul înainte de a-l putea înlocui pe cel vechi la o schimbare de tură.

Ceea ce face mai rău este că nu putem uita lucrurile după bunul plac. Tot ceea ce am învățat rămâne cu noi și se estompează treptat cu timpul, ocupând spațiu pe care l-am putea folosi pentru noi cunoștințe. Și chiar mai rău, acest efect este agravat uneori de un sentiment de „afacere neterminată”. Este mult mai ușor să uiți ceva care este finalizat și de care nu vei avea nevoie niciodată în viitor. În timp ce, atunci când lași lucrurile deoparte pentru a le termina mai târziu, creierul tău se prinde în mod natural de informațiile marcate ca „pentru referințe viitoare”, nedorind să lase noile cunoștințe să le ia locul.

Bine. Acum că am subliniat ideea de a schimba sarcinile, să vedem cum funcționează într-un experiment de gândire din viața reală (ca să spunem așa).

Imaginați-vă că aveți zece dezvoltatori obișnuiți care lucrează la zece sarcini obișnuite - o sarcină per persoană. Presupunând că le putem include într-un mediu perfect fără distragere a atenției, fiecare sarcină poate fi rezolvată într-o anumită perioadă de timp de o singură minte. Întregul lucru va dura atât timp cât este nevoie pentru a finaliza cea mai lungă sarcină.

Acum, să repetăm ​​același experiment mental. De data aceasta, vom schimba constant sarcinile între dezvoltatori fără niciun motiv (important). În fiecare zi, fiecare dezvoltator primește o nouă sarcină la care să lucreze. Și mai bine, hai să-l schimbăm în fiecare oră. Cât de curând vor termina, crezi? Poate niciodată.

Managerul de proiect din primul scenariu a fost capabil să execute proiectul în mod eficient. Al doilea a reușit să-l „execută”, asta e sigur… în sensul că i-au facilitat moartea. Felicitări. Această tehnică de ucidere a proiectelor este foarte eficientă deoarece, pe lângă simpla pierdere de timp, scade și moralul angajaților la zero.

Majoritatea oamenilor ar fi de acord cu exemplul de mai sus atunci când le este prezentat într-un mod pur academic ca acesta. Cu toate acestea, în viața reală, ei uită brusc totul sub cea mai mică presiune. Marele șef cere un raport de progres sau clientul întreabă despre o anumită dată de implementare a caracteristicilor - aproape orice eveniment extern poate determina un manager de proiect să se grăbească la echipă și să-și exprime îngrijorarea, urmată de o serie de reatribuții de sarcini și jonglarea priorităților într-un încercarea de a câștiga puțin timp ici și acolo, rezultând în cele din urmă în nimic altceva decât să arunce proiectul de pe pistă și mai mult.

Acesta este un scenariu din viața reală care apare destul de des, din păcate.

Un manager bun se ridică și protejează echipa de astfel de tulburări minore, absorbind valul de șoc emoțional și transformându-l în subiecte de discuții viitoare productive. Este cu siguranță greu din punct de vedere emoțional, dar este singura modalitate de a menține echipa într-un ritm bun de lucru și de a-i lăsa să facă față.

Regula nr. 6: Utilizați revizuirile de arhitectură ca o modalitate de a îmbunătăți proiectarea sistemului

Industria IT operează cu noțiuni de supra- și sub -inginerie. Când apare într-un interviu, toată lumea spune că suprainginerirea este rea. Acesta este ușor de răspuns, deoarece întrebarea în sine transmite o conotație negativă de „peste”, care înseamnă „prea mult”. Cunoștințele practice adevărate ar fi să recunoașteți când arhitectura dvs. devine excesivă și să o evitați în stadii incipiente.

Permiteți-mi să vă ofer câteva dintre indicațiile mele încercate și adevărate despre asta.

În primul rând, soluția poate fi considerată supraproiectată dacă există o altă soluție mai simplă care oferă toate funcționalitățile necesare. Asta înseamnă că dacă nu cunoști o soluție mai simplă, atunci orice soluție cea mai simplă pe care o poți oferi este cea mai bună în ochii tăi, cu excepția cazului în care cineva dovedește că te înșeli.

Dacă arhitectul nostru imaginar se străduiește cu adevărat pentru perfecțiunea soluției, revizuirea obișnuită a arhitecturii garantează că este suficient de optimă. Din păcate, revizuirea arhitecturii necesită cel puțin alți câțiva arhitecți calificați. Există pericolul de a fi indisponibil sau nepractic în multe cazuri. În absența evaluării inter pares, arhitecții sunt predispuși la greșeli comune. Să le revizuim unul câte unul și să discutăm posibilele remedii pentru fiecare.

Una dintre cele mai populare greșeli este proiectarea fără un scop de afaceri în minte. Pare evident că orice activitate de muncă ar trebui să fie legată de satisfacția consumatorului final sau de succesul companiei sau de o nevoie similară de afaceri. Cu toate acestea, adesea, puteți vedea arhitectura proiectată în întregime sau parțial fără un astfel de scop în minte. Raționamentul fie este absent, fie se rezumă la utilizarea a cât mai multe clopote și fluiere moderne.

Arhitectul în acest caz nu face ceea ce a plătit consumatorul. Mai degrabă, se joacă cu jucării grozave pentru propria lor distracție și plăcere. Acest lucru nu este în niciun caz acceptabil în industria formală. Și totuși, oricum pare să se întâmple destul de des.

Uneori, problema constă în personalitatea arhitectului și în obsesia acestuia pentru anumite tehnologii sau instrumente. Le place doar să le folosească și nu pot explica în mod coerent ce nevoie de afaceri încearcă să rezolve. Aproape de acesta este un alt caz în care oamenii nu știu nimic în afară de a construi ceva din bucăți mici. Cu siguranță, orice eveniment extern le declanșează impulsul de a se scufunda în lumea designului și de a nu se întoarce niciodată la un client real. Chiar dacă declanșatorul inițial poate fi o contribuție validă de afaceri, detașarea lor prelungită de realitate diminuează utilitatea operei lor de artă.

Tratamentul pentru aceasta este foarte simplu, dar necesită autodisciplină. Un arhitect bun nu ar trebui să se atingă niciodată de pix și hârtie până când nu își poate răspunde clar și sincer de ce este nevoie. O astfel de nevoie poate veni sub diferite forme. Ar putea fi o cerință formală, o nevoie implicită de îmbunătățire a produsului sau apariția de noi tehnologii care fac designul anterior mai puțin eficient. În orice caz, nu ar trebui să fie un declanșator formal atâta timp cât arhitecții înșiși înțeleg forța motrice. Apoi pot folosi această forță ca o verificare finală a calității designului lor.

O altă problemă mai greu detectabilă este legată de gândirea arhitecturii bloc. Oamenii cu o astfel de mentalitate cred că există o soluție pentru orice și soluția respectivă este întotdeauna implementată ca un bloc de construcție. Cu alte cuvinte, ele traduc funcționalitatea în componente direct, fără a evalua arhitectura în ansamblu. Ei pot atașa doar o componentă care furnizează funcționalitatea dorită sistemului atunci când apare necesitatea unei astfel de funcționalități. De cele mai multe ori, aceasta satisface cerințe formale, dar lasă sistemul într-o stare incoerentă. Noul bloc nu a fost selectat pe baza compatibilității sistemelor existente pentru dezvoltare, suport sau chiar modelul de licențiere al companiei. Deci, echipa încearcă să modifice configurația existentă sau să implementeze această funcționalitate prin capacitatea sistemului existent. Ca urmare, suportul și întreținerea sistemului se transformă treptat într-un coșmar complicat, urmat îndeaproape de degradarea performanței.

Nu există o soluție simplă pentru această problemă, deoarece proiectarea sistemului este o artă și nu este niciodată posibil să se prezică dacă o nouă componentă trebuie adăugată sau poate fi evitată. Cea mai bună practică ar fi probabil să păstrați un stoc de întreținere și probleme de arhitectură care se acumulează în timp, urmat de revizuiri periodice ale arhitecturii globale a sistemului. Această revizuire periodică poate lua în considerare și tehnologiile apărute. Deci, scopul general al revizuirilor de arhitectură nu ar trebui să fie acela de a remedia problemele, ci de a evalua viabilitatea potențială a îmbunătățirilor dorite și a sistemului în ansamblu față de inevitabilitatea învechită.

Regula nr. 7: Valorificați jucătorii echipei

Majoritatea profesioniștilor din industria IT au fost întrebați într-un interviu dacă sunt buni jucători de echipă sau dacă lucrează bine într-o echipă. Cu toate acestea, probabil că nimeni nu a văzut vreodată o definiție clară pentru aceasta în literatură. Evident, o astfel de persoană ar contribui la succesul echipei în general, dar puțini oameni pot defini efectiv calități personale distinctive care asigură un astfel de succes.

Am observat mulți oameni care lucrează la diferite niveluri și am văzut cum calitățile lor personale au influențat progresul proiectului. Aș dori să prezint următoarele indicații cu privire la calitățile personale care sunt cele mai utile în munca în echipă.

Comunicarea

Prima și cea mai importantă calitate, desigur, este capacitatea de a comunica.

Imaginați-vă o persoană cu zero abilități de comunicare. Cu siguranță că nu primiți feedback de la membrii echipei îi face complet inutili. Acest lucru este atât de evident încât nimeni nu măsoară de fapt această abilitate în timpul interviului, ceea ce înseamnă că abilitate este la un nivel suficient de bun atâta timp cât persoana poate vorbi bine.

Comunicarea nu este o abilitate binară da/nu; este mai mult o fereastră de transfer de informații. Cu cât este mai larg, cu atât schimbul de informații este mai rapid și mai clar.

Deoarece intervalul de deschidere a ferestrei respective variază foarte mult de la populație, măsura lățimii unei astfel de ferestre este o caracteristică importantă a unui jucător de echipă. Rețineți că vorbim despre transmiterea de informații în acest context, dar nu despre vorbirea lină sau încurajarea oamenilor sau motivarea sau organizarea lor prin vorbire și comunicare.

Stilul de comunicare este, de asemenea, irelevant. Informațiile pot fi furnizate oral, textual, în imagini sau într-un mod mixt. Persoana poate vorbi repede sau încet. Pot fi prietenoși, cum ar fi să îți privească în ochi și să zâmbească tot timpul, sau pot privi în altă parte și vorbesc cu o voce monotonă. Stilul vă poate afecta percepția personală despre colegul dvs. de serviciu, dar atâta timp cât înțelegeți clar ce înseamnă, orice stil este suficient.

Să trecem la cazuri practice privind detectarea și măsurarea abilităților de comunicare.

Există două aspecte majore ale abilităților de comunicare în general. În primul rând, este dorința de a împărtăși informații. Unii oameni sunt dornici să împărtășească, dar alții încearcă să ascundă informații. Această înclinație este mai mult sau mai puțin naturală, dar poate fi schimbată încet cu automotivare și antrenament. Este sigur să presupunem că persoana care afișează un fel de dorință de împărtășire a informațiilor o va demonstra și în viitor. De aceea, această trăsătură este bună pentru a prezice succesul viitor al unui candidat într-o echipă.

În viața reală, oamenii care încearcă să ascundă informații sunt ușor de observat. De obicei, ei încearcă să ofere informații intenționate inutile, în loc de orice lucru de care are nevoie. Sau, pun întrebări preliminare pentru a îndrepta fluxul de informații spre interior și pentru a minimiza răspunsurile lor la o apariție de „trebuie de știut”. Oricare ar fi tactica lor, vei simți în cele din urmă că nu ai obținut de la ei informațiile dorite sau că obținerea informațiilor a necesitat prea mult efort suplimentar.

Este important să înțelegeți intenția, deoarece unele tipuri de persoane deschise vă pot pune întrebări preliminare pentru a vă înțelege mai bine întrebarea și apoi vă pot oferi răspunsul în cel mai convenabil mod. Persoana care intenționează să ascundă informațiile va pune întrebări suplimentare doar pentru a îndepărta conversația și nu va răspunde niciodată la întrebarea dvs. inițială.

O altă parte a abilității de comunicare este abilitatea de a se acorda la ascultător.

Oameni diferiți au un nivel diferit de înțelegere a subiectului, un stil de comunicare diferit și poate chiar un interes diferit pentru detalii specifice. Unii oameni inteligenți comunicativi și-ar varia fluxul de conversație în funcție de capacitatea ascultătorului de a-l înțelege și de a-și pregăti răspunsul pentru a furniza informații specifice. În o astfel de pregătire, pot fi adresate câteva întrebări preliminare pentru a reduce interesul ascultătorului. Abilitatea de a „elabora” diferențele de comunicare este o abilitate cu adevărat mare, deoarece ne permite să obținem înțelegere în aproape toate cazurile. Vorbitorii flexibili, pe de altă parte, pot fi uneori blocați în fundături de nerezolvat ale neînțelegerii.

Înțelegerea punctelor forte și a punctelor slabe

Să ne concentrăm pe o altă calitate personală esențială pentru un jucător de echipă.

Majoritatea oamenilor ar fi de acord că un mediu de echipă ar trebui să fie mai prietenos decât lumea înconjurătoare medie pentru a stimula colaborarea și a crește productivitatea. Prin urmare, este important ca o echipă să înțeleagă punctele tari și slabe ale fiecărui membru pentru a distribui sarcinile în mod corespunzător și pentru a acoperi punctele slabe cu puncte forte. Primul pas pe această cale este ca toți membrii să își măsoare onest abilitățile unul față de celălalt. Din punct de vedere psihologic, acest lucru poate fi greu, deoarece avem tendința de a ne ascunde punctele slabe față de ceilalți, protejându-ne pe noi înșine.

Aici atmosfera prietenoasă de echipă vine în ajutor.

Deci noul membru este de așteptat să joace după regulile echipei. Din păcate, unii oameni nu își pot coborî garda chiar și într-un mediu prietenos. Ei se comportă ca niște lupi singuratici pe tot parcursul vieții. Acesta este mai puternic decât ei. Din păcate, o astfel de atitudine nu contribuie la eforturile echipei.

Există o tehnică ușoară de a recunoaște astfel de lupi singuratici la interviu. Ei nu admit niciodată că nu știu ceva. Desigur, oamenilor le place să arate tot ce au mai bun, arătându-și toate abilitățile și încercând să rezolve fiecare problemă grea. Cu toate acestea, există o limită de cunoștințe pentru toată lumea. Limitele noastre ne modelează abilitățile. Neadmiterea limitelor înseamnă că candidații se prezintă ca un om de treabă, la fel de buni la toate și la nimic.

Când angajați un specialist, probabil că ați dori să evitați astfel de oameni. În plus, această atitudine arogantă vine adesea cu o altă trăsătură de tip steag roșu: lipsa de dorință de a cere ajutor. Abilitatea de a cere ajutor este absolut esențială pentru munca în echipă. Fără el, nu putem progresa și dezvolta la fel de repede. O persoană atât de încăpățânată ar arde resursele și timpul companiei, luptând la nesfârșit cu sarcini dificile, dar nu apelând niciodată la ajutor colegilor de echipă. Există un truc ușor de a detecta astfel de candidați la interviu. Pune-le o întrebare care nu are sens sau menționează un termen prostesc. O persoană normală, ideal curioasă ar spune doar că nu știe și ar întreba ce este. O persoană defensivă nu ar face asta niciodată, chiar dacă evidențiați că nu există un răspuns corect sau greșit și că „nu știu” nu o descalifică.

Regula nr. 8: Concentrează-te pe organizarea muncii în echipă

Există la fel de puține informații despre organizarea muncii în echipă ca despre orice subiect anterior de mai sus. Toată lumea știe că munca în echipă este mai bună, dar cum să construiți și să mențineți o echipă rămâne un mister. Cu toate acestea, chiar dacă este imposibil să acoperim toate aspectele de team building, putem explora cel puțin câteva tehnici cheie de team building aici.

Expertiza in constructii

Fiecare proiect IT este unic. Pentru a avea succes în ea, trebuie să înveți și să stăpânești specificul proiectului. Acestea pot include atât cunoștințe tehnice, cât și non-tehnice. Un exemplu de cunoștințe non-tehnice ar putea fi o rețea personală pentru management, clienți, echipe de asistență tehnică etc. Cunoștințele tehnice speciale sunt detalii suplimentare pe lângă abilitățile generale IT.

De exemplu, poate fi necesar să-l cunoașteți pe Maven pentru a construi un proiect. Cu toate acestea, structura exactă a construcției, locația proprietăților și filtrarea vor varia în continuare în funcție de proiect. Ca și în cazul oricărui tip de cunoaștere, stăpânirea unor astfel de detalii necesită timp; cu cât se investește mai mult timp în ea, cu atât pot performa mai bine. Timpul este cea mai valoroasă resursă pe care o ai. Vrei să-ți menții membrul echipei concentrat pe aceeași zonă funcțională cât mai mult timp pentru a-și valorifica expertiza și a-l dezvolta și mai mult, îmbunătățind astfel constant performanța echipei.

Din păcate, nu este posibil să o faci la infinit. Dintr-o parte, oamenii se pot plictisi. Pe de altă parte, riscați să vă pierdeți expertiza, punându-vă în mod neașteptat proiectul în pericol.

Să vedem dacă există modalități de a face față dezavantajelor fără a împiedica mult performanța echipei.

Distribuiți zonele de interes între membrii echipei și lăsați-i să-și dezvolte expertiza în ele. La un moment dat, ei ating un nivel suficient de înalt care are sens în domeniul de aplicare al acestui proiect. Efortul suplimentar de învățare nu îl va îmbunătăți semnificativ în acest moment. Fără motivație și provocare, oamenii inteligenți se plictisesc și încep să-și urască meseria.

Preveniți acest lucru deschizând posibilități de învățare în altă parte pentru ei. Ține-i la curent cu proiectele și stiva tehnologică a companiei și deschide-i noi provocări. Dacă interesul lor se află în sfera de aplicare a proiectului, veți obține dubla recompensă de a vă menține echipa provocată și de a extinde în același timp seturile de abilități utile ale echipei. However, any self development is good to avoid boredom, even if it doesn't intersect with immediate project needs. As long as the team expert brains are engaged, they keep supporting already-learned project areas in the back of their minds.

When leaving the company, team experts take a big portion of expertise with them. One of the countermeasures you can use is to widely disseminate documentation that can be updated on the fly. Think of the “persistent memory storage” mentioned earlier.

Still, a project manager would love to duplicate knowledge in team member heads if possible. Having two of every expert would be a simple solution for that, albeit twice as expensive. But there is a leaner way to do it. The trick is to let most of your developers develop expertise in multiple areas, so that each project aspect is covered by at least one deep expert. At the same time, chose a few senior members to grow the breadth along with the depth of their expertise. Usually, this role is best played by a team development lead or an architect. The team lead interacts with all team members and participates in all task implementations. They can tap into each and every aspect of the project, understanding all of its internals. This way, even if you lose one of the experts, the leader can take over and keep on the project progressing until you can hire and train the replacement.

Another flavor of same idea is to cross-train developers in adjacent areas, letting them to observe, learn, and occasionally try their peers' work. Keep in mind that this cross-training needn't be extensive, so it doesn't disrupt focus on developers' primary tasks and doesn't impede productivity. Developing expertise across leadership and cross-training developers builds you a cushion of protection against unforeseen life culprits and allow you some time to maneuver with project resources.

Minimizing Distraction

Software development is a chain of complex and creative problem solving. Even though, with industry development, these complex problems get more and more automated, the work doesn't become easier. It still involves a large amount of art and individual insight, which is very hard to predict and sometimes even harder to wrangle.

Developers are the edge of the weapon. Their concentration is equivalent to the hardness of the weapon's tip. Increase their focus and you'll cut through problems like a hot knife through butter. Distract them and you'll end up clumsily poking at the butter with a blunted stick.

This cannot be over emphasized: Non-problem-solving work can be intensified with motivation or extra effort. For problem solving work, you need maximum detachment from the mundane world. It is difficult to leave all everyday problems behind, and a good project manager should build a quiet development environment in both the physical and mental senses. A developer's workplace should be analogous to a sensory deprivation tank.

Physically, this is implemented as a closed work space. Every team member should have a cube at least where they can dive into solitude. It is preferable to avoid loud noises and aisle conversations. Quick interpersonal communications should be maintained by emails and chats. Large groups should use closed rooms for their meetings to not distract others. This is a pretty standard picture for office life as it used to be.

Unfortunately, the open space paradigm is being adopted more and more widely even in large offices. I would warn against his fad. Even worse, together with open spaces, top management encourages in-place team conversations. That is, in essence, shouting to a person in another row over an uninvolved team member's head. A developer that is interrupted by loud conversation twenty times a day won't have a shred of concentration left. Certainly a major performance killer.

Allowing for a Learning Curve

Knowledge itself is power. This is especially true for such a complex industry as IT. Every task here has its regular cycle: learn, research, implement. The learning phase in particular is invaluable. Not only does better understanding allow better and faster implementation, there are certain knowledge thresholds that must be passed in order to achieve something at all. Of course, there is no point in over-learning either. Each skill should match the production need and not much above it.

However, often, developers are pressured in the opposite direction; to stop learning and to do nothing but produce. Learning is perceived as wasted effort, as it doesn't move the task progress bar. This seems like a really easy problem to solve, sitting at home and reading this article. Yet in the real life, the slightest work pressure turns every manager into that demanding idiot who insists that everybody “stop learning and start doing something already.” I swear, I have heard those exact words so many times throughout my career… A good manager and team leader should understand that learning is an important part of the process even if it doesn't directly increment the progress bar.

Building a Competitive Development Workshop

The tips and tricks presented above are a subset of effective software production expertise. By understanding and applying them in real life, you'll improve your production effectiveness little by little. If you think they are largely unconnected and lacking a theoretical base, you are absolutely right.

I would like to highlight that building a competitive development workshop is not a single-discipline task. It requires knowledge and expertise in multiple adjacent areas. Building such expertise is a hard work. There is no single theoretical base or idea that would solve all your problems at once. Believing in such a silver bullet just serves to distract you from the real goal.

Try out these tips at work to see if they are worth adopting permanently. If you find them useful (or not), leave a comment below and share your experience!