416 lines
9.8 KiB
Markdown
416 lines
9.8 KiB
Markdown
# Makers3D - Plan de Desarrollo
|
|
|
|
## 1. Objetivo
|
|
|
|
Construir un MVP operable por un equipo pequeno, con trabajo paralelo entre humanos y agentes de IA, minimizando dependencias innecesarias y cerrando primero los recorridos que generan valor real.
|
|
|
|
## 2. Principios de ejecucion
|
|
|
|
1. Desarrollo vertical por recorridos completos.
|
|
2. Nada entra en produccion beta sin prueba y criterio de salida.
|
|
3. La prioridad la marca el negocio: descubrir, contactar, publicar, cobrar y moderar.
|
|
4. Todo diferido queda documentado y fuera del backlog P0.
|
|
|
|
## 3. Roles de trabajo
|
|
|
|
- Producto: protege alcance y acepta entregas.
|
|
- Backend: dominio, API, datos y pagos.
|
|
- Frontend: experiencia publica, area maker y admin.
|
|
- Infra: entornos, despliegue, backups y operacion.
|
|
- QA: criterios, evidencia y regresion.
|
|
|
|
En equipos pequenos una misma persona puede asumir varios roles, pero las responsabilidades deben seguir existiendo.
|
|
|
|
## 4. Fases
|
|
|
|
| Fase | Objetivo | Prioridad | Estimacion |
|
|
|---|---|---|---|
|
|
| F0 | Base de trabajo | P0 | 1 semana |
|
|
| F1 | Identidad y perfil maker privado | P0 | 2 semanas |
|
|
| F2 | Servicios, trabajos y publicacion | P0 | 2 semanas |
|
|
| F3 | Descubrimiento publico | P0 | 2 semanas |
|
|
| F4 | Consulta y mensajeria | P0 | 2 semanas |
|
|
| F5 | Suscripcion y Mercado Pago | P0 | 1-2 semanas |
|
|
| F6 | Resenas, moderacion y admin | P1 | 2 semanas |
|
|
| F7 | Hardening y beta cerrada | P0 | 2 semanas |
|
|
|
|
## 5. Epicas, historias y tareas
|
|
|
|
### F0 - Base de trabajo
|
|
|
|
Objetivo:
|
|
|
|
- dejar el repositorio listo para construir sin improvisacion.
|
|
|
|
Historias:
|
|
|
|
- como equipo quiero un monorepo funcional;
|
|
- como equipo quiero levantar local con un solo comando;
|
|
- como equipo quiero CI minimo antes de tocar negocio.
|
|
|
|
Tareas:
|
|
|
|
- crear estructura `web`, `api`, `worker`;
|
|
- configurar TypeScript, lint y testing;
|
|
- levantar PostgreSQL, MinIO y Nginx en Compose;
|
|
- crear pipeline minimo;
|
|
- documentar comandos y convenciones.
|
|
|
|
Definition of Done:
|
|
|
|
- instalacion limpia funciona;
|
|
- `docker compose up` levanta entorno local;
|
|
- CI ejecuta checks basicos.
|
|
|
|
Pruebas:
|
|
|
|
- build de cada app;
|
|
- smoke test local;
|
|
- test de conexion a base de datos y storage.
|
|
|
|
### F1 - Identidad y perfil maker privado
|
|
|
|
Objetivo:
|
|
|
|
- permitir cuenta, login y area maker sin visibilidad publica.
|
|
|
|
Historias:
|
|
|
|
- como usuario quiero registrarme y verificar email;
|
|
- como usuario quiero acceder y recuperar mi cuenta;
|
|
- como usuario quiero crear mi perfil maker privado.
|
|
|
|
Tareas:
|
|
|
|
- tablas de cuentas y sesiones;
|
|
- registro, login y recuperacion;
|
|
- cookies seguras y CSRF;
|
|
- formulario de perfil maker;
|
|
- ubicacion unica con privacidad;
|
|
- disponibilidad basica.
|
|
|
|
Dependencias:
|
|
|
|
- F0 cerrada.
|
|
|
|
Definition of Done:
|
|
|
|
- un usuario puede registrarse;
|
|
- puede crear perfil maker;
|
|
- puede salir y volver sin perder su borrador.
|
|
|
|
Pruebas:
|
|
|
|
- unitarias de auth;
|
|
- integracion de sesiones;
|
|
- E2E de alta y login.
|
|
|
|
### F2 - Servicios, trabajos y publicacion
|
|
|
|
Objetivo:
|
|
|
|
- permitir que el maker prepare una oferta real publicable.
|
|
|
|
Historias:
|
|
|
|
- como maker quiero publicar un servicio;
|
|
- como maker quiero publicar un trabajo con fotos;
|
|
- como maker quiero saber si ya cumplo minimos.
|
|
|
|
Tareas:
|
|
|
|
- entidades de servicios y trabajos;
|
|
- subida de imagenes;
|
|
- procesamiento basico;
|
|
- pantalla de checklist de publicacion;
|
|
- estado de perfil listo/no listo;
|
|
- URLs publicas de perfil, servicio y trabajo.
|
|
|
|
Dependencias:
|
|
|
|
- F1 cerrada.
|
|
|
|
Definition of Done:
|
|
|
|
- el maker puede publicar 1 servicio y 1 trabajo;
|
|
- el sistema calcula si esta listo para publicar;
|
|
- lo publico sigue inaccesible si no hay habilitacion comercial.
|
|
|
|
Pruebas:
|
|
|
|
- integracion de uploads;
|
|
- unitarias de elegibilidad;
|
|
- E2E de crear servicio y trabajo.
|
|
|
|
### F3 - Descubrimiento publico
|
|
|
|
Objetivo:
|
|
|
|
- abrir la promesa principal al visitante.
|
|
|
|
Historias:
|
|
|
|
- como visitante quiero buscar por necesidad;
|
|
- como visitante quiero filtrar por cercania y capacidad;
|
|
- como visitante quiero abrir perfiles y trabajos desde resultados.
|
|
|
|
Tareas:
|
|
|
|
- documento de busqueda;
|
|
- filtros y ranking minimo;
|
|
- pagina de resultados;
|
|
- mapa con clusters;
|
|
- lista sincronizada;
|
|
- fallback a lista si el mapa falla.
|
|
|
|
Dependencias:
|
|
|
|
- F2 para contar con oferta real.
|
|
|
|
Definition of Done:
|
|
|
|
- un visitante puede descubrir makers sin cuenta;
|
|
- entiende resultados;
|
|
- nunca ve datos privados.
|
|
|
|
Pruebas:
|
|
|
|
- integracion de busqueda y PostGIS;
|
|
- E2E de descubrimiento;
|
|
- pruebas de permisos sobre recursos publicos.
|
|
|
|
### F4 - Consulta y mensajeria
|
|
|
|
Objetivo:
|
|
|
|
- convertir trafico en conversaciones utiles.
|
|
|
|
Historias:
|
|
|
|
- como visitante quiero iniciar una consulta contextual;
|
|
- como usuario quiero registrarme sin perder el borrador;
|
|
- como cliente y maker quiero conversar dentro de la plataforma.
|
|
|
|
Tareas:
|
|
|
|
- flujo de contacto guiado;
|
|
- persistencia de borrador;
|
|
- registro diferido;
|
|
- entidades de consulta, conversacion y mensaje;
|
|
- bandeja;
|
|
- polling controlado;
|
|
- rechazo con motivo.
|
|
|
|
Dependencias:
|
|
|
|
- F1 y F3.
|
|
|
|
Definition of Done:
|
|
|
|
- el contacto se envia una sola vez;
|
|
- el contexto de origen se conserva;
|
|
- ambos actores ven la misma conversacion.
|
|
|
|
Pruebas:
|
|
|
|
- E2E de consulta completa;
|
|
- integracion de idempotencia;
|
|
- test de polling y permisos.
|
|
|
|
### F5 - Suscripcion y Mercado Pago
|
|
|
|
Objetivo:
|
|
|
|
- convertir presencia profesional en negocio.
|
|
|
|
Historias:
|
|
|
|
- como maker quiero contratar el plan;
|
|
- como sistema quiero recibir el webhook;
|
|
- como plataforma quiero controlar visibilidad segun estado comercial.
|
|
|
|
Tareas:
|
|
|
|
- modelo interno de suscripcion;
|
|
- inicio de pago;
|
|
- retorno del navegador;
|
|
- verificacion de webhook;
|
|
- conciliacion basica;
|
|
- retiro de visibilidad por vencimiento.
|
|
|
|
Dependencias:
|
|
|
|
- F2 y F4 recomendadas;
|
|
- puede empezar al final de F3 para ganar tiempo.
|
|
|
|
Definition of Done:
|
|
|
|
- el pago se refleja;
|
|
- la suscripcion cambia de estado;
|
|
- el perfil no se publica solo por pagar.
|
|
|
|
Pruebas:
|
|
|
|
- sandbox de pagos;
|
|
- duplicados y eventos fuera de orden;
|
|
- E2E de alta comercial.
|
|
|
|
### F6 - Resenas, moderacion y admin
|
|
|
|
Objetivo:
|
|
|
|
- cerrar confianza y operacion basica.
|
|
|
|
Historias:
|
|
|
|
- como cliente quiero valorar una relacion real;
|
|
- como admin quiero revisar una resena reportada;
|
|
- como admin quiero suspender un perfil si existe causa.
|
|
|
|
Tareas:
|
|
|
|
- relacion completada;
|
|
- resena verificada;
|
|
- reportes;
|
|
- cola de casos;
|
|
- pantalla admin de makers;
|
|
- auditoria de acciones internas.
|
|
|
|
Dependencias:
|
|
|
|
- F4;
|
|
- F5 si la beta ya cobra.
|
|
|
|
Definition of Done:
|
|
|
|
- existe trazabilidad;
|
|
- el admin puede operar sin tocar base de datos manualmente.
|
|
|
|
Pruebas:
|
|
|
|
- integracion de moderacion;
|
|
- E2E de reporte y revision;
|
|
- permisos admin.
|
|
|
|
### F7 - Hardening y beta cerrada
|
|
|
|
Objetivo:
|
|
|
|
- demostrar que el sistema soporta usuarios reales controlados.
|
|
|
|
Historias:
|
|
|
|
- como equipo quiero restaurar backups;
|
|
- como equipo quiero desplegar con rollback claro;
|
|
- como operador quiero abrir beta con soporte y monitoreo basicos.
|
|
|
|
Tareas:
|
|
|
|
- runbook de deploy;
|
|
- backup y restore;
|
|
- smoke tests;
|
|
- accesibilidad basica;
|
|
- pruebas en movil;
|
|
- checklist de salida;
|
|
- carga inicial de makers fundadores.
|
|
|
|
Dependencias:
|
|
|
|
- F1 a F6.
|
|
|
|
Definition of Done:
|
|
|
|
- staging estable;
|
|
- restore probado;
|
|
- cohortes iniciales definidas;
|
|
- no hay bloqueantes P0 abiertos.
|
|
|
|
Pruebas:
|
|
|
|
- E2E principales;
|
|
- pruebas de restore;
|
|
- validacion manual de pagos, mensajes y publicacion.
|
|
|
|
## 6. Orden optimo de implementacion
|
|
|
|
1. F0 Base
|
|
2. F1 Identidad y perfil privado
|
|
3. F2 Servicios, trabajos y publicacion
|
|
4. F3 Descubrimiento
|
|
5. F4 Consulta y mensajeria
|
|
6. F5 Suscripcion y pagos
|
|
7. F6 Resenas, moderacion y admin
|
|
8. F7 Hardening y beta
|
|
|
|
Este orden protege una regla: primero crear oferta, despues mostrarla, despues convertirla en consultas, despues cobrarla y operarla.
|
|
|
|
## 7. Dependencias criticas
|
|
|
|
- No hay descubrimiento real sin oferta maker publicada.
|
|
- No hay resena valida sin consulta y relacion.
|
|
- No hay publicacion comercial sin suscripcion y sin minimos de calidad.
|
|
- No hay beta con cobros reales sin restore probado y conciliacion basica.
|
|
|
|
## 8. Trabajo paralelizable
|
|
|
|
### Puede correr en paralelo
|
|
|
|
- frontend publico y modelado de resultados una vez definidos contratos;
|
|
- area maker y backend de servicios/trabajos;
|
|
- pipeline CI y entorno staging;
|
|
- copy UX y validaciones de formularios;
|
|
- QA sobre auth mientras backend continua con publicacion.
|
|
|
|
### No conviene paralelizar demasiado pronto
|
|
|
|
- pagos antes de fijar modelo interno de suscripcion;
|
|
- admin antes de definir exactamente que modera;
|
|
- optimizaciones de rendimiento antes de tener recorridos completos.
|
|
|
|
## 9. Riesgos por fase
|
|
|
|
| Fase | Riesgo principal | Mitigacion |
|
|
|---|---|---|
|
|
| F0 | deuda de estructura | monorepo austero y pocas abstracciones |
|
|
| F1 | auth insegura | pruebas y cookies seguras desde el inicio |
|
|
| F2 | complejidad de uploads | limitar tipos de archivo |
|
|
| F3 | ranking confuso | explicaciones simples y filtros duros |
|
|
| F4 | duplicados de consulta | idempotencia y borrador persistente |
|
|
| F5 | incoherencias de pago | webhook verificado y conciliacion |
|
|
| F6 | moderacion lenta | backoffice minimo y motivos claros |
|
|
| F7 | falsa sensacion de preparacion | restore, smoke tests y checklist real |
|
|
|
|
## 10. Criterios de aceptacion globales
|
|
|
|
Una fase se acepta solo si:
|
|
|
|
- cumple el recorrido principal;
|
|
- contempla errores y estados vacios;
|
|
- respeta permisos;
|
|
- tiene pruebas suficientes;
|
|
- queda documentada;
|
|
- y no introduce dependencias tecnicas nuevas sin aprobacion.
|
|
|
|
## 11. Definition of Done global
|
|
|
|
Una historia o tarea esta terminada cuando:
|
|
|
|
- el comportamiento funciona;
|
|
- los permisos son correctos;
|
|
- hay prueba adecuada;
|
|
- el usuario entiende el resultado;
|
|
- no hay regresion conocida;
|
|
- y la documentacion minima esta actualizada.
|
|
|
|
## 12. Preparacion para humanos e IA
|
|
|
|
### Reparto recomendado
|
|
|
|
- humanos: decisiones de negocio, revision de UX, moderacion, riesgos y aceptacion final;
|
|
- IA: scaffolding, CRUD, validaciones, tests, refactor y documentacion operativa;
|
|
- trabajo compartido: contratos, copy UX, casos limite y revisiones.
|
|
|
|
### Regla
|
|
|
|
La IA acelera entrega, pero no reemplaza la aceptacion del flujo ni la comprobacion de negocio.
|