System Design
Stakeholders y actores
Diferencia stakeholders, actores y usuarios para identificar objetivos, decisiones, riesgos, sistemas externos y conflictos que afectan el diseño.
- Última actualización
- Actualizada
- Nivel
- Fundamentos
System Design
Diferencia stakeholders, actores y usuarios para identificar objetivos, decisiones, riesgos, sistemas externos y conflictos que afectan el diseño.
Un sistema no sirve a “usuarios” en abstracto. Sirve, afecta, limita o depende de personas, roles, áreas, sistemas y entidades con objetivos distintos.
Un stakeholder tiene interés, influencia, responsabilidad o impacto sobre el sistema. Un actor interactúa con el sistema para alcanzar un objetivo. Un usuario es una persona que utiliza una interfaz o canal.
Los conceptos pueden coincidir, pero no son equivalentes:
stakeholder
→ puede decidir, financiar, operar, auditar o resultar afectado
actor
→ participa en un caso de uso
usuario
→ persona que utiliza el sistemaUna entidad regulatoria es stakeholder aunque nunca inicie sesión. Una pasarela de pago es actor externo, pero no usuario humano.
Diseñar solo para quien solicita el proyecto deja necesidades ocultas:
Ignorarlos produce un sistema funcional en el happy path, pero inviable en operación real.
personas y sistemas
↓
roles y objetivos
↓
interacciones y decisiones
↓
requisitos, riesgos y conflictosNo modeles nombres propios como actores. Modela responsabilidades estables.
Laura Gómez
→ persona
Cajera
→ rol organizacional
Cajero
→ actor que registra ventas
Operaciones
→ stakeholder responsable del procesoPregunta quién inicia, aprueba, ejecuta, recibe, corrige y audita cada paso.
Pregunta quién crea, consulta, modifica, comparte, retiene y elimina información.
Pregunta quién detecta, responde, escala y asume impacto.
Pregunta quién define reglas, presupuesto, prioridad y aceptación.
Incluye proveedores, dispositivos, jobs, APIs, autoridades y sistemas legacy.
Los primarios obtienen valor directo; los secundarios soportan, administran o reciben efectos indirectos.
Los internos pertenecen a la organización; los externos son clientes, proveedores, reguladores o integraciones.
Una matriz ayuda a planear participación:
| Interés bajo | Interés alto | |
|---|---|---|
| Poder alto | Mantener satisfecho | Involucrar estrechamente |
| Poder bajo | Monitorear | Mantener informado y escuchar |
No uses la matriz para silenciar personas con poco poder; sus necesidades pueden revelar riesgos operativos o éticos importantes.
Nombre o rol:
Tipo:
Objetivos:
Responsabilidades:
Decisiones que controla:
Información que necesita:
Dolores actuales:
Riesgos que percibe:
Influencia:
Disponibilidad:
Conflictos:
Representante u owner:Un actor debe tener un objetivo observable:
Actor: Cajero
Objetivo: registrar una venta válida
Actor: Repartidor
Objetivo: consultar y completar entregas asignadas
Actor: Pasarela de pago
Objetivo: confirmar o rechazar una transacción mediante contrato“Administrador” es demasiado amplio si mezcla configuración, soporte, auditoría y negocio. Divide cuando los objetivos y permisos sean distintos.
Un actor expresa una interacción de negocio. Los permisos técnicos implementan autorización.
actor: encargado de inventario
objetivo: ajustar stock con justificación
permisos posibles:
inventory.read
inventory.adjust
inventory.auditNo diseñes el modelo de actores copiando directamente roles de IAM, ni al revés.
Puede modelarse un actor general cuando varios comparten comportamiento real:
Empleado
├─ Cajero
└─ Encargado de inventarioEs útil si ambos participan en casos comunes. No construyas jerarquías solo porque existen en el organigrama.
Para un sistema de pedidos:
| Stakeholder/actor | Objetivo | Necesidad | Riesgo |
|---|---|---|---|
| Cliente | Recibir pedido correcto | Estado y privacidad | Cobro o entrega incorrecta |
| Operaciones | Coordinar preparación | Cola y trazabilidad | Pedidos estancados |
| Repartidor | Completar entrega | Dirección y contacto mínimo | Datos desactualizados |
| Soporte | Resolver incidentes | Historial y correlación | No poder explicar qué ocurrió |
| Finanzas | Conciliar pagos | Referencias estables | Diferencias contables |
| Pasarela | Procesar pago | Contrato e idempotencia | Timeout o duplicación |
El diseño debe reconciliar estas necesidades, no optimizar solo una.
Ejemplos:
soporte quiere más datos
↔ privacidad exige minimización
caja quiere menos pasos
↔ control interno exige aprobación
negocio quiere entrega rápida
↔ operaciones necesita capacidad realProceso:
No todos necesitan asistir a todas las reuniones.
La representación incorrecta también es un riesgo: un gerente puede no conocer excepciones diarias; un usuario experto puede no representar a principiantes.
Registra la ausencia como riesgo. Usa proxies, evidencia y validación posterior; no inventes sus necesidades.
Incluye accesibilidad, privacidad y consecuencias aunque no tengan influencia política.
Trátalo como dependencia crítica y escala hasta encontrar responsable contractual u operativo.
Modela capacidades y objetivos, no títulos rígidos.
La autorización y la experiencia pueden cambiar según el contexto activo.
Produce visión parcial y problemas operativos posteriores.
“Ventas” no dice quién hace qué ni con qué objetivo.
Jobs, webhooks y dispositivos también disparan comportamiento.
Las responsabilidades no siempre se traducen uno a uno en roles técnicos.
Las personas son útiles si sintetizan investigación; inventadas añaden falsa certeza.
Visión y objetivos del sistema transforma necesidades de stakeholders en resultados y criterios de éxito compartidos.