El libro "Cómo gestionar intelectuales. Yo, nerds y geeks "

imagen Dedicado a los gerentes de proyecto (y aquellos que sue√Īan con convertirse en un jefe).

¬°Escribir toneladas de c√≥digo es dif√≠cil, y administrar personas es a√ļn m√°s dif√≠cil! Entonces solo necesitas este libro para aprender c√≥mo hacer ambas cosas.

¬ŅEs posible combinar historias geniales y lecciones serias? Michael Lopp (tambi√©n conocido en c√≠rculos estrechos como Randes) tuvo √©xito. Te esperan historias ficticias sobre personas ficticias con experiencias incre√≠blemente √ļtiles (aunque ficticias). As√≠ es como Randy comparte su experiencia diversa, a veces extra√Īa, adquirida a lo largo de los a√Īos de trabajo en grandes corporaciones de TI: Apple, Pinterest, Palantir, Netscape, Symantec, etc.

¬ŅEres gerente de proyectos? ¬ŅO quieres entender qu√© hace tu maldito jefe todo el d√≠a? Rand te ense√Īar√° c√≥mo sobrevivir en el mundo t√≥xico de los pavos inflados y prosperar en la locura general de las personas disfuncionalmente vibrantes. En esta extra√Īa comunidad de sabios man√≠acos hay criaturas a√ļn m√°s extra√Īas: gerentes que, a trav√©s de un ritual organizacional m√≠stico, han ganado poder sobre los planes, pensamientos y cuentas bancarias de muchas personas.

Este libro no es como ning√ļn manuscrito sobre gesti√≥n o liderazgo. Michael Lopp no ‚Äč‚Äčesconde nada, solo cuenta todo tal como est√° (tal vez no todas las historias deber√≠an hacerse p√ļblicas: R). ¬°Pero solo de esta manera entender√°s c√≥mo puedes sobrevivir con un jefe as√≠, c√≥mo manejar geeks y nerds, y c√≥mo llevar "ese maldito proyecto" al final feliz!


Extracto Mentalidad de ingeniería


Reflexiones sobre el tema: ¬Ņnecesita continuar escribiendo c√≥digo?


Hay una lista muy corta de gerentes modernos que hay que hacer en el libro de Rands sobre reglas de liderazgo. El laconismo de esta lista se deriva del hecho de que el concepto de "deber" es una especie de absoluto, y cuando se trata de personas, hay muy pocos conceptos absolutos. Un método exitoso para administrar a un empleado será un verdadero desastre para otro. Esta idea es el primer elemento en la lista gerencial de "debe hacer":

¬°Mantente flexible!

Tener en cuenta que ya lo sabes todo es una muy mala idea. En una situaci√≥n en la que el √ļnico hecho inmutable es el hecho de que se est√°n produciendo cambios constantes en el mundo, la flexibilidad se convierte en la √ļnica posici√≥n verdadera.

Paradójicamente, el segundo elemento de la lista es sorprendentemente inflexible. Sin embargo, este artículo es mi favorito personal, porque creo que ayuda a crear las bases para el crecimiento gerencial. Este párrafo dice:

¡Deja de escribir código!

Teóricamente, si quieres ser un líder, debes aprender a confiar en los que trabajan para ti y pasarles la escritura del código por completo. Este consejo suele ser difícil de "digerir", especialmente por los nuevos líderes. Probablemente, una de las razones por las que se convirtieron en líderes es su productividad en el desarrollo, y cuando las cosas salen mal, su primera reacción es recurrir a habilidades en las que están completamente seguros, es decir, a su capacidad para escribir código.

Cuando veo que un l√≠der reci√©n nombrado "cae" antes de escribir el c√≥digo, le digo: "Sabemos que puedes escribir el c√≥digo". La pregunta es diferente: ¬Ņsabes c√≥mo liderar? Ya no eres responsable de ti solo, eres responsable de todo el equipo; y quiero asegurarme de que puede hacer que su equipo resuelva los problemas por su cuenta, sin tener que escribir el c√≥digo usted mismo. Su tarea es descubrir c√≥mo escalar usted mismo. Quiero que no seas el √ļnico, quiero tanta gente como t√ļ ".

Buen consejo, ¬Ņverdad? Escala Gesti√≥n Responsabilidad Tales palabras de moda comunes. Es una pena que el consejo sea incorrecto.

Mal?


