Una consultoría técnica buena entrega en semanas lo que una contratación tarda meses en cubrir. Una mal contratada quema el mismo presupuesto y devuelve el problema intacto. Los cinco patrones de abajo aparecen antes del primer día del consultor, y ninguno se arregla pagando más caro.
Error 1: contratar consultoría para esquivar una decisión
"Traigamos a un consultor para que recomiende qué hacer." La frase aparece cuando el equipo está dividido, el CTO no tiene posición formada o un stakeholder está presionando. El consultor escribe la recomendación y el equipo dividido sigue dividido a la hora de ejecutar.
La consultoría rinde cuando el CTO ya tiene una posición técnica y quiere ponerla a prueba con una mirada externa, cuando falta capacidad de ejecución o cuando alguien tiene que estructurar el proceso de implementación. Marty Cagan separa estos roles en Empowered (Wiley, 2020): la dirección y los límites salen de la dirección del equipo, y la ejecución se queda con el equipo interno.
Error 2: alcance abierto
"Queremos mejorar la arquitectura" es una aspiración. El alcance de una consultoría es una frase con número y fecha: refactorizar la capa de API para soportar 10x el volumen actual, definir la estrategia de migración del monolito, subir el nivel técnico del equipo en tres meses.
Un alcance abierto deja al consultor sin definición de terminado y a ti sin criterio de cobro. El proyecto corre sin fin y las dos partes salen de la relación frustradas.
Error 3: usar al consultor como recurso de desarrollo
Un consultor técnico senior pasando los días en tickets de JIRA aplica capacidad cara al lugar equivocado. Will Larson explica en Staff Engineer (O'Reilly, 2021) que el valor de ese perfil está en las decisiones que toma, los estándares que define y las personas que desarrolla.
Si la cuenta son horas de desarrollo, contrata un ingeniero senior vía agencia o PJ. Si la cuenta es criterio técnico de alto nivel, el perfil cambia y el contrato cambia con él.
Error 4: dejar el conocimiento en el consultor
La consultoría sin transferencia crea dependencia. El consultor se va sabiendo más del sistema que el equipo interno, y la empresa se queda con partes que solo él entiende.
Estructura el proceso para que el equipo aprenda mientras tanto: code review explicado, sesiones de arquitectura abiertas, documentación como entregable. Tom Demarco y Timothy Lister muestran en Peopleware (Dorset House, 1999) cuánta capacidad se va cuando alguien con conocimiento del sistema se aleja.
Error 5: pagar por hora
Una hora con el arquitecto correcto puede valer más que dos sprints de desarrollo. Un contrato medido con reloj cambia el incentivo del consultor hacia el tiempo invertido.
Un buen contrato define entregables, criterios de éxito medibles y pago por alcance. W. Edwards Deming listó la gestión por números entre los obstáculos a eliminar en Out of the Crisis (1986); cobrar consultoría por horas trabajadas repite el error.
Qué resolver antes de firmar
Cuatro cosas en papel: el problema específico, el plazo, el criterio de éxito y el contacto interno con autoridad para decidir. Con esos cuatro, el consultor trabaja con foco y tú cobras por resultados. Sin ellos, el contrato se vuelve una apuesta.
Escribe antes de la reunión de propuesta qué tiene que estar distinto en el sistema, el equipo y la operación cuando termine el proyecto. Tres líneas cambian la conversación con cualquier consultoría.
