¿Cuáles son las técnicas para obtener requisitos de los clientes que no entienden sus necesidades?

Pregunta:

¿Cómo previene una situación en la que primero tiene que producir trabajo-producto y obtener retroalimentación del cliente antes de tomar el camino correcto para satisfacer sus necesidades?

¿Existen técnicas para ayudar al cliente y a nosotros a tener una idea más clara de lo que espera?

Antecedentes sobre lo que solemos tratar:

A menudo desarrollamos (personalizamos) CMS para clientes. Primero y antes de cualquier estructura de información está el "look and feel" del sitio web, toda la "identidad", incluso podríamos decir branding.

Más allá del hecho de que estamos enmarcando la página de inicio con herramientas como Balsamiqy hacemos muchas preguntas como:

  1. Si su sitio web fuera una persona, ¿cómo se vería, comportaría, tendría actitud...?
  2. ¿Qué colores asociaría con su empresa/producto/servicios?
  3. ¿Cómo es tu competencia, cómo se ve su sitio web, qué sientes por ellos?
  4. ¿Cuál es la declaración de misión, visión...?
  5. ¿Cómo se ve su modelo de negocio, quién es su grupo objetivo, qué busca, etc.?

Todo esto más adelante en el caso de nuestros clientes la mayoría de las veces está fuera de "su verdadera visión del diseño de producto/empresa/servicio".

Lo que es más, uno de nuestros clientes cuando comenzamos a hacer preguntas respondió: "Necesito un artista que encuentre los colores adecuados y prepare el diseño. Si es un verdadero artista, cuando entienda la misión que le brindamos, el diseño se manifestará desde adentro". de él..."

Así que también organizamos una reunión con el cliente y el gráfico que eliminaría cualquier "factor de cadena", sin embargo, el cliente usa el mundo como: único, prestigioso, que salva vidas, y también brindamos materiales de marketing que brindan una visión totalmente diferente que el gráfico entendió.

El gráfico preparó un bonito diseño moderno, que mostraba la alegría de vivir, el producto y la empresa como un lugar feliz... Al contrario de la visión del cliente (que afirmó después de ver el proyecto), esta institución tiene una máquina que trata a las personas y rescata la vida, como debería ser : gris, triste, con actitud de funeral/iglesia...

Sé que podemos adaptarnos "después" de que él nos proporcione retroalimentación, sin embargo, esto es una tremenda pérdida de tiempo, dinero y muy a menudo indica frustración.

Hola, Daniel, este tipo de pregunta podría ser más adecuada para nuestro sitio de preguntas y respuestas de Graphics Design SE , ya que no parece ser sobre el campo de la gestión de proyectos. Sin embargo, sugeriría centrarse más en encontrar respuestas en lugar de pedir libros, cursos, etc. El objetivo de nuestra red es que nuestros expertos respondan a su pregunta, en formato de preguntas y respuestas, no que lo lleven a otro lado. ;)
Eso es cierto y no es cierto al mismo tiempo. Estaba pensando en Graphic Design SE, sin embargo, solo vi cosas técnicas. Teniendo en cuenta el formato de preguntas y respuestas también "sí y no", porque la gestión de proyectos no se trata solo de preguntas específicas que responden a "2 semanas", sino también de "aspectos suaves" y "estrategia, filosofía, metodología" completas. Y para esos es mejor apuntar algunos recursos, o tema gurú. Para este tipo de preguntas complejas no existen respuestas simples y esto indica tiempo para investigar y analizar este concepto.
Coincido con @jmort253; las <a href= pm.stackexchange.com/faq > Preguntas frecuentes </a> solicitan específicamente que evitemos las solicitudes de fuentes recomendadas. En mi opinión, la parte de su pregunta que es más apropiada para este sitio es: "¿Cuáles son las técnicas para obtener requisitos de los clientes que no entienden sus necesidades?"
@ MarkC.Wallace, este es un buen punto, y actualizaré y formularé la pregunta de esta manera, sin embargo, cuando alguien publique la pregunta "¿Cuáles son las técnicas para recopilar eficientemente los requisitos de software", algunos podrían responder: familiarícese con Scrum y User Stories, y esto solo me indicará que busque recursos sobre Scrum e historias de usuarios. Entiendo que el concepto de Stack Exchange es "reunir conocimiento en el interior". Pero a veces, cuando el tema es complejo, se necesitan recursos y la pregunta no tiene una respuesta simple.
Punto justo. Creo que la verdad es que estás haciendo una pregunta difícil. Si puede encontrar una buena manera de hacer esa pregunta, creo que muchas personas se beneficiarán de la respuesta.
¡Buenas ediciones @MarkPhillips! También resaltaré la sección de preguntas para enfocar aún más la pregunta.

