¿Y si cada dia empezáramos con un briefing?

21 de octubre de 2017

Esta entrada fue publicada previamente en Agencia de Aprendizaje.

En el artículo de hace meses “Incorporar “nuevo” talento en la empresa” os hablábamos del proceso de incorporación de un responsable de equipo no surgido del mismo. En “Seis o nueve” seguimos hablando del caso y creo que, por último en “¿Qué fue del 360?”. El caso és que al final la persona que, con ciertas dificultades, se estaba incorporando a los ocho meses se ha desvinculado marchándose. Como os hemos ido contando en este proceso se implicó a todo el personal de la empresa con la intención de que se consiguiera una adaptación exitosa con un recorrido a medio y largo plazo. La historia no ha terminado así como se deseaba y actualmente tenemos al equipo de operarios dirigidos directamente por el Jefe de Servicio, sin un mando técnico directo. Mientras se decide si se consolida este modelo apostando por un equipo de alto rendimiento, seguimos trabajando en las sesiones de formación / acompañamiento individuales.
daily_scrum

http://www.becominganagilearchitect.com/scrum-eventos-scrum-diario-stand-up-meeting

Ha sido en una de las primeras que un miembro del equipo me ha hecho la siguiente consulta antes de presentarla al Jefe de Servicio y al resto del equipo. “¿Y si cada dia empezáramos con un briefing?”

“Si cada dia antes de salir a reparar maquinaria en casa de los clientes hiciéramos una reunión de todos de pie en el taller y cada uno comentara brevemente la reparación que tiene previsto empezar o continuar, podríamos resolver pequeñas dudas, poner en común experiencias pasadas sobre la reparación de estas mismas averías o máquinas. Así saldríamos más seguros, con el material necesario y probablemente resolveríamos las averías en menos tiempo para satisfacción del cliente y nuestra. A parte que rebajaríamos nuestro sentimiento de incertidumbre”

Pues si, el briefing definido como la corta reunión diaria de planificación en donde se revisan las tareas más importantes o críticas para el día y que viene siendo utilizado por los de marketing, publicidad y diseño nos puede también servir en un servicio de reparación de maquinaria.

También podemos tomar la idea de los Scrum daily meeting o reunión diaria de sincronización del equipo también llamada Stand-up meeting por el hecho de hacerse de pie que llevan a cabo en la gestión de proyectos los seguidores de metodologías com la Scrum o la Kanban para el desarrollo de software.

Como decimos, un briefing, un scrum daily meeting, , un stand-up-meeting o para que nos entendamos, una reunión de revisión de partes de trabajo nos puede ser de gran ayuda para mejorar nuestra eficacia y eficiencia a la vez que aumentamos la cohesión de equipo y gestionamos el conocimiento compartiéndolo.

Algunas sugerencias:

  • Cada dia a la misma hora.
  • De pie.
  • 5 / 10 / 15  minutos (depende del número de asistentes y tareas a revisar).
  • Cada participante comenta brevemente los partes para el día y los inconvenientes que se podrían presentar.
  • Muy importante: Cuando un participante puede ayudar al otro explicando una experiencia o una técnica si eso va a llevar más de uno o dos minutos, se hace fuera del grupo al terminar la reunión.
  • Que alguien tenga el encargo de moderar, controlar y reconducir la reunión para que no se salga del tema o del tiempo previsto. Si este alguien conoce técnicas de gestión de reuniones, mejor.

Esta reunión como herramienta para la mejora de la productividad y de la cohesión de equipos es adaptable a cualquier tipo de empresa, sea cual sea su objeto. En empresas grandes de trabajadores por turno puede resultar muy compleja de organizar pero se pueden buscar fórmulas.

Si te gusta la idea desde Agencia de Aprendizaje te podemos ayudar a diseñarlas e implementarlas en tu organización. ¿Te apuntas?

Anuncios

PREPARANDO 5: DESARROLLO EN CASCADA vs DESARROLLO ÁGIL

5 de diciembre de 2015

Después de la resaca de nuestro tercer aniversario como Agencia de Aprendizaje, publiqué el 30/11/2015 este artículo mientras preparaba una acción formativa de nivelación. Se trataba de que parte de la organización entrase en contacto con la gestión de proyectos y diera un paso más y conociera las “nuevas” tendencias y así se alineara con una minoria de la organización que si ya estaba al tanto del tema.

DESARROLLO EN CASCADA vs DESARROLLO ÁGIL O lo que es lo mismo Waterfall vs Agile como dicen en inglés.

Estamos hablando de metodologías aplicadas principalmente a desarrollo de software pero que se han trasladado a la gestión de cualquier tipo de proyectos.

El desarrollo en cascada representa la forma “tradicional” de gestión de proyectos en la que no se inicia una siguiente fase hasta que no se ha finalizado la anterior. Sus características diferenciadoras son:

  • Estructurado
  • Un gran proyecto
  • Un proceso secuencial
  • Adecuado para situaciones donde el cambio es poco común
  • Interno (cerrado)
  • Un proceso que requiere de requisitos claramente definidos por adelantado

El desarrollo ágil representa la respuesta a las exigencias actuales. Implica metodologías basadas en el desarrollo iterativo e incremental, donde los requisitos y soluciones evolucionan con el tiempo según la necesidad del proyecto, así el trabajo es realizado mediante la colaboración de equipos auto-organizados y multidisciplinarios, inmersos en un proceso compartido de toma de decisiones a corto plazo. Ágil es:

  • Flexible
  • A base de proyectos pequeños
  • Altamente colaborativa
  • Mejor para aquellos que quieren mejoras continuas
  • Involucra a los clientes
  • Un proceso en el que se espera que los requisitos van a evolucionar y cambiar

“Los líderes ágiles conducen equipos, los no ágiles gestionan tareas.”

Para nosotros existe un importante avance al pasar de la gestión de proyectos “tradicional” a la gestión de proyectos ágil. Nos situamos en linea con las exigencias actuales de cambio, flexibilidad, rapidez, y ajuste a los recursos disponibles.

Existe un Manifiesto para el Desarrollo Ágil de Software que dice lo siguiente:

Estamos descubriendo formas mejores de desarrollar software tanto por nuestra propia experiencia como ayudando a terceros. A través de este trabajo hemos aprendido a valorar:

Individuos e interacciones sobre procesos y herramientas
Software funcionando sobre documentación extensiva
Colaboración con el cliente sobre negociación contractual
Respuesta ante el cambio sobre seguir un plan

Esto es, aunque valoramos los elementos de la derecha, valoramos más los de la izquierda.

Es decir:

  • Lo importante son las personas
  • Lo importante es lo que se hace
  • Co-creando con el cliente
  • Adaptación al cambio

Uno de estos métodos ágiles es el Scrum, del cual hablaremos en otra ocasión, y existen aplicaciones como Trello o Asana que nos permiten gestionarlos.

La cuestión esta en saber si realmente estamos utilizando la metodología más correcta para desarrollar nuestros proyectos. ¿La revisamos juntos?


A %d blogueros les gusta esto: