Posts con el tag ‘proyectos’

Gestión de proyectos complejos: métodos Agile y Scrum

scrum agileEn los últimos años, los modelos de gestión empresarial han tenido que adaptarse a las nuevas condiciones de mercado ‘turbulentas’, típicas del Mundo VUCA, caracterizadas por una competencia extremadamente alta y una necesidad de mayor productividad, velocidad y calidad. Un contexto que ha llevado a un cambio importante en la gestión de los proyectos complejos.

De la experiencia de la industria del software, se han introducido metodologías y técnicas para mejorar la productividad empresarial: el método Agile y Scrum.

¿Qué es el método Agile?

El método Agile está basado en la interacción continua con los stakeholders, cuya satisfacción es crucial para el éxito del proyecto y para el desarrollo de la organización. Los principios que deben respetarse para que un método se pueda definir Agile son:

  1. Individuos e interacciones más que procesos y herramientas.
  2. Software o procesos que funcionan más que documentación exhaustiva.
  3. Colaboración con el cliente más que negociación de contratos.
  4. Responder y adaptarse al cambio más que seguir un plan.

La idea del Método Agile no se basa en el enfoque clásico y lineal de los proyectos, sino en la posibilidad de llevar a cabo un proyecto por fases, llamadas ‘Sprint‘. A cada sprint le corresponde una nueva funcionalidad y se verifica la satisfacción del cliente, tras mostrarle el trabajo realizado hasta entonces. Es un sistema iterativo (e interactivo) que permite aportar fácilmente cambios, reducir los costes de producción y, sobre todo, evitar esfuerzos innecesarios y un posible fracaso del proyecto.

Es un enfoque propio de una start-up, para ensayar rápidamente un producto o servicio en el mercado con la menor inversión posible. Es un proceso iterativo durante el cual la idea y la forma inicial del proyecto se modifican y adaptan, de acuerdo con los feedbacks recibidos por los primeros usuarios, hasta alcanzar el producto deseado.

¿Qué es Scrum?

Scrum es el método Agile más extendido, especialmente adecuado para proyectos complejos e innovadores. Es un marco de trabajo que divide el proceso de gestión de un proyecto en sprint, para coordinar el desarrollo del producto según las necesidades del cliente/encargante. Un proceso iterativo en el que los sprints duran de 2 a 4 semanas.

La teoría detrás de este método es la del control empírico del proceso, según la cual, por un lado, el conocimiento proviene de la experiencia y, por otro lado, las decisiones se basan en lo que se conoce. Por esta razón, se adopta un enfoque incremental que optimiza la previsibilidad y el control del riesgo. El método Scrum se basa en los principios de transparencia, inspección y adaptación.

Los principales componentes de Scrum se dividen en: roles, artefactos y eventos.

ROLES: Hay 3 roles definidos dentro del Scrum Team, que trabajan en estrecha conexión para garantizar un flujo de información continuo y rápido.

Scrum Master: la persona responsable del proceso, que debe asegurar que la metodología Scrum es comprendida y ejecutada con éxito. Debe garantizar que el equipo trabaje de forma coherente con el desarrollo del proyecto, eliminar cualquier obstáculo externo que afecte la productividad del equipo y organizar y facilitar las reuniones.

Product Owner: aquel que conoce todos los requisitos del producto y defiende los intereses de todos los stakeholders. La interfaz entre el negocio, los clientes y los requisitos del producto por un lado y el equipo por el otro. Debe maximizar el valor del producto y del trabajo realizado por el Team de Desarrollo.

Team de Desarrollo: un grupo de profesionales multi-funcionales y auto-organizado, cuyo número suele estar entre 5 y 9 personas. Se ocupa del desarrollo del producto y del ensayo de las funcionalidades y tiene la responsabilidad de organizar las prioridades, transformándolas en tareas a llevar a cabo para completar ese sprint determinado.

ARTEFACTOS: Son 3, diseñados para maximizar la transparencia de la información clave (tanto para el Scrum Team como para todos los stakeholders), así como la oportunidad de inspección y adaptación.

Product Backlog: el documento que contiene la lista de todos los requisitos necesarios para la realización del proyecto. El Product Owner es responsable de su contenido, disponibilidad y de la organización de sus elementos, de acuerdo con sus prioridades respectivas.

Sprint Backlog: el documento que define todas las tareas que hay que completar en sprints individuales. Es una predicción hecha por el Team de desarrollo en relación con las prioridades indicadas en el Product Backlog y el trabajo necesario para alcanzar los objetivos de los sprints.

Incremento: la suma de todos los ítems del Product Backlog completados durante un sprint y durante los sprints previos. Al final de cada sprint, el incremento deberá llevarse a cabo de acuerdo con lo acordado por el Team de desarrollo para garantizar un producto utilizable.

EVENTOS: Hay 4 eventos formales previstos en Scrum (con una duración fija) para crear regularidad, sincronizar actividades y minimizar la necesidad de reuniones indefinidas. El objetivo de estos eventos es permitir una transparencia crítica e la inspección sobre el progreso del proyecto.

Sprint Planning: la reunión en la que el Product Owner ha elaborado el Product Backlog y, en presencia del Team de desarrollo y del Scrum Master, describe los elementos más importantes y el objetivo que hay que alcanzar en el siguiente sprint. Al final de la reunión, el Scrum Master puede completar el Sprint Backlog.

Daily Scrum: una breve confrontación diaria (de unos 15 minutos) entre el Team de desarrollo y el Scrum Master, quien anota el trabajo realizado el día anterior y crea un plan para las próximas 24 horas (hasta la próxima Daily Scrum), para programar y sincronizar las actividades.

