Dedicado aos xestores de proxectos (e aos que soñan con converterse en xefes).
Escribir toneladas de código é difícil, pero xestionar persoas é aínda máis difícil. Así que só necesitas este libro para aprender a facer as dúas cousas.
É posible combinar historias divertidas e leccións serias? Michael Lopp (tamén coñecido en círculos estreitos como Rands) triunfou. Atoparás historias de ficción sobre persoas ficticias con experiencias incriblemente gratificantes (aínda que ficticias). Así comparte Rands as súas variadas, ás veces estrañas experiencias adquiridas ao longo dos anos de traballo en grandes corporacións informáticas: Apple, Pinterest, Palantir, Netscape, Symantec, etc.
Vostede é xestor de proxectos? Ou queres entender o que fai o teu maldito xefe todo o día? Rands ensinarache a sobrevivir no mundo tóxico dos pavos inflados e a prosperar na tolemia xeral de persoas disfuncionalmente extravagantes. Nesta estraña comunidade de maniacos cerebros hai criaturas aínda máis estrañas: xestores que, mediante un ritual organizativo místico, conseguiron poder sobre os plans, pensamentos e contas bancarias de moitas persoas.
Este libro non se parece a ningún manuscrito de xestión ou liderado. Michael Lopp non oculta nada, só o conta como está (quizais non todas as historias deberían facerse públicas: P). Pero só así entenderás como sobrevivir cun xefe así, como xestionar frikis e nerds e como levar "ese maldito proxecto" a un final feliz!
Fragmento. Mentalidade de enxeñería
Pensamentos sobre: deberías continuar escribindo código?
O libro de Rands sobre regras para xestores contén unha lista moi curta de "imprescindibles" da xestión moderna. O laconismo desta lista deriva do feito de que o concepto de "debe" é unha especie de absoluto, e cando se trata de persoas, hai moi poucos conceptos absolutos. Un método de xestión exitoso para un empregado será un verdadeiro desastre para outro. Este pensamento é o primeiro elemento da lista de "imprescindibles" do xestor:
Sexa flexible!
Pensar que xa o sabes todo é moi mala idea. Nunha situación na que o único feito constante é que o mundo está en constante cambio, a flexibilidade convértese na única posición correcta.
Paradoxalmente, o segundo elemento da lista é sorprendentemente inflexible. Non obstante, este punto é o meu favorito porque creo que axuda a crear as bases para o crecemento directivo. Este parágrafo di:
Deixa de escribir código!
En teoría, se queres ser xestor, tes que aprender a confiar nos que traballan para ti e entregarlles a codificación por completo. Este consello adoita ser difícil de dixerir, especialmente para os xestores recén acuñados. Probablemente unha das razóns polas que se converteron en xestores sexa pola súa produtividade no desenvolvemento e, cando as cousas saen mal, a súa primeira reacción é recorrer ás habilidades nas que confían plenamente, que é a súa capacidade para escribir código.
Cando vexo que un xestor recén acuñado "afunde" na escritura de código, dígolle: "Sabemos que podes escribir código. A pregunta é: podes liderar? Xa non es responsable de ti só, es responsable de todo o equipo; e quero asegurarme de que podes conseguir que o teu equipo resolva problemas por si mesmo, sen que teñas que escribir o código ti mesmo. O teu traballo é descubrir como escalarte. Non quero que sexas só un, quero que haxa moitos coma ti".
Bo consello, non? Escala. Xestión. Responsabilidade. Palabras de moda tan comúns. É unha mágoa que o consello sexa incorrecto.
Incorrecto?
Si. O consello está mal! Non completamente equivocado, pero o suficientemente incorrecto como para que tiven que chamar a algúns antigos colegas e pedir desculpas: "Lembras da miña declaración favorita sobre como deberías deixar de escribir código? Está mal! Si... Comeza a programar de novo. Comeza con Python e Ruby. Si, falo en serio! A túa carreira depende diso!"
Cando comecei a miña carreira como programador de software en Borland, traballei no equipo de Paradox Windows, que era un equipo enorme. Só había 13 desenvolvedores de aplicacións. Se engades persoas doutros equipos que tamén traballaban constantemente en tecnoloxías clave para este proxecto, como o motor de base de datos principal e os servizos de aplicacións principais, conseguirás que 50 enxeñeiros participen directamente no desenvolvemento deste produto.
Ningún outro equipo no que traballei nunca se aproxime a este tamaño. De feito, cada ano que pasa, o número de persoas do equipo no que traballo vai diminuíndo paulatinamente. Que está pasando? Somos os desenvolvedores colectivamente cada vez máis intelixentes? Non, só estamos compartindo a carga.
Que estiveron facendo os desenvolvedores nos últimos 20 anos? Durante este tempo escribimos un montón de código. Mar de código! Escribimos tanto código que decidimos que sería unha boa idea simplificar todo e pasar de código aberto.
Afortunadamente, grazas a Internet, este proceso fíxose o máis sinxelo posible. Se es un programador de software, podes comprobalo agora mesmo! Busca o teu nome en Google ou Github e verás un código que esqueceches hai tempo, pero que calquera pode atopar. Asustado, non? Non sabías que o código vive para sempre? Si, vive para sempre.
O código vive para sempre. E o bo código non só vive para sempre, senón que crece porque os que o valoran constantemente aseguran que permaneza fresco. Esta pila de código de alta calidade e ben mantido axuda a reducir o tamaño medio do equipo de enxeñería porque permítenos centrarnos no código existente en lugar de escribir código novo e facer o traballo con menos persoas e nun período de tempo máis curto.
Esta liña de razoamento soa deprimente, pero a idea é que todos somos só un grupo de autómatas de integración que usan cinta adhesiva para conectar diferentes pezas de cousas existentes para crear unha versión lixeiramente diferente do mesmo. Esta é unha liña de pensamento clásica entre os altos executivos que adoran a subcontratación. "Calquera que saiba usar Google e teña algo de cinta adhesiva pode facelo! Entón, por que estamos pagando moito diñeiro ás nosas máquinas?
Pagámoslles moito diñeiro a estes mozos da dirección, pero pensan que son unha tontería. Unha vez máis, o meu punto clave é que hai moitos desenvolvedores brillantes e moi traballadores no noso planeta; son verdadeiramente brillantes e dilixentes, aínda que non levan un só minuto sentados en universidades acreditadas. Ah si, agora son máis e máis!
Non suxiro que empece a preocuparse polo seu lugar só porque supostamente algúns compañeiros brillantes o están a cazar. Suxírolle que comece a preocuparse porque a evolución do desenvolvemento de software probablemente estea avanzando máis rápido que vostede. Levas dez anos traballando, cinco deles como xestor, e pensas: "Xa sei como se desenvolve o software". Si, xa sabes. Adeus…
Deixa de escribir código, pero...
Se segues o meu consello orixinal e deixas de escribir código, tamén deixarás de participar voluntariamente no proceso de creación. É por esta razón que non uso activamente a subcontratación. Os autómatas non crean, producen. Os procesos ben deseñados aforran moito diñeiro, pero non aportan nada novo ao noso mundo.
Se tes un equipo pequeno que fai moito por pouco diñeiro, entón a idea de deixar de escribir código paréceme unha mala decisión profesional. Mesmo nas empresas monstros coas súas interminables regulacións, procesos e políticas, non tes dereito a esquecer como desenvolver software ti mesmo. E o desenvolvemento de software está en constante cambio. Está cambiando agora mesmo. Baixo os teus pés! Neste mesmo segundo!
Tes obxeccións. Entender. Escoitemos.
"Rands, vou camiño da cadeira de director! Se sigo escribindo código, ninguén crerá que podo crecer".
Quero preguntarche o seguinte: dende que sentou na súa cadeira "Estou a piques de ser CEO!", notaches que o panorama do desenvolvemento de software está cambiando, incluso dentro da túa empresa? Se a túa resposta é afirmativa, fareiche outra pregunta: como está a cambiar exactamente e que vas facer con estes cambios? Se respondeches "non" á miña primeira pregunta, entón tes que pasar a unha cadeira diferente, porque (aposto!) O campo do desenvolvemento de software está cambiando neste mesmo momento. Como vas crecer se esqueces de forma lenta pero segura como desenvolver software?
O meu consello é que non te comprometas a implementar toneladas de funcións para o teu próximo produto. Debes tomar medidas constantemente para estar ao tanto de como o teu equipo está a crear software. Podes facelo tanto como director como vicepresidente. Algo máis?
"Uf, Rands! Pero alguén ten que ser o árbitro! Alguén ten que ver o panorama xeral. Se escribo código, perderei a perspectiva".
Aínda tes que ser árbitro, aínda tes que retransmitir as decisións, e aínda tes que pasear polo edificio catro veces cada luns pola mañá cun dos teus enxeñeiros para escoitar o seu despotricar semanal "Estamos todos condenados" durante 30 anos. minutos.! Pero ademais de todo iso, tes que manter unha mentalidade de enxeñaría, e non tes que ser un programador a tempo completo para facelo.
Os meus consellos para manter unha mentalidade de enxeñería:
- Use o ambiente de desenvolvemento. Isto significa que debes estar familiarizado coas ferramentas do teu equipo, incluído o sistema de creación de código, o control de versións e a linguaxe de programación. Como resultado, dominarás o idioma que usa o teu equipo cando falas de desenvolvemento de produtos. Isto tamén che permitirá seguir usando o teu editor de texto favorito, que funciona perfectamente.
- Debe ser capaz de debuxar un diagrama arquitectónico detallado que describa o seu produto en calquera superficie en calquera momento. Agora non me refiro á versión simplificada con tres celas e dúas frechas. Debe coñecer o diagrama detallado do produto. O máis difícil. Non un bonito diagrama calquera, senón un diagrama que é difícil de explicar. Debe ser un mapa axeitado para unha comprensión completa do produto. Está cambiando constantemente e sempre debes saber por que se produciron certos cambios.
- Asumir a implementación dunha das funcións. Estou literalmente arremecido mentres escribo isto porque este punto ten moitos perigos ocultos, pero realmente non estou seguro de que poida lograr o punto 1 e o punto 2 sen comprometerse a implementar polo menos unha función . Ao implementar unha das funcións vostede mesmo, non só participará activamente no proceso de desenvolvemento, senón que tamén lle permitirá cambiar periodicamente do papel de "Xestor encargado de todo" ao papel de "Home encargado de implementar un". das funcións”. Esta actitude humilde e sen pretensións recordarache a importancia das pequenas decisións.
- Aínda estou tremendo por todas partes. Parece que alguén xa me está a berrar: “¿O xerente que asumiu a posta en marcha da función?! (E estou de acordo con el!) Si, aínda es o director, o que significa que debería ser unha pequena función, vale? Si, aínda tes moito que facer. Se non podes asumir a implementación da función, teño algúns consellos para ti: corrixir algúns erros. Neste caso, non sentirás a alegría da creación, pero entenderás como se crea o produto, o que significa que nunca quedarás sen traballo.
- Escribir probas unitarias. Aínda o fago ao final do ciclo de produción cando a xente comeza a tolear. Pense nel como unha lista de verificación de saúde para o seu produto. Fai isto a miúdo.
Outra obxección?
"Rands, se escribo código, confundirei ao meu equipo. Non saberán quen son: un xestor ou un programador".
Todo ben.
Si, dixen: "Está ben!" Alégrome de que penses que podes confundir ao teu equipo só nadando no estanque de desenvolvedores. É sinxelo: os límites entre os diferentes roles no desenvolvemento de software están actualmente moi difuminados. Os mozos da IU fan o que en xeral se pode chamar programación de JavaScript e CSS. Os desenvolvedores están aprendendo cada vez máis sobre o deseño da experiencia do usuario. As persoas comunícanse entre elas e aprenden sobre erros, sobre o roubo do código alleo e tamén sobre o feito de que non hai ningunha boa razón para que un xestor non participe nesta bacanal informativa masiva, global e de polinización cruzada.
Ademais, queres formar parte dun equipo formado por compoñentes facilmente substituíbles? Isto non só fará que o teu equipo sexa máis áxil, senón que dará a cada membro do equipo a oportunidade de ver o produto e a empresa desde unha variedade de perspectivas. Como podes chegar a respectar a Frank, o tipo tranquilo que se encarga das construcións, como non despois de ver a simple elegancia dos seus guións de construción?
Non quero que o teu equipo se confunda e se confunda. Pola contra, quero que o teu equipo se comunique de forma máis eficaz. Creo que se estás involucrado na creación do produto e traballando nas funcións, estarás máis preto do teu equipo. E o máis importante, estará máis preto dos cambios constantes no proceso de desenvolvemento de software dentro da súa organización.
Non deixes de desenvolverte
Un compañeiro meu de Borland atacoume verbalmente unha vez por chamala "codificadora".
"Rands, o codificador é unha máquina sen sentido! Mono! O programador non fai nada importante, excepto escribir liñas aburridas de código inútil. Non son un programador, son un programador de software!"
Tiña razón, odiaría o meu primeiro consello aos novos CEO: "Deixa de escribir código!" Non porque estou suxerindo que sexan programadores, senón máis porque estou suxerindo proactivamente que comecen a ignorar unha das partes máis importantes do seu traballo: o desenvolvemento de software.
Entón actualicei o meu consello. Se queres ser un bo líder, podes deixar de escribir código, pero...
Sexa flexible. Lembra o que significa ser enxeñeiro e non deixes de desenvolver software.
Sobre o autor
Michael Lopp é un veterano desenvolvedor de software que aínda non deixou Silicon Valley. Durante os últimos 20 anos, Michael traballou para unha variedade de empresas innovadoras, incluíndo Apple, Netscape, Symantec, Borland, Palantir, Pinterest, e tamén participou nunha startup que pasou lentamente ao esquecemento.
Fóra do traballo, Michael dirixe un popular blog sobre tecnoloxía e xestión baixo o pseudónimo de Rands, onde comenta ideas no campo da xestión cos lectores, expresa a súa preocupación pola necesidade constante de manter o dedo no pulso e explica que, a pesar do xenerosas recompensas por crear un produto, o teu éxito só é posible grazas ao teu equipo. O blog pódese atopar aquí .
Michael vive coa súa familia en Redwood, California. Sempre atopa tempo para andar en bicicleta de montaña, xogar ao hoquei e beber viño tinto, xa que estar saudable é máis importante que estar ocupado.
» Podes atopar máis detalles sobre o libro en
»
»
Para Khabrozhiteley 20% de desconto usando o cupón - Xestión de persoas
Tras o pagamento da versión en papel do libro, enviarase unha versión electrónica do libro por correo electrónico.
PD: o 7% do prezo do libro irá destinado á tradución de novos libros informáticos, unha relación de libros entregados á imprenta .
Fonte: www.habr.com