Dedicat managerilor de proiect (și celor care visează să devină șefi).
Este greu să scrii tone de cod, dar gestionarea oamenilor este și mai dificilă! Așa că aveți nevoie doar de această carte pentru a învăța cum să le faceți pe amândouă.
Este posibil să combinați povești haioase și lecții serioase? Michael Lopp (cunoscut și în cercurile înguste ca Rands) a reușit. Veți găsi povești fictive despre oameni fictivi cu experiențe incredibil de plină de satisfacții (deși fictive). Așa își împărtășește Rands experiențele sale variate, uneori ciudate, dobândite de-a lungul anilor de lucru în mari corporații IT: Apple, Pinterest, Palantir, Netscape, Symantec etc.
Ești manager de proiect? Sau vrei să înțelegi ce face seful tău toată ziua? Rands vă va învăța cum să supraviețuiți în lumea toxică a curcanilor umflați și să prosperați în nebunia generală a oamenilor disfuncțional extravagant. În această comunitate ciudată a creierului maniacal există creaturi și mai ciudate - manageri care, printr-un ritual organizațional mistic, au câștigat putere asupra planurilor, gândurilor și conturilor bancare ale multor oameni.
Această carte este diferită de orice manuscris de management sau leadership. Michael Lopp nu ascunde nimic, doar le spune așa cum este (poate că nu toate poveștile ar trebui făcute publice: P). Dar numai așa vei înțelege cum să supraviețuiești cu un astfel de șef, cum să gestionezi tocilari și tocilari și cum să duci „proiectul ăla nenorocit” la un final fericit!
Extras. Mentalitatea inginerească
Gânduri despre: Ar trebui să continuați să scrieți cod?
Cartea lui Rands despre regulile pentru manageri conține o listă foarte scurtă de „treburile” manageriale moderne. Laconismul acestei liste provine din faptul că conceptul de „trebuie” este un fel de absolut, iar când vine vorba de oameni, există foarte puține concepte absolute. O metodă de management de succes pentru un angajat va fi un adevărat dezastru pentru altul. Acest gând este primul articol din lista de „trebuie” a managerului:
Rămâneți flexibil!
Să te gândești că știi deja totul este o idee foarte proastă. Într-o situație în care singurul fapt constant este că lumea este în continuă schimbare, flexibilitatea devine singura poziție corectă.
În mod paradoxal, al doilea element de pe listă este surprinzător de inflexibil. Cu toate acestea, acest punct este preferatul meu personal, deoarece cred că ajută la crearea bazei creșterii manageriale. Acest paragraf spune:
Nu mai scrie cod!
În teorie, dacă vrei să fii manager, trebuie să înveți să ai încredere în cei care lucrează pentru tine și să le predă în totalitate codificarea. Acest sfat este, de obicei, greu de digerat, mai ales pentru managerii nou bătuți. Probabil că unul dintre motivele pentru care au devenit manageri este din cauza productivității lor în dezvoltare, iar atunci când lucrurile merg prost, prima lor reacție este să recurgă la abilitățile în care au deplină încredere, care este capacitatea lor de a scrie cod.
Când văd că un manager nou creat „se scufundă” în scrierea codului, îi spun: „Știm că poți scrie cod. Întrebarea este: poți conduce? Nu mai ești responsabil doar pentru tine, ești responsabil pentru întreaga echipă; și vreau să mă asigur că poți determina echipa ta să rezolve singur problemele, fără să fii nevoit să scrii singur codul. Treaba ta este să-ți dai seama cum să te scalzi. Nu vreau să fii doar unul, vreau să fie mulți ca tine.”
Un sfat bun, nu? Scară. management. Responsabilitate. Cuvintele la modă atât de comune. Păcat că sfatul este greșit.
Incorect?
Da. Sfatul este greșit! Nu complet greșit, dar suficient de greșit încât a trebuit să sun niște foști colegi și să-mi cer scuze: „Îți amintești afirmația aia preferată despre cum ar trebui să încetezi să scrii cod? E greșit! Da... Începe din nou programarea. Începeți cu Python și Ruby. Da, vorbesc serios! Cariera ta depinde de asta!”
Când mi-am început cariera ca dezvoltator de software la Borland, am lucrat în echipa Paradox Windows, care era o echipă imensă. Au fost doar 13 dezvoltatori de aplicații. Dacă adăugați oameni din alte echipe care au lucrat în mod constant la tehnologii cheie pentru acest proiect, cum ar fi motorul de bază de date de bază și serviciile de aplicație de bază, ați avut 50 de ingineri implicați direct în dezvoltarea acestui produs.
Nicio altă echipă pentru care am lucrat vreodată nu se apropie de această dimensiune. De fapt, cu fiecare an care trece, numărul de oameni din echipa la care lucrez scade treptat. Ce se întâmplă? Devenim noi dezvoltatorii, împreună, din ce în ce mai deștepți? Nu, doar împărțim sarcina.
Ce au făcut dezvoltatorii în ultimii 20 de ani? În acest timp am scris o grămadă de cod. Mare de cod! Am scris atât de mult cod încât am decis că ar fi o idee bună să simplificăm totul și să mergem la sursa deschisă.
Din fericire, datorită internetului, acest proces a devenit acum cât se poate de simplu. Dacă sunteți un dezvoltator de software, îl puteți verifica chiar acum! Căutați numele dvs. pe Google sau Github și veți vedea un cod pe care l-ați uitat de mult, dar pe care îl poate găsi oricine. Înfricoșător, nu? Nu știai că codul trăiește pentru totdeauna? Da, el trăiește pentru totdeauna.
Codul trăiește pentru totdeauna. Și codul bun nu numai că trăiește pentru totdeauna, ci crește pentru că cei care îl prețuiesc în mod constant se asigură că rămâne proaspăt. Această grămadă de cod de înaltă calitate, bine întreținut ajută la reducerea dimensiunii medii a echipei de inginerie, deoarece ne permite să ne concentrăm pe codul existent mai degrabă decât să scriem cod nou și să facem treaba cu mai puțini oameni și într-un interval de timp mai scurt.
Această linie de raționament sună deprimant, dar ideea este că toți suntem doar o grămadă de automate de integrare care folosesc bandă adezivă pentru a conecta diferite bucăți de lucruri existente împreună pentru a crea o versiune ușor diferită a aceluiași lucru. Aceasta este o linie clasică de gândire în rândul directorilor seniori care iubesc externalizarea. „Oricine știe să folosească Google și are bandă adezivă poate face asta! Atunci de ce plătim mulți bani la mașinile noastre?”
Îi plătim acești oameni de la conducere cu bani foarte mari, dar ei cred așa prostii. Încă o dată, punctul meu cheie este că există mulți dezvoltatori geniali și foarte muncitori pe planeta noastră; sunt cu adevărat strălucitori și sârguincioși, deși nu au petrecut niciun minut stând în universități acreditate. O, da, acum sunt din ce în ce mai mulți!
Nu vă sugerez să începeți să vă faceți griji pentru locul dvs. doar pentru că unii camarazi geniali se presupune că îl vânează. Vă sugerez să începeți să vă faceți griji pentru că evoluția dezvoltării software probabil se mișcă mai repede decât dumneavoastră. Lucrezi de zece ani, cinci dintre ei ca manager și te gândești: „Știu deja cum este dezvoltat software-ul”. Da, stii. Pa…
Nu mai scrie cod, dar...
Dacă urmați sfatul meu inițial și nu mai scrieți cod, veți înceta, de asemenea, să mai participați la procesul de creare. Din acest motiv nu folosesc în mod activ externalizarea. Automatele nu creează, ele produc. Procesele bine concepute economisesc o mulțime de bani, dar nu aduc nimic nou în lumea noastră.
Dacă aveți o echipă mică care face multe pentru bani puțini, atunci ideea de a nu mai scrie cod mi se pare o decizie proastă de carieră. Chiar și în companiile monstru cu reglementările, procesele și politicile lor nesfârșite, nu aveți dreptul să uitați cum să dezvoltați singur software. Și dezvoltarea de software este în continuă schimbare. Se schimbă chiar acum. Sub picioarele tale! Chiar în această secundă!
Ai obiecții. A intelege. Sa ascultam.
„Rands, sunt în drum spre scaunul de director! Dacă continui să scriu cod, nimeni nu va crede că pot crește.”
Vreau să vă întreb asta: de când ați fost în scaunul dvs. „Sunt pe cale să fiu CEO!”, ați observat că peisajul dezvoltării software se schimbă, chiar și în cadrul companiei dumneavoastră? Dacă răspunsul tău este da, atunci îți voi pune o altă întrebare: cum anume se schimbă și ce vei face cu aceste schimbări? Dacă ați răspuns „nu” la prima mea întrebare, atunci trebuie să vă mutați pe un alt scaun, pentru că (pariu!) domeniul dezvoltării de software se schimbă chiar în această secundă. Cum vei crește vreodată dacă uiți încet, dar sigur cum să dezvolți software?
Sfatul meu este să nu vă angajați să implementați o mulțime de funcții pentru următorul dvs. produs. Trebuie să luați în mod constant măsuri pentru a fi la curent cu modul în care echipa dvs. creează software. Poți face asta atât ca director, cât și ca vicepreședinte. Altceva?
„Uf, Rands! Dar cineva trebuie să fie arbitru! Cineva trebuie să vadă imaginea de ansamblu. Dacă scriu cod, îmi pierd perspectiva.”
Încă trebuie să fii arbitru, mai trebuie să difuzezi deciziile și tot trebuie să te plimbi prin clădire de patru ori în fiecare luni dimineață cu unul dintre inginerii tăi, pentru a asculta dezvăluirea lui săptămânală „Toți suntem condamnați” pentru 30 de ani. minute. ! Dar dincolo de toate acestea, trebuie să menții o mentalitate inginerească și nu trebuie să fii programator cu normă întreagă pentru a face asta.
Sfaturile mele pentru menținerea unei mentalități inginerești:
- Utilizați mediul de dezvoltare. Aceasta înseamnă că ar trebui să fii familiarizat cu instrumentele echipei tale, inclusiv cu sistemul de construire a codului, controlul versiunilor și limbajul de programare. În consecință, veți deveni competenți în limbajul folosit de echipa dvs. atunci când vorbiți despre dezvoltarea de produse. Acest lucru vă va permite, de asemenea, să continuați să utilizați editorul de text preferat, care funcționează perfect.
- Trebuie să fiți capabil să desenați o diagramă arhitecturală detaliată care să descrie produsul dvs. pe orice suprafață în orice moment. Acum nu mă refer la versiunea simplificată cu trei celule și două săgeți. Trebuie să cunoașteți schema detaliată a produsului. Cel mai dificil. Nu orice diagramă drăguță, ci o diagramă greu de explicat. Ar trebui să fie o hartă potrivită pentru o înțelegere completă a produsului. Se schimbă constant și ar trebui să știi întotdeauna de ce au avut loc anumite schimbări.
- Preia implementarea uneia dintre funcții. Chiar tresar în timp ce scriu asta, deoarece acest punct are o mulțime de pericole ascunse, dar nu sunt sigur că poți realiza punctul #1 și punctul #2 fără a te angaja să implementezi cel puțin o caracteristică. Implementând singur una dintre funcții, nu numai că veți fi implicat activ în procesul de dezvoltare, ci vă va permite și să treceți periodic de la rolul de „Manager responsabil de tot” la rolul de „Om responsabil cu implementarea uneia”. a funcțiilor.” Această atitudine umilă și modestă vă va aminti de importanța deciziilor mici.
- Încă tremur peste tot. Se pare că cineva deja țipă la mine: „Managerul care și-a luat asupra sa implementarea funcției?! (Și sunt de acord cu el!) Da, încă ești managerul, ceea ce înseamnă că ar trebui să fie o mică funcție, bine? Da, mai ai multe de făcut. Dacă pur și simplu nu vă puteți ocupa de implementarea funcției, atunci am câteva sfaturi de rezervă pentru dvs.: remediați unele erori. În acest caz, nu vei simți bucuria creației, dar vei înțelege cum este creat produsul, ceea ce înseamnă că nu vei fi niciodată lăsat fără muncă.
- Scrieți teste unitare. Încă fac asta târziu în ciclul de producție, când oamenii încep să înnebunească. Gândiți-vă la asta ca la o listă de verificare a sănătății pentru produsul dvs. Faceți asta des.
Obiecție din nou?
„Rands, dacă scriu cod, îmi voi încurca echipa. Ei nu vor ști cine sunt: un manager sau un dezvoltator.”
Bine.
Da, am spus: „Bine!” Mă bucur că crezi că îți poți deruta echipa doar înotând în iazul dezvoltator. Este simplu: granițele dintre diferitele roluri în dezvoltarea de software sunt în prezent foarte neclare. Băieții UI fac ceea ce se poate numi, în linii mari, programare JavaScript și CSS. Dezvoltatorii învață din ce în ce mai multe despre designul experienței utilizatorului. Oamenii comunică între ei și învață despre bug-uri, despre furtul codului altor persoane și, de asemenea, despre faptul că nu există niciun motiv întemeiat ca un manager să nu participe la această bacanală masivă, globală, cu polenizare încrucișată a informațiilor.
În plus, vrei să faci parte dintr-o echipă formată din componente ușor de înlocuit? Acest lucru nu va face doar echipa dvs. mai agilă, ci va oferi fiecărui membru al echipei posibilitatea de a vedea produsul și compania dintr-o varietate de perspective. Cum poți ajunge să-l respecti pe Frank, tipul calm care se ocupă de build-uri, mai mult decât după ce ai văzut eleganța simplă a scenariilor de build?
Nu vreau ca echipa ta să devină confuză și haotică. Dimpotrivă, vreau ca echipa ta să comunice mai eficient. Cred că dacă ești implicat în crearea produsului și lucrează la funcții, vei fi mai aproape de echipa ta. Și mai important, veți fi mai aproape de schimbările constante în procesul de dezvoltare a software-ului din cadrul organizației dumneavoastră.
Nu te opri din dezvoltare
Un coleg de-al meu de la Borland m-a atacat verbal odată pentru că o numeam „codificator”.
„Rands, codificatorul este o mașină fără minte! Maimuţă! Codificatorul nu face nimic important decât să scrie linii plictisitoare de cod inutil. Nu sunt un programator, sunt un dezvoltator de software!”
Avea dreptate, ar fi urât sfatul meu inițial pentru noii CEO: „Nu mai scrie cod!” Nu pentru că sugerez că sunt programatori, ci mai mult pentru că sugerez în mod proactiv să înceapă să ignore una dintre cele mai importante părți ale muncii lor: dezvoltarea de software.
Așa că mi-am actualizat sfatul. Dacă vrei să fii un lider bun, poți să nu mai scrii cod, dar...
Fii flexibil. Amintiți-vă ce înseamnă să fii inginer și nu te opri din dezvoltarea software-ului.
Despre autor
Michael Lopp este un dezvoltator de software veteran care încă nu a părăsit Silicon Valley. În ultimii 20 de ani, Michael a lucrat pentru o varietate de companii inovatoare, inclusiv Apple, Netscape, Symantec, Borland, Palantir, Pinterest și a participat, de asemenea, la un startup care a trecut încet în uitare.
În afara serviciului, Michael conduce un blog popular despre tehnologie și management sub pseudonimul Rands, unde discută cu cititorii idei din domeniul managementului, își exprimă îngrijorarea cu privire la nevoia constantă de a ține degetul pe puls și explică că, în ciuda recompense generoase pentru crearea unui produs, succesul tău este posibil doar datorită echipei tale. Blogul poate fi găsit aici .
Michael locuiește cu familia sa în Redwood, California. Întotdeauna găsește timp să meargă cu bicicleta de munte, să joace hochei și să bea vin roșu, deoarece a fi sănătos este mai important decât a fi ocupat.
» Mai multe detalii despre carte gasiti la
»
»
Pentru Khabrozhiteley 20% reducere folosind cupon - Gestionarea oamenilor
La plata versiunii pe hârtie a cărții, o versiune electronică a cărții va fi trimisă prin e-mail.
PS: 7% din prețul cărții va merge la traducerea de noi cărți de calculator, o listă de cărți predate tipografiei .
Sursa: www.habr.com