Dedicat als gestors de projectes (i als que somien amb convertir-se en caps).
Escriure tones de codi és difícil, però gestionar persones és encara més difícil! Així que només necessites aquest llibre per aprendre a fer les dues coses.
És possible combinar històries divertides i lliçons serioses? Michael Lopp (també conegut en cercles estrets com Rands) ho va aconseguir. Trobareu històries de ficció sobre persones de ficció amb experiències increïblement gratificants (encara que de ficció). Així és com Rands comparteix les seves experiències variades, de vegades estranyes, adquirides al llarg dels anys de treball en grans corporacions de TI: Apple, Pinterest, Palantir, Netscape, Symantec, etc.
Ets gestor de projectes? O vols entendre què fa el teu maleït cap tot el dia? Rands t'ensenyarà a sobreviure al món tòxic dels galls dindis inflats i a prosperar en la bogeria general de persones extravagants disfuncionalment. En aquesta estranya comunitat de maníacs intel·lectuals hi ha criatures encara més estranyes: gestors que, mitjançant un ritual organitzatiu místic, han aconseguit poder sobre els plans, pensaments i comptes bancaris de moltes persones.
Aquest llibre és diferent a qualsevol manuscrit de gestió o lideratge. Michael Lopp no amaga res, només ho explica tal com és (potser no s'han de fer públiques totes les històries: P). Però només d'aquesta manera entendràs com sobreviure amb un cap així, com gestionar frikis i nerds i com portar "aquest maleït projecte" a un final feliç!
Fragment. Mentalitat d'enginyeria
Pensaments sobre: hauríeu de continuar escrivint codi?
El llibre de Rands sobre regles per a directius conté una llista molt breu de "imprescindibles" de gestió moderna. El laconisme d'aquesta llista prové del fet que el concepte "deu" és una mena d'absolut, i quan es tracta de persones, hi ha molt pocs conceptes absoluts. Un mètode de gestió reeixit per a un empleat serà un veritable desastre per a un altre. Aquest pensament és el primer ítem de la llista de coses obligades del gestor:
Sigues flexible!
Pensar que ja ho saps tot és molt mala idea. En una situació on l'únic fet constant és que el món canvia constantment, la flexibilitat es converteix en l'única posició correcta.
Paradoxalment, el segon element de la llista és sorprenentment inflexible. Tanmateix, aquest punt és el meu favorit perquè crec que ajuda a crear les bases per al creixement directiu. Aquest paràgraf diu:
Deixa d'escriure codi!
En teoria, si vols ser gerent, has d'aprendre a confiar en els qui treballen per a tu i entregar-los completament la codificació. Aquests consells solen ser difícils de digerir, especialment per als directius de nova creació. Probablement una de les raons per les quals es van convertir en directius és per la seva productivitat en el desenvolupament, i quan les coses van malament, la seva primera reacció és recórrer a les habilitats en les quals tenen plena confiança, que és la seva capacitat per escriure codi.
Quan veig que un gestor acabat d'encunyar "s'enfonsa" en escriure codi, li dic: "Sabem que pots escriure codi. La pregunta és: pots liderar? Ja no ets responsable de tu mateix, ets responsable de tot l'equip; i vull assegurar-me que podeu aconseguir que el vostre equip resolgui els problemes pel seu compte, sense que hàgiu d'escriure el codi vosaltres mateixos. La teva feina és esbrinar com escalar-te. No vull que siguis només un, vull que hi hagi molts com tu”.
Bon consell, oi? Escala. Gestió. Responsabilitat. Paraules de moda tan comunes. És una llàstima que el consell sigui equivocat.
Incorrecte?
Sí. El consell és incorrecte! No del tot equivocat, però prou equivocat que vaig haver de trucar a alguns antics col·legues i demanar disculpes: "Recordeu la meva declaració preferida sobre com heu de deixar d'escriure codi? Està malament! Sí... Torna a començar a programar. Comenceu amb Python i Ruby. Sí, ho dic seriosament! La teva carrera depèn d'això!"
Quan vaig començar la meva carrera com a desenvolupador de programari a Borland, vaig treballar a l'equip de Paradox Windows, que era un equip enorme. Només hi havia 13 desenvolupadors d'aplicacions. Si afegiu persones d'altres equips que també treballaven constantment en tecnologies clau per a aquest projecte, com ara el motor de base de dades bàsic i els serveis d'aplicacions bàsics, teniu 50 enginyers directament implicats en el desenvolupament d'aquest producte.
Cap altre equip amb el qual he treballat mai s'acosta a aquesta mida. De fet, cada any que passa, el nombre de persones de l'equip en el qual treballo va disminuint progressivament. Què està passant? Som els desenvolupadors col·lectivament cada cop més intel·ligents? No, només estem compartint la càrrega.
Què han estat fent els desenvolupadors durant els últims 20 anys? Durant aquest temps vam escriure un munt de codi. Mar de codi! Vam escriure tant de codi que vam decidir que seria una bona idea simplificar-ho tot i anar de codi obert.
Afortunadament, gràcies a Internet, aquest procés s'ha tornat el més senzill possible. Si sou un desenvolupador de programari, podeu comprovar-ho ara mateix! Cerqueu el vostre nom a Google o Github i veureu un codi que fa temps que heu oblidat, però que qualsevol pot trobar. Por, oi? No sabíeu que el codi viu per sempre? Sí, viu per sempre.
El codi viu per sempre. I el bon codi no només viu per sempre, sinó que creix perquè els qui el valoren constantment asseguren que es mantingui fresc. Aquest munt de codi d'alta qualitat i ben mantingut ajuda a reduir la mida mitjana de l'equip d'enginyeria perquè ens permet centrar-nos en el codi existent en lloc d'escriure codi nou i fer la feina amb menys persones i en un període de temps més curt.
Aquesta línia de raonament sona depriment, però la idea és que tots som només un munt d'autòmats d'integració que utilitzen cinta adhesiva per connectar diferents trossos de coses existents junts per crear una versió lleugerament diferent del mateix. Aquesta és una línia de pensament clàssica entre els alts executius que estimen la subcontractació. "Qualsevol persona que sàpiga utilitzar Google i tingui una mica de cinta adhesiva pot fer-ho! Aleshores, per què estem pagant molts diners a les nostres màquines?"
Paguem molts diners a aquests nois de la direcció, però pensen una tonteria. Una vegada més, el meu punt clau és que hi ha molts desenvolupadors brillants i molt treballadors al nostre planeta; són realment brillants i diligents, tot i que no han passat ni un minut asseguts a universitats acreditades. Ah sí, ara n'hi ha més i més!
No suggereixo que comencis a preocupar-te pel teu lloc només perquè presumptament alguns companys brillants el busquen. Us suggereixo que us comenceu a preocupar perquè l'evolució del desenvolupament de programari probablement s'està movent més ràpid que vosaltres. Fa deu anys que treballes, cinc d'ells com a gerent, i penses: “Ja sé com es desenvolupa el programari”. Sí, ja ho saps. Adéu…
Deixa d'escriure codi, però...
Si seguiu el meu consell original i deixeu d'escriure codi, també deixareu de participar voluntàriament en el procés de creació. És per aquest motiu que no faig servir activament l'externalització. Els autòmats no creen, produeixen. Els processos ben dissenyats estalvien molts diners, però no aporten res de nou al nostre món.
Si teniu un equip petit que fa molt per pocs diners, la idea de deixar d'escriure codi em sembla una mala decisió professional. Fins i tot a les empreses monstruoses amb les seves interminables regulacions, processos i polítiques, no teniu dret a oblidar-vos de com desenvolupar programari. I el desenvolupament de programari està en constant canvi. Està canviant ara mateix. Sota els teus peus! En aquest mateix segon!
Tens objeccions. Entendre. Escoltem.
“Rands, vaig camí cap a la cadira del director! Si segueixo escrivint codi, ningú creurà que puc créixer".
Vull preguntar-vos això: des que vau seure a la vostra càtedra "Estic a punt de ser CEO!", us heu adonat que el panorama del desenvolupament de programari està canviant, fins i tot dins de la vostra empresa? Si la teva resposta és afirmativa, et faré una altra pregunta: com està canviant exactament i què faràs amb aquests canvis? Si heu respost "no" a la meva primera pregunta, haureu de passar a una altra cadira, perquè (aposto!) el camp del desenvolupament de programari està canviant en aquest mateix moment. Com creixeràs si, a poc a poc, però segurament, oblides com desenvolupar programari?
El meu consell és que no us comprometeu a implementar tones de funcions per al vostre proper producte. Heu de prendre mesures constantment per estar al corrent de com el vostre equip està creant programari. Podeu fer-ho tant com a director com a vicepresident. Alguna cosa més?
"Uf, Rands! Però algú ha de ser l'àrbitre! Algú ha de veure el panorama general. Si escric codi, perdré la perspectiva".
Encara has de ser l'àrbitre, encara has de difondre les decisions, i encara has de passejar per l'edifici quatre vegades cada dilluns al matí amb un dels teus enginyers per escoltar el seu diari setmanal "Tots estem condemnats" durant 30 anys. minuts.! Però, més enllà de tot això, cal mantenir una mentalitat d'enginyeria i no cal ser un programador a temps complet per fer-ho.
Els meus consells per mantenir una mentalitat d'enginyeria:
- Utilitzeu l'entorn de desenvolupament. Això vol dir que hauríeu d'estar familiaritzat amb les eines del vostre equip, com ara el sistema de creació de codi, el control de versions i el llenguatge de programació. Com a resultat, seràs competent en el llenguatge que utilitza el teu equip quan parles de desenvolupament de productes. Això també us permetrà continuar utilitzant el vostre editor de text favorit, que funciona perfectament.
- Heu de poder dibuixar un diagrama arquitectònic detallat que descrigui el vostre producte en qualsevol superfície en qualsevol moment. Ara no em refereixo a la versió simplificada amb tres cel·les i dues fletxes. Heu de conèixer el diagrama detallat del producte. El més difícil. No un diagrama simpàtic qualsevol, sinó un diagrama difícil d'explicar. Ha de ser un mapa adequat per a una comprensió completa del producte. Està canviant constantment i sempre hauríeu de saber per què s'han produït determinats canvis.
- Assumir la implementació d'una de les funcions. Literalment estic fent una gran ànima mentre escric això perquè aquest punt té molts perills ocults, però realment no estic segur que puguis aconseguir el punt 1 i el punt 2 sense comprometre't a implementar almenys una funció . Amb la implementació d'una de les funcions tu mateix, no només participaràs activament en el procés de desenvolupament, sinó que també us permetrà canviar periòdicament del rol de "Gestor encarregat de tot" al rol d'"Home encarregat d'implementar-ne un". de les funcions”. Aquesta actitud humil i modesta et recordarà la importància de les petites decisions.
- Encara estic tremolant per tot arreu. Sembla que algú ja em crida: “El gerent que es va encarregar de la implementació de la funció?! (I estic d'acord amb ell!) Sí, encara sou el gerent, el que vol dir que hauria de ser una petita funció, d'acord? Sí, encara tens molt per fer. Si simplement no podeu assumir la implementació de la funció, us tinc un consell de recanvi: corregiu alguns errors. En aquest cas, no sentiràs l'alegria de la creació, però tindreu una comprensió de com es crea el producte, la qual cosa significa que mai us quedareu sense feina.
- Escriu proves unitàries. Encara ho faig al final del cicle de producció quan la gent comença a tornar-se boja. Penseu en això com una llista de control de salut per al vostre producte. Feu això sovint.
Una altra objecció?
"Rands, si escric codi, confondré el meu equip. No sabran qui sóc: un gestor o un desenvolupador".
Està bé.
Sí, vaig dir: "D'acord!" M'alegro que pensis que pots confondre el teu equip només nedant a l'estany de desenvolupament. És senzill: els límits entre els diferents rols en el desenvolupament de programari són actualment molt difuminats. Els nois de la IU fan el que en general es pot anomenar programació de JavaScript i CSS. Els desenvolupadors aprenen cada cop més sobre el disseny de l'experiència d'usuari. Les persones es comuniquen entre elles i aprenen sobre errors, sobre el robatori del codi d'altres persones, i també sobre el fet que no hi ha cap bona raó perquè un gestor no participi en aquesta bacanal d'informació massiva, global i de pol·linització creuada.
A més, vols formar part d'un equip format per components fàcilment substituïbles? Això no només farà que el vostre equip sigui més àgil, sinó que donarà a cada membre de l'equip l'oportunitat de veure el producte i l'empresa des de diferents perspectives. Com pots arribar a respectar en Frank, l'home tranquil que s'encarrega de les construccions, com no després de veure la senzilla elegància dels seus guions de construcció?
No vull que el teu equip es torni confós i caòtic. Al contrari, vull que el vostre equip es comuniqui de manera més eficaç. Crec que si estàs involucrat en la creació del producte i treballant en les funcions, estaràs més a prop del teu equip. I el que és més important, estaràs més a prop dels canvis constants en el procés de desenvolupament de programari dins de la teva organització.
No deixis de desenvolupar-te
Un company meu de Borland em va atacar verbalment una vegada per dir-la "codificadora".
"Rands, el codificador és una màquina sense sentit! mico! El programador no fa res important, excepte escriure línies avorrides de codi inútil. No sóc un programador, sóc un desenvolupador de programari!"
Tenia raó, hauria odiat el meu consell inicial als nous CEO: "Deixeu d'escriure codi!" No perquè suggereixi que siguin programadors, sinó més perquè suggereixo de manera proactiva que comencin a ignorar una de les parts més importants de la seva feina: el desenvolupament de programari.
Així que he actualitzat el meu consell. Si vols ser un bon líder, pots deixar d'escriure codi, però...
Sigues flexible. Recordeu què vol dir ser enginyer i no deixeu de desenvolupar programari.
Sobre l’autor
Michael Lopp és un desenvolupador de programari veterà que encara no ha sortit de Silicon Valley. Durant els darrers 20 anys, Michael ha treballat per a diverses empreses innovadores, com Apple, Netscape, Symantec, Borland, Palantir, Pinterest, i també ha participat en una startup que lentament va passar a l'oblit.
Fora de la feina, Michael dirigeix un popular bloc sobre tecnologia i gestió sota el pseudònim de Rands, on comenta idees en l'àmbit de la gestió amb els lectors, expressa la seva preocupació per la necessitat constant de mantenir el dit al pols i explica que, malgrat la generoses recompenses per crear un producte, el vostre èxit només és possible gràcies al vostre equip. El blog es pot trobar aquí .
Michael viu amb la seva família a Redwood, Califòrnia. Sempre troba temps per fer bicicleta de muntanya, jugar a hoquei i beure vi negre, ja que tenir salut és més important que estar ocupat.
» Podeu trobar més detalls sobre el llibre a
»
»
Per a Khabrozhiteley 20% de descompte amb cupó - Gestió de persones
Un cop pagat la versió en paper del llibre, s'enviarà una versió electrònica del llibre per correu electrònic.
PD: el 7% del preu del llibre es destinarà a la traducció de nous llibres informàtics, llistat de llibres lliurats a la impremta .
Font: www.habr.com