Sprint Review: una revisión al final de cada sprint para evaluar si el objetivo se ha logrado y con qué resultados. Participa todo el Scrum Team y también el cliente o encargante del producto, al cual se mostrará el trabajo realizado hasta ese sprint.

Sprint Retrospective: un análisis retrospectivo adicional llevado a cabo con la participación de todo el Scrum Team para evaluar qué seguir haciendo, qué dejar de hacer y qué mejorar en el siguiente sprint, para obtener rendimientos aún más eficientes.

Estas metodologías nacieron en un contexto informático, pero los procesos y principios que los rigen las hacen muy rentables para cualquier sistema de negocio que se enfrente a la gestión de proyectos innovadores y complejos, donde se vuelven centrales los individuos y las interacciones más que los procesos y los instrumentos.

Por Andrés Raya

Bibliografía:

 

 

Gestión de Equipos, Gestión de Equipos, Gestión de Personas | , , , , , Leave a comment Permalink

El análisis de pre-mortem: mejor prevenir que curar

Todos sabemos que los proyectos fracasan. Las causas son muchas e incluyen todos los factores que intervienen en la gestión del ciclo de vida de un plan de negocios o producto. Una razón importante es que muchas personas involucradas en la planificación suelen ser reacias a hablar de sus preocupaciones o reservas en el momento de la puesta en marcha.

Los médicos realizan un análisis post-mortem para entender por qué una persona murió. Lo hacen para resolver un crimen, prevenir la muerte de otras personas, para satisfacer la curiosidad científica. En cualquier caso, una vez que alguien ha muerto, ya es demasiado tarde para ayudarle.

Los empresarios y sus inversores también analizan la razón de la “muerte” de un producto, un servicio o una empresa. Y, como en el caso de la muerte de las personas, cuando se lleva a cabo el análisis post-mortem significa que ya es demasiado tarde para hacer algo. Por esta razón, Gary Klein, Jefe Científico de Klein Associates y autor de ‘Fuentes de poder: cómo se toman las decisiones’, introdujo el concepto de pre-mortem. Se trata de la simulación del fracaso de un proyecto llevado a cabo antes de su lanzamiento, para que se pueda mejorar a tiempo.

Hay una cierta tendencia a considerar los riesgos como acontecimientos no ponderables. Si bien es cierto que no podemos saber si y cuándo ocurrirá un evento problemático, también es cierto que podemos preparar un plan de acción y tomar medidas para eliminar o reducir el impacto de un hecho negativo inesperado. Una cuidadosa evaluación, documentación y gestión de riesgos son factores esenciales en toda actividad de gestión de proyectos.

Por otra parte, entre las causas más frecuentes del fracaso de un proyecto, más allá de los factores de organización y gestión, también hay enfoques psicológicos erróneos, como el exceso de optimismo, la creencia de que un evento incierto tendrá siempre un resultado favorable.

En general, el optimismo es un rasgo psicológico positivo que nos apoya en las dificultades y que nos permite perseguir objetivos a largo plazo, incluso soportando dificultades inmediatas. Sin embargo, contiene un elemento de peligro que se debe tener en cuenta, ya que el optimismo nos lleva a sobreestimar las probabilidades de un evento favorable.

No se trata de limitar el entusiasmo y la pasión, que, en cambio, son ingredientes clave para el éxito, sino de desactivar una tendencia a subestimar los problemas y los riesgos, lo que lleva a no dedicar el tiempo suficiente a la actividad de planificación de los detalles del proyecto.

En tiempos de incertidumbre y cambios rápidos como los actuales, la tendencia es no pararse demasiado en las fases de puesta en marcha y planificación, para llegar rápidamente a la fase de ejecución. Se nos olvida, sin embargo, que cuesta mucho menos identificar y eliminar los errores a través de una cuidadosa planificación previa, que tener que corregir los fallos una vez en marcha.

A diferencia de una típica sesión de crítica, en la que a los miembros del equipo se les pide lo que podría salir mal, el análisis pre-mortem empieza con el presupuesto de que “el paciente” ya está muerto, por lo que nos preguntamos lo que efectivamente salió mal.

Klein sugiere reunir el equipo de trabajo y enumerar todas las razones del fracaso. Cada miembro del equipo tiene que escribir al menos una causa en una lista común. El siguiente paso es averiguar juntos cómo evitar el resultado negativo. Estudios académicos estiman que el análisis pre-mortem puede mejorar en un 30% la identificación de posibles riesgos, mejorando así el enfoque y la toma de decisiones.

Los miembros del equipo deben imaginar los escenarios negativos y preparar las estrategias de rescate o verdaderas exit strategy, que son requisitos esenciales en el desarrollo de cualquier proyecto. El análisis de pre-mortem, no sólo ayuda al equipo en la identificación con antelación de problemas potenciales, sino que también reduce posibles actitudes de superioridad de los que gestionan un proyecto. El análisis preventivo y colectivo hace más humildes y abre horizontes, iluminando nuevas perspectivas hasta entonces no consideradas.

Además, identificar las debilidades que nadie había mostrado antes, permite que el equipo se sienta apreciado por su capacidad de análisis. Los miembros con menos experiencia aprenden de los más veteranos y se asegura así la participación activa y responsable en el proyecto de todos los integrantes del grupo.

El ejercicio también sensibiliza al equipo para detectar signos tempranos de problemas una vez que el proyecto ya se haya puesto en marcha y poder intervenir a tiempo con correcciones adecuadas. Al final, un pre-mortem bien ejecutado puede ser la mejor manera de sortear cualquier necesidad de un post-mortem doloroso.

Por Andrés Raya

 

Gestión de Equipos, Gestión de Personas, Liderazgo | , , , , Leave a comment Permalink