Antecedentes: una gran empresa de consultoría quiere utilizar mejor el tiempo de sus consultores cuando están entre asignaciones. El plan es tener un concepto interno que gestione proyectos internos, que tienen como objetivo entregar valor a la empresa (demostraciones de venta, productos internos, etc.) y también brindar a los consultores la oportunidad de adquirir nuevas habilidades (por ejemplo, obtener experiencia trabajando como Scrum). Maestro).
El uso de Scrum para estos proyectos está obteniendo resultados mixtos, ya que el personal abandona los proyectos casi de inmediato cuando recibe una asignación remunerada, lo que hace que sea imposible obtener una velocidad constante.
Estas circunstancias también aumentan la demanda sobre la facilidad con la que uno puede ingresar a estos proyectos, por ejemplo, la legibilidad del código, la documentación de la toma de decisiones, etc. Un riesgo es que esto podría aumentar la naturaleza en cascada de estos proyectos, lo que me gustaría mucho. para evitar
Entonces, ¿cómo gestionar estos proyectos? ¿Métodos de proyecto a utilizar? Trampas a evitar, y ¿cómo? Cualquier ayuda sería muy apreciada
Scrum asume un equipo fijo, por lo que, como dijo otro respondedor, no es una sorpresa que haya encontrado Scrum frustrante. Y mientras dices que quieres "utilizar" a las personas más empuja contra las suposiciones falsas que puedes programar al 100% a las personas, sin embargo, estoy de acuerdo con los objetivos de ayudar a las personas que no están en un cliente a encontrar formas de enfocarse en otras actividades valiosas.
Esto suena más a conceptos como "FedEx Days" o "80% time". Esencialmente, generar pautas para la gente pero no tratar de crear proyectos con fechas, entregas o compromisos. Recoge "Drive" de Daniel Pink. También puede darle algunas ideas sobre cómo puede ayudar a motivar y guiar a los consultores en el banco.
He trabajado en consultorías y, según mi experiencia, siempre nos entusiasmó trabajar juntos cuando volvimos a nuestra base de operaciones. Nos dio una manera de mejorar nuestro negocio y aprender unos de otros y el desafío del liderazgo era encontrar formas de facilitar eso para nosotros y al mismo tiempo apoyar a los clientes.
En cuanto a herramientas más específicas, puede probar un tablero Kanban, pero le preguntaría seriamente por qué necesita medir la velocidad (velocidad o rendimiento). Tal vez solo necesite un indicador visible o una forma de entregar o una forma de ver lo siguiente que debe recoger cuando regrese. Cree la herramienta a su medida, no la conduzca con el proceso. Buena suerte
No estoy seguro de que Scrum sea la herramienta adecuada para el trabajo en este caso. Un caso similar se puede encontrar en el desarrollo de software libre/de código abierto, donde las contribuciones son intermitentes y heterogéneas.
Probablemente un sistema sin iteraciones específicas, pero con implementación continua y velocidad variable, como Kanban , podría adaptarse mejor a usted.
No existe una bala de plata para solucionar el problema de su organización que no invertirán en proyectos internos. La forma de hacer un proyecto con éxito es dotarlo de personal de manera realista y ejecutarlo con ese personal. Si tiene personas que simplemente están matando el tiempo, no estarán interesadas ni comprometidas con su asignación de duración desconocida a corto plazo.
Sugeriría que usar una metodología de proyecto iterativo en realidad te está perjudicando.
¿Por qué? Las metodologías ágiles se basan en un equipo constante con una velocidad alcanzable constante. Si tiene un equipo de 5 y en un ciclo de 3 semanas (sprint, incluso) pierde a 2 personas, pierde el control de esa velocidad y tendrá que entregar menos o cambiar el marco de tiempo de su ciclo de desarrollo.
Creo que sus proyectos podrían ser más exitosos si dedicara un equipo más pequeño (¿2 personas?) él o ella una pequeña cantidad de trabajo que su organización puede comprometer a dejar que terminen. En nuestros proyectos ágiles y no ágiles (y algunos con híbridos de cada uno) hacemos que nuestros paquetes de trabajo definibles y comprobables sean lo más "factibles" posible en menos de una semana. Todo lo que supere los 3-5 días de trabajo se cuestiona con la esperanza de que se rompa.
Creo que la mejor manera para usted es crear primero un backlog, tratar de hacer una visión de qué es exactamente lo que quiere lograr con esta herramienta. Una vez que tenga un retraso como se mencionó anteriormente, intente tener 2 personas a bordo a largo plazo. Estos muchachos deberían entender el diseño/requisitos. Entonces puedes seguir agregando personas a su alrededor. Para un proyecto interno ninguna empresa en el mundo pondrá recursos ni dinero. Así que haga demostraciones de vez en cuando para actualizar a las partes interesadas y hacer uso de las personas en el grupo
Scrum sugiere tener un equipo fijo, por lo que será difícil rastrear la velocidad de su proyecto.
lo que sugeriría es dividir las tareas en el tamaño más pequeño que se pueda completar en un día y luego aplicar el ciclo de desarrollo de estilo Kanban. ayudará a poner en marcha el trabajo, así como también podrá monitorear la contribución individual.
david hillier
magnus.westrom