Respuestas (6)

La solicitud de requisitos es un proceso iterativo, que comienza en un nivel abstracto y desciende a medida que itera. Es una extracción de datos de las partes interesadas; por lo tanto, se trata de hacer un montón de preguntas, de varias maneras diferentes y volverse más táctico a medida que avanza. Dado que se trata de una extracción de datos, las técnicas no son ciencia espacial. Incluye encuestas, entrevistas, talleres y grupos focales. Lo que significa que debe comprender el universo de partes interesadas involucradas, los segmentos a los que pertenecen y las misiones y valores que a menudo están en desacuerdo entre sí.

Los requisitos entrarán en conflicto, y esta parte del proceso de iteración. Debe eliminar el conflicto de los requisitos ofensivos y amontonar y apilar lo que queda. Y luego tendrá su línea base de requisitos a partir de la cual podrá planificar el resto del trabajo. Y tendrá, no puede tener, segmentos de partes interesadas que simplemente no están contentos.

Con respecto a la parte del producto del trabajo de la pregunta, eso es parte de este proceso. A veces, debe demostrar la funcionalidad, los clientes tienen que jugar con el widget, antes de poder tomar una decisión. Es parte del grupo de enfoque y el costo de hacer negocios.

@David " A veces debe demostrar la funcionalidad, los clientes tienen que jugar con el widget, antes de poder tomar una decisión". ¿Cómo demostraría NFR? En mi caso, ¿diseño ("aspecto y sensación, marca") antes de que finalmente esté terminado? Y sí, enmarcamos con alambre todas las "pantallas", que pasaron, el diseño flotante no...
Entiendo la iteración al respecto, pero creo que no puedes llamar a un cliente para que venga 4 o 5 veces antes de darle un presupuesto. ¿Correcto? ¿O estoy viendo esto mal?

En la fase inicial de definición del alcance del proyecto, debe comprender qué quiere el cliente y qué quieren los usuarios. Sus habilidades de gestión de proyectos se pondrán a prueba al tratar de equilibrar ambos conjuntos de requisitos y entregar un producto con el que ambos estén satisfechos.

Para comprender los requisitos de su cliente, use las técnicas que han propuesto otras respuestas, incluido lo que ya está haciendo: hacer preguntas. Por experiencia, he descubierto que para proyectos más grandes es bueno comenzar el proceso con un taller (para proyectos más pequeños, una reunión cara a cara suele ser suficiente). Esta es realmente una sesión de ideas, pero deberá estructurarla para asegurarse de que puede involucrar a su cliente y mantenerlo enfocado en lo que necesita: sus requisitos. Por ejemplo, es posible que desee colocar algunos de los resultados de las pruebas de usabilidad (ver a continuación) frente a ellos y pedirles individualmente que escriban soluciones en notas autoadhesivas y las peguen en la pared. Luego puede revisarlos en grupo y acordar cuál es la mejor solución.

Haga un seguimiento del taller con entrevistas 1-1 y luego produzca un documento de requisitos en cualquier forma que atraiga a su cliente, por ejemplo, una presentación de diapositivas, una hoja de cálculo, etc.

¡Para recopilar los requisitos de los usuarios, realice algunas pruebas de usabilidad!

No hay mejor manera de entender cuáles son los requisitos de los usuarios (y estas son las personas que más importan). La información que obtendrá de la participación de los usuarios es la información más valiosa que obtendrá sobre un sitio web. También es una excelente manera de desafiar lo que su cliente quiere o cree que quiere. Las pruebas de usabilidad informadas atraviesan las opiniones personales sobre cómo deberían funcionar los sitios web. A menudo encontrará que lo que pensó que funcionaría para el usuario en realidad no funciona en absoluto, o el usuario lo ignora. También puede validar la nueva funcionalidad que ha introducido. Idealmente, las pruebas de usabilidad deberían realizarse a lo largo de un proyecto: durante la fase de alcance para reunir los requisitos; después del wireframing para probar los conceptos; después del diseño visual para probar la reacción a él.

Hay mucha información sobre el tema en libros y en la web (incluido el sitio UX Stack Exchange ). Algunas técnicas típicas de pruebas de usabilidad son:

  • pruebas cara a cara: invite a los participantes a hacer clic en el sitio web mientras usted observa, toma notas y hace preguntas (también trate de monitorear su comportamiento durante estas sesiones para saber cómo puede modificarlo para futuras sesiones)
  • pruebas de laboratorio: pueden ser las mismas que las anteriores, pero si puede encontrar las instalaciones, los participantes interactúan con el sitio web mientras su cliente observa a través de un espejo de dos vías; también puede usar herramientas de seguimiento ocular para monitorear dónde siguen los ojos de los usuarios en la pantalla
  • encuestas en línea