Si ¬°El consejo est√° mal! No es que est√© completamente mal, pero lo suficientemente mal como para tener que llamar a algunos ex colegas y disculparme: "¬ŅRecuerdas esa declaraci√≥n favorita m√≠a de que deber√≠as dejar de escribir c√≥digo? Esta mal! S√≠ ... comience a programar nuevamente. Comience con Python y Ruby. S√≠, lo digo en serio! ¬°Tu carrera depende de eso!

Cuando comencé mi carrera como desarrollador de software en Borland, trabajé en el equipo de Paradox para Windows, y era un equipo enorme. Solo un desarrollador de aplicaciones tenía 13 personas. Si agregamos personas de otros equipos que también trabajaron constantemente en tecnologías clave para este proyecto, como el motor de base de datos principal y los principales servicios de aplicaciones, conseguimos que 50 ingenieros participen directamente en el desarrollo de este producto.

Ning√ļn otro equipo para el que he trabajado se ha acercado a tama√Īos similares. De hecho, con cada a√Īo que pasa, el n√ļmero de personas en el equipo en el que trabajo est√° disminuyendo gradualmente. Que esta pasando ¬ŅSomos desarrolladores colectivamente cada vez m√°s inteligentes? No, solo distribuimos la carga.

¬ŅQu√© han estado haciendo los desarrolladores durante los √ļltimos 20 a√Īos? Durante este tiempo, escribimos un mont√≥n de c√≥digo basura. Mar de c√≥digo! Escribimos tanto c√≥digo que decidimos: ser√≠a bueno simplificar todo y cambiar al c√≥digo fuente abierto.

Afortunadamente, gracias a Internet, este proceso ahora se ha vuelto lo m√°s simple posible. Si es un desarrollador de software, ¬°puede consultarlo ahora mismo! Busque su nombre en Google o en Github, y ver√° un c√≥digo que olvid√≥ hace mucho tiempo, pero que cualquiera que desee puede encontrar. Miedo, ¬Ņeh? ¬ŅNo sab√≠as que el c√≥digo vive para siempre? S√≠, √©l vive para siempre.

El c√≥digo vive para siempre. Un buen c√≥digo no solo vive para siempre, crece, porque quienes lo valoran constantemente se preocupan de que no pierda su frescura. Este conjunto de c√≥digo de alta calidad y bien mantenido ayuda a reducir el tama√Īo promedio de un equipo de ingenier√≠a, ya que nos permite centrarnos no en escribir c√≥digo nuevo, sino en el c√≥digo existente y trabajar con menos personas involucradas y en menos tiempo.

Esta l√≠nea de razonamiento suena deprimente, pero la idea es que todos somos solo un grupo de m√°quinas de integraci√≥n que usan cinta adhesiva para conectar diferentes piezas de cosas existentes para crear una versi√≥n ligeramente diferente de la misma cosa. Esta es una l√≠nea cl√°sica de pensamiento para la alta gerencia que ama el outsourcing. ‚Äú¬°Esto puede hacerlo cualquier persona que sepa c√≥mo usar Google y que tenga cinta adhesiva! Entonces, ¬Ņpor qu√© estamos pagando un mont√≥n de dinero a nuestras m√°quinas expendedoras?

Pagamos mucho dinero a este tipo de ejecutivos, y ellos piensan que esas tonterías. Una vez más: mi idea clave es que hay muchos desarrolladores brillantes y muy diligentes en nuestro planeta; son realmente brillantes y celosos, aunque no han pasado un solo minuto sentados en universidades acreditadas. ¡Oh, sí, ahora hay más y más!

No sugiero que comiences a preocuparte por tu lugar solo porque algunos camaradas brillantes supuestamente se aprovechan de √©l. Le sugiero que empiece a preocuparse por √©l, porque la evoluci√≥n del desarrollo de software puede estar avanzando m√°s r√°pido que usted. Lleva diez a√Īos trabajando, de los cuales cinco a√Īos como l√≠der, y piensa: "Ya s√© c√≥mo se desarrolla el software". Si tu sabes Adios ...

Deja de escribir código, pero ...


Si sigue mis consejos iniciales y deja de escribir c√≥digo, al mismo tiempo dejar√° de participar voluntariamente en el proceso de creaci√≥n. Es por esta raz√≥n que no soy particularmente activo en el outsourcing. Las m√°quinas no crean, producen. Los procesos bien dise√Īados pueden ahorrar mucho dinero, pero no aportar√°n nada nuevo a nuestro mundo.

