- Resultado de una encuesta a más de 100 grandes empresas tecnológicas
- Si se resume la forma en que las grandes tecnológicas gestionan proyectos ⇨ "depende de la situación (It Depends)"
- En la mayoría de los casos no existe una metodología ni una forma de trabajo fija, y cada equipo elige lo que mejor le funciona
- Las empresas que cotizan en bolsa o que han recibido inversión mostraron baja satisfacción con tener PM dedicados, mientras que las que no habían recibido inversión mostraron alta satisfacción
- La autonomía del equipo y la satisfacción tienen una alta correlación
- Incluso en los equipos con problemas, la causa no era tanto la metodología sino la incapacidad de mostrar bien la visión, la falta de transparencia o la carencia de herramientas
- La mayoría de las respuestas sobre JIRA fueron negativas
- Enfoques de gestión de proyectos que no funcionaron bien
- Los ingenieros no participan en la estimación de la duración del proyecto
- Los requisitos cambian incluso cuando hay un PM dedicado
- Los equipos sin autonomía para cambiar un método de gestión de proyectos que había fracasado registraron baja satisfacción
- Cómo llevan adelante los proyectos las grandes tecnológicas
- Los ingenieros lideran la mayoría de los proyectos
- No hay una metodología fija, y los equipos pueden elegir libremente
- En proyectos a nivel de equipo no hay un Project Manager dedicado. En proyectos grandes que involucran a varios equipos o a toda la empresa, se asigna un Technical Program Manager. En Uber, la proporción es de aproximadamente 1:50
- Se proporcionan herramientas de desarrollo de primer nivel, y eso tiene un gran impacto en ciclos de iteración cortos
La estructura organizacional de las grandes tecnológicas que influye en los proyectos
- Entorno básico
- Los ingenieros y los equipos tienen autonomía
- No son recursos inconscientes (trabajadores de fábrica), sino solucionadores de problemas curiosos
- Los datos, el código y la documentación internos se comparten con transparencia
- Los ingenieros también están expuestos al negocio y a las métricas del negocio
- En vez de comunicación jerárquica, hay comunicación directa entre ingenieros para mayor rapidez
- Se invierte en una experiencia de desarrollador menos frustrante
- Sueldos más altos justificados por mayor apalancamiento
- Posibilidad de contratar talento de mayor nivel
- Equipos empoderados y autónomos
- Equipos con ownership claro
Product Manager sí, Project Manager no
- El rol del Product Manager es entender "What game we're playing" y "How we're going to play it"
- En muchos casos, los Product Managers de las grandes tecnológicas no hacen Project Management
- El equipo es responsable de la ejecución, y por lo general el responsable de hacer gestión de proyectos es el manager técnico (líder del equipo)
- En equipos empoderados y autónomos, es raro que la gestión de proyectos sea top-down ⇨ se hace entre todos
- Dudas comunes cuando no hay un Project Manager dedicado
- Proyectos a nivel de equipo: simplificar el proceso y fortalecer las relaciones personales
- Proyectos complejos: las grandes tecnológicas asignan un Technical Program Manager (TPM)
- Sí existen Program Managers / Project Managers dedicados. Por lo general están vinculados con el exterior, los clientes y la planificación de ejecución a largo plazo
- Entorno centrado en producto y por qué no usan Scrum
- El Scrum ejecutado por sprints no encaja bien con contextos de despliegue rápido
- La infraestructura y las herramientas para desarrolladores reemplazan muchas actividades de Scrum
- Las grandes tecnológicas aprendieron que invertir en infraestructura y herramientas para desarrolladores mejora la productividad
- Facebook, Google y Netflix no usan Scrum. ¿Por qué?
- Las personas capaces y autónomas necesitan menos este tipo de estructura
- Si a un equipo competente se le da libertad sobre cómo operar, se puede aprovechar mejor su potencial
- Escalar una organización de ingeniería va mucho más allá de los procesos a nivel de equipo
- Aun así, sería un error que todos imiten a las grandes tecnológicas y dejen de usar Scrum
→ Hay situaciones en las que sí conviene usar Scrum, e incluso puede generar mayor productividad
- Equipo "kitchen sink": cuando un solo equipo tiene que resolverlo todo (startup en etapa inicial)
- Al momento de formar un equipo nuevo
- Cuando se despliega una vez cada pocas semanas
- Cuando es obligatorio reportar el avance del proyecto en un formato estandarizado
¿Cómo debería operar un equipo?
- Los cambios iterativos siempre son mejores que los cambios de "big bang"
- Es más difícil enseñar a pescar que simplemente darle un pescado a alguien
- Dirigir, mentorizar y hacer coaching tienen cada uno su utilidad
- Dirigir consiste en microgestionar de forma auxiliar solo cuando ellos podrían hacerlo por sí mismos, pero en ese momento no pueden
- Cuantas menos personas se necesiten para tomar una decisión, más rápido se puede decidir
- Optimizar para reportar equivale a optimizar para un entorno de menor confianza
- Los consultores tienden a sesgarse hacia resultados fáciles de medir, porque esa es la forma más sencilla de demostrar su valor
- Aprender de los competidores directos está subestimado
- Algunos de los mejores ingenieros prefieren renunciar antes que ser microgestionados
8 comentarios
"La mayoría de las respuestas sobre JIRA fueron negativas"
Creo que es necesario gestionar los issues de alguna forma, y yo también tenía una opinión negativa de JIRA, así que probé deliberadamente otras herramientas (
github issues, trello, asana, etc.).Pero al final, como dicen, más vale viejo conocido, y terminé volviendo a JIRA...
Aun así, sigo pensando si habrá una mejor manera.
¿En qué sentido pensaste que lo viejo sigue siendo mejor?
Me gusta YouTrack. Es una herramienta de gestión de proyectos creada por JetBrains, y me permite manejar proyectos justo en la medida en que lo necesito.
Nuestro equipo se cambió a Linear y, en general, el nivel de satisfacción subió bastante. Les recomiendo que lo revisen.
Parece que es este producto, https://linear.app/. Se ve interesante.
Las ventajas que siento que tiene son
opinionated.Más o menos así es como yo lo percibo.
¿Qué hacen las herramientas de desarrollo de primera clase?
Lo traje tal cual para preservar el tono del original.
En este momento, probablemente sea la mejor herramienta de desarrollo que una organización puede ofrecer.