Los asiduos a esta newsletter me habréis escuchado decir más de una vez que la ejecución no es responsabilidad del Product Manager. La función de un Product Manager es definir el qué y el por qué, mientras que el equipo de ingeniería se encarga de definir el cómo y el cuándo, es decir, gestionar la ejecución.

Ahora bien, pese a que la ejecución no es responsabilidad del PM, la realidad es que si la ejecución no funciona, el producto está muerto. Por muy bien que haga su trabajo, si las condiciones de la empresa no favorecen el desarrollo del producto, más le vale ir buscando otro empleo.

Ahora bien, ¿cómo puede evaluar un Product Manager la capacidad de ejecución de una empresa? Muchas veces los PM ni son, ni tienen por qué ser técnicos. Porque Product Management es principalmente una función de negocio. Así, muchos PMs no tienen el conocimiento necesario para evaluar esta capacidad de antemano.

El artículo de hoy trata de resolver esa carencia con una única pregunta.

¿Con qué frecuencia hacéis despliegues?

En 2018, Nicole Forsgren, Jez Humble y Gene Kim publicaron Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations.

El libro condensa los resultados de varios estudios hechos por los autores en los que trataban de identificar cuáles eran las características que diferenciaban a los mejores equipos del resto. 

La siguiente tabla es un buen resumen:

Citando a los propios autores:

To summarize, in 2017 we found that, when compared to low performers, the high performers have: 46 times more frequent code deployments 440 times faster lead time from commit to deploy 170 times faster mean time to recover from downtime 5 times lower change failure rate (1/5 as likely for a change to fail) 

Cómo podéis ver, la principal característica que distingue a los mejores equipos del resto es la frecuencia con la que hacen despliegues. Estos lo hacen bajo demanda, múltiples veces al día si es necesario. Mientras tanto, el resto de equipos lo hacen entre una vez a la semana y al mes.

¿Por qué considero que es la pregunta clave? Porque si el equipo es capaz de sacar código a producción a demanda es porque la empresa ha invertido el tiempo y los recursos necesarios para llegar a ese punto. 

Eso nos garantiza de salida que:

1. Tienen automatizado el proceso de despliegue 

Nadie puede lanzar código a producción a demanda si no ha invertido tiempo automatizando los distintos pasos que les permiten hacer un despliegue, con tan sólo pulsar un botón o lanzar un comando. 

Si para hacer una release, se tienen que juntar Gandalf y Ragadast porque son los únicos que saben generarla, ten por seguro que tu velocidad de iteración será baja.

2. Tienen test automáticos que cubren la aplicación

Si lanzas código a producción a menudo, obviamente es porque todo tu proceso de testeo está automatizado y no tiene que haber ningún QA teniendo que hacer trabajo manual.

Si no puedes lanzar una release sin que un QA se pase un día entero revisando la aplicación, no pretendas considerarte ágil.

3. Siguen buenas prácticas de desarrollo

De nuevo, si lanzas código a producción a menudo, es porque tu proceso de desarrollo te permite hacerlo, de forma que pueden confiar en que su código está en un estado que siempre permite ser desplegado en cuánto sea necesario.

4. Son autónomos

Sólo puedes hacer varios despliegues al día si tu equipo es autónomo para hacerlo, esto es, no dependes de nadie externo para hacerlo.

Una de las principales causas que reduce la velocidad de iteración es precisamente la necesidad de coordinar a varios equipos. Si un equipo no tiene todos los medios para poder trabajar autónomamente, obviamente la velocidad de iteración se resentirá.

5. Trabajan en lotes (batches) pequeños

Me habéis leído también por aquí la importancia de trabajar de forma evolutiva, aportando valor de forma pequeña pero continuada, frente a plantear grandes castillos que puedan llevar meses de desarrollo.

Para poder desplegar código a producción de forma contínua y segura, los lotes tienen que ser por necesidad pequeños. Los mejores equipos son capaces de dividir en componentes mínimos cualquier funcionalidad e ir desplegándola poco a poco en lugar de esperar hacer un big bang final, siempre proclive al fallo.

6. Monitorean sus sistemas de forma proactiva

Otro aspecto que nos garantiza que un equipo pueda hacer múltiples despliegues al día es que ha invertido para tener la infraestructura necesaria para detectar cualquier error en producción o fallo en la infraestructura de forma automatizada.

De esta forma, cualquier cambio que impacte negativamente en el sistema, es detectado a los pocos minutos, y puede ser corregido o echado atrás si es necesario.

Conclusión

Por asombroso que parezca, con una única pregunta, podemos intuir muchísimo de la capacidad de ejecución de una empresa. 

Y no sólo eso, todos los aspectos anteriores también están correlacionados con un menor burnout de los equipos y una mayor retención. 

In summary, our research found evidence that technical and Lean management practices contributed to reductions in both burnout and deployment pain. These findings have serious implications for technology organizations: not only do investments in technology make our software development and delivery better, they make the work lives of our professionals better.

Es decir, la pregunta no sólo te da pistas sobre la capacidad de ejecución, si no que también te puede anticipar lo motivado o quemado que va a estar tu equipo. 

E incluso te puede indicar el grado de seniority que te vas a encontrar. Los mejores ingenieros van a estar en entornos adaptados para los mejores equipos. No se les ocurriría trabajar en un entorno que no estuviera optimizado para la ejecución. 

Es difícil obtener más por menos.

Y ahora que lo sabes, no te olvides de preguntarlo en tu próxima entrevista de trabajo: ¿con qué frecuencia hacéis despliegues?