Si tiene un equipo peque√Īo y hace mucho por poco dinero, entonces la idea de dejar de escribir c√≥digo parece una mala decisi√≥n profesional. Incluso en compa√Ī√≠as monstruosas con sus regulaciones, procesos y pol√≠ticas interminables, no tiene derecho a olvidar c√≥mo desarrollar software usted mismo. Y el desarrollo de software cambia constantemente. Ella est√° cambiando ahora mismo. Debajo de tus pies! ¬°Este mismo segundo!

Tienes una objeción Entiendo Vamos a escuchar
"Randy, ¡voy camino a la silla del director!" Si sigo escribiendo código, nadie creerá que soy capaz de crecer ".
Quiero preguntarle esto: desde que tom√≥ su asiento "¬°Pronto me convertir√© en director!", ¬ŅHa notado que el campo del desarrollo de software est√° cambiando incluso dentro de su empresa? Si su respuesta es s√≠, entonces le har√© otra pregunta: ¬Ņc√≥mo cambia exactamente y qu√© va a hacer en relaci√≥n con estos cambios? Si respondi√≥ "no" a mi primera pregunta, entonces necesita pasar a otra silla, porque (¬°me importa un poco!) El alcance del desarrollo de software cambia en este mismo momento. ¬ŅC√≥mo va a crecer si olvida lenta pero seguramente c√≥mo desarrollar software?

Mi consejo es que no te confíes toneladas de funciones para tu próximo producto. Debe tomar medidas constantemente para mantenerse actualizado sobre cómo su equipo crea software. Puede hacer esto como director y como vicepresidente. Algo mas?
"Uh, Randy! ¡Pero alguien debe ser un árbitro! Alguien debería ver el panorama general. Si escribo un código, perderé de vista la perspectiva ".
Todav√≠a tiene que seguir siendo el √°rbitro, todav√≠a tiene que transmitir las decisiones, y todav√≠a tiene que recorrer el edificio cuatro veces todos los lunes por la ma√Īana con uno de sus ingenieros para escuchar su diatriba semanal durante 30 minutos: "Todos estamos condenados ! " Pero adem√°s de todo esto, debe mantener la forma de pensar de la ingenier√≠a en s√≠ mismo, y para esto no tiene que ser un programador a tiempo completo.

Mi consejo para mantener una mentalidad de ingeniería:

  1. Utiliza el entorno de desarrollo. Esto significa que debe estar familiarizado con las herramientas de su equipo, incluido un sistema de creación de código, control de versiones y un lenguaje de programación. Como resultado de esto, dominará el lenguaje que usa su equipo cuando habla sobre el desarrollo de productos. También le permitirá continuar usando su editor de texto favorito que funciona muy bien.
  2. Debe poder dibujar un diagrama arquitectónico detallado que describa su producto en cualquier superficie y en cualquier momento. Ahora no me refiero a una versión simplificada con tres celdas y dos flechas. Debe conocer el diagrama detallado del producto. Lo mas dificil. No cualquier esquema bonito, sino un esquema difícil de explicar. Esta debería ser una tarjeta adecuada para una comprensión completa del producto. Está cambiando constantemente, y siempre debe saber por qué se han producido estos u otros cambios.
  3. Asumir la implementaci√≥n de una de las funciones. Literalmente tiemblo cuando escribo esto, porque este punto est√° lleno de muchos peligros ocultos, pero realmente no estoy seguro de que puedas cumplir con el p√°rrafo 1 y el p√°rrafo 2 sin asumir al menos una funci√≥n . Gracias a la implementaci√≥n independiente de una de las funciones, no solo participar√° activamente en el proceso de desarrollo, sino que tambi√©n le permitir√° cambiar peri√≥dicamente del rol de "Gerente responsable de todo" al rol de "Persona responsable de la implementaci√≥n de una de las funciones". Esta posici√≥n modesta y sin pretensiones le recordar√° la importancia de las peque√Īas decisiones.
  4. Todav√≠a estoy temblando Parece que alguien ya me est√° gritando: ‚Äú¬°¬ŅEl l√≠der que se hizo cargo de la implementaci√≥n de la funci√≥n ?! (¬°Y estoy de acuerdo con √©l!) S√≠, sigues siendo un l√≠der, lo que significa que deber√≠a ser una peque√Īa funci√≥n, ¬Ņde acuerdo? S√≠, todav√≠a tienes mucho que hacer. Si no puede asumir la implementaci√≥n de la funci√≥n de ninguna manera, entonces tengo un consejo adicional para usted: lidiar con algunos errores. En este caso, no sentir√° las alegr√≠as de la creaci√≥n, pero comprender√° c√≥mo se crea el producto, lo que significa que nunca se quedar√° sin trabajo.
  5. Escribir pruebas unitarias. Todav√≠a hago esto en las √ļltimas etapas del ciclo de producci√≥n, cuando la gente comienza a volverse loca. Piense en ello como una lista de verificaci√≥n de salud para su producto. Hazlo a menudo.

