Un buen proceso nace del dolor

"No invente procesos donde no hay dolor." Tem un gestor que adora los procesos por los procesos mismos. Crea flujos llenos de flechas, formularios de veinte campos, etapas de aprobación en cascada... todo para intentar evitar problemas hipotéticos que nunca sucedieron en la empresa. ¿El resultado? Una burocracia pesada que atrasa a quien quiere trabajar sin proteger absolutamente nada. Un buen proceso nace de una manera muy diferente. Nace del dolor real. Alguien sufrió en la operación, el equipo se detuvo para aprender del tropiezo y surgió un acuerdo ágil para prevenir que esa misma falla vuelva a suceder. Cuando la regla nace para curar una herida abierta que todo el equipo sintió en carne propia, nadie necesita fiscalizar: el propio equipo defiende el proceso porque sabe que protege su trabajo. ## Señales de un proceso artificial ¿Cómo descubrir si su área está funcionando sobre ingeniería real o sobre burocracia imaginaria? Observe cuatro síntomas clásicos en el día a día: - Nadie sabe explicar por qué existe: la respuesta estándar para una etapa obligatoria es "siempre lo hicimos así desde que entré". - Siempre es evadido: para lograr cumplir con los plazos, los profesionales crean caminos paralelos en el chat y solo completan el sistema formal después de que la entrega ya salió al aire. - Genera más formularios que resultados: el tiempo dedicado a documentar y pedir sellos supera el tiempo dedicado a construir y probar la solución. - Fue copiado de otro lugar sin adaptación: alguien leyó sobre el modelo de un gigante tecnológico e intentó aplicar la misma estructura en un equipo de diez personas con otra realidad de negocio. ## Lo que Taiichi Ohno y Fred Brooks enseñan sobre burocracia La diferencia entre la estandarización útil y la burocracia de oficina fue explicada magistralmente por Taiichi Ohno, padre del Sistema de Producción Toyota, en el libro Toyota Production System: Beyond Large-Scale Production (1988). Para Ohno, cualquier estándar de trabajo solo es legítimo cuando nace en el Gemba (el lugar real donde se crea el valor) con el objetivo directo de eliminar Muda (desperdicio, retrabajo o sobrecarga). Cuando un flujo es diseñado lejos de la operación por personas que no ejecutan la tarea, no elimina el desperdicio: se convierte en el desperdicio mismo. En la ingeniería de software, Fred Brooks aportó una alerta complementaria en el clásico The Mythical Man-Month (1975) y en el ensayo No Silver Bullet (1986). Brooks dividió los desafíos técnicos en complejidad esencial (la dificultad intrínseca del problema real de negocio) y complejidad acidental (la fricción que nosotros mismos creamos con herramientas mal elegidas y rituales innecesarios). No fue por casualidad que los diecisiete autores del Manifiesto Ágil (2001) eligieron como primer valor fundamental: "Individuos e interacciones sobre procesos y herramientas". Los procesos deben reducir la complejidad acidental, nunca multiplicarla. ## Cómo nace un buen proceso en la práctica Para crear acuerdos que aumenten la confiabilidad sin entorpecer la entrega, sigo un ciclo de cinco pasos cada vez que ocurre un incidente relevante: 1. Ocurre un problema real El cliente se quejó de un cálculo erróneo en la factura. Un error crítico escapó a producción sin pruebas. Un despliegue derribó la integración un viernes. Comience siempre por un dolor concreto y observable, nunca por una suposición teórica. 2. Análisis de causa en el sistema Pregunte qué causó la falla. No "quién" se equivocó, sino "qué" falló en el engranaje. ¿Qué ausencia de traba automática, de visibilidad o de alineamiento permitió que una persona bien intencionada cometiera ese error? 3. Solución proporcional al riesgo La protección debe costar mucho menos que el perjuicio que evita. No sirve de nada crear un proceso manual de 10 etapas para todas las entregas de todo el año solo para evitar un error raro que cuesta 50 reales. Si puede automatizar la revisión en el conducto de código en vez de crear una reunión humana, automatice siempre. 4. Prueba de manejo con plazo definido Implemente el nuevo flujo como piloto en un alcance pequeño durante dos o cuatro semanas. Vea si realmente evita el dolor original sin trabar el ritmo. Ajuste lo que quedó pesado antes de expandirlo al resto de la organización. 5. Revisión periódica contra fósiles Un proceso que no se revisa se convierte en un fósil corporativo. El contexto de la empresa cambia, la arquitectura evoluciona, el equipo madura. El proceso debería cambiar junto con ellos o ser retirado cuando el riesgo deje de existir. ## El equilibrio y la documentación del "por qué" Poco proceso genera caos y retrabajo constante. Demasiado proceso genera parálisis y apatía. El punto exacto de madurez operacional es simple: protección rigurosa donde el error es costoso, libertad total donde el equipo puede experimentar. Para mantener ese equilibrio vivo, adopte una regla de oro: todo proceso interno debería tener la primera línea explicando por qué existe y qué problema real resolvió cuando fue creado. Así, dentro de un año, cuando alguien cuestione si esa etapa todavía tiene sentido o puede ser eliminada, la decisión estará informada por hechos. Un proceso sin memoria del problema que lo generó se convierte en dogma. Y en tecnología, el dogma es el camino más corto hacia la irrelevancia. > Continúe profundizando: lea también Categorización y Prioridad y Cultura que Frena o Sabotea. Conozca también la actuación en Liderazgo Ejecutivo y CTO Fraccional y nuestros Estudios de Caso. --- ### Referencias y lecturas verificables - Ohno, T. (1988). Toyota Production System: Beyond Large-Scale Production. Productivity Press. - Brooks, F. P. (1975 / 1995). The Mythical Man-Month: Essays on Software Engineering. Addison-Wesley. - Beck, K., et al. (2001). Manifiesto para el Desarrollo Ágil de Software. Agile Alliance.