← Volver al listado de tecnologías ← Índice de BMAD Method

El Analyst: Brainstorming del Kanban

17 de diciembre de 2024 Por: Artiko

bmadanalystbrainstormingproduct-brief

El rol del Analyst

El Analyst es el primer agente que entra en accion. Su alias oficial es “Vision Crystallizer” y su mision es transformar una idea vaga en un documento concreto y accionable: el Product Brief.

No toma decisiones tecnicas. No elige frameworks ni bases de datos. Su trabajo es entender que quieres construir, para quien y por que. Las decisiones de como le corresponden al Architect mas adelante.

Como cargar el Analyst

En tu IDE agentico, carga el archivo _bmad/agents/analyst.md. Dependiendo de tu herramienta:

# Claude Code
"Carga el agente en _bmad/agents/analyst.md y actua como el Analyst"

# Cursor / Windsurf
Agrega el contenido de analyst.md como regla de proyecto o contexto

Una vez cargado, la IA adoptara el rol del Analyst: hara preguntas especificas, usara tecnicas de brainstorming estructuradas y generara el artefacto en el formato correcto.

Las 3 tecnicas de brainstorming

El Analyst aplica tres tecnicas complementarias para explorar tu idea desde distintos angulos:

1. Analisis de riesgos

Identifica que puede salir mal antes de escribir una linea de codigo:

Riesgos tecnicos (complejidad de real-time, escalabilidad)
Riesgos de producto (usuarios no adoptan la herramienta)
Riesgos de scope (el proyecto crece sin control)

2. Estado futuro ideal

Te pide que imagines el producto terminado y exitoso:

Como se ve la app cuando un usuario la abre por primera vez
Que metricas indicarian que el proyecto fue un exito
Que diferencia a tu Kanban de Trello, Jira o Notion

3. Brainstorming inverso

En lugar de preguntar “que features necesitas”, pregunta:

“Que haria que los usuarios abandonen tu app?”
“Que errores de UX son imperdonables en un Kanban?”
“Que feature NO deberias incluir en el MVP?”

Esta tecnica inversa revela restricciones y prioridades que el brainstorming directo no captura.

Dialogo con el Analyst para el Kanban

Asi se ve una sesion tipica con el Analyst. El agente guia la conversacion:

Preguntas sobre objetivos

Analyst: Describeme tu proyecto en una o dos oraciones. Que problema resuelve y para quien?

Tu: Quiero un tablero Kanban para equipos pequenos de desarrollo que necesitan algo mas simple que Jira pero mas potente que sticky notes.

Analyst: Que significa “mas simple que Jira” para ti? Que aspectos de Jira te parecen innecesariamente complejos?

Tu: Los workflows configurables, los campos custom infinitos, los reportes que nadie mira. Quiero columnas, tarjetas y ya.

Preguntas sobre usuarios

Analyst: Quien usaria esto? Describeme al usuario tipico.

Tu: Equipos de 3-8 developers. El lead crea el tablero, invita al equipo, y todos mueven tarjetas.

Analyst: Estos usuarios ya usan alguna herramienta? Que los motivaria a cambiar?

Tu: Usan Trello pero les falta colaboracion en tiempo real y les molesta el modelo de precios.

Preguntas sobre features

Analyst: Si solo pudieras tener 3 features en el MVP, cuales serian?

Tu: Tableros con columnas personalizables, tarjetas con titulo y descripcion, y que se actualice en tiempo real cuando alguien mueve una tarjeta.

Analyst: Y que feature NO deberia estar en el MVP?

Tu: Reportes, integraciones con Slack/GitHub, y calendario.

Preguntas sobre restricciones

Analyst: Hay restricciones tecnicas o de negocio que deba conocer?

Tu: Quiero que sea self-hosted para no depender de un SaaS. Y que funcione bien con 50 usuarios concurrentes.

El artefacto: product-brief.md

Despues del dialogo, el Analyst genera el Product Brief. Este es el documento que alimentara al PM en la siguiente fase.

Para nuestro proyecto Kanban, el brief generado seria algo como:

# Product Brief: Kanban Board

## Vision
Tablero Kanban minimalista y self-hosted para equipos pequenos
de desarrollo que necesitan colaboracion en tiempo real
sin la complejidad de herramientas enterprise.

## Problema
Los equipos pequenos (3-8 personas) estan atrapados entre
herramientas demasiado simples (sticky notes, Trello free)
y demasiado complejas (Jira, Azure DevOps). Necesitan algo
intermedio: facil de usar, colaborativo y sin lock-in de SaaS.

## Usuarios Target
- **Primario**: Tech leads de equipos de 3-8 developers
- **Secundario**: Developers individuales del equipo
- **Terciario**: Product managers no-tecnicos que necesitan
  visibilidad

## Features Prioritarias (MVP)

