Esta semana tuve la oportunidad de discutir con algunos compañeros sobre por qué tenemos ciertos mecanismos para asegurarnos aprender cuando las cosas van mal.
En la industria del softare, por lo general, tenemos una tolerancia bastante alta a ciertos tipos de errores. Dejando de lado seguridad y privacidad, temas con los que tenemos que tener siempre mucho más cuidado, la velocidad de desarrollo lleva implícito que en algun momento la vamos a liar.
Por una parte, es importante tener mecanismos para que nuestras liadas no impacten al usuario del producto, o lo hagan de la menor manera posible. Herramientas como tests de integración que validan ciertos escenarios críticos, o canarios, que simplemente comprueban que todo siga funcionando aunque no hayamos hecho nada (no es raro que de repente encontremos que un sistema está caído aunque no hagamos nada, un disco duro que se ha llenado es un ejemplo de libro).
Por otra parte, cuando las cosas pasan (porque invariablemente, pasan), tenemos que buscar la manera de convertir un error, un bug, una regresión, en una herramienta de aprendizaje para todo el equipo, que vaya más allá de la persona o el conjunto de personas que provocaron el problema.
Estos mecanismos tienen varios nombres dependiendo de las empresas, en general en la industria se denominan Post Mortems, y en Amazon llevan el nombre de Correction of Errors (o COE).
Estos documentos, que se redactan por parte del equipo y se revisan posteriormente, tienen detalles de qué pasó, por qué se generó el problema, cuantas personas han sido impactadas, qué se podría haber hecho para detectar y solucionar el problema en menos tiempo. A su vez se describen una serie de medidas correctivas para evitar que el problema vuelva a suceder.
El objetivo de este tipo de documentos es contribuir a la responsabilidad compartida. Independientemente de quién ha causado el problema, es responsabilidad del equipo asegurarse que las condiciones que generaron el problema no se vuelvan a repetir exactamente.
Jeff Bezos dijo en su momento que «las buenas intenciones no funcionan» y que la solución a un problema no puede ser «intentarlo mejor, poner más esfuerzo» porque son acciones que no se pueden medir, y su eficacia no se puede comprobar.
Un buen mecanismo se puede establecer, ejecutar, mejorar y validar.
Un proceso de offboarding es también un mecanismo, y si estás pensando cambiar de aires después de navidades, te recomiendo mi libro para poder dejar las cosas cerradas, asignadas y tu mente lista para los nuevos retos. Disponible en Libros.com, en Amazon y allá donde se vendan libros.
rlbisbe @ dev 
Tengo curiosidad por saber cómo cada compañia maneja esos post mortem y cómo se generan acciones para evitar caer dos veces en el mismo problema…
Cada día el software se hace más ágil (no hay color en cuanto a las horas de testing y demás en el disco de Windows 98 que en una update de Win10, que si está mal ya habrá un futuro update que lo corrija), y que sea más ágil implica que hay más posibilidad de cagarla. O más bien, la cagamos más veces (no estoy diciendo que Agile = fallos, pero si que hay pros y contras).
Miedo me da el día en el que por ser tan rápidos áreas críticas (seguridad, etc) se queden atrás.