Decidir y avanzar cuando cambian las prioridades

Empieza por una decisión

Cuando todo parece urgente, una lista más larga rara vez ayuda. Conviene identificar qué decisión está detenida, quién puede tomarla y qué información le falta. El primer entregable puede ser un mapa de dependencias o una prueba pequeña, antes de escribir una nueva aplicación.

Un ciclo que el equipo pueda repetir

1. Elegir un problema. Describir una fricción observable: introducir un dato dos veces, buscar una versión o esperar una validación.
2. Acordar un cambio pequeño. Definir quién lo usará, qué entra y qué queda fuera de esta entrega.
3. Probar el recorrido completo. Incluir la excepción y el error, no solo el caso ideal.
4. Observar y decidir. Revisar si el cambio se utiliza y qué impide que funcione antes de añadir más alcance.

Un ejemplo de planificación

Imagina un equipo que recibe solicitudes por email y las copia a una hoja. En vez de empezar por un CRM completo, puede probar un formulario con un responsable, una lista común y un estado visible. La primera revisión compara si se siguen perdiendo solicitudes y si el equipo necesita volver al email para entenderlas.

Este es un ejemplo de método, no un resultado atribuido a un cliente. Si la prueba no reduce la fricción, toca revisar el flujo; automatizar más pasos no resolverá necesariamente el problema.

Qué dejar escrito

Una página basta para empezar: problema, persona responsable, alcance de la prueba, dependencias, señal de mejora y fecha de revisión. Las decisiones que cambian deben actualizarse junto al trabajo, para que diseño, desarrollo y operación compartan el mismo contexto.

Ve cómo trabajamos en Estrategia o cuéntanos qué decisión necesitas desbloquear.