¿Cuál es el mejor método para mantener los proyectos de software en marcha cuando los requisitos no están bien definidos? (es decir, solo se proporcionan conceptos funcionales generales).
Si los requisitos están vagamente definidos, entonces debería haber una entrega regular y frecuente de software funcional al cliente. Wireframes y prototipos pueden ayudar, pero no tanto en comparación con el sistema funcional. Por software de trabajo no me refiero a que construya todo, sino que inicialmente se centre en aquellas piezas que proporcionarán más valor al cliente. Deja que el cliente juegue con lo que has construido para él. Esto también aclarará los requisitos para el propio cliente y sabrá más sobre lo que necesita en lugar de lo que quiere.
En primer lugar, debe asegurarse de controlar el proyecto. Un proyecto vagamente definido se entrega vagamente, así que cambie el estado inicial lo antes posible por:
Para mantener las cosas en orden a medida que avanza, acostúmbrese a decir "estamos buscando llamar a esta característica/componente terminado en esta versión (antes del próximo informe de estado) y estamos buscando comentarios/respuestas finales". Realmente ayuda adoptar un cronograma de lanzamiento periódico donde el producto es "potencialmente liberable" al final de cada período de lanzamiento (por ejemplo, Scrum)
Mantenga el proyecto dividido en "cosas que sabemos y podemos comprometernos a desarrollar en una fecha determinada" y "cosas que no sabemos lo suficientemente bien como para abarcar otras que no sean la cantidad de lanzamientos que debemos presupuestar para completarlo". tenga un proyecto que pueda controlar/supervisar e informar. Mantenga suficiente trabajo en la parte bien definida del proyecto para mantener al equipo protegido mientras usted y tal vez un líder técnico trabajan para dar definición a la otra parte.
Primero averiguaría qué significa "en camino". ¿Hay una función mínima que debe entregarse en una fecha determinada? ¿Un resultado comercial que debe lograrse? Si es así, esto debería ayudar a proporcionar un enfoque y una visión para el proyecto. Si hay algo pequeño que se puede entregar temprano, esta es una excelente manera de demostrar la capacidad del equipo para entregar, ganar la confianza de las partes interesadas y ganar tiempo para más adelante.
Una vez establecida la visión, averigüe qué aspectos son menos conocidos. ¿Hay partes de la interfaz de usuario que nadie puede imaginar correctamente? ¿Arquitectura que nunca ha sido probada? Codifique el resto y obtenga comentarios sobre estos aspectos riesgosos lo más rápido posible. Las sugerencias de Aziz de exhibición regular son la mejor manera que he encontrado para hacer esto. Recuerde que las diferentes áreas del proyecto tendrán diferentes partes interesadas, por lo que, por ejemplo, muestre cualquier aprendizaje arquitectónico a los arquitectos; interfaces de usuario para los usuarios; funcionalidad empresarial a los departamentos que se preocupan por ella.
En lugar de centrarme en el valor, tiendo a preferir centrarme en el riesgo (recordando que las áreas de conocimiento deficiente o limitado tienden a conllevar un montón de riesgos que ni siquiera conoces todavía), y luego entrego la cosa valiosa más pequeña que hará una diferencia. Esto se puede hacer repetidamente y de forma incremental hasta que se logre una visión más amplia.
En términos de metodología, Rapid Development de Steve McConnell proporciona una tabla que muestra qué metodologías son apropiadas para proyectos dadas ciertas características a nivel de proyecto. Para proyectos con "requisitos poco entendidos", la espiral, la creación de prototipos evolutivos y el uso de software COTS se clasifican como los mejores. Las cascadas modificadas y la entrega evolutiva también parecen ser adecuadas, pero no tanto. Si observa, estas son metodologías que brindan una gran visibilidad tanto para el cliente como para la gerencia sobre el trabajo realizado por el equipo de desarrollo, permiten "correcciones de rumbo" en medio del proyecto y están diseñadas para ayudar en la gestión de riesgos. .
Sin embargo, hay una serie de criterios que utiliza McConnell para elegir una metodología. Esto incluye una comprensión de los requisitos y la arquitectura, la confiabilidad deseada, la gestión de riesgos, el uso de un cronograma predefinido, la cantidad de gastos generales, la visibilidad del cliente, etc.
Si tiene disponible una copia de Rapid Development, la tabla a la que hago referencia está en las páginas 156-157. Probablemente le interese la mayor parte (si no todo) del Capítulo 7, que trata sobre la planificación del ciclo de vida. El capítulo 6, que analiza la opinión de McConnell sobre el desarrollo rápido, también podría ser de interés.
Si va a administrar proyectos de software, le recomiendo no solo este libro, sino también la Guía de supervivencia de proyectos de software de McConnell . Ambos libros eran (y siguen siendo) de lectura obligatoria en el curso de gestión de proyectos y procesos de software que tomé, y tienen una alta calificación en lo que respecta a los libros de procesos de SE. También se centran en las "mejores prácticas" que se aplican a un buen número de proyectos.
Un proyecto con requisitos vagamente definidos es una receta para los problemas.
Su trabajo como PM debe ser ajustar los requisitos.
El próximo hito o 2 (o 3) debe ser concreto; los futuros se pueden definir de manera más flexible, hasta que avancen en la tubería, luego se deben definir claramente.
No es posible crear algo que esté vagamente definido . Defínelo y síguelo.
Sigo creyendo que no es realista tener un buen seguimiento en un proyecto vagamente definido.
Aunque creo que las otras respuestas brindan la mejor manera de solucionar el problema, de todos modos dejaría en claro a las partes interesadas que no podemos tener plazos claros sin hitos claros del proyecto. Les haría compartir la culpa de cualquier retraso que (eventualmente) suceda.
vadim feldman
Miguel