Un equipo diseña un servicio de venta de entradas para un festival regional. El sistema soporta la carga prevista sin problemas y la revisión del diseño finaliza con aprobación. Sin embargo, las condiciones cambian: el organizador ahora exige que la venta de entradas siga funcionando incluso si un centro de datos se cae durante el periodo de venta. El mismo diseño ahora presenta un único punto de fallo, y los ingenieros que lo diseñaron deben decidir qué modificar, qué descartar y cómo justificar su decisión.
Este es un escenario ilustrativo, no un incidente documentado. Representa la situación que se busca ensayar en un ejercicio práctico de diseño de sistemas: un diseño que funcionaba bien bajo ciertas restricciones se enfrenta a otras nuevas, y los ingenieros deben justificarlo o revisarlo. Esta guía está dirigida a líderes de capacitación en ingeniería y gerentes de ingeniería. Explica qué es un ejercicio práctico de diseño de sistemas, cómo crearlo, cómo ejecutarlo y calificarlo, y dónde la capacitación deja de ser suficiente. Cada caso y criterio debe ser validado por un ingeniero sénior antes de su uso.
¿Qué es un kata de diseño de sistemas?
Un kata de diseño de sistemas es un ejercicio de diseño breve y con un tiempo limitado. Un pequeño equipo recibe un problema de negocio de un párrafo, esboza una arquitectura, la presenta a sus compañeros y responde preguntas difíciles. Los buscadores también lo llaman kata de arquitectura o kata arquitectónico. El formato fue creado por Ted Neward como un taller y está documentado, con sus reglas y el rol del moderador, en Página de katas arquitectónicos de Neal FordLa pregunta que motiva a Newark, citada allí, es cómo se supone que las organizaciones pueden formar grandes arquitectos cuando los ingenieros tienen la oportunidad de diseñar menos de media docena de veces en toda su carrera. Un kata les brinda repeticiones adicionales sin riesgo de producción.
Datos Rápidos
| Pregunta | Respuesta corta |
|---|---|
| ¿Cuál es la tarea? | Defienda una arquitectura cuando cambie una restricción. |
| ¿De qué tamaño es el grupo? | El formato original utiliza grupos pequeños de 3 a 5 personas, con un moderador. |
| ¿Qué puntuación obtienes? | El razonamiento de compromiso y la respuesta a una nueva restricción, no el diagrama más bonito. |
| ¿Es suficiente con un cuestionario sobre patrones de diseño? | No. Confirma los requisitos previos, pero no si un ingeniero puede justificar una elección bajo presión. |
| ¿Quién valida el caso? | Un gerente de ingeniería o un arquitecto sénior. |
| ¿Qué no puede corregir un kata? | Falta de autoridad en materia de diseño, requisitos poco claros y falta de tiempo para diseñar adecuadamente en el trabajo. |
| ¿Cómo sabes que funcionó? | Un caso nuevo e inédito, evaluado según criterios acordados, además de un seguimiento de las revisiones de diseño reales. |
1. Describa el problema de rendimiento.
Comience por la tarea, no por el tema. La tarea consiste en defender una arquitectura bajo restricciones cambiantes. En el trabajo real, esto sucede en revisiones de diseño, seguimientos de incidentes y reuniones de planificación donde un requisito cambia: mayor tráfico, una promesa de disponibilidad más estricta, una nueva regla de residencia de datos, un presupuesto más ajustado.
Muchos ingenieros pueden diseñar una arquitectura coherente. Menos aún pueden discernir qué sacrificarían cuando dos objetivos entran en conflicto y qué evidencia les haría cambiar de opinión. Esa segunda habilidad es la que se practica en el kata.
Redacte una declaración de rendimiento de una sola frase y pídale a un gerente de ingeniería que la revise: "Dada una arquitectura y una restricción modificada, el ingeniero identifica qué falla, propone un cambio, expone las ventajas y desventajas y menciona lo que aún desconoce".
2. Diagnosticar las deficiencias de aprendizaje y contexto.
Antes de construir nada, compara la tarea con lo que tu programa practica y evalúa actualmente.
- ¿La práctica utiliza la tarea real? Si la formación enseña patrones de forma aislada y la evaluación es un examen de opción múltiple, nadie ha practicado la defensa de una elección.
- ¿Cuál es la demanda cognitiva? En la taxonomía revisada de Bloom, comparar opciones con restricciones se sitúa en analizar y evaluar, y proponer un diseño revisado llega a crear. Nuestra guía para relacionar las actividades de aprendizaje con la taxonomía de Bloom. Muestra cómo adaptar la actividad a ese nivel.
- ¿Hay algo más que habilidad que lo impida? Verifica si los ingenieros tienen tiempo para diseñar, si alguien es responsable de las decisiones de arquitectura y si los requisitos están documentados. Si una decisión la toma alguien ajeno al equipo, ningún ejercicio modificará las capacidades del equipo. Transfiere esas causas a quienes puedan solucionarlas.
3. Preparación y práctica del diseño
Asigne una función específica a cada etapa.
Preparación. Verifica los requisitos previos con un breve diagnóstico: el vocabulario que usa tu equipo (disponibilidad, consistencia, latencia, costo), los conceptos básicos que se espera que conozcan y tu propia plantilla de revisión de diseño. El estudio a tu propio ritmo es adecuado para esta etapa, y una verificación de conocimientos solo confirma los requisitos previos.
Práctica. Ejecuta el kata en sí. En el formato descrito en el sitio web de Neal Ford, después de que se formen los equipos, el ejercicio se desarrolla en tres fases: una fase de discusión donde el equipo define lo que está construyendo, una fase de revisión por pares donde cada equipo presenta y responde preguntas, y una fase de votación donde los compañeros dan un pulgar hacia arriba ("lo lograron"), un pulgar hacia abajo ("faltaron algunas cosas") o un pulgar hacia abajo ("fallaron por completo"). Algunas reglas vale la pena tomar prestadas directamente: los equipos pueden hacer suposiciones sobre tecnología desconocida, pero deben indicarlas, y no pueden asumir que pueden contratar a un equipo de estrellas.
Agregue la restricción variable. El kata estándar presenta un problema fijo. Para entrenar la habilidad en esta guía, añade una segunda tarjeta a la mitad: una restricción modificada que el equipo debe asimilar. Esta es una decisión de diseño nuestra, no forma parte de las reglas originales, así que pruébala.
Comentarios. Vincula la retroalimentación a las decisiones, no a una puntuación total. "Te mudaste a dos regiones, pero no dijiste qué sucede con un pedido realizado durante el cambio" es más útil que "3 de 5".
¿Información en tiempo real o revisión asíncrona? La facilitación en vivo resulta más útil cuando una decisión es ambigua y los ingenieros aprenden de un colega experimentado que explica por qué mantendría su postura. La revisión asíncrona es suficiente para comparar una justificación escrita con un ejemplo comentado.
4. Analice un ejemplo realista.
A modo de ejemplo, un ingeniero sénior debe validar el caso y los criterios de respuesta antes de su uso.
El caso. Un festival regional vende 20 000 entradas durante un fin de semana, con la mayoría de las ventas en los primeros diez minutos. La primera versión del briefing solicita un servicio de reservas que pueda gestionar ese pico de demanda. El diseño consiste en una única capa web, una única base de datos y una llamada al proveedor de pagos al finalizar la compra.
La restricción modificada. A mitad del evento, el organizador añade: las ventas deben continuar aunque un centro de datos deje de funcionar, y no se podrá vender ninguna entrada dos veces.
Un primer intento. "Añadir un segundo centro de datos y replicar la base de datos". El equipo ha recurrido a un componente conocido, pero no ha especificado qué sucede con la regla de no doble venta cuando los dos sitios no pueden comunicarse entre sí.
Comentarios y reintento. El facilitador pide al equipo que identifique los dos objetivos en conflicto y cuál protegerían en caso de una división de la red. En el segundo intento, se les pide que elijan uno y que describan la experiencia del cliente.
Un intento más enérgico. «Protegeríamos la regla de no doble venta. Durante una división, solo el sitio principal vende entradas y el otro muestra una página de espera. Aceptamos una menor disponibilidad durante un breve período para evitar vender el mismo asiento dos veces. Hemos asumido que la división es poco frecuente y breve, y nos gustaría que el organizador confirmara que una página de espera es aceptable. Si necesitan que ambos sitios vendan, asignaríamos bloques de asientos separados a cada sitio con anticipación, a costa de algunos asientos sin vender». Nótese que esta respuesta identifica el conflicto, toma partido, indica el costo y señala lo que desconoce.
Explicar por qué cada respuesta es defendible o incompleta. Evalúe cada opción según criterios aprobados, no según la arquitectura preferida del revisor. El primer intento menciona un componente, pero no ofrece ventajas ni desventajas. El intento más sólido es específico, expone sus supuestos y ofrece una alternativa con su precio.
5. Evaluar la capacidad y planificar la transferencia
La evidencia de capacidad se manifiesta en el desempeño en un caso nuevo que el ingeniero no ha visto. Se evalúa el razonamiento de compensación y la respuesta a una nueva restricción. Una rúbrica simple utiliza una escala de 0 a 2 por criterio:
| Criterio | Evidencia observable |
|---|---|
| Ejecución de tareas | Defiende la arquitectura bajo la restricción modificada y documenta las pruebas que respaldan la decisión. |
| Razonamiento | Explica las limitaciones pertinentes, las alternativas consideradas y lo que aún permanece incierto. |
| Límites | Sigue los procedimientos de diseño aprobados y solicita ayuda cuando le falta información o autoridad. |
Anclajes: 0 significa ausente o sin respaldo, 1 significa parcial con omisiones relevantes y 2 significa completo y justificado según los criterios acordados. Defina los errores críticos por separado, como ignorar un requisito de seguridad o protección de datos establecido, para que una puntuación general no pueda ocultar uno. Esta rúbrica es una propuesta, no un estándar de preparación validado: adáptela con un gerente de ingeniería y póngala a prueba. Nuestra guía para Diseñar prácticas interactivas con retroalimentación útil. Explica cómo redactar comentarios que estén vinculados a las decisiones.
Planifique la transferencia de forma deliberada. Después del kata, pida a cada ingeniero que lleve una decisión de diseño real a una revisión y aplique las mismas preguntas. Una revisión sin culpabilización de un incidente pasado es otro buen puente hacia el trabajo real; consulte nuestra guía para realizar revisiones de incidentes sin culpabilización.
Donde la entrega interactiva ayuda
Los formatos interactivos ayudan cuando todos deben comprometerse antes de ver al grupo. En una sesión kata en vivo, un facilitador puede mostrar la restricción modificada, pedir a cada miembro del equipo que escriba la compensación que haría y por qué, luego revelar la dispersión antes de que comience la discusión. La votación entre pares al final del formato original es fácil de realizar de la misma manera. El mismo caso se puede ejecutar a ritmo propio para la preparación o para los ingenieros que no puedan asistir a la sesión. AhaSlides admite el aprendizaje interactivo y la alternancia entre la entrega en vivo y a ritmo propio. Es una herramienta de presentación y aprendizaje, no un lugar para dibujar o ejecutar arquitectura, así que mantenga los diagramas en una pizarra o en su herramienta de diseño. Verifique cualquier función específica de autoría, retroalimentación o informes en la que planee confiar con su propio flujo de trabajo. Para obtener orientación sobre la elección de formatos, consulte nuestro artículo sobre cuándo utilizar el aprendizaje adaptativo, interactivo y en directo.
Mide lo que cambió
Decida de antemano qué demostraría que los ingenieros pueden defender una arquitectura bajo restricciones cambiantes. Compare el razonamiento de compensación en un caso desconocido con una línea base establecida antes del programa. Defina quiénes participan, el denominador y el cronograma. Si los resultados mejoran, analice qué otros cambios se produjeron durante el mismo período, como una nueva plantilla de revisión de diseño, un cambio de personal o un incidente que llamó la atención, antes de atribuir el mérito a la capacitación.
Restricciones que pueden persistir
- Autoridad de diseño. Si el equipo no toma la decisión, ponerla en práctica tiene un efecto limitado.
- Tiempo Un kata lleva horas; los diseños reales llevan semanas e implican datos que un kata no puede proporcionar.
- Cobertura del caso. Un caso concreto pone de manifiesto algunas disyuntivas. Una puntuación no refleja el criterio general de un ingeniero.
- Complejidad. Una mayor complejidad no implica necesariamente una mejor arquitectura, así que no hay que premiar la mayor cantidad de componentes.
- Transferencia Un buen desempeño en un taller no es lo mismo que un buen desempeño en una evaluación tensa, así que comprueba el rendimiento después del kata, en un entorno real.
Comunica estos problemas a los patrocinadores con anticipación y planifica soluciones específicas. Un kata mejora la capacidad de los ingenieros para explicar y defender sus ideas. No genera autoridad ni tiempo.
Preguntas frecuentes
¿Qué es un kata de diseño de sistemas?
Un ejercicio de diseño breve y con tiempo limitado en el que un pequeño equipo esboza una arquitectura para un problema empresarial, la presenta a sus compañeros y responde preguntas desafiantes. También se le conoce como kata de arquitectura.
¿Cuántas personas deberían formar un equipo?
El formato original utiliza grupos pequeños de 3 a 5 personas, generalmente como uno de los 4 a 10 grupos en una sala. Utilice grupos lo suficientemente pequeños para que todos puedan hablar.
¿Cómo se evalúa un kata de diseño de sistemas?
Proporcione un nuevo caso y evalúe el razonamiento de compensación y la respuesta a una restricción modificada según los criterios acordados. La votación de los compañeros es una retroalimentación útil, pero no constituye una calificación por sí sola.
Por dónde empezar
Elija una decisión de diseño recurrente en su organización y redacte un breve párrafo explicativo al respecto. Añada una restricción modificada, pida a un gerente de ingeniería que valide el caso y los criterios de respuesta, y elabore una rúbrica de tres criterios con una lista de errores críticos. Realice una prueba piloto con un equipo antes de implementarla en todo el sistema.
Para ver cómo se puede realizar un kata en directo con tu propio equipo y reutilizarlo posteriormente a tu propio ritmo, explora AhaSlides.
