Dedicado a directores de proyectos (y a aquellos que sueñan con convertirse en jefes).
Escribir toneladas de código es difícil, ¡pero gestionar personas es aún más difícil! Así que sólo necesitas este libro para aprender a hacer ambas cosas.
¿Es posible combinar historias divertidas y lecciones serias? Michael Lopp (también conocido en círculos estrechos como Rands) tuvo éxito. Encontrarás historias ficticias sobre personas ficticias con experiencias increíblemente gratificantes (aunque ficticias). Así es como Rands comparte sus variadas y a veces extrañas experiencias adquiridas a lo largo de años de trabajo en grandes corporaciones de TI: Apple, Pinterest, Palantir, Netscape, Symantec, etc.
¿Eres director de proyectos? ¿O quieres entender qué hace tu maldito jefe todo el día? Rands te enseñará cómo sobrevivir en el mundo tóxico de los pavos inflados y prosperar en la locura general de personas disfuncionalmente extravagantes. En esta extraña comunidad de cerebritos 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 se parece a ningún manuscrito sobre gestión o liderazgo. Michael Lopp no oculta nada, simplemente cuenta las cosas tal como son (quizás no todas las historias deberían hacerse públicas :P). ¡Pero sólo así entenderás cómo sobrevivir con un jefe así, cómo manejar a geeks y nerds y cómo llevar "ese maldito proyecto" a un final feliz!
Extracto. Mentalidad de ingeniería
Pensamientos sobre: ¿Debería continuar escribiendo código?
El libro de Rands sobre reglas para gerentes contiene una lista muy breve de "obligaciones" de la gerencia moderna. El laconismo de esta lista se debe al 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 de gestión exitoso para un empleado será un verdadero desastre para otro. Este pensamiento es el primer elemento de la lista de “cosas que debe hacer” el gerente:
¡Manténgase flexible!
Pensar que ya lo sabes todo es muy mala idea. En una situación en la que el único hecho constante es que el mundo cambia constantemente, la flexibilidad se convierte en la única posición correcta.
Paradójicamente, el segundo elemento de la lista es sorprendentemente inflexible. Sin embargo, este punto es mi favorito porque creo que ayuda a crear las bases para el crecimiento gerencial. Este párrafo dice:
¡Deja de escribir código!
En teoría, si quieres ser gerente, debes aprender a confiar en quienes trabajan para ti y entregarles la codificación por completo. Este consejo suele ser difícil de digerir, especialmente para los gerentes recién nombrados. Probablemente una de las razones por las que se convirtieron en gerentes es por su productividad en el desarrollo, y cuando las cosas van mal, su primera reacción es recurrir a las habilidades en las que tienen plena confianza, que es su capacidad para escribir código.
Cuando veo que un nuevo gerente se “hunde” en la escritura de código, le digo: “Sabemos que puedes escribir código. La pregunta es: ¿puedes liderar? Ya no eres responsable sólo de ti mismo, eres responsable de todo el equipo; y quiero asegurarme de que puedas lograr que tu equipo resuelva los problemas por sí solo, sin que tengas que escribir el código tú mismo. Tu trabajo es descubrir cómo escalar tú mismo. No quiero que seas solo uno, quiero que haya muchos como tú”.
Buen consejo, ¿verdad? Escala. Gestión. Responsabilidad. Palabras de moda tan comunes. Es una pena que el consejo sea incorrecto.
¿Incorrecto?
Sí. ¡El consejo está mal! No del todo equivocado, pero sí lo suficientemente equivocado como para que tuve que llamar a algunos antiguos colegas y pedirles disculpas: “¿Recuerdas mi afirmación favorita sobre cómo deberías dejar de escribir código? ¡Está incorrecto! Sí... Comience a programar nuevamente. Comience con Python y Ruby. ¡Si hablo en serio! ¡Tu carrera depende de ello!
Cuando comencé mi carrera como desarrollador de software en Borland, trabajé en el equipo de Paradox Windows, que era un equipo enorme. Sólo había 13 desarrolladores de aplicaciones. Si agrega personas de otros equipos que también trabajaron constantemente en tecnologías clave para este proyecto, como el motor de base de datos central y los servicios de aplicaciones principales, obtendrá 50 ingenieros directamente involucrados en el desarrollo de este producto.
Ningún otro equipo para el que he trabajado se acerca siquiera a este tamaño. De hecho, cada año que pasa, la cantidad de personas en el equipo en el que trabajo disminuye gradualmente. ¿Qué está sucediendo? ¿Nos estamos volviendo cada vez más inteligentes, colectivamente, los desarrolladores? No, sólo estamos compartiendo la carga.
¿Qué han estado haciendo los desarrolladores durante los últimos 20 años? Durante este tiempo escribimos un montón de código. ¡Mar de código! Escribimos tanto código que decidimos que sería una buena idea simplificar todo y pasar al código abierto.
Afortunadamente, gracias a Internet, este proceso ahora es lo más sencillo posible. Si eres desarrollador de software, ¡puedes comprobarlo ahora mismo! Busca tu nombre en Google o Github y verás un código que hace mucho que olvidaste, pero que cualquiera puede encontrar. Miedo, ¿verdad? ¿No sabías que el código vive para siempre? Sí, vive para siempre.
El código vive para siempre. Y un buen código no sólo vive para siempre, sino que crece porque quienes lo valoran se aseguran constantemente de que permanezca actualizado. Esta pila de código de alta calidad y bien mantenido ayuda a reducir el tamaño promedio del equipo de ingeniería porque nos permite concentrarnos en el código existente en lugar de escribir código nuevo y realizar el trabajo con menos personas y en un período de tiempo más corto.
Esta línea de razonamiento suena deprimente, pero la idea es que todos somos solo un grupo de autómatas de integración que usan cinta adhesiva para conectar diferentes partes de cosas existentes para crear una versión ligeramente diferente de la misma cosa. Esta es una línea de pensamiento clásica entre los altos ejecutivos amantes de la subcontratación. “¡Cualquiera que sepa utilizar Google y tenga algo de cinta adhesiva puede hacerlo! Entonces, ¿por qué pagamos tanto dinero por nuestras máquinas?
Pagamos mucho dinero a estos directivos, pero piensan tonterías. Una vez más, mi punto clave es que hay muchos desarrolladores brillantes y muy trabajadores en nuestro planeta; son realmente brillantes y diligentes, aunque no han pasado ni un minuto sentados en universidades acreditadas. ¡Oh, sí, ahora hay más y más!
No te sugiero que empieces a preocuparte por tu lugar sólo porque supuestamente algunos camaradas brillantes lo están buscando. Le sugiero que empiece a preocuparse por eso porque la evolución del desarrollo de software probablemente avanza más rápido que usted. Llevas diez años trabajando, cinco de ellos como directivo, y piensas: “Ya sé cómo se desarrolla el software”. Sí, lo sabes. Adiós…
Deja de escribir código, pero...
Si sigues mi consejo original y dejas de escribir código, también dejarás de participar voluntariamente en el proceso de creación. Es por esta razón que no utilizo activamente la subcontratación. Los autómatas no crean, producen. Los procesos bien diseñados ahorran mucho dinero, pero no aportan nada nuevo a nuestro mundo.
Si tienes un equipo pequeño que hace mucho por poco dinero, entonces la idea de dejar de escribir código me parece una mala decisión profesional. Incluso en empresas monstruosas con sus infinitas regulaciones, procesos y políticas, no tienes derecho a olvidar cómo desarrollar software tú mismo. Y el desarrollo de software cambia constantemente. Está cambiando ahora mismo. ¡Bajo tus pies! ¡En este mismo segundo!
Tienes objeciones. Entender. Vamos a escuchar.
“¡Rands, voy camino a la silla del director! Si sigo escribiendo código, nadie creerá que puedo crecer”.
Quiero preguntarle esto: desde que se sentó en su silla de “¡Estoy a punto de ser CEO!”, ¿ha notado que el panorama del desarrollo de software está cambiando, incluso dentro de su empresa? Si tu respuesta es sí, entonces te haré otra pregunta: ¿cómo está cambiando exactamente y qué vas a hacer al respecto? Si respondió “no” a mi primera pregunta, entonces debe cambiar de silla, porque (¡apuesto!) el campo del desarrollo de software está cambiando en este mismo momento. ¿Cómo vas a crecer si, de forma lenta pero segura, te olvidas de cómo desarrollar software?
Mi consejo es que no se comprometa a implementar toneladas de funciones para su próximo producto. Debe tomar medidas constantemente para estar al tanto de cómo su equipo está creando software. Puede hacer esto tanto como director como vicepresidente. ¿Algo más?
“¡Uf, Rands! ¡Pero alguien tiene que ser el árbitro! Alguien tiene que ver el panorama general. Si escribo código, perderé la perspectiva".
Todavía tienes que ser el árbitro, todavía tienes que transmitir las decisiones y todavía tienes que caminar alrededor del edificio cuatro veces cada lunes por la mañana con uno de tus ingenieros para escuchar su perorata semanal "Estamos todos condenados" durante 30 minutos. minutos. ! Pero más allá de todo eso, hay que mantener una mentalidad de ingeniería y no es necesario ser un programador de tiempo completo para hacerlo.
Mis consejos para mantener una mentalidad de ingeniería:
- Utilice el entorno de desarrollo. Esto significa que debe estar familiarizado con las herramientas de su equipo, incluido el sistema de creación de código, el control de versiones y el lenguaje de programación. Como resultado, dominará el lenguaje que utiliza su equipo cuando habla sobre desarrollo de productos. Esto también te permitirá seguir usando tu editor de texto favorito, que funciona perfectamente.
- Debe poder dibujar un diagrama arquitectónico detallado que describa su producto en cualquier superficie y en cualquier momento. Ahora no me refiero a la versión simplificada con tres celdas y dos flechas. Debes conocer el diagrama detallado del producto. El más difícil. No cualquier diagrama lindo, sino un diagrama que es difícil de explicar. Debe ser un mapa adecuado para una comprensión completa del producto. Cambia constantemente y siempre debes saber por qué se produjeron ciertos cambios.
- Asumir la implementación de una de las funciones. Literalmente estoy haciendo una mueca de dolor mientras escribo esto porque este punto tiene muchos peligros ocultos, pero realmente no estoy seguro de que puedas lograr los puntos 1 y 2 sin comprometerte a implementar al menos una característica. Al implementar una de las funciones usted mismo, no solo participará activamente en el proceso de desarrollo, sino que también le permitirá cambiar periódicamente del rol de "Gerente a cargo de todo" al rol de "Hombre a cargo de implementar una". de las funciones”. Esta actitud humilde y sencilla le recordará la importancia de las pequeñas decisiones.
- Todavía estoy temblando por todos lados. Parece que alguien ya me está gritando: “¡¿El gerente que asumió la implementación de la función?! (¡Y estoy de acuerdo con él!) Sí, todavía eres el gerente, lo que significa que debería ser una función pequeña, ¿de acuerdo? Sí, todavía te queda mucho por hacer. Si simplemente no puede encargarse de la implementación de la función, tengo algunos consejos adicionales para usted: corrija algunos errores. En este caso, no sentirá la alegría de la creación, pero comprenderá cómo se crea el producto, lo que significa que nunca se quedará sin trabajo.
- Escribe pruebas unitarias. Todavía hago esto al final del ciclo de producción, cuando la gente empieza a volverse loca. Piense en ello como una lista de control de salud para su producto. Haga esto con frecuencia.
¿Otra vez objeción?
“Rands, si escribo código, confundiré a mi equipo. No sabrán quién soy: un gerente o un desarrollador”.
Está bien.
Sí, dije: "¡Está bien!" Me alegra que pienses que puedes confundir a tu equipo simplemente nadando en el estanque de desarrolladores. Es simple: los límites entre los diferentes roles en el desarrollo de software son actualmente muy borrosos. Los chicos de UI hacen lo que en términos generales se puede llamar programación JavaScript y CSS. Los desarrolladores aprenden cada vez más sobre el diseño de la experiencia del usuario. Las personas se comunican entre sí y aprenden sobre errores, sobre el robo de códigos de otras personas y también sobre el hecho de que no hay una buena razón para que un gerente no participe 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 sólo hará que su equipo sea más ágil, sino que también le dará a cada miembro del equipo la oportunidad de ver el producto y la empresa desde una variedad de perspectivas. ¿Cómo puedes llegar a respetar a Frank, el tipo tranquilo a cargo de las construcciones, más que después de ver la sencilla elegancia de sus guiones de construcción?
No quiero que tu equipo se vuelva confuso y caótico. Al contrario, quiero que tu equipo se comunique de forma más eficaz. Creo que si participas en la creación del producto y trabajas en las funciones, estarás más cerca de tu equipo. Y lo más importante, estará más cerca de los constantes cambios en el proceso de desarrollo de software dentro de su organización.
No dejes de desarrollarte
Una colega mía en Borland una vez me atacó verbalmente por llamarla "codificadora".
“¡Rands, el codificador es una máquina sin sentido! ¡Mono! El codificador no hace nada importante excepto escribir líneas aburridas de código inútil. ¡No soy codificador, soy desarrollador de software!
Tenía razón, habría odiado mi consejo inicial a los nuevos directores ejecutivos: "¡Dejen de escribir código!" No porque esté sugiriendo que sean programadores, sino más bien porque estoy sugiriendo proactivamente que comiencen a ignorar una de las partes más importantes de su trabajo: el desarrollo de software.
Así que actualicé mi consejo. Si quieres ser un buen líder, puedes dejar de escribir código, pero...
Se Flexible. Recuerda lo que significa ser ingeniero y no dejes de desarrollar software.
Acerca del Autor
Michael Lopp es un desarrollador de software veterano que todavía no ha abandonado Silicon Valley. Durante los últimos 20 años, Michael ha trabajado para una variedad de empresas innovadoras, incluidas Apple, Netscape, Symantec, Borland, Palantir, Pinterest, y también participó en una startup que lentamente quedó flotando en el olvido.
Fuera del trabajo, Michael dirige un popular blog sobre tecnología y gestión bajo el seudónimo de Rands, donde analiza ideas en el campo de la gestión con los lectores, expresa su preocupación por la necesidad constante de estar al día y explica que, a pesar de la generosas recompensas por crear un producto, su éxito sólo es posible gracias a su equipo. El blog se puede encontrar aquí. .
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.
» Puede encontrar más detalles sobre el libro en
»
»
Para Khabrozhiteley 20% de descuento usando cupón - Manejo de humanos
Tras el pago de la versión impresa del libro, se enviará una versión electrónica del libro por correo electrónico.
PD: el 7% del precio del libro se destinará a la traducción de nuevos libros de informática, una lista de libros entregada a la imprenta. .
Fuente: habr.com