Somos una empresa que fabrica moldes y otras herramientas que nuestros clientes luego utilizan en sus máquinas. Me dieron un conjunto de requisitos para crear una aplicación web, que alguien cree que nuestros clientes querrían usar.
Haciendo ingeniería de requisitos / trabajo de BA / análisis de partes interesadas, quería dar un paso atrás y primero identificar el problema comercial que la aplicación propuesta debería resolver. La cosa es: nadie me puede decir. No se realizó ninguna encuesta a los clientes, las ventas desconocen los problemas que la aplicación web propuesta podría resolver, el departamento de marketing tampoco identificó una necesidad, el PM solo esboza los requisitos funcionales en lugar de identificar el problema subyacente (si lo hay).
He llegado a la conclusión de que crear una aplicación web para nuestros clientes no es más que una idea de una o más partes interesadas (probablemente de alto nivel).
Creo que los altos directivos estarían disponibles para una reunión en la que potencialmente podría preguntar sobre el problema, pero:
¿No molestaría eso potencialmente a quienes inicialmente propusieron el desarrollo de tal aplicación?
Entonces, si entiendo bien, su empresa cree que debe crear una aplicación para su cliente. ¿El cliente no lo ha solicitado y usted no tiene ninguna validación de que el problema que se está resolviendo existe?
La forma en que proceda realmente dependerá de dónde encaje en la organización general. Asumiré que es un administrador de programas/proyectos (dado el tema de este StackExchange).
También asumo que no hay una estructura a nivel de cartera en su empresa. Esta sería la mejor manera de lidiar con esto. Sin embargo, eso no va a resolver este problema.
Si los requisitos provienen de un gerente de producto que es su par o más o menos equivalente a usted: continúe con la planificación, para que pueda calcular el nivel de recursos que se necesitarían. Luego, use la misma guía que se muestra a continuación, si los requisitos provienen de alguien mayor.
Si los requisitos provienen de alguien en un puesto superior (dos o más niveles por encima de usted): debe practicar la Escuela de Gestión de Proyectos de Pothole. En pocas palabras, debe encontrar a alguien con autoridad e interés para informar. Por ejemplo, si a un vicepresidente de ingeniería se le ocurrieron los requisitos, trate de informarle al vicepresidente de ventas. El vendedor no quiere desperdiciar recursos en algo que el cliente no quiere y tampoco quiere molestar al cliente perdiendo el enfoque o entregando algo que no quiere.
La razón de esto es que, como gerente de proyecto (gerente de programa, maestro de scrum, etc.), no tiene autoridad directa. Necesitas trabajar con influencia. Si tratas de abordarlo directamente, es muy probable que seas el atropellado por el autobús. Rara vez se considera que la función de gestión de proyectos tiene "experiencia", por lo que cuando surge un problema, ya están en desventaja.
Y como dijo Tobias, no involucres al cliente. Incluso si tiene relaciones directas, estaría discutiendo información interna de la empresa y eso afectará su credibilidad con el cliente y su empresa.
Mucha suerte, me encantaría saber cómo va.
Llamar a la alta gerencia suena como ignorar a alguien en la jerarquía. Si el PM puede presentar requisitos funcionales, tiene en mente al menos algunos problemas comerciales u oportunidades de mercado, incluso si el PM no puede formularlos, por ejemplo.
Haga lo siguiente para identificar la necesidad del negocio:
La cosa es: nadie me puede decir.
Se llama innovación. Cambia tu ángulo de ataque. Parece impulsado a identificar casos de uso, etc., sin embargo, con bastante frecuencia, todo esto llega en el flujo del proyecto. Este es también el territorio de TDD, desarrollo basado en pruebas .
Lo que debes hacer es esto. Debe mantener informadas a todas las partes interesadas y tratar de reunirlas en una mesa redonda de vez en cuando si es posible. Mantenga un cronograma de salud y documentación de su trabajo, pero no lo sobrecargue. Entiende cómo ve tu patrocinador tu papel y tu actuación. Necesita comprender los riesgos y los impactos de requisitos poco claros y falsos, etc. Buena suerte.
Editar: Muy recomendable leer los materiales de Karl Wiegers .
Crear una plantilla o encontrar un ejemplo de requisitos bien escritos para compartir con los miembros del equipo ayuda a establecer una calidad y coherencia mínimas en todos los ámbitos. Además, la creación de un glosario puede brindar la capacidad de rechazar historias mal escritas basadas en un vocabulario compartido. Si todo lo demás falla, la creación de prototipos en papel de una implementación basada en los requisitos puede demostrar las brechas y motivar al equipo a ayudar.
Referencias
Ene