Llevar adelante algo que nadie sabe bien cómo se hace
Un proyecto ambiguo no se resuelve planificando mejor: se resuelve convirtiendo incertidumbre en certeza, en el orden correcto. Lo primero que hay que atacar no es lo más grande, es lo que puede hundir todo lo demás.
«Necesitamos que los clientes puedan facturar desde el sistema.» Tres áreas involucradas, un proveedor externo, nadie sabe qué requisitos legales aplican, y hay una fecha que alguien mencionó en una reunión.
La reacción habitual es pedir que se defina mejor el alcance. Rara vez funciona: nadie tiene la definición completa, y esperarla es esperar para siempre. El trabajo de liderar algo así es exactamente el opuesto: avanzar produciendo definiciones, en un orden que reduzca el riesgo lo antes posible.
Qué se ataca primero
El instinto es empezar por lo que se sabe hacer, porque se avanza rápido y se siente bien. Es casi siempre el orden equivocado.
| Orden | Qué se hace primero | Qué pasa a las seis semanas |
|---|---|---|
| Por comodidad | Lo que el equipo sabe hacer | Mucho avance visible y el riesgo grande intacto |
| Por tamaño | La parte más grande | Se descubre tarde que dependía de algo que no se puede |
| Por riesgo | Lo que puede invalidar todo lo demás | Menos avance visible y el proyecto ya no puede fracasar entero |
Convertir incertidumbre en certeza
El método, en cuatro pasos
- Escribí todo lo que no sabés. Sin filtrar, en una lista. La sensación de caos baja mucho cuando la ambigüedad pasa a ser quince preguntas concretas.
- Marcá cuáles bloquean y cuáles no. «No sabemos qué color va el botón» no bloquea nada. «No sabemos si el proveedor permite facturar a nombre de terceros» bloquea el proyecto entero.
- Para cada bloqueante, definí cómo se despeja y quién. Una llamada con el proveedor, una prueba técnica de un día, una consulta al área legal. Con nombre y fecha.
- Publicá la lista. Que todos vean qué está sin definir y quién lo está despejando es lo que evita que quince personas asuman quince cosas distintas.
Antes de seguir, predecí
Coordinar sin ser el cuello de botella
En un proyecto con varias áreas, el riesgo es que toda la información pase por una persona: funciona dos semanas y después se rompe.
Lo que hay que establecer temprano
- Un dueño por frente, con nombre. No un área: una persona que responde por esa parte.
- Un lugar único donde está el estado. Un documento vivo con qué está definido, qué no y quién lo despeja. Si el estado sólo existe en tu cabeza, sos el cuello de botella.
- Una cadencia liviana. Una reunión corta por semana con los dueños de frente, y el resto por escrito.
- Decisiones anotadas donde todos las vean. La mayor parte del retrabajo en proyectos multiárea viene de decisiones que se tomaron en una conversación de a dos.
- Un criterio de terminado por frente, acordado antes de empezar. «Listo» significa cosas distintas para cada área, y eso se descubre siempre tarde.
El proyecto sin definición
Escenario · 1 decisión como mínimo
«Necesitamos que los clientes puedan facturar desde el sistema»
Tres áreas involucradas, un proveedor externo para la integración fiscal, requisitos legales que nadie conoce del todo, y una fecha que alguien mencionó: fin de trimestre. Te piden que lo lideres. ¿Por dónde arrancás?
Pasan tres semanas de reuniones de definición. El documento sigue teniendo huecos en la parte fiscal.
DesenlaceTres de las doce semanas gastadas sin haber reducido el riesgo principal. Y los huecos que quedan son exactamente los que nadie podía llenar desde una reunión: hacía falta probar algo con el proveedor.
El plan queda armado con doce semanas y dependencias entre áreas. En la semana 3, el proveedor avisa que su ambiente de pruebas tarda seis semanas en habilitarse.
DesenlaceEl plan entero se cae por una incógnita que estaba desde el día uno y no se había tocado. Planificar en detalle antes de resolver las incógnitas grandes es ordenar el trabajo alrededor de algo que todavía puede cambiar de forma.
Listás cuatro incógnitas: qué exige la ley, cómo responde el proveedor, si la base soporta el volumen, y cómo se ve la pantalla. ¿Cuál atacás primero?
En la semana 4 hay pantallas lindas. En la 5 se descubre que el comprobante legal exige campos que no estaban en ningún diseño.
DesenlaceSe avanzó en lo que se podía y no en lo que decidía. La pregunta para ordenar no es qué se puede hacer ya, sino qué incógnita, si sale mal, obliga a rehacer más cosas.
En dos semanas queda claro qué exige la normativa y qué campos lleva el comprobante.
DesenlaceBuen primer paso: ahora se sabe qué hay que construir. Y falta el otro riesgo grande, que no depende de vos: conviene haber pedido el acceso al proveedor en paralelo, el primer día, porque su tiempo corre aunque nadie lo empuje.
Pedís el acceso el primer día. Avisan que tarda seis semanas. Quedan seis para integrar y probar. ¿Qué hacés con ese dato?
En la semana 7 el acceso llega y quedan cinco para todo lo demás.
DesenlaceEl dato existía en la semana 1 y se comunicó cuando ya no servía para decidir. Lo que se lidera en un proyecto así no es el trabajo: es la información sobre lo que todavía no se sabe.
Con eso sobre la mesa se consigue un ambiente de pruebas provisorio del proveedor para la semana 3, y se acuerda que la primera entrega cubre sólo un tipo de comprobante.
DesenlaceEl proyecto sigue sin estar definido del todo, y ahora las dos incógnitas que podían hacerlo fracasar están resueltas en el primer mes. Eso es liderar algo ambiguo: no completar la definición antes de empezar, sino producirla en el orden que baje el riesgo primero.
Fijate qué se ataca primero en cada camino. Casi nunca es lo que se puede mostrar antes.
Lo que preguntan sobre esto
Cierre
Autoevaluación
¿Lo entendiste?
Práctica