El piloto funcionó y la implementación no

La brecha que nadie planea

El piloto termina bien. Un grupo de voluntarios utilizó el sistema durante un trimestre y reportó que les ahorró tiempo. Se toma la decisión de implementarlo para todos. Dentro de un mes, el uso es una fracción de lo que el piloto predijo y el grupo de piloto está defendiendo una herramienta que la mayoría de la organización ha abandonado silenciosamente.

El sistema no cambió. La población sí, y la población nunca fue parte del diseño.

Tres propiedades que un piloto no puede decirte

Los voluntarios son tolerantes. Las personas que se inscriben en un piloto están interesadas en que funcione, y compensan los fallos reexpresándolos, reintentándolos y verificando los resultados. Nada en su comportamiento te dice si la misma calidad se mantiene con un usuario que se le dijo que use la herramienta y no tiene interés en su éxito.

Los arreglos manuales son requisitos invisibles. Durante un piloto, alguien vuelve a subir un documento, corrige una solicitud o arregla una entrada de índice a mano cada semana. Esas intervenciones mantienen la calidad medida alta mientras ocultan el trabajo de ingeniería que se requerirá en la implementación. El inventario honesto es una lista de lo que los humanos hicieron alrededor del sistema, y cada elemento es either automatizado o aceptado como costo permanente.

La adopción se mide de manera incorrecta. Las encuestas de satisfacción miden el entusiasmo, que los pilotos tienen en exceso. Lo que predice la implementación es la repetición: la proporción de usuarios que regresan sin ser solicitados en semanas consecutivas, y la proporción del flujo de trabajo objetivo que realmente se mueve hacia la herramienta en lugar de ser duplicado alrededor de ella.

Qué recopilar antes de la decisión de implementación

• Usuarios que regresan semanalmente, no usuarios totales. Un piloto con treinta participantes y cinco que regresan es un producto de cinco personas con espectadores entusiastas.
• Una lista escrita de cada intervención manual realizada durante el piloto, con un propietario y una decisión para cada una.
• La tasa de fallos en los usuarios menos similares al grupo de piloto — aquellos que se unieron tarde, o que fueron agregados debido a una reorganización en lugar de porque lo solicitaron.
• El costo del piloto a escala de implementación, incluyendo la carga de soporte que actualmente recae en el equipo de piloto como efecto secundario de su entusiasmo.
• Un flujo de trabajo, definido lo suficientemente estrecho como para que el éxito sea inequívoco, en lugar de una plataforma que se espera que absorba varios.

Implementar de todos modos

La implementación sigue siendo generalmente la decisión correcta; el error es tratarla como una expansión de lo mismo en lugar de una nueva implementación con una nueva población. Ejecútala en cohortes, mantén la instrumentación que midió a los usuarios que regresaban durante el piloto, y staffea la primera cohorte con la misma atención que recibió el piloto. El modo de fallo no es un mal producto, es un buen piloto malinterpretado como evidencia sobre desconocidos.