Select Page
¿Management Tradicional o Ágil?

¿Management Tradicional o Ágil?

¿Management Tradicional o Ágil?

¿Por qué el tipo de problema importa?

¿Sabías que más del 70% de los proyectos que siguen un enfoque tradicional fallan en entornos de alta incertidumbre o cambio constante?
Estudios como el Chaos Report han demostrado que el fracaso muchas veces no está en la ejecución… sino en haber elegido mal el enfoque.

¿Y si el verdadero problema no fuera el método que eliges, sino no entender el tipo de problema que estás enfrentando?

Antes de decidir si conviene un enfoque tradicional o uno ágil, es fundamental entender la naturaleza del problema. Para eso, nos apoyamos en dos marcos complementarios:

    •  La Matriz de Stacy
    •  El marco Cynefin

La Matriz de Stacy es una herramienta de análisis creada en los años 90 por el profesor Ralph D. Stacey, especialista en gestión organizacional y teoría de la complejidad. Surgió como respuesta a un problema común en entornos empresariales: la tendencia a aplicar siempre el mismo enfoque de gestión sin considerar la naturaleza del problema.

Esta matriz se ha vuelto especialmente relevante en contextos donde la innovación, la transformación digital o el desarrollo de productos requieren respuestas adaptativas y no meramente procedimentales.

Stacy Matrix
Cynefin framework

El Marco Cynefin fue desarrollado en 1999 por Dave Snowden, un investigador galés en teoría de la complejidad y gestión del conocimiento.

Este marco es herramienta para la toma de decisiones según la naturaleza del contexto o problema. Se utiliza ampliamente en gestión empresarial, estrategia, liderazgo y resolución de problemas complejos.

Ambos ayudan a diagnosticar con qué estás lidiando, evaluando dos dimensiones clave:

1. Certidumbre: ¿Qué tan claro es el problema y su solución?

2. Acuerdo: ¿Qué tanto consenso hay entre los involucrados?

La Matriz de Stacy

Esta matriz cruza certeza y acuerdo para clasificar el tipo de problema y, por lo tanto, sugerir el enfoque adecuado:

Alto Acuerdo Bajo Acuerdo
Alta Certidumbre Problema Simple: soluciones conocidas, procesos repetibles.
Enfoque tradicional.
Problema Complicado: requiere análisis experto.
Planificación detallada.
Baja Certidumbre Problema Complejo: múltiples variables, relaciones no evidentes.
Necesita ciclos cortos, prueba y error.
Problema Caótico: sin tiempo para análisis.
Actuar, contener, luego reflexionar.
El marco Cynefin

Refuerza la idea de que no todos los problemas se abordan igual:

1. Simple (Claro)

Enfoque: Procedimientos estándar, buenas prácticas.

2. Complicado

Enfoque: Análisis de expertos, planificación robusta.

3. Complejo

Enfoque: Experimentos, ciclos cortos, aprendizaje continuo.

4. Caótico

Enfoque: Acción inmediata, contención, estabilización.

Conclusión

No se trata de ser fan del enfoque ágil o del tradicional.
Se trata de entender el problema antes de aplicar la solución.
Cuando el entorno es estable y predecible, un enfoque tradicional puede funcionar.
Pero en entornos inciertos, cambiantes o con múltiples actores y puntos de vista, necesitas flexibilidad, adaptación y ciclos cortos.

El enfoque no debe ser un dogma.
Debe ser una respuesta consciente al contexto que estás enfrentando.

Déjanos tus comentarios

El Ingeniero de Software como eje del Producto

El Ingeniero de Software como eje del Producto

El Ingeniero de Software como eje del Producto

Por qué reducir al Ingeniero de Software a “escritor de código” es un error estratégico

Antes de hablar de liderazgo —tema que abordaré en el próximo post—, es fundamental entender bien a los equipos que serán liderados. En este caso particular, quiero centrarme en una figura clave dentro de cualquier organización tecnológica: el Ingeniero de Software. El Liderazgo lo dejaré para el siguiente post.

A lo largo de mi experiencia he sido testigo de cómo ha evolucionado su rol, así como las expectativas sobre sus capacidades y responsabilidades.

La industria del software ha atravesado transformaciones profundas —en gran parte gracias a las ideas de referentes que replantearon cómo desarrollamos productos y servicios digitales— y, como consecuencia, también ha cambiado lo que se espera de un Ingeniero de Software.

Aunque en algunas corporaciones aún se pretende dictar de forma rígida lo que un ingeniero debe hacer o codificar, la realidad es que su papel se ha ampliado: hoy participa activamente en la toma de decisiones y en la definición de soluciones.

El ingeniero de software moderno es un colaborador clave, el corazón técnico del producto.

Es fundamental reconocer que su impacto no depende únicamente de sus conocimientos técnicos. Para aportar verdadero valor, necesita desarrollar tanto habilidades técnicas (hard skills) como habilidades interpersonales y organizativas (soft skills).

