Lineamientos Operacionales AIKIMIA LAB

Guía completa de procesos, metodologías y estándares para la excelencia en desarrollo de soluciones de IA empresarial

Los Mandamientos de AIKIMIA

1. Estándar no particular
Pensemos siempre en estandarización cada vez que hagamos nuestros flujos que estos puedan servir para casos genéricos no particulares.
2. Conectores "plugins" modulares
Cada flujo que creemos debería ser un flujo independiente pensando como plugins que luego podamos usar llamando un webhook al flujo. Ejemplos de los que tenemos: (firewall, rag, transcript, podcast, extract text, conteo de tokens, text to speech).
3. No todo es AI
No todo es agentes, existen las expresiones regulares, APIs, código tradicional.
4. Su poner
Para evitar errores no supongamos, preguntemos sin miedo para estar alineados.
5. Low cost
Pensemos en mentalidad low cost como haríamos esto invertiendo lo mínimo posible, APIs, modelos, etc.
6. Descomposición en problemas pequeños
Descompongamos los retos en retos pequeños, para abordarlos de la mejor manera.
7. Que no nos dé miedo decir no sé
Somos un equipo y debemos apoyarnos.
8. Notificar a tiempo
No esperemos hasta faltando poco para los entregables, notifiquemos con antelación para tomar acción.
9. Debemos ser solucionadores
No esperemos que alguien del equipo resuelva nuestros problemas, cuando escalamos algo es porque ya hemos explorado mil alternativas.
10. No se aprende leyendo se aprende haciendo
Práctica práctica.
11. Documentemos
Documentemos todo, para que sea más fácil el entendimiento.
12. Tengamos estética
Que nuestro código y flujos sean estéticos.
13. Usen las herramientas
Usen la IA a su favor: Manus, ChatGPT, Minimax, etc.
14. Seamos directos
No disfracemos las cosas, digamos abiertamente y concretamente las cosas, para evitar malinterpretaciones.

Estructura de Trabajo para Nuevos Proyectos

Ciclo de Backlog de 15 Días

Cada 15 días ejecutamos un ciclo completo de planificación, priorización y asignación de trabajo. Este ciclo garantiza agilidad sin sacrificar la planificación estratégica.

1
Escuchar Requerimientos de las Áreas
Proceso: Reuniones estructuradas con cada área de negocio para capturar necesidades, problemas y oportunidades. Se utilizan templates estandarizados para garantizar completitud de información.

Entregables: Lista consolidada de requerimientos con contexto de negocio, impacto esperado y urgencia.
2
Priorizar Requerimientos
Proceso: La priorización será otorgada por Norman o Daniel basada en el contexto de negocio, impacto estratégico y recursos disponibles.

Resultado: Lista priorizada de requerimientos listos para descomposición y asignación.
3
Descomponer en Problemas Pequeños
Principio: Cada requerimiento se descompone en problemas atómicos que puedan ser resueltos en 2-5 días por un desarrollador.

Enfoque de Estandarización: Cada problema pequeño se analiza para identificar patrones reutilizables y componentes estándar.

Validación: Cada descomposición debe pasar por review técnico para garantizar coherencia arquitectónica.
4
Seleccionar y Asignar Casos a Desarrolladores
Proceso de Asignación: Selección de casos pequeños basada en competencias técnicas del desarrollador, carga de trabajo actual, oportunidades de aprendizaje y dependencias entre tareas.

Balanceamiento: Máximo 3 tareas activas por desarrollador para mantener foco y calidad.
5
Construir Casos de Uso y Requerimientos
Template de Caso de Uso:
  • Descripción del problema
  • Criterios de aceptación específicos
  • Inputs y outputs esperados
  • Restricciones técnicas y de negocio
  • Definición de "Done"
  • Casos de prueba mínimos

Validación: Cada caso de uso debe ser aprobado por el desarrollador asignado y el tech lead antes de iniciar desarrollo.
6
Crear Hitos Formales en Plane
Estructura de Hitos:
  • Hito de Análisis (25% del tiempo estimado)
  • Hito de Desarrollo (50% del tiempo estimado)
  • Hito de Testing (15% del tiempo estimado)
  • Hito de Documentación (10% del tiempo estimado)

Tracking: Cada hito debe tener criterios de completitud medibles y fechas específicas de entrega.

Lineamientos de Documentación en Plane

Hitos Claros y Concretos

Estructura Obligatoria de Hitos:

  • Título: Descripción específica y accionable
  • Criterios de Completitud: Lista verificable de entregables
  • Fecha de Inicio: Fecha real de inicio del trabajo
  • Fecha de Entrega: Fecha comprometida de finalización
  • Dependencias: Hitos o recursos de los que depende
  • Riesgos Identificados: Potenciales bloqueadores

Evidencias Obligatorias

Tipos de Evidencia Requeridos:

  • Screenshots: Capturas de pantalla de interfaces y resultados
  • Logs de Testing: Resultados de pruebas automatizadas y manuales
  • Code Snippets: Fragmentos de código relevantes
  • Métricas: Datos de rendimiento y calidad
  • Videos Demo: Demostraciones de funcionalidad (cuando aplique)

Descripción Detallada

Template de Descripción de Hito

1. Contexto: ¿Por qué es necesario este hito?

2. Objetivo: ¿Qué se busca lograr específicamente?

3. Enfoque Técnico: ¿Cómo se va a abordar el problema?

4. Criterios de Éxito: ¿Cómo sabemos que está completo?

