Estaba haciendo una pregunta sobre PMSE cuando esta pregunta me llamó la atención. He estado trabajando como Project Manager para una empresa de software.
La mayor parte de nuestro trabajo lo obtenemos de una agencia. La agencia, a su vez, obtiene ese trabajo de otra agencia, que puede obtenerlo de otra agencia o del cliente directo. Al final de esta cadena siempre hay un cliente directo (por supuesto). Los siguientes son los dos modos en los que obtenemos trabajo:
Nosotros > Agencia #1 > Agencia #2 > Cliente
Nosotros > Agencia #1 > Agencia #2 > Agencia #3 > Cliente
Inicialmente habíamos comenzado a seguir Agile para el desarrollo, pero pronto nos dimos cuenta de que no funcionaba para nosotros. La razón es que para cada sprint, si tenemos alguna aclaración requerida o elementos bloqueados que deben ser atendidos, atraviesa la ruta desde nosotros hasta el cliente final.
Bajo tal situación, los elementos de acción ascienden en la cadena dependiendo de las prioridades de las agencias involucradas o de los clientes. Muchas veces, no recibimos actualizaciones en un solo sprint, se extiende a 2 o 3 sprints para obtener actualizaciones.
A medida que recibimos elementos de trabajo, los analizamos y estimamos y los enviamos para su aprobación, lo que también puede demorar semanas o días, según la disponibilidad del respectivo gerente de proyecto/cuenta de las agencias. Lo mismo se aplica a la aprobación de tareas terminadas, que es relativamente más rápida.
Sabemos que no podemos seguir completamente los modelos de Waterfall tal como están. Hemos estado pensando en formular y seguir una combinación de Waterfall, Agile y V-model para facilitarnos la vida.
Dado el nivel de dependencia que tenemos de varias partes interesadas, ¿qué proceso general de desarrollo adoptaremos?
Tengo una opinión diferente a las otras respuestas aquí. El problema aquí es, claro, la gestión de proyectos.
Las limitaciones fundamentales parecen ser:
Ahora scrum no funcionará, porque scrum depende en gran medida de los tiempos de respuesta rápidos para la aceptación/aclaración del trabajo. Kanban no funcionará porque todas las tareas de bloqueo se bloquearán en las comunicaciones del cliente, por lo que el equipo de desarrollo no puede asignarle más recursos para hacer avanzar la tarea.
Entonces, ¿qué puede hacerse?
En primer lugar, mejorar la cadena de suministro. Trabaje con sus clientes para generar confianza y permitir comunicaciones más directas con el cliente <--> equipo de desarrollo cuando las conversaciones se refieran a la definición de tareas, reglas comerciales. Estas conversaciones deben limitarse a que los desarrolladores soliciten al cliente final información técnica y decisiones técnicas y devuelvan las respuestas. Cualquier flujo de información que regrese al cliente debe manejarse a través de la cadena de suministro (como demoras, costos, el cliente solicita el suministro de una máquina de movimiento perpetuo o alguna otra tarea imposible)
Cree una biblioteca más grande de tareas 'listas para usar' o 'realizables'. Tareas donde el trabajo está definido, claramente entendido por los desarrolladores y el cliente está feliz de que ese trabajo continúe.
Programe reuniones de revisión periódicas con el cliente final para que revisen el estado actual del trabajo. Si bien es posible que no se sepa cuándo se organiza la reunión qué trabajo será demostrable, esto crea un pulso regular de comentarios de los clientes finales a los desarrolladores para mantener su dirección en línea con las necesidades percibidas de sus clientes.
Finalmente, acepte que en ocasiones el trabajo se bloqueará debido a retrasos en la comunicación con el cliente. Puede manejar eso internamente teniendo trabajo para otros clientes que se pueden programar, adivinando lo que el cliente preguntará mientras espera la respuesta, aceptando que podría estar desperdiciando trabajo o teniendo personal por contrato para que que solo les pagas cuando tienes trabajo disponible (ohh espera, eso es lo que han hecho tus clientes...)
No tiene una dependencia de múltiples partes interesadas; tiene una falla de proceso en la interfaz entre usted y la Agencia #1. Buscar metodologías alternativas no resolverá el problema del proceso, pero abordarlo directamente podría hacerlo.
Según su descripción, no tiene ningún contacto directo con el usuario final. Si bien pueden ser partes interesadas en algún sentido abstracto, según su descripción, tiene exactamente una interfaz de cliente: Agencia #1.
El hecho de que esta agencia pueda tener sus propias partes interesadas (y así sucesivamente) debería ser irrelevante para definir su interfaz de comunicaciones con la Agencia #1. Si no se le permite comunicarse directamente con la Agencia n.º 2, la Agencia n.º 3 o el usuario final, entonces deben excluirse como partes interesadas de su proceso interno.
Tiene varias formas de lidiar con los retrasos excesivos en las comunicaciones. Algunos ejemplos incluyen:
No se puede disimular un problema de proceso fundamental cambiando de metodología. No hay bala de plata; debe abordar este problema de frente. El marco de gestión de proyectos que elija no es realmente relevante para resolver el problema en cuestión.
Me inclino a pensar que más que un cambio de proceso tu equipo necesita un cambio de relación.
Creo que ustedes necesitan "acercarse" al eventual cliente.
¿Qué tal construir un caso aguas arriba en
Escalamiento: resalte el impacto que está teniendo el proceso actual, es decir, retrasos en la entrega, aclaración, comunicación lenta
Bucles de retroalimentación más breves: proponer ideas para agilizar los canales de comunicación con el cliente (p. ej., reuniones virtuales diarias/semanales/llamadas en conferencia directamente con el cliente/los encargados de tomar decisiones).
Rechazar: abogar por no retomar historias/comprometerse donde hay demasiadas incógnitas. Esto resaltará aún más el dolor que ustedes están experimentando.
No estoy seguro de cuál es la cultura política en su relación con esas agencias, por lo que debe tener cuidado al equilibrar esto diplomáticamente para que las agencias no se sientan amenazadas o marginadas. Por lo tanto, es necesario reforzar el mensaje de que se trata estrictamente de mejorar la comunicación y facilitar una toma de decisiones más rápida.
¿Has considerado Kanban ?
Este es un proceso Lean, pull que parece adecuado para su situación.
Esto es lo que puede hacer y cómo puede beneficiarse de Kanban:
Kanban se trata de optimización, pero lo que es más importante, se trata de una mayor previsibilidad. Después de un tiempo, obtendrá mejores datos sobre el tiempo promedio para completar un elemento. Armado con aquellos que podría tratar de influir en sus partes interesadas -> agencias con las que coopera.
Aquí hay un buen enlace de Kanban para que comiences: http://www.leankanbanuniversity.com/introducing-kanban
david hillier
david hillier