Puede recopilar todos estos datos para mejorar los resultados de su proyecto actual y planificar proyectos futuros.

Los datos recopilados de las sesiones de prueba pueden informar sus conversaciones con el cliente sobre lo que quiere, cuál es su estrategia, etc. Los datos de prueba de usabilidad proporcionan una base de evidencia sólida para tomar decisiones de diseño y funcionalidad al planificar su proyecto.

Si espera hasta las pruebas de usuario para validar los requisitos, es demasiado tarde.
@DavidEspina Estoy diciendo que comienza con las pruebas de usuario para recopilar requisitos y luego validarlos con más pruebas de usuario después de la estructuración. Tal vez sea solo semántica, pero no estoy definiendo las pruebas de usuario como las "pruebas de aceptación del usuario" más formales, sino como una forma de interactuar con los usuarios para comprender lo que quieren.
Edité mi respuesta para aclarar que se trata de pruebas de usabilidad y no de pruebas de aceptación del usuario.
Eso tiene más sentido. De acuerdo con mi respuesta sobre los grupos focales.
He agregado más información sobre los requisitos del cliente porque están informados por las pruebas de usabilidad.

No estoy seguro de haber respondido la pregunta del OP:

¿Cómo previene una situación en la que primero tiene que producir trabajo-producto y obtener retroalimentación del cliente antes de tomar el camino correcto para satisfacer sus necesidades?

Si entiendo el problema correctamente, el OP está trabajando con el cliente para desarrollar los requisitos iniciales para el proyecto (preiniciación). El punto de fricción parece ser algunos requisitos suaves no funcionales (NFR). (la apariencia/marca del sitio web). Es difícil hacer pruebas de usuario en NFR (no imposible, pero más difícil). Si el equipo de OP no convence al cliente de que puede cumplir con esos requisitos, entonces no habrá proyecto. Estos también son requisitos suaves no funcionales: no hay una respuesta objetiva. El cliente no sabe cómo debería verse el sitio web (si lo supiera, toda la interacción sería diferente).

Creo que OP ha dado la mejor respuesta hasta ahora; hay una lista de preguntas para obtener impresiones subjetivas de la marca y tratar de identificar temas clave que deben reflejarse en el diseño del sitio web.

Yo ofrecería dos sugerencias más:

  1. Consulte algunos libros sobre publicidad: parte de la pregunta queda fuera del dominio de la gestión de proyectos. Cosas muy interesantes, pero no PM. Algunas de las respuestas tenderán un puente sobre el arte de vender donde no estoy calificado para comentar.
  2. Prepara dos o más alternativas en base a las respuestas a las preguntas de branding y pide al cliente que seleccione los elementos que funcionan. Contextualice el experimento correctamente: está presentando material exploratorio para asegurarse de que comprende el NFR; el cumplimiento real del NFR será parte de la ejecución del proyecto después de que el proyecto esté autorizado y planificado.

Podría ser que alguna forma de análisis FODA podría adaptarse aquí para identificar los conceptos que son partes centrales (fortalezas) y partes periféricas (oportunidades) de la marca deseada. El eje interno/externo podría representar la ventaja competitiva/discriminadores de la competencia. (No estoy familiarizado con él, pero creo que el Cuadrante Mágico de Gartner sigue un modelo similar). Si el Equipo del Proyecto y el Cliente pueden usar eso como un proceso estructurado para identificar las características clave de la marca, creo que lo harán. Habré identificado un grupo de NFR.

También existe una analogía con la gestión de riesgos. La gestión de riesgos es un intento de brindar al gerente de operaciones información procesable; el administrador de riesgos lo hace al disminuir la incertidumbre sobre las incógnitas. En este ejercicio de requisitos, el equipo del proyecto intenta reducir la incertidumbre mutua sobre el NFR flexible del cliente. La clave tanto en la gestión de riesgos como en la situación del OP es que no tiene que resolver el problema durante la etapa de requisitos iniciales, solo necesita establecer un marco y confiar en que el problema está limitado y que los límites se estrecharán con el tiempo para llegar a un conjunto de requisitos finales que coincida con las verdaderas necesidades del cliente.

El OP ha hecho lo que creo que es una pregunta poderosa que tiene implicaciones para la gestión del alcance en muchos proyectos. Creo que no es nada raro que la parte interesada no exprese o no pueda expresar los NFR blandos. El cierre exitoso del proyecto significa que el PM necesita descubrir y cuantificar esos requisitos.

