Para explicar un proyecto técnico a un público no técnico, empieza por las consecuencias que necesita entender y muestra después el mecanismo necesario para valorar las pruebas y las contrapartidas. Sustituir palabras técnicas por otras más cortas solo ayuda si también facilita seguir el razonamiento.
Tus colegas pueden conocer al cliente, el proceso operativo o el presupuesto mucho mejor que tú. Lo que quizá les falte sea el contexto especializado de un diagrama de arquitectura. Constrúyelo sin eliminar la incertidumbre necesaria para juzgar la propuesta. Con el texto revisado, puedes preparar una presentación a partir de texto en Presenti y conservar ese razonamiento al editar el borrador.
Empieza por la pregunta que debe responder el público
Anota quién estará en la reunión y qué necesitas de cada persona. Soporte puede tener que explicar un cambio a los clientes; producto, elegir el alcance de un piloto; finanzas, entender el compromiso de recursos. Estas preguntas requieren detalles distintos de los de una revisión de código.
En el ejemplo, un equipo de ingeniería solicita permiso para probar una nueva manera de generar informes. Participan producto, operaciones y soporte. Deben entender qué verá el usuario, qué puede fallar y qué pruebas hacen falta antes de ampliar el despliegue.
La guía de diapositivas del MIT EECS Communication Lab recomienda adaptar la explicación a los conocimientos del público, presentar las figuras desconocidas y dar un mensaje claro a cada diapositiva. Decide qué parte del mecanismo necesita comprender la audiencia antes de mostrar toda la arquitectura.
Antes y después: explicar una propuesta de informes con cola
Este es un ejemplo didáctico de comunicación. El sistema propuesto y los datos de práctica ilustran una reescritura; no son resultados de clientes ni de una prueba de producto en funcionamiento.
La primera diapositiva se titula «Orquestación asíncrona con colas persistentes y procesos de trabajo idempotentes». El diagrama muestra una puerta de enlace de API, una cola, procesos de trabajo, una base de datos, flechas de reintento y monitorización. Un especialista puede reconocer el patrón. Los demás todavía necesitan saber qué cambia para quien solicita un informe.
Reescribe el título: «El usuario podrá salir de la página mientras se prepara el informe». Debajo, muestra la secuencia propuesta:
- El usuario solicita un informe.
- La aplicación confirma la recepción y registra una tarea pendiente.
- Un proceso en segundo plano prepara el informe.
- La aplicación muestra el resultado terminado o un estado de error claro.
Añade junto al diagrama la diferencia esencial: «Solicitud aceptada» no significa «Informe listo». Una confirmación rápida puede cambiar la experiencia de espera, pero no demuestra por sí sola que el cálculo termine antes.
La guía de Microsoft sobre nivelación de carga mediante colas explica cómo una cola separa la llegada de trabajo de su procesamiento. También advierte que la cola crece si el trabajo llega más rápido de lo que se procesa. Para esta presentación, se convierte en una pregunta sencilla: «¿Qué verá el usuario si se acumulan tareas pendientes?».
Conserva los términos necesarios para decidir
Algunos términos merecen una definición; otros pueden quedarse en el anexo de ingeniería. Explica una vez cada término necesario en su contexto y utiliza después la misma expresión.
| Término | Explicación para el público | Pregunta que ayuda a responder |
|---|---|---|
| Cola | Lugar donde esperan las tareas de informes pendientes de procesamiento. | ¿Qué ocurre cuando muchas personas piden informes a la vez? |
| Proceso de trabajo | Proceso en segundo plano que genera el informe. | ¿Qué sigue trabajando cuando el usuario abandona la página? |
| Reintento | Un nuevo intento después de un fallo o una interrupción. | ¿Cómo se recupera una solicitud y cuándo debe intervenir alguien? |
| Procesamiento idempotente | Procesar de nuevo la misma tarea sin producir un resultado duplicado no deseado. | ¿Qué evita que un reintento duplique registros o acciones? |
La tabla no demuestra que el sistema ya resuelva correctamente estos casos. Identifica lo que ingeniería debe explicar o probar. Conserva el tratamiento real de fallos, las decisiones de implementación y las pruebas en el material de apoyo.
Una analogía puede abrir la explicación: la cola se parece a una fila de solicitudes por atender. Explica también dónde deja de servir. Varios procesos y los reintentos pueden afectar al orden, de modo que una imagen de «primero en entrar, primero en salir» podría atribuir al diseño un comportamiento que no ofrece.
Haz comprensibles los datos sin reforzar sus conclusiones
Utiliza este conjunto para practicar: de 100 solicitudes de informes, 90 terminan en 60 segundos y diez tardan más. Supongamos un objetivo del 95 % en 60 segundos. Son datos ilustrativos, no mediciones de un sistema probado para este artículo.
| Qué dice el ejemplo | Qué permite concluir |
|---|---|
| 90 de 100 solicitudes terminan en 60 segundos. | La proporción dentro del intervalo es del 90 %. |
| El objetivo ilustrativo es del 95 % en 60 segundos. | La muestra queda por debajo; una confirmación rápida no elimina esa diferencia. |
| No se aporta comparación con el sistema actual. | No se demuestra una mejora de rendimiento. |
| No se desglosan las diez solicitudes más lentas. | La causa del retraso sigue siendo una pregunta, no un hallazgo. |
Una diapositiva débil dice «La nueva arquitectura genera informes rápidos». Un título más útil es «La muestra de práctica no alcanza el objetivo propuesto de tiempo de finalización». Muestra denominador y umbral junto a los datos y explica qué pruebas adicionales podrían cambiar la decisión.
En una propuesta real, define cuándo empieza y termina la medición, la carga, el número de solicitudes y si se incluyen los fallos. Separa observaciones, previsiones y objetivos. Si comparas el sistema actual y el propuesto, utiliza condiciones comparables o explica las diferencias. La guía de narrativa de datos en inglés desarrolla ese recorrido desde la evidencia hasta la acción.
Seis diapositivas que conservan la pregunta de ingeniería
Puedes adaptar este relato al ejemplo de informes. Sustituye los detalles ilustrativos por datos revisados del proyecto antes de utilizarlo en el trabajo.
Diapositiva 1: la experiencia actual
Título: «Generar un informe obliga al usuario a esperar en la página».
Explicación oral: «El flujo actual pide permanecer aquí hasta que se prepara el informe. Evaluamos otro que confirma la solicitud y permite acceder al resultado después». Muestra los pasos actuales y no añadas una tasa de fallos que no hayas medido.
Diapositiva 2: qué cambiaría
Título: «El flujo propuesto separa solicitar el informe de recibirlo».
Explicación oral: «La aplicación registra la solicitud, un proceso en segundo plano crea el informe y el usuario ve su estado. Confirmar y terminar son sucesos distintos». Utiliza el diagrama de cuatro pasos, no todo el mapa de despliegue.
Diapositiva 3: qué se sabe
Título para los datos de práctica: «El 90 % termina en 60 segundos, por debajo del objetivo propuesto del 95 %».
Explicación oral: «La muestra ilustrativa contiene 100 solicitudes. Diez superan el umbral. Necesitamos mediciones representativas y una referencia del sistema actual antes de afirmar una mejora». En una presentación real, sustituye el ejercicio por pruebas y límites reales.
Diapositiva 4: la nueva responsabilidad
Título: «El nuevo flujo necesita estados y recuperación claros».
Explicación oral: «El usuario necesita saber si el informe está pendiente, terminado o fallido. Soporte debe distinguir una tarea lenta de otra que requiere intervención. El diseño debe permitir reintentos sin duplicados no deseados». Remite a las preguntas concretas de diseño y pruebas en el anexo.
Diapositiva 5: un siguiente paso acotado
Título: «Un piloto limitado puede probar la espera y la recuperación».
Explicación oral: «Antes de empezar, acordemos participantes, condiciones de entrada y parada, mediciones y responsable. Mediremos finalización y fallos, no solo confirmaciones». Deja los valores en blanco hasta que las personas responsables los acuerden.
Diapositiva 6: la decisión que puedes respaldar
Título: «Decidir si se realiza el piloto y quién revisa los resultados».
Explicación oral: «Solicitamos el piloto con alcance definido y una revisión de las pruebas acordadas antes de ampliarlo». Si quedan cuestiones que impiden incluso ese paso, pide la acción menor necesaria para resolverlas.
Prepara un anexo que responda a la siguiente pregunta
El recorrido simplificado debe conducir al detalle, no hacerlo desaparecer. Usa etiquetas estables: arquitectura y dependencias; definiciones de medición; condiciones de prueba; fallos y reintentos; alternativas consideradas; responsables del despliegue o de la reversión. Señala desde la diapositiva principal la página pertinente.
Prepara preguntas que hagan visible la diferencia esencial. Ante «¿Los informes serán instantáneos?», responde por partes: cambia la confirmación de la solicitud, pero terminar el informe sigue dependiendo del procesamiento y la carga. Ante «¿Qué ocurre si se acumulan tareas?», muestra el plan de estados y recuperación, o explica lo que falta diseñar.
Prueba la explicación con un colega del público previsto. Pídele que describa qué cambia para el usuario y qué decisión solicitas. Si solo recuerda «un sistema más rápido», debes aclarar mejor la diferencia entre confirmar y completar.
Prepara el encargo antes de pedir un borrador
Descarga el encargo de explicación técnica y el relato de seis diapositivas como recurso de texto para copiar. Incluye datos ilustrativos y distinciones que debes conservar.
Reúne en el encargo la descripción del público, las consecuencias, el mecanismo breve, las definiciones, las pruebas revisadas, la incertidumbre y la decisión solicitada. Utiliza ese texto para proponer un esquema y un borrador en Presenti. Cuenta con la persona responsable del proyecto técnico al acortar las explicaciones: una frase más fluida puede eliminar una condición importante.
Explica [proyecto] a [público y funciones]. Necesita comprender o decidir: [tarea]. Utiliza solo el mecanismo y las pruebas proporcionados. Organiza seis diapositivas: consecuencia, mecanismo, pruebas, contrapartida, siguiente paso y decisión. Define los términos desconocidos que requiere la decisión. Conserva unidades, denominadores, incertidumbre y límites. Señala las pruebas ausentes en lugar de inventarlas. Mantén la implementación detallada en un anexo referenciado.
Una señal útil de que la explicación funciona es una conversación más concreta: qué condición sigue pendiente, qué contrapartida es aceptable y qué pruebas hacen falta después. Esas preguntas ayudan tanto a ingeniería como a sus colegas a elegir cómo avanzar.
