¿Cómo trato con un cliente potencialmente difícil en un proyecto web?

Soy gerente de proyectos con tres años de experiencia trabajando como PM.

Tenemos un cliente aquí que tiene una relación bastante buena con nuestra empresa. Nos envió un proyecto web de una de sus referencias que incluye solo 4 o 5 líneas de especificación de alto nivel. Pero no ha enviado ningún tipo de requisitos detallados para que pueda estudiar sus necesidades comerciales y generar un cuestionario en consecuencia.

Altos funcionarios me dijeron que siguiera adelante con la creación de una página de inicio, ya que él es un cliente valioso. No tengo un contacto directo ni nada, estoy atascado y sintiendo la presión de la autoridad superior.

¿Alguna solución o respuesta a esta situación?

¿Esperaba el cliente que hiciera un seguimiento de sus requisitos de alto nivel con un análisis de requisitos más detallado? ¿O esperaban que construyera el sitio a partir de 4 o 5 líneas de especificación de requisitos de alto nivel?
Anoté esta preocupación y la pasé a la autoridad superior. De High Level Specs quiero decir que el alcance del proyecto suena grande pero no tengo detalles al respecto. Obviamente, una página de inicio es una página principal, tengo miedo de que el alcance se desplace y también se lo dije a mi alta dirección.
Creo que me has entendido mal. El cliente le dio requisitos de alto nivel pero ningún detalle. ¿Esperaba el cliente que hiciera un análisis detallado de los requisitos, o esperaba que procediera con la creación del producto de inmediato, en función de las especificaciones de alto nivel que ya proporcionaron?
Su pregunta es correcta, los clientes a veces esperan continuar con la creación del producto de inmediato, pero a veces también sucede que las personas por encima de usted (administración de alto nivel) necesitan un gerente de proyecto para comenzar de inmediato y nos quedamos atascados.

Respuestas (4)

Con respecto a la respuesta de @mamoo:

Por supuesto, lo mejor es aclarar los requisitos. Debido al hecho de que no tiene acceso al cliente, la parte interesada interna debe ser su primera opción.

Desafortunadamente, puede ser difícil encontrar un horario para que alguna parte interesada (por ejemplo, la gerencia) participe en un taller o en otro trabajo técnico.

Intente que la parte interesada pertinente (por ejemplo, el patrocinador del proyecto) tome una decisión sobre cómo continuar con el proyecto. Esto podría lograrse en una reunión corta y tal vez informal:

  • Indique su problema . Plantéelo como un riesgo: La página Web podría no satisfacer al cliente debido a...
  • Proporcione una probabilidad para el riesgo.
  • Proporcione un impacto de riesgo cualitativo y uno o dos ejemplos, por ejemplo, "El cliente podría pensar que no somos capaces de construir una página web sofisticada".
  • Dar una solución , resp. Mitigación del riesgo: podría entablar una conversación directa con el cliente, por lo tanto, necesita los detalles de contacto.

Teniendo esto, la parte interesada relevante puede tomar una decisión, por ejemplo

  • Involucrar al cliente directamente para identificar los requisitos.
  • Acepte el riesgo e intente calcular nuestros requisitos "de alguna manera".

Si realmente está atascado, trasladaría la responsabilidad a sus gerentes: valide la página de inicio con ellos, anote cualquier requisito que sea necesario y haga que lo apruebe uno de sus superiores. Si realmente es así de simple, no tendrán ningún problema en compartir la responsabilidad de validarlo contigo ;)

Tiene información contradictoria en su enunciado del problema. Primero indica que el cliente ofreció requisitos de muy alto nivel con el entendimiento de que su empresa conocería su negocio y solicitaría requisitos adicionales. Luego indicas que tus jefes te piden que te saltes ese trabajo y procedas a desarrollar el producto. Parece que su cliente quiere desglosar los requisitos en colaboración, pero sus jefes no. Entonces tus jefes son difíciles, no tu cliente, ¿verdad?

Si el cliente paga el esfuerzo de construir este producto sin solicitar otros requisitos, producir el producto sin trabajar con el cliente para descomponer las especificaciones sería un gran error, un gran riesgo para su empresa. Como han dicho otros, aumenta ese riesgo. No significa que tengan que escuchar o que vayan a escuchar, pero debes dejarlo registrado. Entonces, haz lo que dicen.

Si el esfuerzo no es pagado por el cliente y la empresa solo quiere armar algo para iniciar conversaciones y tal vez mostrar las capacidades de su empresa, entonces proceda. Tal vez entrevistar a algunos de sus colegas que pueden conocer información más detallada sobre su cliente lo ayudará a desglosar esas especificaciones usted mismo con cierto grado de precisión. Después de todo, usted indica que el cliente es bien conocido por su empresa. Dado que el cliente no pagó por él, se convierte en un punto de partida para las futuras sesiones de requisitos.

No entendí su punto "... con el entendimiento de que su empresa aprendería su negocio..." ya que no vi evidencia de esto. Sin embargo, me acabo de dar cuenta de que está traduciendo internamente "... requisitos detallados para que pueda estudiar ..." como "requisitos detallados para que pueda estudiar". Yo no lo leí así. Creo que esto necesita una aclaración por parte del OP. Específicamente, ¿era la intención del cliente que su especificación de alto nivel fuera seguida por un análisis de requisitos más detallado del OP?"
Ah, sí, veo tu punto. Hice una interpretación. OP debería comentar sobre eso.

Cree una estructura alámbrica/prototipo interactivo con el mínimo esfuerzo

  1. Como señaló @mamoo, intente validar los requisitos con el patrocinador interno del proyecto.

  2. Como @david-espina y otros señalaron, haga que sus superiores sean conscientes del riesgo que implica construir algo sin tener mucha idea de lo que quiere el cliente.

  3. Hay herramientas disponibles (p. ej., Axure o Evolus Pencil, de código abierto ) que pueden crear una estructura alámbrica/prototipo interactivo rápido sin ningún tipo de codificación. Puede comprimirlo y enviarlo por correo electrónico al patrocinador de su proyecto. Esto es muy visual y el patrocinador de su proyecto puede mirarlo y hacer clic para ver navegaciones, ventanas emergentes... También pueden reenviarlo al cliente para que haga lo mismo. A diferencia de una larga revisión de documentos de requisitos, esta es una forma sencilla de obtener comentarios de la alta gerencia y los clientes.

De esta manera, puede obtener una validación rápida de su enfoque en lugar de invertir muchos recursos y tiempo para crear algo que su cliente no quiera.

Ashok, creo que no entendiste mi punto. Conozco bien estas herramientas, sin embargo, si las partes interesadas le pasaron un proyecto relacionado con la gestión de "aerolíneas", digamos. ¿No suena grande ese alcance? pero el punto es cómo va a funcionar como si no tuviera esa especificación llamada "documento de requisitos específicos del usuario" para que pueda convertirlo en jerga técnica
ESTÁ BIEN. Si alguna de las otras respuestas te ayudó, puedes marcarla como respuesta aceptada. Si ninguno de ellos ayudó y encontró una manera de lidiar con eso, puede responder su propia pregunta. Esto ayudará a otros que enfrentan una situación similar.
¿Cómo trato con un cliente potencialmente difícil en un proyecto web?
RespuestasAquíPolítica de privacidad1y, 0v