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:
- 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.
- 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.
- 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.
- 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.
- 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»
ExtractoCupón de 20% de descuento para vendedores ambulantes -
Managing HumansTras 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í .