Equipos y stakeholders

📐 Fundamento

Stakeholder: cualquier persona/grupo afectado por o que afecta al proyecto.

Tipos típicos:

• Sponsor: quien aprueba el proyecto y consigue presupuesto.
• Cliente / Usuario: quien usa el producto.
• Equipo del proyecto: quienes lo construyen.
• Management: la jerarquía organizacional.
• Otros equipos: dependencias internas (otro dev team, infra, legal).
• Externos: proveedores, reguladores, partners.

Mapa de stakeholders (matriz poder × interés):

              Bajo interés       Alto interés
Alto poder    │ MANTENER       │ GESTIONAR    │
              │ SATISFECHOS    │ CERCANAMENTE │
              │ (CEO, regul.)  │ (Sponsor)    │
Bajo poder    │ MONITOREAR     │ MANTENER     │
              │                │ INFORMADOS   │
              │ (otros equipos)│ (usuarios)   │

Plan de comunicación por cuadrante:

Stakeholder Register:

Nombre        | Rol            | Poder | Interés | Posición  | Estrategia
--------------+----------------+-------+---------+-----------+------------------
María (CEO)   | Sponsor        | Alto  | Alto    | A favor   | Reportes mensuales
Juan (CFO)    | Aprueba presup.| Alto  | Medio   | Neutral   | ROI cada quarter
Ana (cliente) | Lead user      | Bajo  | Alto    | A favor   | Beta tester
Carlos (TI)   | Otra área      | Medio | Medio   | En contra | Sync semanal

Anti-patrón: ignorar a stakeholders "en contra". Generalmente tienen razones legítimas que merecen atención.

📐 Fundamento

RACI clarifica roles para cada actividad:

• Responsible: quien HACE el trabajo.
• Accountable: quien rinde cuentas (uno solo).
• Consulted: a quien se consulta.
• Informed: a quien se informa después.

Actividad                    | PM   | Tech Lead | Devs | QA   | PO   | CTO
-----------------------------+------+-----------+------+------+------+-----
Definir requerimientos       | C    | C         | I    | I    | A,R  | I
Diseño técnico               | I    | A,R       | C,R  | I    | C    | C
Implementación               | I    | A         | R    | I    | I    | I
Testing                      | I    | C         | R    | A,R  | C    | I
Decisión de release          | C    | C         | I    | C    | A    | I
Comunicación a clientes      | A,R  | I         | I    | I    | C    | I

Reglas:

• Una sola "A" por actividad (sin esto, nadie es responsable).
• Si hay muchas "C" e "I", revisar si todas son necesarias.
• Si una persona tiene "R" en muchas cosas, está saturada.

Antes de RACI: "¿quién decide esto?" → pelea política. Con RACI: "Ana es A, ella decide. Pregunto su opinión."

📐 Fundamento

Modelo Tuckman (1965): 5 fases del desarrollo de equipos:

1. Forming    — "nos conocemos, somos educados"
2. Storming   — "diferencias, conflictos emergen"  ← FASE CRÍTICA
3. Norming    — "encontramos cómo trabajar juntos"
4. Performing — "alto rendimiento"
5. Adjourning — "el proyecto/equipo termina"

Lo que el líder debe hacer en cada fase:

Las 5 disfunciones de un equipo (Lencioni):

                 Resultados        ← lograr objetivos
                     ▲
              Foco en métricas
                     ▲
               Compromiso
                     ▲
            Conflicto productivo
                     ▲
                 Confianza         ← base de todo

Cada nivel depende del de abajo:

• Sin confianza → la gente no se anima a discrepar.
• Sin conflicto productivo → no hay ideas reales.
• Sin conflicto → "compromiso" es sólo "asentimiento".
• Sin compromiso → nadie se hace cargo de las métricas.
• Sin rendir cuentas → no se logran resultados.

Cómo construir confianza:

• Vulnerabilidad del líder ("yo no sé X, ayúdenme").
• Feedback directo (pero respetuoso).
• Conocimiento personal (más allá del trabajo).

Conflicto productivo vs destructivo:

Productivo:                    Destructivo:
"No estoy de acuerdo con X     "Vos siempre proponés ideas
porque creo que..."            estúpidas."

Sobre ideas, hechos, datos     Sobre personas, motivos
Construye                      Destruye

📐 Fundamento

Team Topologies (Skelton & Pais, 2019):

4 tipos de equipos:

Cognitive load: capacidad mental que un equipo puede manejar. Si es alta, productividad cae.

