Cuando el cliente no tiene la razón

El desafío de construir productos de software a medida.

Recientemente en Hackealo conocimos la experiencia de Martin — Software developer en una reconocida Software Factory — con uno de sus clientes, historia con la que probablemente te podrás sentir identificado. Aquí te la compartimos junto con nuestra reflexión.

“Hace 3 años trabajo en una Software Factory bastante activa que se encarga principalmente de proyectos que arrancan de cero — nada de enlatados, sólo productos a medida — y nuestros clientes por lo general son Startups o empresas interesadas en crear productos de inicio a fin. Los clientes y los proyectos en general son interesantes. El equipo es genial y siempre se aprende algo nuevo. Para ser sinceros hay buena demanda de nuestros servicios así que podemos darnos el lujo de elegir, pero cada tanto aparece uno de esos clientes que te hacen dudar si el cliente realmente ‘siempre tiene la razón’. Les presento a Fernando**:

**Nombre cambiado.

Este fue el quinto correo que recibí aquel domingo. Pero no me mal interpreten: prefiero mil veces un cliente involucrado con el proceso a uno distante que pretende aparecer al final para ‘ver la magia’. Pero Fernando es otro tema. Con este cliente definitivamente no quedó clara nuestra metodología de desarrollo (¿falla nuestra?), visiblemente conoce poco del proceso de ‘product building’ (¿o tal vez sea terquedad?), y con certeza este producto es Fernando-oriented (¿y si Fernando no es el típico end-user?). Es frustrante.

Pienso que así como el paciente no le dice al doctor lo que tiene que hacer, es mejor dejar al especialista hacer su parte y confiar en el proceso. Construir productos es un trabajo en equipo y aunque el cliente tenga claro su objetivo, no siempre tiene la razón, particularmente en lo que desconoce: programación.”

Lo que le sucede a Martin es una situación muy común actualmente en el mundo de la programación. Siendo claros, construir productos de software a medida es un proceso que se nutre del trabajo de muchas áreas (Marketing, Diseño, UX, negocio, estrategia, etc.) y aunque la programación sea ‘el área’ que provee el resultado más tangible — A.K.A. ‘el producto operativo’ — definitivamente no se trata del producto final (¿quizás porque el aporte de las otras áreas son, en esencia, hipótesis a validarse?). No existe un protocolo o plan a seguir que vaya a garantizar la satisfacción total del usuario final, porque precisamente éste — por mucho que se le conozca — es un ser complejo con necesidades a satisfacer de n-formas posibles, formas que aunque se tengan identificadas en la teoría, sólo se pueden descifrar por medio del ‘prueba y error’. Es por ello que iterar es necesario y si queremos alcanzar LA solución rápidamente y con el menor costo posible, el enfoque tiene que estar en validar primero lo importante y necesario. Es que al final del día, ‘funciona’ siempre será mejor que ‘está perfecto’, porque sencillamente la perfección — cuando se trata de satisfacción del cliente — es una utopía.

Por lo anterior es que existen las metodologías de desarrollo como Scrum (ver entrada: ¿Es SCRUM la mejor forma de crear software?) y metodologías para la creación de productos que ya han demostrado ser exitosas. El problema está cuando es ‘a medida’, porque el cliente es el que aprueba o rechaza la solución y no el mercado.

“…El problema está cuando es ‘a medida’, porque el cliente es el que aprueba o rechaza la solución y no el mercado.”

El usuario final: el dueño de la razón.

Ni todo el dinero del mundo invertido en ads de Facebook podrá ser suficiente hacer que un producto inútil sea aceptado por el mercado. Productos que no agregan valor, no generan interés y están condenados a desaparecer. Ejemplo: Internet Explorer. Es decir, quien en definitiva tiene la razón sobre cualquier aspecto del producto, es el usuario final del mismo y no el cliente que paga por tus horas de programación. Esta es una verdad que tu cliente debe entender desde el comienzo si deseas no frustrarte en el proceso.

Comenzando con el pie izquierdo.

Una de las instancias claves al momento de construir productos es ‘la entrevista inicial con el cliente’. Verás, no se trata solamente de conocer que es lo que realmente busca y conocer sus expectativas con respecto al resultado final, sino de identificar 1) qué tanto entendimiento tiene de las variables que pueden afectar al producto (e.g. Competencia, comportamiento del usuario tipo, productos sustitutos, etc), 2) qué tan buen ‘jugador en equipo’ es, y 3) cuales son sus motivaciones reales (solucionar un problema a alguien o simplemente tener un producto ‘brillante’). Siempre será más fácil trabajar con un cliente que no tiene tan claro qué es lo que necesita que con un cliente no entiende el contexto que rodea a su problema/solución o que no entiende su rol en el proceso de ‘product building’. ¿Y en qué momento aparecen los clientes como Fernando? — Simple. Cuando desde el día 1 aceptas trabajar con clientes sin identificar esos 3 aspectos.

