Más que habilidades de comunicación, técnicas lean para descartar características inútiles sin valor, más que preguntar "¿qué quieres?" o "¿hay algo más?" al cliente.
Al leer el libro Agile Project Management de James A. Crowder, dice: "Las organizaciones deben esforzarse por proporcionar un entorno en el que el presupuesto no se centre en el tiempo y el movimiento, sino que debe centrarse en los valores percibidos de los objetivos del proyecto... . En el EV clásico el cambio es malo y la incertidumbre es peor" .
Del libro Brilliant Agile Project Management de Rob Colle y Edward Scotcher: "Agile acepta el cambio e incluso lo alienta. El cambio no se ve como el enemigo, se ve como una parte importante de la evolución de cualquier buena idea".
En un enfoque ágil, todo es especulativo y el alcance nunca se cierra hasta que el cliente está satisfecho.
Me parece que estas declaraciones son para proyectos internos en empresas de software como Facebook, Uber, Airbnb, o incluso en proyectos internos donde hay una iniciativa para mejorar los procesos continuamente.
En un contexto en el que manejas proyectos con clientes externos y proyectos con desarrollo ad-hoc, estamos limitados por la triple restricción todo el tiempo. ¿Cuáles son las técnicas que usa para configurar el alcance y minimizar el número de iteraciones si estamos en un contrato con restricción de tiempo?
Editar
*Restricción triple es el nombre que usa PMI para describir las restricciones en cualquier proyecto en Tiempo + Costo + Alcance (+ Calidad en la 6ta versión del PMBOK) Cualquier cambio en cualquiera de estas restricciones afectará al otro. Un cambio en el tiempo afectará su costo, cualquier cambio en el alcance afectará el tiempo y el costo, etc.
Esto es tan restrictivo, fijo y antiguo en términos de agilidad. Una vez que tenga su línea de base, no puede cambiarla, sino a través de un proceso de cambio formal. Con proyectos externos basados en la perspectiva clásica, gestiona contratos para entregar un producto o servicio en un tiempo específico y dentro de un presupuesto .
Por eso en el enfoque clásico el cambio es malo. Si cambia su línea de base (tiempo, costo o alcance), lo llevará a un nuevo trabajo o reprogramación. Sin embargo, en Agile, el cambio se acepta todo el tiempo. Tipo de 2 filosofías en conflicto entre sí en la gestión del cambio, pero necesitamos limitar los cambios de manera que cumplan con los plazos.
Si entiendo su pregunta correctamente, ¿está preguntando cuál es la mejor manera de abordar el desarrollo ágil en una situación en la que hay un límite máximo de tiempo?
La respuesta obvia es restringir el alcance. Y una buena técnica para hacerlo es desarrollar primero hacia un producto mínimo viable (MVP) .
Comienza obteniendo del cliente una lista de los requisitos absolutamente imprescindibles . Los requisitos son tales que, si el producto está completo al 100 % , excepto ese único requisito, y no hay forma de agregarlo, entonces la única opción es desechar el producto. La recopilación de esos requisitos es su MVP.
Luego, estima cuánto tiempo cree que llevará desarrollar ese MVP: ahora tiene su programa mínimo. En ese momento, agrega relleno al cronograma. El relleno tiene dos propósitos. Primero, una red de seguridad por si te subestimaste. En segundo lugar, espacio para iterar mejoras: cuanto más relleno tenga, más requisitos 'debería tener' y 'podría tener' puede cumplir.
Sin embargo, es importante que una vez que haya completado el MVP, muéstreselo al cliente . Los requisitos prácticamente siempre cambian una vez que los clientes tienen un producto funcional frente a ellos. En este punto, puede renegociar cualquiera de los 'requisitos de relleno' que agregó anteriormente, a cambio de agregar nuevos requisitos. Quite algunos de los antiguos o aumente el tiempo/costo del proyecto.
El objetivo es la colaboración. Según el manifiesto , ' Colaboración del cliente sobre negociación de contratos'.
En nuestra empresa nos enfrentamos a esta situación cada vez que tomamos un contrato de Precio Fijo. Por favor, consulte nuestra descripción de enfoque aquí .
erik
Máximo Décimo
Todd A. Jacobs