II. Mapa

El señor de los anillos, de J.R.R. Tolkien, es una aventura épica contada en tres
volúmenes y en cientos de páginas. En ella hay lenguas inventadas, historias,
tramas y subtramas en abundancia. Es una historia asombrosa, pero también
complicada.
Realmente es fácil perderse leyendo El señor de los anillos, pero Tolkien
pensó en nosotros. Al principio del libro hay un mapa. Mientras los personajes
atraviesan lugares como el Monte del Destino, las Minas de Moria o las
Montañas Nubladas,[5] el lector puede consultar el mapa y recordar dónde
sucede la acción y cómo se entrelaza la historia.
El mapa que el equipo debe crear el lunes no difiere mucho del de Tolkien: un
diagrama sencillo que representa una gran complejidad. En vez de elfos y magos
moviéndose por la Tierra Media, el mapa mostrará clientes moviéndose a través
de un servicio o de un producto. No es tan emocionante, pero sí igual de útil.
El mapa será un elemento importante durante la semana. Al final del lunes,
habrá que usar el mapa para reducir el desafío a un objetivo específico durante el
sprint. A lo largo de la semana, el mapa dotará de estructura a los bocetos de
soluciones y al prototipo. Ayudará a mantener la visión conjunta de todos los
elementos y reducirá el esfuerzo requerido a la memoria a corto plazo de cada
integrante del equipo.
Pero hay un aspecto que estos mapas no comparten con el del El señor de los
anillos: son sencillos. Por más complicado que sea el desafío empresarial, es
posible convertirlo en un mapa gracias a un par de palabras y unas cuantas
flechas. Para demostrar lo que queremos decir, nos gustaría hablar de Flatiron
Health, una empresa que se enfrentaba a un complejo desafío con un mapa muy
sencillo.
En el exterior, el horizonte de Manhattan quedaba deslucido por la nieve y los nubarrones grises, pero en el interior de la sala de reuniones el ambiente era muy
acogedor. Cuatro de nosotros (Jake, John, Braden y Michael Margolis, nuestro
socio en la investigación) habíamos viajado a Nueva York para realizar un sprint
con Flatiron Health, una de las inversiones más importantes de Google Ventures.
El sprint se iba a llevar a cabo en las oficinas de Google en Manhattan, un
edificio que antiguamente había pertenecido a la Autoridad Portuaria y que
ocupa una manzana completa. La distribución del edificio es confusa; Jake se
perdió en tres ocasiones durante el primer día, pero logramos encontrar el
camino hasta una sala vacía situada en la novena planta, empujamos la mesa
hacia una de las paredes y colocamos las sillas en semicírculo frente a una
pizarra.
Ya conocíamos la historia de Flatiron. La empresa fue fundada por un par de
amigos, Nat Turner y Zach Weinberg. A principios de los años 2000, Nat y Zach
crearon una empresa de publicidad tecnológica llamada Invite Media, que más
adelante vendieron a Google.
Unos años después, ambos empezaron a pensar en su nueva start-up, y el tema
de la salud era el más recurrente. Ambos tenían amigos y familiares luchando
contra el cáncer y habían sido testigos de primera mano de la complejidad de los
tratamientos. Tuvieron una idea. El análisis de datos a gran escala podía, en su
opinión, estudiar montones de informes médicos y de resultados de pruebas y
ayudar a los facultativos a elegir el mejor tratamiento en cada momento. De
modo que dejaron Google y crearon Flatiron Health.
La start-up tuvo un inicio espectacular. Flatiron consiguió reunir más de
ciento treinta millones de dólares para su fundación y adquirió la empresa líder
en el sector de los informes médicos. Contrataron a un equipo de ingenieros y
oncólogos de primer orden y lograron hacerse con cientos de clínicas
oncológicas como clientes. Ya estaban dispuestas las piezas para dar comienzo a
un proyecto que ambos creían que podía tener un impacto profundo en el
desenlace del cáncer: mejorar la participación en los ensayos clínicos.
Los ensayos clínicos facilitan el acceso a los tratamientos más novedosos.
Para algunos pacientes, eso se traduce en medicamentos que pueden salvar sus
vidas. Pero los ensayos clínicos no solo consisten en el uso de nuevos fármacos,
sino también en recopilar mejor los datos. Los resultados obtenidos en cada
ensayo clínico se recopilan y se organizan, de manera que puedan servir de
ayuda a los investigadores interesados en establecer la eficacia de las terapias
nuevas y de las ya existentes.
Sin embargo, en Estados Unidos solo el cuatro por ciento de los pacientes con
cáncer participa en ensayos clínicos. El otro noventa y seis por ciento de los
datos sobre el tratamiento oncológico resulta inaccesible para los médicos y los investigadores que podrían usarlos para comprender mejor la enfermedad y tratar
mejor a los futuros pacientes.
Flatiron quería acercar los ensayos clínicos a todos los pacientes que fueran
aptos para participar. Esperaban crear una herramienta de software que ayudara a
las clínicas oncológicas a asignar pacientes a los ensayos clínicos adecuados; un
trabajo tedioso si se hace a mano, y tal vez el mayor obstáculo a la hora de reunir
participantes para un ensayo. Aquellos pacientes aquejados con el mismo tipo de
cáncer podrían ser susceptibles de participar en ensayos centrados en reexaminar
la eficacia de los tratamientos convencionales. Otros pacientes que presentaran
un tipo de cáncer poco común podrían ser susceptibles de participar en ensayos
que probaran terapias nuevas y mucho más específicas. Había tantos pacientes
con características únicas y tantos ensayos clínicos que sería una tarea imposible
para un ser humano.
La empresa decidió empezar con un sprint, y para ello reunió a un gran
equipo. La Decisora era la doctora Amy Abernethy, jefa del equipo médico de
Flatiron. Nat, el director ejecutivo, estuvo con nosotros unas horas para ponernos
al corriente de todo lo necesario. También se nos unieron seis líderes de
departamentos de Flatiron, oncólogos e ingenieros informáticos, además de Alex
Ingram, un jefe de producción.[6]
Por la mañana, completamos los ejercicios de «Empezar por el final». Elegir
la meta («Más pacientes en ensayos clínicos») fue fácil, así que trasladamos
nuestros esfuerzos al proceso de identificar las preguntas cruciales del sprint.
—Debemos ser rápidos —dijo Amy. Tiene un acento poco común: mitad
australiano, donde se graduó en Medicina, y mitad de Carolina del Norte, donde
pasó varios años dirigiendo investigaciones oncológicas en la Duke University
—. Si te han diagnosticado un cáncer, no puedes sentarte a esperar mientras se
consideran distintos ensayos clínicos. Tienes que empezar el tratamiento
inmediatamente.
Jake le quitó el capuchón al rotulador y pensó un momento, intentando
convertir el problema en una pregunta. Después, escribió en la pizarra para que
todos pudieran leer: «¿Podemos encontrar compatibilidades lo bastante rápido?».
—Cada clínica tiene su propio proceso —explicó Alex, el jefe de producción
—. Son grupos de personas que llevan años trabajando juntas de la misma
manera. Debemos ofrecerles algo que sea infinitamente mejor que el proceso
establecido o no querrán cambiar su dinámica de trabajo.
Jake añadió a la pizarra: «¿Querrán las clínicas cambiar su dinámica de
trabajo?».
Una vez escritas las preguntas del sprint, empezamos con el mapa. Michael
Margolis y Alex Ingram habían hablado con el personal de las clínicas oncológicas y, con ayuda de Amy, nos explicaron cómo funcionaba el proceso de
selección de los participantes en los ensayos clínicos.
Con el fin de encontrar pacientes compatibles con un ensayo clínico, los
médicos y los coordinadores de análisis examinaban largas listas de requisitos:
historial de tratamiento, recuento sanguíneo, mutaciones de ADN en las células
cancerígenas y mucho más. Puesto que el cuidado de los pacientes con cáncer
cada vez es más sofisticado y personalizado, los requisitos son también más
específicos.
—Para un ensayo normal, podemos estar hablando de un puñado de pacientes
adecuados en todo el país —dijo Amy—. Es como buscar agujas en un pajar. Era un sistema complicado y confuso. Pero, tras una hora de discusión y de
revisión, fuimos capaces de crear un mapa sencillo: A la izquierda se incluyó la lista de personas involucradas en la selección de
los participantes en un ensayo clínico: el paciente y el médico (ambos
fundamentales para determinar la decisión sobre el tratamiento), y también el
coordinador del ensayo clínico (a quien era fácil pasar por alto, pero que podía
estar mejor informado sobre la disponibilidad del ensayo). A partir de ese punto,
el mapa muestra al paciente concertando una cita, al médico y al personal
buscando ensayos compatibles, la cita en cuestión, el proceso de inclusión en el
ensayo, y por último, el comienzo del tratamiento.
Tras esos pasos tan sencillos se escondían todo tipo de dificultades
relacionadas con el proceso de inclusión: personal saturado de trabajo, datos
incompletos y lagunas de comunicación. Tal como Amy nos había explicado,
muchos de los médicos que debían sugerir ensayos clínicos ni siquiera estaban al
tanto de los que se estaban llevando a cabo en sus propias clínicas. Por la tarde
tendríamos tiempo para repasar todos los problemas y las oportunidades. Pero de
momento, con este mapa teníamos de sobra para empezar.
Flatiron Health tenía un problema complicado y un mapa muy directo. El mapa
siempre debe ser sencillo. No hay por qué captar todos los detalles y matices. Al
contrario, se deben incluir los pasos fundamentales para que los clientes pasen
del inicio al final, en este caso, del diagnóstico del cáncer a la participación en
un ensayo clínico.
Veamos unos cuantos ejemplos más. (Regalamos puntos extra a quien consiga
encontrar los elementos comunes a todos los mapas.) El lunes que comenzó su
sprint, Savioke tenía que organizar información sobre robótica, navegación,
dinámica hotelera y hábitos de los huéspedes. Este es su mapa: El primer día de su sprint, Blue Bottle Coffe examinó información sobre la
selección de los cafés, la atención al cliente, la dinámica de la cafetería y los
canales de distribución. Aquí está su mapa:
¿Los elementos comunes? Cada mapa está centrado en el cliente y muestra
una lista de actores fundamentales a la izquierda. Cada mapa es una historia con
un principio, un desarrollo y un final. Y, sin importar el tipo de empresa, todos
los mapas son simples. Los diagramas solo se componen de palabras, flechas y
cajas. A partir de aquí, cada equipo puede hacer el suyo.
Dibujar un mapa
El primer boceto del mapa se realizará el lunes por la mañana, tan pronto como
se hayan escrito la meta a largo plazo y las preguntas del sprint. El mapa irá en la
misma pizarra en la que se ha descrito la meta. Es hora de ponerse manos a la
obra. Para dibujar los mapas, hay que seguir estos pasos (hay un listado al final
del libro, así que no es necesario memorizar todo esto):
1. Anotar a los actores (a la izquierda)
Los «actores» son los personajes importantes de la historia. Por lo general son
distintos tipos de clientes, aunque a veces se trata de personas diferentes, como
por ejemplo el equipo de venta o un organismo regulador gubernamental: son
actores importantes y deben anotarse. Y otras veces, por supuesto, hay un robot.
2. Escribir el final (a la derecha)
Normalmente es más fácil imaginar el final que el desarrollo intermedio de la
historia. La historia de Flatiron acababa con el tratamiento. La de Savioke con
una entrega. Y la de Blue Bottle con la compra del café.
3. Palabras y flechas que las unen
El mapa debe ser funcional, no una obra de arte. Deberían bastar las palabras, las
flechas y algún que otro recuadro. No hace falta ser un experto dibujante.
4. Que sea sencillo
El mapa debería tener entre cinco y quince pasos. Si hay más de veinte, es
posible que sea demasiado complicado. Si es sencillo, el equipo puede ponerse
de acuerdo en la estructura del problema sin necesidad de discutir durante la
búsqueda de soluciones.
5. Pedir ayuda
Quien realice el dibujo debería preguntar de cuando en cuando al equipo: «¿Osparece correcto este mapa?».
El primer boceto del mapa debería estar listo en un tiempo de entre treinta y
sesenta minutos, pero no es extraño seguir corrigiéndolo y actualizándolo a lo
largo del día a medida que se discuten los problemas. Nosotros nunca somos
capaces de hacerlo bien a la primera, pero hay que empezar con algo.
Es en este momento cuando se alcanza un punto crucial. Tenemos la idea general
de la meta a largo plazo, las preguntas del sprint y el mapa. Ya pueden verse las
líneas básicas del sprint: las incógnitas que habrá que responder en la prueba del
viernes y la línea argumental de las soluciones y el prototipo. La meta a largo
plazo es la motivación del equipo y su vara de medir.
Durante el resto del día, tomarán la palabra los expertos del equipo para
recabar más información sobre el problema. Surgirán más preguntas a medida
que se avance, y habrá que anotarlas y actualizar el mapa, y tal vez incluso
reescribir la meta a largo plazo. Además, como equipo, se tomarán notas para
añadir más elementos al mapa dibujado en la pizarra.
El trabajo del lunes por la tarde consiste en configurar una visión única
usando el conocimiento personal y la experiencia de todos los miembros del
equipo. En el siguiente capítulo, ofreceremos una receta para obtener
información de los expertos de la empresa y enseñaremos una manera casi
mágica de tomar notas.