Una metrica fundamental (*) que cualquier equipo de desarrollo/producto (bueno, en realidad toda la empresa debería estar involucrada aquí) debe medir y mejorar es el tiempo desde que un cliente tiene un problema hasta que ese mismo cliente deja de tenerlo.
Parece una metrica tonta, es facilísima de medir, basta con tener un tracker de issues e ir cambiando los estados a medida que la fases (reporte, evaluación, fix, deploy, test, close). Sí, esto es el peñazo universal, pero también lo era ponerte el cinturón de seguridad al montarte en el coche ahora no puedes avanzar un metro sin él puesto.
Una de esas fases es el deploy, es decir desde que tu código está en el control de versiones, hasta que llega a estar en producción.
Nadie ya discute que ese es un buen procedimiento, que debe estar automatizado y responder a cambios en el repositorio.
Vale, ahora imaginad que retrocedemos 20 años en la época en la que había un servidor FTP donde unos ficheros PHP era ejecutados por apache. O incluso unos scripts corriendo por CGI (las lambdas de hace unos años, para los milenials)
Imaginaos editar directamente esos ficheros en producción, es decir, cuando guardas en el editor la siguiente request ya usaría el nuevo código.
Obviamente hay muchas razones para no hacer esto, pero así se hacia hace años y es el en lo que tienes que pensar cuando tu deploy tarda 30 minutos: el baseline son unos milisegundos, así que todo lo lejos que estés de milisegundos lo estás haciendo peor que hace 25 años.
Digo obviamente pero yo no tengo tan claro que las herramientas actuales de desarrolladores no sean “caballos más rápidos” y no coches como diría Ford. Lo mejor que he visto últimamente en esta línea es esto y glitch, que está empezando de juguete pero “ojo lluvia” que viene de gente que sabe como hacer producto web. Pero este tema da para otro post.
Nos hemos acostumbrado a que las cosas vayan lentas a cambio de unas promesas que, en muchos casos, no son ni media verdad.
(*) Si tienes un equipo de desarrollo mediano (+10) la métrica TTF (time to fix) es un driver buenísimo para mejorar la calidad del desarrollo. Y además si eres CTO te sirve como métrica para poner en el excel para los inversores (que siempre es un peñazo encontrar buenas métricas)