Soft Skills (Habilidades Blandas)
    • Trabajo en equipo y colaboración
    • Adaptabilidad y gestión del cambio
    • Comunicación efectiva
    • Pensamiento crítico y resolución de problemas
    • Proactividad y autonomía
    • Feedback y aprendizaje continuo
    • Orientación al cliente y valor
    • Gestión del tiempo y priorización
Hard Skills (Habilidades Técnicas)

    • Programación y dominio de lenguajes
    • Herramientas administrativas y de documentación
    • Control de versiones y trabajo en repositorios
    • Automatización y DevOps
    • Testing y QA
    • Cloud Computing
    • Diseño de arquitectura
    • Seguridad en el desarrollo
    • Bases de datos y modelado de datos
    • UX y accesibilidad

El trabajo de un programador es mucho más amplio que solo escribir código. Además de programar, participa en actividades esenciales para garantizar que el equipo entregue valor al negocio de manera continua. Esto va desde la colaboración con stakeholders hasta la evolución constante del equipo y del producto.

Si tuviéramos que imaginar el peso de cada una de estas áreas en su día a día, probablemente el acto de codificar ocuparía solo una parte. El resto se distribuye entre diseño, validación, comunicación, soporte, decisiones técnicas y evolución del producto.

Distribución de Tareas de un Ingeniero de Software (Porcentajes)

1. Programación y Desarrollo (30%-40%)

    • Escribir y revisar código.
    • Implementación de features basadas en los requerimientos del sprint.
    • Refactorización de código para mantener estándares de calidad.
    • Pruebas automatizadas (unitarias, de integración).

2. Refinamiento y Discovery (15%-20%)

    • Participación en sesiones de refinamiento para entender y descomponer historias de usuario.
    • Análisis de requisitos con el Product Owner y los stakeholders.
    • Participación en discovery para investigar soluciones técnicas o alternativas.
    • Validación y aclaración de dudas técnicas durante la fase de planificación
    Ingeniero de Software Coding

    3. Reuniones de Comunicación y Colaboración (15%-20%)

    • Dailies: Revisar progreso y coordinarse con el equipo.
    • Planning y retrospectivas: Definir objetivos del sprint y mejorar procesos.
    • Sincronización con otras áreas: Colaboración con diseñadores UX, DevOps, QA, etc.
    • Comunicación con stakeholders para alinear la visión técnica con las expectativas del negocio.

    4. Testing y Control de Calidad (10%-15%)

      • Desarrollo basado en pruebas (TDD/BDD) para asegurar un código robusto.
      • Code reviews para mantener estándares de calidad y compartir conocimiento.
      • Corrección de bugs detectados en ambientes de prueba o producción.
      “Su labor comienza desde las etapas más tempranas del ciclo de vida del producto: participa en el descubrimiento, colabora en el diseño, comprende las necesidades del negocio, conceptualiza soluciones viables y se hace responsable de su calidad y mantenimiento”

      5. Investigación y Aprendizaje Continuo (10%-15%)

        • Exploración de nuevas tecnologías o patrones que aporten valor al equipo.
        • Capacitación en mejores prácticas y herramientas de desarrollo.
        • Documentación de procesos y mejoras continuas.

      6. Mejora Continua y Automatización (5%-10%)

        • Optimización de procesos del equipo (automatización, scripts, pipelines).
        • Participación en la mejora de prácticas de desarrollo dentro del equipo.
        • Monitoreo y ajuste de herramientas de CI/CD para mejorar el flujo de trabajo.
      Developer Creating

      Conclusión

      El Ingeniero de Software no debe ser reducido a una función operativa limitada a escribir líneas de código. Su labor comienza desde las etapas más tempranas del ciclo de vida del producto: participa en el descubrimiento, colabora en el diseño, comprende las necesidades del negocio, conceptualiza soluciones viables y se hace responsable de su calidad y mantenimiento.

      Es crucial invitarlo a involucrarse activamente en las reglas del negocio, en la validación de hipótesis y en la toma de decisiones técnicas que impactan directamente en el producto. En este sentido, debe ser tratado como un agente de valor y corresponsable del resultado, no sólo del entregable. Con ello también viene el deber de asumir las consecuencias —positivas o negativas— de su involucramiento o de su ausencia.

      No debe ser evaluado exclusivamente por su capacidad de escribir código o por métricas de productividad numérica. Su impacto real se manifiesta en cómo contribuye al entendimiento del negocio, en su involucramiento con el equipo, en la mejora continua del producto y en la responsabilidad compartida por la calidad.

      Tratarlo como corresponsable del éxito implica ampliar la mirada con la que se le mide. No se trata de controlar su output, sino de observar su evolución como profesional integral: ¿cómo aporta valor?, ¿cómo se adapta?, ¿cómo mejora?, ¿cómo colabora?

      Por lo tanto, las evaluaciones deben centrarse en la calidad del trabajo, la madurez técnica, la colaboración en equipo y la mejora continua de sus procesos. Todo esto sin dejar de atender las responsabilidades técnicas que el equipo tiene en conjunto.