Criterios de activación para cambiar una versión candidata

En un proyecto de desarrollo de software en el que planeamos lanzarlo cada tres semanas, tengo un cliente que ha estado retrasando la UAT para una versión candidata alrededor de 4 semanas.

La alta gerencia no ve la necesidad de presionarlos, pero esto nos está causando problemas. Para que el equipo no se detenga por completo, hemos comenzado a trabajar en algunas características futuras, pero estas son después de que algunas solicitudes de cambios menores entren en conflicto con el trabajo inicial y tomará un tiempo considerable para integrarse nuevamente en la próxima versión.

La relación con el cliente es difícil decir lo mejor. ¿Cómo comunicaría las dificultades al cliente? Solicitar financiación no es una opción.

Respuestas (2)

Difiero de la opinión de @CodeGnome. Los procesos y planes no pueden ser unilaterales: deben ser acordados por todas las partes del proyecto o cualquier sistema. En su caso, el cliente claramente no está de acuerdo con usted, por razones que no ha escrito o que quizás desconoce. Su alta gerencia tampoco está dispuesta a trabajar con usted para resolver su problema. ¿Porqué es eso?

No puede tener un "plan para lanzar cada 3 semanas" cuando el cliente está retrasando la UAT por 4. Parecería que el cliente no está participando en la priorización del trabajo para la próxima versión, ni en la conciliación de las solicitudes de cambio con el alcance original del proyecto ( aunque su oración "pero estos son después de algunas solicitudes de cambios menores en conflicto con el trabajo inicial" no es muy clara).

En mi opinión, tiene que encontrar a alguien que tenga el respeto y/o la autoridad para llevar a cabo esta discusión o encargarse usted mismo (muy bien podría ser usted, ya que está dirigiendo el equipo) para tener una discusión abierta y sincera sobre el desafíos que usted y su equipo enfrentan y, por lo tanto, también lo son el cliente y también la gerencia. ¡Después de todo, hay un costo financiero de demora en el que incurre el cliente! Por todos los medios, también esté preparado para ofrecer soluciones, como hacer que su equipo participe para escribir casos de UAT (¡debe haber una razón por la que están retrasando UAT!) o cualquier otra cosa que ayude a resolver las cosas.

Todos deben llegar a la(s) causa(s) fundamental(es) de la situación, elaborar un proceso con el que todos estén de acuerdo y los objetivos, tanto funcionales como financieros, del proyecto. Solo entonces podrás ver el éxito en el futuro.

En mis (demasiados) años de experiencia, he pasado por muchas de esas experiencias (clientes difíciles, gerencia renuente), y lo que finalmente funcionó es que hombres y mujeres cuerdos se reúnan, obtengan una perspectiva y resuelvan las cosas. Desafortunadamente, casi siempre toma demasiado tiempo, y las personas que más sufren son el equipo que trabaja en el proyecto.

Espero que esto ayude, y que pueda tener esa conversación con el cliente. Una vez que tenga un acuerdo sobre el proceso, por todos los medios, 'detenga la línea' la próxima vez que se desarrolle esta situación.

Gracias Mahesh, estoy teniendo estas conversaciones. Realizamos pequeños cambios que no generan conflictos que agregamos a las características y proporcionamos nuestros casos de UAT, en parte para confirmar los requisitos reales cuando se sienten ambiguos y en parte para ayudar al cliente.

Usa Jidoka como Control de Procesos

En Kanban, que depende en gran medida de la cooperación de todas las partes para cumplir con las colas definidas y los límites de trabajo en curso, lo correcto cuando hay un error en el flujo es "detener la línea".

Esto hace un par de cosas útiles:

  1. Garantiza que los errores no se propaguen aguas abajo.
  2. Garantiza que los errores de producción/proceso se hagan visibles en toda la organización.
  3. Evita que se infrinjan los límites de trabajo en curso (WIP), ya que el trabajo incompleto en la cola de UAT debe contarse contra el límite de WIP global acordado.
  4. Evita errores en cascada causados ​​por trabajar en iteraciones futuras cuando la iteración actual está incompleta.
  5. Hace explícito el costo del error del proceso, ya que la línea no puede continuar hasta que se resuelva el problema del proceso o se rediseñe el proceso.

Esto no es un problema de comunicaciones; es un problema de proceso. Debe tratarlo como tal y aplicar los controles de proceso apropiados tanto para irradiar la información como para corregir la desviación del plan. En este caso, "detener la línea" es el control de proceso correcto.

Soy consciente de que esto es lo que debemos hacer. Pero también significa que tengo un equipo de 3 desarrolladores sin trabajo planificado para ellos. El cliente nos paga por función, no por tiempo y materiales (que pretendo cambiar paulatinamente). Entonces detener la línea no es una opción viable.