¬ŅUna objeci√≥n de nuevo?
“Rand, si escribo el código, confundiré a mi equipo. No sabrán quién soy, el líder o el desarrollador ".
Bueno

S√≠, dije: "¬°Bien!" Me alegra que creas que puedes confundir a tu equipo solo nadando en un estanque de desarrolladores. Aqu√≠ todo es simple: los l√≠mites entre los diversos roles en el campo del desarrollo de software son actualmente muy borrosos. Los chicos de la interfaz de usuario est√°n haciendo lo que generalmente se puede llamar programaci√≥n de JavaScript y CSS. Los desarrolladores est√°n aprendiendo cada vez m√°s sobre el dise√Īo de las interacciones de los usuarios. Las personas se comunican entre s√≠ y aprenden sobre los errores, el robo del c√≥digo de otra persona y tambi√©n que no hay una buena raz√≥n para que el l√≠der no pueda participar en esta bacanal de informaci√≥n masiva, global y de polinizaci√≥n cruzada.

Adem√°s, ¬Ņquieres formar parte de un equipo formado por componentes f√°cilmente reemplazables? Esto no solo har√° que su equipo sea m√°s √°gil, sino que le dar√° a cada uno de sus miembros la oportunidad de ver el producto y la compa√Ī√≠a desde una variedad de puntos de vista. ¬ŅC√≥mo puedes respetar a Frank, ese tipo genial responsable del dise√Īo, si no despu√©s de que ves la simple elegancia de sus guiones de ensamblaje?

No quiero que la confusión y el caos reinen en tu equipo. Por el contrario, quiero que la comunicación en su equipo sea más efectiva. Estoy seguro de que si usted mismo está involucrado en la creación de un producto y trabajando en funciones, estará más cerca de su equipo. Y lo que es más importante, estará más cerca de los cambios constantes en el proceso de desarrollo de software dentro de su organización.

No dejes de desarrollar


Un colega mío de Borland una vez me atacó verbalmente por llamarla "codificadora".
‚ÄúRand, ¬°el codificador es una m√°quina sin cerebro! Mono Un codificador no hace m√°s que escribir l√≠neas aburridas de c√≥digo in√ļtil. ¬°No soy un programador, soy un desarrollador de software! "
Tenía razón, odiaría mi consejo inicial a los nuevos líderes: "¡Deja de escribir código!" No porque con esto supuestamente suponga que son codificadores, sino más bien porque los invito proactivamente a comenzar a ignorar una de las partes más importantes de su trabajo: el desarrollo de software.

Entonces, finalicé mi consejo. Si quieres ser un buen líder, puedes dejar de escribir código, pero ...

Se flexible. Recuerde lo que significa ser ingeniero y no deje de desarrollar software.

Sobre el autor


Michael Lopp es un veterano de desarrollo de software que a√ļn no ha abandonado Silicon Valley. En los √ļltimos 20 a√Īos, Michael logr√≥ trabajar en una variedad de compa√Ī√≠as innovadoras, incluidas Apple, Netscape, Symantec, Borland, Palantir, Pinterest, y tambi√©n particip√≥ en una startup que lentamente se fue al olvido.

Además de su trabajo, Michael mantiene un blog popular sobre tecnologías y gestión bajo el seudónimo Rands, donde discute ideas de gestión con los lectores, expresa su preocupación por la necesidad constante de mantenerse al día y explica que, a pesar de las generosas recompensas por el producto creado, su éxito solo es posible gracias a tu equipo El blog se puede encontrar en www.randsinrepose.com .

Michael vive con su familia en Redwood, California. Siempre encuentra tiempo para andar en bicicleta de monta√Īa, jugar hockey y beber vino tinto, ya que estar sano es m√°s importante que estar ocupado.

¬ĽSe puede encontrar m√°s informaci√≥n sobre el libro en el sitio web del editor
¬Ľ Contenidos
¬Ľ Extracto

Cupón de 20% de descuento para vendedores ambulantes - Managing Humans

Tras el pago de la versión en papel del libro, se envía una versión electrónica del libro por correo electrónico.

PD: el 7% del costo del libro se destinará a la traducción de nuevos libros de computadora, la lista de libros entregados a la imprenta está aquí .

Source: https://habr.com/ru/post/440842/


All Articles