Tipos de cognitive load:

• Intrínseca: complejidad del problema.
• Extrínseca: complejidad accidental (tools, procesos).
• Germane: aprendizaje productivo.

Reducir cognitive load: equipos pequeños, scope claro, plataformas que abstraen complejidad.

Conway's Law:

"Las organizaciones diseñan sistemas que reflejan su estructura de comunicación."

Si tenés 4 equipos → vas a tener un sistema de 4 partes. Cambiar la arquitectura sin cambiar la organización es muy difícil.

Inverse Conway maneuver: cambiá primero la estructura organizacional para que produzca la arquitectura que querés.

📐 Fundamento

Canales de comunicación:

Tipo                    | Sincrónico | Persistente | Cuándo usar
------------------------+------------+-------------+----------------
Reunión                 |    Sí      |     No      | Decisiones, conflictos
Llamada / video         |    Sí      |     No      | Discusiones complejas
Slack/Teams             |  Casi      |     Sí      | Coordinación rápida
Email                   |    No      |     Sí      | Anuncios formales
Documento (Confluence)  |    No      |     Sí      | Decisiones, knowledge
PR comments             |    No      |     Sí      | Code review
Pull Request descripción|    No      |     Sí      | Por qué del cambio

Anti-patrón #1: todo en reuniones. Reuniones cuestan = #personas × duración × $/hora.

Anti-patrón #2: todo asincrónico. Algunas decisiones requieren high-bandwidth (video).

Async-first culture (GitLab, Basecamp):

• Default: documento escrito.
• Reuniones solo cuando async no funciona.
• Decisiones documentadas (ADR — Architecture Decision Record).

# ADR-042: Migrar de REST a GraphQL para la API móvil

## Status
Accepted (2026-05-15)

## Context
La app móvil sufre de over-fetching y under-fetching, requiriendo
múltiples requests para construir cada pantalla.

## Decision
Migrar la API móvil a GraphQL usando Apollo Server. La API web sigue
con REST.

## Consequences
+ Cliente móvil pide solo lo necesario.
+ Mejor performance en redes móviles.
- Curva de aprendizaje para el equipo backend.
- Caching más complejo que REST.

## Considered Alternatives
- BFF (Backend for Frontend) — descartado, agrega capa innecesaria.

Reuniones efectivas (cuando son necesarias):

• Agenda escrita ANTES.
• Solo invitar a quien debe estar.
• Time-boxed (15min, 30min, max 60min).
• Decisión + acciones documentadas al final.
• "¿Quién hace qué para cuándo?"

Daily standup: 15 min máx, 3 preguntas (¿qué hice?, ¿qué haré?, ¿bloqueos?). NO es un status report — es coordinación entre devs.

📐 Fundamento

Teoría X vs Y (McGregor, 1960):

Estudios consistentes muestran que para trabajo creativo (como software), Teoría Y produce mejor performance.

Drive (Dan Pink, 2009): 3 motivadores intrínsecos:

1. Autonomía: capacidad de decidir sobre el propio trabajo.
2. Maestría: mejorar continuamente en algo difícil.
3. Propósito: sentir que el trabajo importa.

Para ingenieros: salario competitivo es necesario pero no motivante. Lo que motiva: trabajo desafiante, libertad técnica, impacto real.

Lo que MATA la motivación:

• Micromanagement.
• Trabajo sin sentido / siempre apagar incendios.
• Falta de reconocimiento.
• Promesas incumplidas.
• "Equipo tóxico" tolerado.

Feedback efectivo (Radical Candor, Kim Scott):

              Care Personally
                    ▲
                    │
Ruinous   ────────  │  ──────── Radical
Empathy             │           Candor      ← objetivo
                    │
                    │
─────────────────── + ──────────────────→ Challenge Directly
                    │
                    │
Manipulative ────── │ ──────── Obnoxious
Insincerity         │          Aggression
                    │
                    ▼

Radical Candor: decirle a alguien lo que necesita escuchar (challenge), porque te importa (care).

Anti-patrones:

• "Ruinous Empathy" — no decir lo malo por no herir → la persona no mejora.
• "Obnoxious Aggression" — decir lo malo sin cuidar → la persona se cierra.

Estructura de feedback (SBI):

• Situation: "En la review del miércoles..."
• Behavior: "...interrumpiste a Ana 3 veces..."
• Impact: "...y eso hizo que perdiéramos su perspectiva sobre X."

Concreto, no personal, accionable.