+1 en análisis FODA y proporcionar/comprender la razón estratégica de por qué se necesita el producto. Aunque puede que no haya presupuesto para ello en proyectos de personalización de diseño/crm más pequeños.
@MarkPhillips: ¡Cierto! ¿Cuáles son algunos caminos alternativos para que los equipos más pequeños obtengan el NFR suave?
esa sería una excelente pregunta por sí sola, especialmente si especifica las limitaciones que puede enfrentar el equipo más pequeño.
@MarkPhillips "¡Cierto! ¿Cuáles son algunos caminos alternativos para que los equipos más pequeños obtengan el NFR suave?" Es exactamente la pregunta que busco respuesta...

No quiero ahondar en temas de diseño gráfico, ya que mi sentimiento estético puede no ser compartido por otros. En cuanto a obtener los requisitos del cliente, hay algunas consideraciones:

¿Cómo estructura y dimensiona el espacio de su producto?

a) Estructura: ¿qué atributos del producto considera que dominan y limitan en gran medida su diseño? Por ejemplo, para un avión, sería el perfil de misión requerido: ¿qué carga útil, qué distancia, qué altura y qué velocidad debería llevar? No tiene sentido concentrarse en las características auxiliares del producto si la incapacidad de arreglar la parte superior de la escala de atributos conduce a la aparición de características y múltiples rediseños.

Una vez que haya decidido qué atributos generalmente irían primero, debe hacerlos tan independientes entre sí como sea posible (decimos ortogonales , perpendiculares entre sí).

b) Para lograr la independencia de los atributos, generalmente eliminaría los atributos fuertemente correlacionados entre sí y dejaría un número manejable de dimensiones. Dado el corto período de atención de los clientes y sus recursos limitados, no recomendaría más de cinco dimensiones en total, preferiblemente dos o tres (para dejar opciones a los clientes).

A continuación, ¿cuáles son los extremos en cada dimensión? Digamos, ¿un jet regional o un jumbo para vuelos transpacíficos? (nota mental: ¿evitar las analogías con los coches? Comprobar) Prepare bocetos de diseño para cada combinación de extremos y siéntese con el cliente para ver cómo se siente acerca de las variantes. (No intente cuestionarlo ahora: el dinero es suyo). Hágale saber que estas son solo aproximaciones aproximadas y se refinarán a medida que se revelen más preferencias. Refina, fijando sus decisiones sobre lo que es y lo que no es aceptable. Repite el proceso...

Sin embargo, hay otra ruta (que funciona para productos menos subjetivos): encontrar a alguien con suficiente conocimiento tanto de la industria del cliente como de su dominio temático y reclutarlo para que trabaje como "intérprete". Sin embargo, la complicación habitual es que un 'intermediario', ya sea que trabaje a tiempo completo para usted o no, pone en juego toda una serie de prejuicios y preferencias propias, y posiblemente también una agenda oculta.

"¿Cómo previene una situación en la que primero tiene que producir trabajo-producto y obtener comentarios de los clientes antes de tomar el camino correcto para satisfacer sus necesidades?"

No se puede en muchos casos. Pero por lo que he leído/entendido de su pregunta, todo se reduce a la gestión de riesgos.

Usted dijo:

Lo que es más, uno de nuestros clientes cuando comenzamos a hacer preguntas respondió: "Necesito un artista que encuentre los colores adecuados y prepare el diseño. Si es un verdadero artista, cuando entienda la misión que le brindamos, el diseño se manifestará desde adentro". de él..."

Traducido que dice - Quiero un artista que pueda leer mi mente.

Con un cliente como ese, tiene dos opciones: seguir tratando de establecer requisitos y luego documentarlos y ser muy claro y específico, o incorporar el proceso de demostraciones y creación de prototipos en el costo. Comience con una idea cruda y obtenga comentarios y construya a partir de ahí.

Tal vez me lo haya perdido en otras respuestas, pero creo que una de las piezas clave es obtener una mejor comprensión de lo que el cliente realmente está tratando de lograr a un alto nivel.

  • Metas medibles

    • ¿Aumentar el tamaño total del mercado?
    • ¿Aleja a los usuarios de los competidores?
    • ¿Evitar que los usuarios actuales se vayan?
    • ¿Ser visto como la mejor solución en el espacio?
    • cualquier otra cosa que estén tratando de lograr, siempre que sea medible de alguna manera
  • Restricciones

    • ¿Qué no pueden hacer?
    • ¿Hay regulaciones que deben seguir?
  • Personajes de usuario

    • ¿A quién se dirigen? (esto debe proporcionar información, no solo unas pocas palabras)
    • ¿En qué contexto usa este producto esta persona?

Construir esto con el cliente puede ayudarlo no solo a orientarlo en la dirección correcta, sino que a menudo ayudará a que el cliente piense (y exprese) más sobre cómo debería ser el producto final.