La industria del software necesita inventar menos y aprender más de otras disciplinas

Un hospital redujo en 20 % su tasa de errores en trato con pacientes porque tuvieron la humildad y curiosidad de aprender de otras industrias.

Great Ormond Street Hospital for Children publicó un estudio en el que miembros de su personal médico fueron a observar cómo Ferrari hace los pit stops en la F1 para aprender cómo mejorar sus procesos de manejo de pacientes:

Muchas cosas pueden salir mal, y a veces salen mal, mientras la persona diminuta y vulnerable es trasladada de cirugía a cuidados intensivos. Mover el pequeño cuerpo de una cama a otra es solo una parte del complejo conjunto de movimientos que deben ocurrir. Cables, equipo, personas e información se mueven en una danza intrincada en la que un paso en falso puede poner al niño en peligro mortal. En 15 minutos toda la tecnología y los sistemas de soporte, incluyendo ventilación, de dos a cuatro líneas de monitoreo, múltiples vasodilatadores e inotrópicos, se transfieren dos veces: pasando del sistema del quirófano al equipo portátil y luego a los sistemas de cuidados intensivos. El conocimiento íntimo del paciente obtenido durante un procedimiento que puede durar hasta ocho horas debe transmitirse del equipo quirúrgico al equipo de la unidad de cuidados intensivos.

En el caso de GOSH, no hubo una encuesta ni una búsqueda dirigida de un referente que guiara cambios en el procedimiento de traspaso. La proverbial chispa surgió cuando dos doctores cansados, Alan Goldman y Martin Elliott, se sentaron a relajarse después de cirugías largas. Martin Elliott, MD, FRCS, Profesor de Cirugía Cardiotorácica en University College London y Presidente de Servicios Cardiotorácicos, recuerda: “Había hecho un trasplante y luego un cambio arterial en la mañana, y los dos estábamos bastante hechos polvo [agotados]. La Fórmula Uno apareció en la tele justo cuando nos sentábamos al final de la cirugía, y nos dimos cuenta de que el pit stop, donde cambian llantas y cargan combustible, era prácticamente idéntico en concepto a lo que hacemos en el relevo de pacientes —así que les hablamos por teléfono.” Los dos doctores reconocieron la importancia del trabajo en equipo para transformar una operación de pit stop de alto riesgo en una que fuera segura y rápida. Se preguntaron: “Si ellos pueden hacerlo, ¿por qué nosotros no?”

En el automovilismo de Fórmula Uno, el equipo de pit stop completa la tarea compleja de cambiar neumáticos y reabastecer el auto en alrededor de siete segundos. Los doctores vieron esto como análogo al esfuerzo del equipo de cirujanos, anestesistas y personal de UCI para transferir de forma segura y rápida al paciente, el equipo y la información del quirófano a la UCI.

Alan Goldman y Martin Elliot tuvieron la humildad y curiosidad de explorar cómo otra disciplina, que pudiera parecer que no tiene nada que ver con la medicina, les podría ayudar a mejorar sus procesos. Eso es algo que nos falta mucho en la industria del software: humildad y curiosidad. En vez de voltear a ver cómo otras industrias o disciplinas han resuelto un problema fundamental antes, queremos reinventar la rueda. Nos encanta pretender que los problemas que estamos resolviendo son especiales y que somos nosotros los que tenemos que encontrar la solución ideal. Pero eso es mentira: nada de lo que estamos haciendo es fundamentalmente nuevo; solo lo hacemos con otras herramientas.

Lo que le digo a las personas con las que trabajo es que es importante aprender a reconocer los patrones y las formas de los problemas. Si trabajas en software, y tu problema es que no tienes una buena relación con tu PM, ¿de verdad crees que no hay otra industria donde la forma fundamental del problema sea la misma? Déjame romperte esa burbuja.

En la aviación la seguridad no se negocia. El piloto revisa el plan de vuelo, mira el radar y dice: “Con ese frente no paso. Necesito desviarme.” Despacho sabe que eso significa más combustible, horarios más apretados, tal vez una multa por perder slot. Pero nadie dice “ay, no seas dramático”. Ajustan el plan porque lo que está en riesgo no es una métrica: es la integridad del sistema.

O en la producción de películas. El director llega con una imagen en la cabeza y el productor levanta la ceja porque eso significa días extra de rodaje en un país carísimo. Y no pelean para ver quién manda. Pelean para ver qué intención vale la pena proteger y qué parte del sueño se puede ajustar sin romper la historia.

En la cocina de un restaurante, el chef revisa su línea, todo ordenado porque en treinta minutos empieza el caos. Llega el gerente de sala y dice: “Oye, hoy viene un grupo grande… ¿podemos meter un plato especial?” El chef hace una pausa. No está diciendo “no quiero”. Está calculando fricción, tiempos, errores. Si acepta, algo más se va a romper. Si no acepta, el gerente pierde una oportunidad de venta. Y lo resuelven hablando claro: puedo hacerlo, pero te va a costar veinte minutos más por mesa. Tú dime qué prefieres sacrificar.

Todas estas historias hablan de lo mismo: dos roles legítimos, con responsabilidades que chocan por diseño, tratando de construir algo que ninguno podría hacer solo. Cuando olvidamos eso, reducimos el trabajo a peleas de ego. Cuando lo recordamos, aparece esa sensación rara de “así debería sentirse colaborar con adultos”.

La curiosidad y la humildad pagan con dividendos:

La ganancia real para los pacientes fue la seguridad. Los resultados mostraron que el nuevo procedimiento de relevo había roto el vínculo entre los errores técnicos y los errores de información. Antes de que se introdujera el nuevo protocolo, los pacientes que habían tenido equipo “menos que perfecto” presentaban una mayor tasa de omisiones de información en la sesión de traspaso. Con el nuevo protocolo, el hecho de que alguien cometiera un error con el equipo ya no hacía más probable que alguien olvidara comunicar una pieza importante de información al equipo de UCI.

Antes del nuevo protocolo de relevo, aproximadamente el 30% de los errores con pacientes ocurrían tanto en el equipo como en la información; después, solo el 10% de los errores ocurrían en ambas áreas. Aunque no era perfecto, el hospital sí mejoró. Separar el momento en que se cambiaba el equipo y el momento en que se intercambiaba la información en etapas distintas del protocolo cortó el vínculo entre errores en la manipulación del equipo y errores en los informes. La Dra. Catchpole encontró interesante la reacción del hospital ante el éxito del ejercicio de benchmarking. La gente no reaccionó diciendo: “Esto es genial, ya no necesitamos hacer nada más.” Lo que dijeron fue: “Esto es genial, pero podemos hacerlo aún mejor.”

¿Cuándo fue la última vez que viste a alguien en la industria de software voltear a ver cómo se resuelven estos problemas fundamentales de colaboración en otras industrias? ¿Qué otras cosas podrías aprenderle a industrias y disciplinas que podrían parecer no tener nada que ver con desarrollo de software?

Si leer esto te tocó un nervio y quieres mejorar, yo te puedo dar el coaching que necesitas. Llena el formulario y trabajemos juntos. 

Puedo ayudarte a diseñar una carrera más clara, más tuya y más sostenible. Conoce cómo.

Vuélvete miembro para dejar comentarios, y desbloquear otros beneficios.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *