Los requisitos claros y coordinados están estrechamente relacionados con el cierre exitoso del proyecto. Los equipos pequeños pueden experimentar varios obstáculos para desarrollar y administrar los requisitos durante la fase de inicio de un proyecto. A los efectos de esta pregunta, suponga que el equipo del proyecto está "vendiendo" el trabajo a las partes interesadas (porque si el equipo del proyecto está empleado por las partes interesadas o tiene una relación a largo plazo con ellas, la vida es más fácil y estamos tratando de examinar técnicas para superar los obstáculos, no técnicas para eludir los obstáculos.
Así que imagina que eres el PM de un pequeño equipo que intenta convencer a un nuevo cliente de que puedes completar el proyecto. Usted y el cliente acordaron los requisitos funcionales, pero sabe que otros equipos de proyecto pueden cumplir con esos requisitos funcionales. ¿Cómo obtiene los requisitos blandos y convence al cliente de que puede (sobre) cumplir con esos requisitos? (Todos obtienen "marketing" como primera respuesta; es demasiado fácil).
Esta pregunta está inspirada en un comentario hecho por @mark Phillips aquí
La respuesta corta para mí es tener siempre historias de usuario. Llego a esto con experiencia en desarrollo de software, muchos gerentes de producto no tienen experiencia en desarrollo y no pueden pensar en unidades de trabajo de desarrollo. Sin embargo, pueden trabajar con nosotros para definir quiénes son los usuarios finales y qué harán con el producto final. Una vez que podamos elaborar una lista de posibles usuarios, podemos desarrollar los tipos de interacciones que estos "usuarios" tendrán con el producto. Cada "usuario" tiene un papel que desempeñar y, por lo tanto, tiene un conjunto diferente de características/funcionalidades que requiere. Entonces, la parte difícil es encontrar la superposición entre estos "usuarios" y crear requisitos estrictos a partir de eso. Sin embargo, habrá muchos requisitos suaves que no encajan en unidades de trabajo definibles y que pueden usarse como pautas en cuanto a la sensación del producto.
La ventaja clave de esto para mí ha sido obtener escenarios comprobables. Cuanto más podamos describir en términos humanos ("suaves") la naturaleza de la interacción de los usuarios con el producto, más fácil será generar una buena lista de casos de prueba positivos y negativos.
Tener una comprensión de la interacción humana y una buena historia de cómo se probará el producto a lo largo del camino siempre ha sido clave para obtener la aceptación de fuera del departamento de desarrollo/ingeniería.
No existe una fórmula para obtener y convencer a un cliente de que puede cumplir con sus requisitos suaves. Se trata de relaciones y personalidades. Algunas personas "hacen clic" entre sí, otras no.
Puede ser frustrante, especialmente para un equipo pequeño y hambriento, pensar que hay algunos trabajos que no obtendrán por su lado blando. Pero la alternativa es gastar tiempo y dinero haciendo trabajo gratis, tratando de "ayudar" al cliente a descubrir elementos que son intangibles. Puede parecer que el cliente está obteniendo un buen trato ya que usted les está brindando consultoría estratégica sin costo alguno. Pero si el cliente no lo ha pedido, es probable que no vea el valor y, por lo tanto, no vea/entienda el valor de lo que está haciendo.
Hay gente que aprecia el lado tierno que traes a la mesa. Hay personas que te "entienden" a ti y a tu equipo y con las que el equipo hará click. Dedique su tiempo a encontrar a esos clientes, en lugar de tratar de convencer a los que no hacen clic de su valor.
MCW