¿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?
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 Balsamiq
y hacemos muchas preguntas como:
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.
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.
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:
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.
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:
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.
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
Restricciones
Personajes de usuario
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.
jmort253
Daniel Skowronski
MCW
Daniel Skowronski
MCW
jmort253