### Must Have (P0)
1. Crear/editar/eliminar tableros
2. Columnas personalizables por tablero
3. Tarjetas con titulo, descripcion y asignado
4. Drag & drop de tarjetas entre columnas
5. Actualizaciones en tiempo real (multi-usuario)
6. Autenticacion basica (email + password)

### Should Have (P1)
7. Etiquetas de color en tarjetas
8. Filtrar tarjetas por asignado o etiqueta
9. Invitar usuarios al tablero por email
10. Limite WIP (Work In Progress) por columna

### Nice to Have (P2)
11. Historial de movimientos de tarjetas
12. Comentarios en tarjetas
13. Due dates con recordatorios

## Fuera de Scope (MVP)
- Reportes y analytics
- Integraciones (Slack, GitHub, CI/CD)
- Calendario o vista timeline
- Automaciones y workflows configurables
- App movil nativa

## Metricas de Exito
- Un equipo puede crear un tablero y mover tarjetas
  en menos de 2 minutos
- Las actualizaciones en tiempo real se reflejan
  en menos de 500ms
- El sistema soporta 50 usuarios concurrentes
  sin degradacion
- El deploy self-hosted funciona con un solo
  docker-compose up

## Restricciones
- **Self-hosted**: no depender de servicios cloud propietarios
- **Performance**: 50 usuarios concurrentes como minimo
- **Simplicidad**: onboarding sin documentacion
- **Open source friendly**: licencia permisiva

## Riesgos Identificados
1. **Real-time complexity**: WebSockets o SSE pueden
   complicar el deploy y la escalabilidad
2. **Scope creep**: la tentacion de agregar "solo una
   feature mas" antes del MVP
3. **Auth complexity**: manejar sesiones, tokens y
   permisos puede consumir mucho tiempo
4. **Drag & drop UX**: implementar DnD que se sienta
   natural y funcione en mobile

Revisar y aprobar el brief

El Analyst no avanza automaticamente a la siguiente fase. Primero te pide que revises el brief:

Analyst: He generado el Product Brief. Revisalo y confirmame si captura correctamente tu vision. Puedo ajustar cualquier seccion.

Este es un punto de control critico. Revisa especialmente:

Que las features P0 sean realmente las minimas para un MVP funcional
Que “Fuera de Scope” sea claro para evitar scope creep
Que los riesgos sean realistas y no omitan nada obvio
Que las metricas sean medibles (no “que sea rapido” sino “menos de 500ms”)

Iterar sobre el brief

Si algo no esta bien, pide cambios:

Tu: Las features P1 deberian incluir busqueda de tarjetas, no solo filtro por asignado.

Analyst: Entendido. Agrego “Busqueda full-text de tarjetas por titulo y descripcion” como P1 item 11 y ajusto la numeracion.

Itera hasta que el brief refleje exactamente lo que quieres. Es mucho mas barato cambiar un parrafo en el brief que refactorizar codigo despues.

Guardar el artefacto

Una vez aprobado, el brief se guarda en:

_bmad/docs/product-brief.md

Y el workflow-status.md se actualiza:

## Current Phase: REQUIREMENTS

## Artifacts
- [x] product-brief.md
- [ ] PRD.md
...

## Phase History
| Phase | Status | Date | Agent |
|-------|--------|------|-------|
| Brainstorming | COMPLETED | 2024-12-17 | Analyst |
| Requirements | IN_PROGRESS | - | PM |

Haz commit del brief:

git add _bmad/docs/product-brief.md _bmad/workflow-status.md
git commit -m "feat: product brief del Kanban aprobado (Analyst)"

Tips para mejores resultados con el Analyst

Se especifico en tus respuestas

Malo: “Quiero una app de tareas” Bueno: “Quiero un tablero Kanban para equipos de 3-8 developers que colaboran en tiempo real”

No te saltes las preguntas incomodas

Cuando el Analyst pregunta “que NO deberia incluir”, responde con honestidad. Definir los limites es tan importante como definir las features.

Piensa en usuarios, no en tecnologia

El Analyst no quiere escuchar “quiero usar React y PostgreSQL”. Quiere escuchar “mis usuarios son developers que necesitan velocidad y simplicidad”. La tecnologia viene despues con el Architect.

Usa la tecnica del “si solo pudiera tener 3…”

Cuando dudes sobre prioridades, preguntate: “Si solo pudiera tener 3 features y lanzar manana, cuales serian?” Eso separa el MVP real del wishlist.

No busques perfeccion

El brief es un documento vivo. Se puede actualizar despues. Lo importante es que capture la esencia del proyecto para que el PM pueda trabajar.

Que sigue

Con el Product Brief aprobado, el siguiente agente en la cadena es el Product Manager. Tomara este brief y lo expandira en un PRD completo con epicas, user stories detalladas y criterios de aceptacion medibles.

← Capitulo 2: Instalacion | Siguiente → Capitulo 4: El PM (proximo)