¿Y qué hacer con clientes como Fernando?

Si en estos momentos estás trabajando con un cliente de este tipo y deseas continuar con la relación laboral, es necesario cambiar el panorama. Aquí unas recomendaciones:

1. Realiza una ‘intervención’

La única manera de solucionar un problema, es reconociendo el problema. No de tu parte, sino del cliente. Tómate el tiempo para sentarte y explicarle en detalle cómo funciona el proceso de ‘product building’ en general y la metodología de desarrollo que utilizas. Es necesario que tenga una visión clara de donde está parado y qué papel juega.

Probablemente si tu cliente es como Fernando, está pensando en un lanzar un producto que considera, teóricamente, que va a funcionar. En este escenario el enfoque tiene que estar en validar esa teoría antes de ingresar 1 línea de código — Pero tranquilo, también se factura por pensar ;-)

2. Replanteen las reglas de juego

Establezcan las métricas del éxito de la solución. Típicamente un cliente como Fernando que busca una solución a medida, se coloca en una posición de juez de la solución, termina siendo él quien decide si ‘sirvió’ o no… y generalmente el mercado le contradice y termina siendo el programador el culpable del fracaso. Un cliente insatisfecho, aún no teniendo la razón, es malo para el negocio. Entonces es simple: definan realmente qué determina el éxito de la solución en función del mercado, no de las necesidades de Fernando (e.g. X procesos completados exitosamente dentro de la plataforma, X descargas, X usuarios registrados, X quejas por fallas técnicas, etc.)

3. Definan el objetivo real

El objetivo no final no debería ser ‘hacer lo que el cliente pide’ sino ‘satisfacer el problema que quiere solucionar el cliente’, dos ideas que no necesariamente significan lo mismo. Generalmente el cliente visualiza una forma para materializar la solución, un ‘cómo’, que puede no ser el camino indicado. Todo Fernando quiere un producto perfecto para salir al mercado. Pero tu rol como creador del producto es conducir la conversación hacia el objetivo real, el que va a garantizar que, aunque el producto fracase en el mercado por otras variables distintas a la programación, el cliente te siga eligiendo.

Si logras identificar que el cliente con el que te estás entrevistando puede ser como Fernando pero deseas avanzar con la relación laboral, estas recomendaciones te pueden ser útiles:

4. Edúcalo… o al menos ilumínale el camino.

Antes de entrar en profundidad sobre qué necesita, si identificas que tu cliente desconoce del proceso de creación de productos, puedes sugerirle informarse un poco más. Aquí un contenido que puede ser de gran ayuda:

• Derrumbando los mitos de UX: Ideal para cuando el cliente tiene preconceptos (errados o no) sobre UX.
• Lean Startup para principiantes: Guía introductoria sobre la metdología de Eric Ries que le puede interesar a tu cliente.
• Explicando Metodologías ágiles: Explicación sencilla sobre metodologías ágiles en el desarrollo de proyectos informáticos. Tu cliente lo puede entender fácilmente.
• Consejos para escribir mejores ‘User stories’.

Y estos links para ti:

• Guía para estimar proyectos de desarrollo de Software.
• Trabajando con clientes que no entienden de programación.

5. Pídele que te explique cómo es el mercado, el problema y el usuario.

Invierte unos minutos para entender si realmente conoce de la industria en la que quiere colocar el producto, si es capaz de describir al usuario y cómo llegó a conocerlo (lo estudió?, es él/ella el usuario tipo?) y sobre todo, cuál es el problema que quiere solucionar y por qué (existen soluciones sustitutas? qué le motiva?). Conocer esta información te dará la confianza suficiente para determinar si es un cliente en el que vale la pena invertir horas y esfuerzo.

6. Establece la noción de que el usuario final tiene la razón.

Se trata de desconectar al cliente del poder de evaluación del éxito de la solución, porque el cliente no tiene la última palabra, el usuario final sí. Y aún cuando el cliente es de hecho el usuario final, es necesario que se logre evaluar objetivamente si la solución resuelve o no el problema presentado inicialmente. En este sentido la mejor estrategia es involucrar al cliente en el proceso de definición del usuario final (creación de personas), para así descentralizar el rol de juez de la solución — algo que realmente te evitará momentos de frustración.

Cuando tu cliente no tiene la razón, la mejor estrategia es encontrar juntos a quien sí la tiene: el usuario final.

¿Te pareció interesante? — Deja tu comentario y comparte esta entrada ;-)

Ingresa ahora en Hackealo.co y accede a ofertas de empleo pensadas para ti.