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.

      MVP

      MVP

      ¿MVP? ¿Para qué sirve? Quiero empezar con las razones por las cuales es conveniente hacer un MVP y no con la definición, creo que es el flujo correcto para este tema, ya que el concepto es simple, pero puede llegar a confundir, sin embargo, las razones son muy claras para decidirse a hacer uno. ¿Para qué queremos un MVP? Hay una serie de ventajas, algunas parecerán retadoras, pero créeme, sí son ventajas.
      • Exponer nuestro producto a los clientes
      • Es una manera efectiva de recibir retroalimentación para saber el rumbo de las siguientes fases, y priorizar los desarrollos
      • Es una forma de empezar a generar ROI
      • Es una gran manera de apresurar el Time-to-Market que es esencial para comenzar a generar flujo de dinero o servicios
      • Comienza a posicionarse en el mercado
      • No inviertes una gran cantidad de dinero y tiempo en características que quizás no sean importantes
      • Nos obligamos a ser concisos y enfocarnos en la necesidad que deseamos plantear
      Todas estas son razones muy positivas y muy claras de por qué es buena idea hacer un MVP, ahora vamos a las definiciones formales o que dan los autores. Definiciones formales Sí, bueno, son necesarias, las bases y las formalidades son a mi parecer fundamentales. MVP o Producto Mínimo Viable es la versión de un nuevo producto que permite a un equipo recolectar la máxima cantidad de aprendizaje validado de los clientes con el mínimo esfuerzo. (1) Es un término acuñado por Frank Robinson en el 2001 (2): El MVP es ese dulce punto en el cuadrante superior izquierdo en una gráfica donde el ROI está en el eje Y mientras el riesgo en el eje x que se correlaciona directamente con el esfuerzo y el Time-to-Market   Después de ver que es un MVP, por qué no mejor vemos ¿Qué es un MVP? Sí, trataremos de aclararlo un poco más. Un MVP es nuestro producto, aún no está terminado, pero es una versión mínima pero funcional que ya realiza el objetivo que perseguimos con él. (no perder de vista la V en MVP) El ejemplo clásico que verán en todos lados, (aunque se puede hacer con cualquier producto) es que tenemos un producto nuevo, una especie de vehículo para transportarnos de un lugar cercano a otro. Se me antoja llamarlo automóvil. Innovador, donde no tenga la necesidad de caminar. La idea es que pueda tener radio y aire acondicionado, que tenga lucecitas y esté forrado en piel, a lo mejor que venga en 43 diferentes colores radiantes y que sea descapotable. ¿Podría decir que una llanta es parte de mi producto? Sí, inobjetablemente. ¿Es mínimo? Sí, definitivamente ¿Es viable? No, no cumple con el primer propósito Mi proyecto automóvil tiene muchas características, sin embargo. Tiene un primer propósito único: llevarme de un lado a otro sin necesidad de caminar. Es entonces que la opción de algo mínimo y viable es la opción de una tabla con ruedas, que básicamente es una patineta, que cumple con la definición de MVP. Que ya puede transportarme, evitar que camine y si tengo 17 años me va a encantar. Por favor tomémoslo como es, un ejemplo. Yo también veo algunos detalles, pero si quieren discutirlo, escríbanme. MVP   Después de este brevísimo pero ilustrativo ejemplo veamos otros puntos de vista. El MVP como método científico Eric Ries(3) Menciona que se puede ver a través del método científico. Y seamos honestos, ese argumento sí que podría ser definitivo. De manera muy general, el método científico se resume en los siguientes pasos:
      1. La observación
      2. Reconocimiento del problema
      3. Hipótesis
      4. Experimentación
      5. Análisis de resultados
      6. Comprobación de la hipótesis
      Después de haber observado el medio que nos rodea, reconocemos alguna necesidad que podemos cubrir. Tenemos la hipótesis de que nuestro producto va a ser exitoso, ya que tenemos la solución perfecta. Es el momento de la experimentación: Es allí donde entra nuestro MVP Una parte apenas completa que resuelve la necesidad a cubrir, para, obtener los resultados que nos servirán para comprobar si vamos por buen camino, o cambiamos el rumbo. Suena lógico, ¿cierto? no podemos asegurar que algo funciona ni meterle un par de años de desarrollo y varios millones de pesos si no he comprobado que va a resolver el problema y si no va a tener buena aceptación, aunque ese podría ser un problema de marketing.   El MVP como una prueba. En el mundo del software, todo lo que se realiza necesita una prueba. Si se realiza un formulario, debe haber un caso de uso que pueda validar que el formulario es correcto, que guarda la información y regresa un mensaje de éxito. El MVP puede verse como la “prueba de fuego” de tu producto, servicio, estrategia de marketing, software, tienda, etcétera, cuyo resultado servirá para saber si vamos bien o cambiamos la estrategia. La idea es que “No es necesario tener un producto terminado para lanzarlo al mercado” o “No hace falta que mi estrategia esté completa y súper-mega definida para probarla” o ” no es necesario que tenga todos los servicios estructurados y con precios” o… Bueno creo quedó claro. Hay mil formas de tener un MVP.  Tantas como productos o servicios, estrategias, software, tienda etcétera (sí, repetí lo de arriba, no quiero que se nos olvide que aplica para cualquier cosa) o tantas como la imaginación nos puede dar, los dos casos más famosos y que menciona el libro “Lean Startup” (4) son la tienda online de zapatos Zappos, donde el fundador para probar su idea, montó una tienda SIN STOCK, cada par vendido él lo compraba en la zapatería y lo mandaba por paquetería. Él invirtió lo necesario para hacer una prueba, para comprobar su hipótesis: “Hacía falta quien vendiera zapatos online, porque la demanda era grande”.  ¿Metió dinero? Sí, ¿Pudo haber metido más? Mucho más. Hizo lo mínimo indispensable para poder comprobar su punto. Cuando comprobó que su hipótesis era correcta y la demanda era suficiente, invirtió en stock y en todo lo necesario para darla a conocer masivamente. El otro caso es Dropbox, ellos invirtieron en publicidad sin tener nada construido, pusieron una página de internet para que te pre-suscribieras y al obtener feedback y darse cuenta de la gran demanda, comenzaron a construir la infraestructura. Puede haber tantos MVPs o fases del proyecto o pruebas o hipótesis como sean necesarias. Es importante probarlas y tener retroalimentación. ¿Qué debemos tomar en cuenta al hacer un MVP? ¡Sea pues! ¿Cómo empezamos? Bueno queda claro qué debemos hacer, más bien debemos tener en cuenta los siguientes puntos al diseñar nuestro MVP: No pierdas el foco Es fácil perderse entre todo lo que puede hacer un sistema, o todo lo que puede abarcar un producto, o todos los servicios que podríamos dar, siempre hay un poco más que se puede hacer.  Lo que queremos es salir con lo mínimo indispensable para comprobar nuestra hipótesis, así que no pierdas eso de vista. Es una prueba, hazlo para que sea probado y acepta los resultados Hay programadores que crean el escenario ideal para probar sus desarrollos, siempre pasan las pruebas, por eso existen (¿existían?) departamentos de QA (Quality Assurance) independientes, para probar exhaustivamente el desarrollo, sólo así descubrimos qué está bien, qué requiere volver a hacerse o cambiarse. ¿Makes sense? Envía tu prueba a tu mercado específico Hay que tener siempre en cuenta el mercado al que mandemos nuestro MVP. No te olvides de él. NO le vayas a enviar un videojuego a mis papás, probablemente no recibas el mejor feedback que pudieras recibir, quizás no recibas feedback. Tu primer mercado si eres una start up con un producto nuevo serán los llamados early adopters quienes son entusiastas y recibirás un gran feedback, esto te dará un gran impulso y dirección. Tal vez para tu segunda fase tengas un feedback distinto. Prepárate para el cambio. Oye, pero… ¿Algo puede salir mal? De acuerdo a Andrea Contigiani(4), sí. Si tu idea es revolucionaria y no tienes el soporte para tomar acciones rápidas puedes estar regalando la idea a alguien más. El consejo que da Andrea es, no salgas demasiado pronto con el MVP. Sin embargo, hay formas de protegerte, propiedad intelectual, inversionistas, no estás cien por ciento protegido. No quiero decir que tu producto, servicio, estrategia, software no sea grandioso o grandiosa, pero… en general es poco probable que te roben la idea. Se da y hay que tener definitivamente todas las precauciones, pero haz tu MVP. Espero que este pequeño documento te haya servido. Si tienes alguna duda, comentario o si podemos participar en tu estrategia para tu MVP, estaremos felices de hacer equipo. Tenemos un Workshop perfecto para tu equipo de trabajo   (1) http://www.startuplessonslearned.com/2009/08/minimum-viable-product-guide.html (2) http://www.syncdev.com/minimum-viable-product/ (3) https://amzn.to/2AU2zju (4) https://knowledge.wharton.upenn.edu/article/the-limitations-of-lean-startup-principles/