5. Impacto: ¿Qué valor aporta al proyecto general?

Actualización Diaria Obligatoria

Protocolo de Actualización Diaria

Horario: Antes de las 9:00 AM, sin excepción

Contenido Mínimo:

  • Progreso del día anterior (% de completitud)
  • Actividades planificadas para el día actual
  • Bloqueadores identificados o resueltos
  • Cambios en estimaciones de tiempo
  • Solicitudes de ayuda o recursos

Estados de Progreso

EXECUTION

Criterios: Hito iniciado, trabajo en progreso activo, desarrollador asignado trabajando en la tarea.

IN PROGRESS

Criterios: Avance significativo (>50%), entregables parciales disponibles, en camino a completitud.

DONE

Criterios: Todos los criterios de completitud cumplidos, evidencias subidas, validación técnica aprobada.

Proceso de Backlogs Diarios

Seguimiento Diario de Proyectos

Estructura de Daily Standup

Horario: 9:00 AM - 9:30 AM (máximo)

Formato por Desarrollador (10 minutos máximo):

  • Estado Actual: ¿En qué trabajé ayer? ¿Qué logré?
  • Stoppers: ¿Qué me está bloqueando o ralentizando?
  • Siguiente Paso: ¿Qué voy a hacer hoy? ¿Cuál es mi prioridad?
  • Solicitudes: ¿Necesito ayuda, recursos o clarificaciones?

Reglas Estrictas:

  • Máximo 10 minutos por persona
  • Enfoque en hechos, no en excusas
  • Identificación clara de blockers
  • Compromiso específico para el día

Resolución de Stoppers

Protocolo de Resolución

Prerequisitos antes de escalar un stopper:

  • ✅ Revisión de mandamientos aplicables
  • ✅ Testing de al menos 3 enfoques diferentes
  • ✅ Consulta de documentación existente
  • ✅ Búsqueda en repositorio de conocimiento
  • ✅ Intento de descomposición del problema

Proceso de Resolución Colaborativa:

  • Presentación del Problema: Descripción clara y contexto
  • Enfoques Intentados: ¿Qué se ha probado y por qué no funcionó?
  • Brainstorming Grupal: Máximo 15 minutos de ideas
  • Selección de Solución: Decisión basada en mandamientos
  • Asignación de Responsabilidades: Quién hace qué y cuándo

Proceso de Cierre de Entregables

Entregables Obligatorios para Cierre

Cada proyecto debe completar TODOS los siguientes entregables antes de considerarse finalizado. No hay excepciones.

1
Flujos Estándar Documentados
Contenido Requerido:
  • Diagrama de flujo completo del proceso
  • Inputs y outputs de cada paso
  • Puntos de decisión y criterios
  • Manejo de errores y excepciones
  • Configuraciones y parámetros
  • APIs y endpoints utilizados

Formato: Markdown con diagramas en Mermaid, almacenado en repositorio central de documentación.
2
Video Demostrativo
Especificaciones del Video:
  • Duración: 5-15 minutos máximo
  • Calidad: 1080p mínimo
  • Audio: Narración clara en español
  • Contenido: Demo completo del flujo funcionando
  • Casos de uso: Al menos 2 escenarios diferentes
  • Troubleshooting: Demostración de manejo de errores

Almacenamiento: YouTube (unlisted) + backup en repositorio interno.
3
Cierre Formal del Plane
Checklist de Cierre:
  • ✅ Todos los hitos marcados como DONE
  • ✅ Evidencias subidas para cada hito
  • ✅ Retrospectiva del proyecto completada
  • ✅ Lecciones aprendidas documentadas
  • ✅ Métricas finales registradas
  • ✅ Aprobación del tech lead
4
Documentación Formal
Documentos Requeridos:
  • README Técnico: Instalación, configuración, uso
  • Documentación de API: Endpoints, parámetros, ejemplos
  • Guía de Usuario: Manual para usuarios finales
  • Arquitectura: Diagramas y decisiones técnicas
  • Testing: Casos de prueba y resultados
  • Deployment: Instrucciones de despliegue

Estándar: Documentación versionada, searchable y mantenible.
5
Análisis de Costos del Proyecto
Desglose de Costos:
  • Tiempo de Desarrollo: Horas invertidas por rol
  • APIs y Servicios: Costos de llamadas y suscripciones
  • Infraestructura: Compute, storage, networking
  • Herramientas: Licencias y software utilizado
  • Testing: Recursos para QA y validación

Análisis: Comparación vs. presupuesto inicial, identificación de desviaciones y optimizaciones futuras.
6
Limitaciones y Mejoras Futuras
Documentación de Limitaciones:
  • Restricciones técnicas conocidas
  • Casos de uso no soportados
  • Limitaciones de rendimiento
  • Dependencias externas críticas
  • Riesgos de seguridad identificados

Roadmap de Mejoras:
  • Funcionalidades prioritarias para v2.0
  • Optimizaciones de rendimiento
  • Integraciones adicionales
  • Mejoras de UX identificadas
  • Estimaciones de esfuerzo para cada mejora
Criterios de Aceptación Final

Un proyecto solo se considera completamente cerrado cuando:

  • ✅ Todos los 6 entregables están completos y validados
  • ✅ La solución está funcionando en producción
  • ✅ Los usuarios finales han sido entrenados
  • ✅ El monitoreo y alertas están configurados
  • ✅ El handover al equipo de soporte está completo
  • ✅ La retrospectiva del proyecto ha sido realizada