Xiao Zou se hizo cargo recientemente de un proyecto de desarrollo. Los usuarios del proyecto solo elevaron las expectativas y lograron los resultados, sin ninguna otra información auxiliar, y solicitaron completarlo dentro de 2 meses.
De acuerdo con los requisitos presentados por los usuarios, combinados con la situación real, los documentos de requisitos se resolvieron y acordaron. Se envió una versión después de medio mes y se probó continuamente durante varios días en un entorno formal. Durante el proceso de prueba, los principales líderes del usuario siguieron presentando nuevas ideas y nuevas características. Para cooperar prácticamente con los usuarios, Xiao Zou también prepararon contramedidas.
Debido a que los líderes superiores prestan atención al conjunto y no se preocupan por los detalles del desarrollo, a menudo exigen progreso. En el proceso de desarrollo y prueba, Xiao Zou también encontró constantemente errores relacionados y no consideró los detalles al comienzo del desarrollo y el diseño. El impulso constante del liderazgo, para perseguir el progreso, el acoplamiento de la lógica de desarrollo y la lógica empresarial no siguió los requisitos de ingeniería de software en el seguimiento, lo que resultó en problemas de calidad del producto. Los cambios y reparaciones posteriores continúan.
Para este proyecto, ¿cómo responde usted como gerente de proyecto?
Para el personal de TI, especialmente aquellos que gestionan proyectos, es inevitable hacer una pregunta: ¿por qué los clientes siempre cambian sus necesidades repetidamente? En el curso de su propia carrera de gestión de proyectos de software, se enfrentó a los cambios de las necesidades de los usuarios casi todos los días. Sintió que si no podía manejar eficazmente estos cambios, el plan del proyecto se ajustaría una y otra vez, y la fecha de entrega del software se retrasaría una y otra vez. La paciencia del usuario desapareció gradualmente. La moral del personal se está volviendo cada vez más baja, y finalmente todos esperan un resultado: lo mejor es que el proyecto termine de inmediato.
El cambio de requisitos debe gestionarse activamente, específicamente:
1. En el contrato del proyecto, configure una Junta de Control de Cambios (CCB) y estipule un estricto proceso de control de cambios. En términos generales, en la etapa de contrato, los clientes están felices de aceptar este método de gestión estandarizado.
2. Después de obtener la iniciativa en la etapa de contrato, la implementación estricta en la etapa de implementación también es crítica. La relación con los clientes no puede verse influenciada por la implementación estricta del proceso de cambio, este aspecto depende del arte de gestión y comunicación de los gerentes de proyecto y gerentes técnicos. Nuestro objetivo no es permitir que los usuarios no propongan cambios, sino dificultar que los usuarios propongan cambios a voluntad.
3. Para los cambios propuestos por el usuario, puede lidiar con la situación real, considerar al cliente desde el punto de vista del cliente, y algunas necesidades pueden guiarlo para que se dé cuenta en el proyecto posterior, lo que también puede brindar buenas oportunidades de proyecto para la empresa.
En el aprendizaje y la práctica continuos, he resumido dos métodos más efectivos, que pueden resolver este problema en la etapa de desarrollo de software.
1. Etapa de análisis de demanda para definir las necesidades del usuario a través del prototipo
En la etapa de análisis de la demanda de los proyectos de software, existe una gran cantidad de información de la demanda que debe recopilarse, analizarse y procesarse. Este es el comienzo de la gestión de la demanda. La comprensión de las necesidades de los clientes y del personal de I + D se caracteriza por "en general hay más consenso y hay más diferencias en los detalles". Incluso a través de la comunicación repetida, una "especificación de requisitos del usuario" puede producirse dentro del límite de tiempo, pero con experiencia práctica, la descripción de los requisitos del usuario siempre es "no lo suficientemente clara" y "no lo suficientemente clara". Esto se debe principalmente a que en esta etapa, los denominados productos están concebidos en el cerebro de todos. En esta etapa, el desarrollo de prototipos es un mejor método auxiliar, que en realidad expresará la realidad virtual que existe en la mente de todos. Una interfaz, varios controles, la forma de la apariencia es fija y la descripción de la función es clara: el departamento de I + D comprende las necesidades del usuario. En este momento, comuníquese con el usuario nuevamente, el usuario básicamente puede decir: "Esto es lo que quiero" o "No, esto no es lo que quiero, lo que quiero es ...". En circunstancias normales, la comunicación de requisitos después del prototipo es mucho más práctica: la comprensión de las dos partes se acercó rápidamente a una solución de compromiso y nació formalmente una especificación de requisitos que puede guiar el proceso de desarrollo.
2. Adoptar un estricto proceso de gestión de cambio de demanda
Una vez que finaliza la fase de análisis de requisitos, si los usuarios solicitan que se agreguen nuevos requisitos al sistema de software entregado, deben pasar por el proceso de gestión de cambios de requisitos. Este proceso debe ser acordado con el usuario al comienzo del establecimiento del proyecto de software. La compañía de software general tiene un proceso de gestión para cambiar las necesidades. Puede explicar la necesidad de esta gestión al usuario hasta que se llegue a un consenso con el usuario sobre este tema. No hay necesidad de preocuparse de que los usuarios no lo acepten. Ha habido muchas solicitudes para el desarrollo exitoso de la experiencia de proyectos de software. El proceso de gestión del cambio de demanda tiene una racionalidad incuestionable. Esta es exactamente la experiencia y el valor de las compañías de software. Los usuarios eventualmente entenderán y estarán de acuerdo.
Me gustaría recordarles a todos que nunca deben tomarse una foto de sus senos. Antes de eso, pueden preguntarse: "Si toman una foto de sus senos, no puedo terminarla a tiempo. ¿Puedo asumir todas las responsabilidades?" Hay una mejor manera de reducir tales problemas, es decir, después de la etapa de análisis de requisitos, no tener contacto íntimo con los usuarios, sino informar regularmente el progreso del desarrollo de software de acuerdo con el ciclo del proyecto de software o el acuerdo inicial entre las dos partes. Si se utiliza el desarrollo iterativo para la investigación y el desarrollo del software, esto puede hacerse cuando cada fase del producto se entrega para su lanzamiento, y los requisitos del usuario que se consultan se incorporarán a la versión del software en una fase futura.
¡Los estudiantes que necesitan materiales de preparación de PMP pueden dejar un mensaje!
