Tu equipo lleva meses con Copilot. Algunos ingenieros lo adoran, otros lo ignoran. Cuando preguntas si está funcionando, la respuesta es «creo que sí». Nadie tiene datos. Esto tiene solución, y empieza con un primer trimestre con orden.
Hay un escenario que se repite en muchos equipos de desarrollo. Puede que sea el tuyo.
Lleváis meses con herramientas de IA activas. Algunos ingenieros les sacan partido, otros ni las tocan. Hay sensación de que algo ha mejorado, pero cuando alguien pregunta «¿cuánto?» o «¿dónde?», la respuesta es vaga. No hay datos. No hay criterios compartidos. No hay una forma clara de saber si esto está funcionando o solo está creando la ilusión de que funciona.
Esto no es un desastre. Es algo peor: un caos ordenado. Parece que todo avanza porque hay actividad, pero no hay dirección. Y la reacción natural, meter más herramientas, más formación, más iniciativas, suele empeorar las cosas.
Lo que necesitas no es hacer más. Es hacer con orden. Y eso cabe en 90 días.
Lo que este plan resuelve (y lo que no)
Un plan de 90 días no te va a llevar a la madurez. Eso lleva más tiempo. Lo que sí va a hacer es sacarte de la improvisación: construir una lectura honesta de tu punto de partida, concentrar esfuerzos donde hay más retorno, poner los primeros límites útiles y generar una base de evidencia para decidir qué viene después.
Si en 90 días consigues que tu equipo pueda responder con datos básicos a «¿dónde nos está aportando valor la IA y dónde no?», ya habrás avanzado más que la mayoría de organizaciones.
Semanas 1-2: entiende qué está pasando de verdad
No empieces rediseñando procesos ni lanzando nuevas iniciativas. Empieza escuchando.
Lo que tienes que hacer:
Habla con 8-12 personas clave: tech leads, ingenieros senior, un par de perfiles junior, algún PM técnico. No hagas una encuesta, ten conversaciones. Lo que buscas es entender cómo se está usando la IA en el día a día real: qué herramientas, en qué momentos del flujo, con qué frecuencia, con qué resultados percibidos.
Mapea los flujos que más usa IA y los que menos. Identifica dónde hay señales claras de valor (tareas que antes tardaban X y ahora tardan Y) y dónde hay señales de riesgo (código que nadie entiende, revisiones que se saltan, inconsistencias entre equipos).
Lo que no debes hacer:
No intentes sacar conclusiones definitivas todavía. El objetivo de estas dos semanas es tener un mapa, no un veredicto. Tampoco hagas un cuestionario formal, generarás datos sin contexto. Las conversaciones te dan matices que un formulario nunca te dará.
Cómo sabes que has terminado esta fase:
Puedes llenar una tabla mental con tres columnas: «dónde hay valor claro», «dónde hay dudas» y «dónde hay riesgo». Si no puedes, necesitas más conversaciones.
Semanas 3-4: prioriza y pon los primeros límites
Ahora que tienes una foto real, la tentación es intentar arreglarlo todo. No lo hagas. Enfoca.
Lo que tienes que hacer:
Escoge entre 5 y 7 casos de uso donde concentrar esfuerzos. No los 20 que han surgido los 5-7 que tienen más retorno potencial con menor riesgo. En equipos de desarrollo, esto suele ser: generación y revisión de tests, documentación técnica, refactors de bajo riesgo, soporte en tareas repetitivas, y análisis de código legacy.
Define guardrails mínimos. No para bloquear, sino para dar coherencia. Decide qué se puede delegar a la IA y qué no. Aclara en qué contextos se necesita más revisión humana. Establece qué estándares de calidad son innegociables. Escríbelo en una página, si no cabe en una página, es demasiado complejo para esta fase.
Asigna un owner. No un comité, una persona con nombre y apellidos que sea responsable de que este plan se ejecute. Sin ownership, esto se diluye en la siguiente semana con carga de trabajo.
Lo que no debes hacer:
No te obsesiones con las métricas perfectas todavía. Empieza midiendo algo sencillo: nivel de uso en los flujos priorizados, percepción de valor por equipo, y si los guardrails se están respetando o no. Perfeccionarás las métricas después.
Cómo sabes que has terminado esta fase:
Puedes responder a «¿en qué 5 cosas nos estamos concentrando, con qué límites y quién es responsable?». Si la respuesta es clara, adelante.
Semanas 5-8: prueba en contexto real
Aquí es donde las decisiones se encuentran con la realidad. Y la realidad siempre tiene sorpresas.
Lo que tienes que hacer:
Escoge 1-2 equipos y trabaja con ellos de forma intensiva. Aplica los casos de uso priorizados y los guardrails definidos. Observa qué pasa. No «monitoriza desde arriba», involúcrate lo suficiente para ver las fricciones de cerca.
Presta atención especial al modelo de revisión. Este es el punto donde más organizaciones se atascan: el código se genera más rápido pero la revisión sigue exactamente igual, y el cuello de botella se desplaza sin que nadie lo verbalice. Si esto pasa, necesitas adaptar la revisión: no todos los cambios tienen el mismo riesgo ni necesitan el mismo nivel de validación. Diferencia. Un refactor menor asistido por IA no necesita la misma revisión que un cambio en la lógica de negocio.
Dale contexto a la IA. La calidad de lo que genera depende directamente del contexto que recibe. Si tus equipos trabajan sin estándares compartidos, sin convenciones claras, sin buenas prácticas documentadas, la variabilidad de los resultados será alta. Invierte tiempo en dar estructura: patrones, convenciones, ejemplos de referencia. Esto no es solo una mejora técnica, es lo que convierte a la IA de impredecible en útil.
Lo que no debes hacer:
No escales antes de validar. Si algo funciona en un equipo, antes de llevarlo a diez necesitas entender por qué funciona, puede que dependa de las personas, no del proceso. Y no ignores los resultados negativos: si un caso de uso no está dando el valor esperado, descártalo pronto y concentra recursos en los que sí.
Cómo sabes que has terminado esta fase:
Tienes evidencia (no solo percepciones) de qué funciona y qué no. Los equipos piloto pueden explicar con claridad dónde la IA les aporta y dónde no. Y el modelo de revisión ha sido al menos discutido, si no adaptado.
Semanas 9-12: consolida y prepara lo que viene
Si has llegado aquí con las fases anteriores bien hechas, ya no estás improvisando. Ahora toca convertir los aprendizajes en algo que se sostenga más allá de estos 90 días.
Lo que tienes que hacer:
Consolida lo que ha funcionado. Documéntalo de forma sencilla (no un whitepaper, un documento de dos páginas que cualquiera pueda leer en 10 minutos). Incluye: qué casos de uso se han validado, qué guardrails se están aplicando, qué métricas se están recogiendo y qué fricciones se han encontrado.
Comparte entre equipos. Lo que has aprendido con los equipos piloto necesita llegar al resto. Monta una sesión breve, abre un canal dedicado, crea un repositorio de prácticas, el formato da igual. Lo que importa es que el conocimiento deje de estar en las cabezas de unas pocas personas.
Haz una lectura ejecutiva. Siéntate con los stakeholders relevantes y repasa: ¿qué hemos aprendido? ¿Dónde hay más valor? ¿Dónde hay más riesgo? ¿Qué debería ser el siguiente paso? Esta sesión es la que transforma un proyecto piloto en el inicio de una adopción real.
Define la siguiente etapa. No un plan a 18 meses, simplemente los próximos 90 días. Con la visibilidad que tienes ahora, esas decisiones serán mucho mejores que las que podías tomar al principio.
Cómo sabes que has terminado esta fase:
Puedes responder con datos a las tres preguntas que al principio dependían de la intuición: «¿dónde nos está aportando valor la IA?», «¿dónde hay riesgo?», y «¿qué deberíamos hacer a continuación?».
En 90 días no estarás maduro. Pero ya no estarás ciego.
Este plan no resuelve toda la madurez. Pero hace algo que la mayoría de organizaciones no han hecho todavía: sustituir la improvisación por evidencia. Y a partir de ahí, cada decisión que tomes sobre IA en tus equipos de desarrollo será mejor que la anterior.
El valor de estos primeros 90 días no está en demostrar actividad. Está en construir la base para que los próximos 18 meses tengan dirección.
