Deja que la tecnología exista antes de terminarla: el caso de la implementación iterativa

Resumen del artículo:El instinto habitual en los proyectos tecnológicos es planificar a fondo, construir completamente y entonces publicar. E…Pensamos en nuestros clientes, así que hemos hecho una breve extracción del artículo. Pulsa para entender la idea principal rápidamente.

El instinto habitual en los proyectos tecnológicos es planificar a fondo, construir completamente y entonces publicar. El resultado es un largo intervalo durante el cual no llega información real de usuarios reales, seguido de un lanzamiento que a menudo revela que unas partes del sistema importan mucho más que otras. El enfoque más productivo es poner algo real en manos de clientes reales lo antes posible y dejar que la experiencia de usarlo revele qué construir a continuación.

Hay una creencia específica que hace que los proyectos tecnológicos duren más de lo necesario, y no es sobre complejidad técnica ni presupuesto. Es la convicción de que el sistema necesita estar completo antes de que se le permita ser experimentado. El portal de cliente completo antes de que ningún cliente lo use. El flujo de trabajo automatizado completo antes de que ninguna parte de él se ejecute. El chatbot terminado con cada pregunta frecuente cubierta antes de que aparezca en la web.

La intención detrás de esta creencia es respetuosa: quieres presentar algo pulido, algo que cumpla el estándar que tus clientes esperan. La consecuencia, sin embargo, es que el punto en el que llega información real de uso real se empuja cada vez más hacia el futuro. Y esa información, el patrón de cómo las personas interactúan realmente con el sistema, es el dato más valioso disponible para las decisiones sobre qué construir a continuación.

El patrón en cómo se desarrollan las plataformas

Cada plataforma digital que está en uso generalizado hoy, cada marketplace, cada herramienta profesional, cada aplicación de consumo, empezó con una versión dramáticamente más simple que la que existe ahora. La versión inicial hacía un pequeño número de cosas, algunas de ellas imperfectamente, y las personas que la usaron dijeron al equipo, mediante su comportamiento y a veces directamente, qué necesitaban más y dónde encontraban fricción.

Las decisiones que dieron forma al desarrollo de esas plataformas, las funcionalidades que se volvieron centrales y las que quedaron en desuso silenciosamente, se tomaron con esos datos de uso real y no desde la especificación inicial. La especificación era el punto de partida, no la guía. La guía era la experiencia real de personas reales usando un producto real.

Esta dinámica aplica directamente a los negocios de servicios que implementan tecnología por primera vez. El empresario y el equipo de implementación juntos tienen una imagen clara de lo que la tecnología debe hacer. Esa imagen merece la pena actuar sobre ella. Es la base para la primera versión. Pero la siguiente versión, y la que viene después, debería estar moldeada significativamente por lo que los clientes que usaron la primera versión experimentaron.

Por qué la visibilidad importa tanto como la calidad

Hay una dimensión práctica en el argumento para publicar pronto que merece decirse directamente. Una inversión tecnológica, por bien diseñada que esté, produce valor solo si es visible, está en uso y cumple con lo que fue construida para hacer. Un sistema aún en desarrollo no hace ninguna de estas cosas. Un sistema que se publica, aunque sea en forma limitada, puede ser visto, puede ser experimentado, y puede comenzar a demostrar su valor.

Para un negocio de servicios, esto significa que un sistema de recordatorios de citas funcionando en su forma más simple, un solo mensaje a un intervalo fijo antes de cada cita, es más útil que un sistema sofisticado de recordatorios en múltiples pasos que todavía está siendo configurado. La versión simple hace algo real para los clientes que lo reciben y genera feedback real. La versión sofisticada, hasta que se lanza, no genera nada.

Esto no es un argumento para lanzar productos que estén mal construidos o que fallen en su promesa central. Es un argumento de que el estándar para lo que califica como "listo para publicar" en la mayoría de los proyectos tecnológicos empresariales se establece más alto de lo necesario, y que el coste de ese tiempo extra de desarrollo se paga en beneficio retrasado y en ausencia de la información del mundo real que habría hecho más efectiva la siguiente fase de desarrollo.

Cómo GLC estructura la implementación para esto

Los planes de implementación que construimos con los clientes incluyen puntos de revisión explícitos después de cada etapa de publicación. En cada punto de revisión, las preguntas que hacemos no son solo si la tecnología está funcionando como se diseñó, sino qué revela la experiencia de usarla sobre lo que más importa a las personas a quienes está diseñada para servir.

Las preguntas típicas de revisión incluyen cómo está encontrando el equipo administrativo el nuevo flujo de trabajo, dónde siguen haciendo cosas manualmente que el sistema debería haber cubierto, qué están mencionando o preguntando los clientes en sus interacciones con el negocio, y si alguna parte de la implementación está creando fricción que no se anticipó. Las respuestas a estas preguntas, recogidas después de cada etapa de un despliegue por fases, producen un conjunto de prioridades de desarrollo que está fundamentado en el uso real y no en supuestos de planificación.

Las empresas que terminan con entornos tecnológicos que las sirven genuinamente casi siempre llegaron a su estado actual mediante ese tipo de proceso iterativo. El sistema completo que tienen ahora es el producto de muchos ciclos de uso, observación y ajuste. El camino hacia un sistema completo es más largo en tiempo de calendario, pero produce consistentemente sistemas que se usan en lugar de sistemas que simplemente se toleran.

Si quieres hablar sobre cómo estructurar una implementación por fases para un proyecto tecnológico que estás considerando, esa es una conversación donde GLC puede proporcionar un marco específico basado en lo que ha funcionado en contextos similares. Escríbenos.