Errores comunes en la comunicación con el cliente: cómo no frustrar a su cliente

Cuando alguien solicita un proyecto, debemos asumir que es muy importante y que se preocupa profundamente por el producto en el que trabajará. Por lo tanto, es seguro asumir que un cliente generará muchas expectativas en torno al producto final y, por lo tanto, puede emocionarse cuando se trata de la entrega.

A lo largo del proyecto, un cliente puede entusiasmarse mucho con una función entregada y amarlo, y al día siguiente puede descubrir que algo no funciona y ese afecto se habrá ido. La mayoría de las veces, es solo una cuestión de comunicación con el cliente que salió mal.

Aunque no hay recetas para el éxito cuando se trata de desarrollo de software remoto, creo que hay algunas cosas que deben evitarse para mantener una relación saludable y productiva con los clientes que depositaron tanta confianza en sus manos.

No falle en la comunicación básica con los clientes

Imagine la comunicación con los clientes como lo haría con la comunicación diaria con compañeros de trabajo, amigos o cualquier otra persona a la que le brindaría cortesía.

Si un viejo amigo está de visita en casa y acepta disfrutar de un manjar local “en su antiguo lugar” al mediodía, unas semanas más tarde, ¿aparecería allí? ¿Te mantendrías en contacto mientras tanto, llamar para confirmar con unos días de anticipación? ¿O tal vez asumirías que están demasiado ocupados y no querrías molestarlos sin una buena razón? ¿Esperarías que te avisaran cuando lleguen?

No es probable que sigas chateando todos los días a menos que tengas mucho de qué hablar, pero mantendrás alguna forma de comunicación, por cortesía y practicidad: no quieres que la otra persona piense que te olvidaste de ella. , pero definitivamente no querrás conducir hasta la mitad de la ciudad sin una buena razón.

En algún momento, probablemente también experimentó situaciones similares en su comunicación profesional, incluso con socios y compañeros de trabajo de mucho tiempo. Algunos proyectos se ejecutan con una comunicación mínima, como decir “lo de siempre, al mediodía, ahí nos vemos” para confirmar un almuerzo ligero. Incluso si surge algo, la otra parte seguramente se lo hará saber y usted aceptará reprogramar la cita.

Sin embargo, las cosas no son tan simples o lineales en el mundo del desarrollo de software.

Si comienza a trabajar en un proyecto, especialmente cuando está tratando con un nuevo cliente, si nunca saben de usted, comenzarán a tener dudas sobre su trabajo y compromiso. Incluso si te presentas con un producto impecable después de algunas semanas, es posible que los clientes ya no tengan una percepción ideal de ti.

Aunque a veces puede parecer incómodo, ¡no está de más hablar con el cliente incluso si no tienes nada fuera de lo habitual que informar! ¿Tienes alguna duda sobre un pequeño punto de una historia de usuario? Si crees que es importante, házselo saber. ¿Llegas un poco tarde y no estás seguro de poder cumplir con la fecha estimada que acordaste? ¡Llama al cliente lo antes posible! Es mejor que se enteren enseguida.

No tienes ninguna duda y el proyecto está perfectamente dentro del plazo previsto, pero ¿el cliente no habla mucho? ¿Por qué no enviar un correo electrónico describiendo su progreso cada pocos días? No hará ningún daño porque los correos no serán una molestia para nadie, además documentarás tu progreso y mantendrás una comunicación regular con el cliente.

La comunicación defectuosa con el cliente fomenta expectativas poco realistas

Entonces, al principio, mencioné que el cliente seguramente tendrá muchas expectativas sobre el proyecto, ¿verdad? Derecha. Período.

El cliente ya espera mucho del producto. Si no sale como lo imaginaban, los clientes inevitablemente se sentirán frustrados. Entonces, ¿por qué alguien promete más de lo que puede cumplir, creando así expectativas aún menos realistas?

Aquí hay un paralelo rápido: compró una tableta en línea y le prometieron una entrega de 10 días. El octavo día, la tienda le dice que hay un problema y retrasa la entrega una semana. Para compensarte por las molestias, el minorista promete darte un crédito de la tienda de $75.

Probablemente no necesites esa tableta durante los próximos días de todos modos, ¡así que crees que es una buena oferta! Ahora puede disfrutar de la tableta, además de usar el crédito de la tienda para comprar algo bueno para sus hijos. Pero el taller llama al día siguiente y dice que todo se solucionó de la noche a la mañana.

Recibirás la tableta al día siguiente. Sin extras, sin crédito en la tienda. ¡Ahora eres tú el que está frustrado!

"¿Qué? ¡Justo ayer me dijiste que conseguiría un trato mejor! ¡No es justo! Ya les dije a los niños…”

Rebobine un par de días y todo lo que esperaba era la tableta de todos modos. Si nadie le hubiera prometido un trato mejor, habría estado satisfecho con su juguete cuando llegó al día siguiente. Pero ahora, sientes que te lo estás perdiendo sin ninguna buena razón, aparte de la decisión de la tienda de avisarte.

¿Cómo pueden los desarrolladores, especialmente los autónomos, evitar situaciones similares en su comunicación con los clientes?

Al no volverte loco y decir todo lo que te viene a la mente en primer lugar. Las sugerencias no están prohibidas; en realidad, son muy bienvenidos si cree que una característica solicitada en particular no es una muy buena opción para resolver el problema en cuestión. Pero la clave es: Piensa primero.

• Escuchar al cliente.

• Analice su problema.

• Analizar la solución propuesta.

• Asegúrese de que esté dentro del presupuesto/programación.

• Finalmente, continúe y presente su sugerencia.

Esta es la razón por la cual las habilidades de comunicación con el cliente pueden ser complicadas, porque fallar en solo uno de los primeros cuatro pasos significa que podría terminar perdiendo el tiempo y, peor aún, el tiempo de su cliente.

No asuma que sabe lo que necesita el cliente

Parafraseando a Mary Schmich, Damas y caballeros de la clase del '17: Escuchar al cliente. Si pudiera ofrecerle un solo consejo para el futuro, sería escuchar al cliente.

Si te llamaron para un proyecto es porque alguien necesita algo. ¿Y quién sabría mejor sobre esa necesidad que su cliente? Puede parecer obvio, pero a veces, en el mundo real, la gente lo olvida.

Dejame darte un ejemplo. Un minorista solicita un "sistema de software" para su negocio. Apenas lo ves, saltas a la conclusión de que lo que quieren es algo para registrar todos los productos disponibles, registrar cada compra realizada, generar recibos para los clientes e informar sobre lo que se vendió periódicamente y sobre qué artículos se están agotando. valores.

Entonces, en tu primera reunión, quieres demostrar que eres eficiente y presentarles lo que has preparado, las características propuestas, un diseño básico que vaya con la identidad visual de la tienda y todo. Pero luego el cliente desconcertado dice que, en realidad, lo que necesitan es un algoritmo para calcular cómo exhibir mejor los productos en los estantes, ¡con el objetivo de aumentar los ingresos para marcas y productos específicos!

El error aquí fue simplemente no identificar qué problema se suponía que debía resolver. Por supuesto, en este caso, dado que era muy temprano en el proyecto, habría mucho tiempo para hacerlo bien, pero a veces, este tipo de error ocurre más adelante. Aunque no puede ser tan drástico como el ejemplo anterior, aún puede dañar el proyecto y/o su relación con el cliente.

Mi sugerencia es la siguiente: Habla con tus futuros usuarios, mucho si es posible, y consulta a varios stakeholders del proyecto. Ellos son los que tienen una buena visión general de la situación y saben lo que necesitan. Trate de averiguar lo que hacen actualmente, en cada paso del camino, y explique cómo el software sería útil. Me gusta decir que, cuando trato de entender lo que un cliente desea, mi objetivo es casi poder realizar su trabajo por mí mismo. Si te acercas a este punto, entonces realmente has descubierto cuáles son sus necesidades.

No entender lo que pide el cliente

No es raro recibir algún tipo de documentación sobre el problema en cuestión. A veces es solo una descripción de alto nivel, mientras que otras veces es un documento detallado con casos de uso y reglas comerciales. En cualquier caso, no importa cuán claros sean los registros, lo único que no puede hacer es asumir que todo lo que está escrito allí es la verdad absoluta.

¿¿¿Qué???

Exactamente. Primero, algo puede significar una cosa para alguien, en un contexto determinado, y una cosa completamente diferente para personas que no pertenecen a esa realidad. Y si hay algo que tú y el cliente no tenéis en común, ¡es el contexto!

En segundo lugar, no todo el mundo es un escritor muy hábil; tratan de decir A pero terminan describiendo B.

Entonces, después de leer todo lo que te han enviado, ¿cómo estarás seguro de que lo que lees es realmente lo que significan? Bueno, digerirás todo, tomarás algunas notas, analizarás todo y… convocarás una reunión . (¿Ves? ¡Todo se trata de comunicación!) En la reunión, hablarás sobre el problema y describirás lo que entendiste con tus propias palabras. En esta etapa, probablemente podrá identificar cualquier malentendido.

“Oh, pero en mi caso, no obtuve ningún documento. Simplemente me senté con el cliente y me explicaron todo mientras tomaba algunas notas”.

Bueno, todavía no hay garantía de que entendiste lo que significaban y mi sugerencia sigue en pie: tómate un tiempo con tus notas, piensa en todo el problema, organiza todo, preferiblemente en algún tipo de línea de tiempo de eventos, y luego llama/reúnete de nuevo con el cliente para presentar lo que entendiste. Puede sonar repetitivo para usted, pero a veces incluso el cliente no tiene una visión completa de todos los procesos involucrados para realizar una tarea específica y luego verá cuán complejo tendrá que ser el software.

Al final, debe estar seguro de que no hay ambigüedad ni malentendidos.

Por qué no debes entregar todo lo que pide el cliente sin pensarlo

Bien, ahora que sabes que debes escuchar al cliente y confirmar lo que entendiste, puedes seguir adelante y hacer todo lo que te pidió, ¿verdad?

¡Incorrecto!

Ahora es el momento en que finalmente puedes usar toda la experiencia que tienes y preguntarte: ¿lo que el cliente te pidió va a resolver su problema? ¿Es lo que te pidieron realmente lo que necesitan?

Te sorprendería ver cuántas veces la respuesta es “no”.

Antes de solo entregar lo que el cliente pidió, necesitamos analizar el problema y, si no está de acuerdo con lo que el empleador propuso, entonces es su trabajo y responsabilidad profesional dejarlo claro. Por supuesto, debe explicar por qué cree que su propuesta no es buena y qué hará su enfoque alternativo para abordar estas deficiencias. Una vez más, la comunicación es la clave.

Si usted y el cliente son razonables, entonces procederán con su solución o tendrán una sesión de lluvia de ideas para encontrar una mejor (en caso de que su idea no sea aceptable para el cliente por alguna razón).

Prototipo: no escriba una documentación extensa

Ya dije que usted y su cliente generalmente no tienen la misma perspectiva, ¿verdad? Por lo tanto, así como afecta su comprensión de su documentación, afectará su comprensión de lo que entrega por escrito. Es una cuestión de contexto, también.

Entonces, estoy de acuerdo en que de alguna manera (en un nivel superior o inferior), tenemos que documentar lo que estamos a punto de desarrollar. Pero entregar varias páginas de texto sin ningún elemento visual no te servirá de mucho. El cliente se aburrirá de leerlo, dejará de prestar atención y probablemente no podrá entender lo que quiere decir con esas complejas reglas comerciales, o interpretará algo completamente diferente de lo que había imaginado.

Tenga en cuenta que estos malentendidos pueden ser aún peores si el cliente no tiene formación técnica.

Todos estos factores pueden resultar en el mismo resultado problemático: los clientes se quejarán cuando entregues el producto porque es probable que no sea lo que tenían en mente.

Esto es lo que sugiero: Prototipo siempre, incluso si es solo un boceto para dibujar cuál es su plan. Y cualquier definición que tengas que hacer, comienza desde allí. Haga referencias y trate de mantenerlo simple.

Deje de perder el tiempo convenciendo al cliente de que tiene razón

Casi puedo estar seguro de que todos los desarrolladores han pasado por la siguiente situación: Al comienzo del proyecto, el cliente dice: “Necesito que el color de fondo del software sea amarillo. Ya ha sido acordado por la junta”. Luego, cuando se entrega el software, dicen “Ah, pero el color de fondo no puede ser amarillo. ¡Te dije que tenía que ser verde! Ahora, ¿cómo deberías lidiar con esto?

Seguramente, de nada servirá, en cualquier caso, insistir simplemente en que tú tenías razón y ellos estaban equivocados. En todo caso, solo les hará pasar un mal rato tanto a usted como al cliente.

Siempre es bueno tener un buen registro de comunicación con el cliente, solo para asegurarse de estar en la misma página y dejar un rastro escrito. La mayoría de las veces, si se trata de algo simple, puede simplemente enviar un correo electrónico al cliente y decirle: "Como acordamos en esa reunión, el fondo del sistema será amarillo". Y si, en el futuro, el cliente cambia de opinión, puede argumentar que lo hizo de esa manera debido a esa reunión mencionada en el correo electrónico, pero si realmente se necesita hacer esa modificación, puede ejecutarla, por x horas adicionales. (y a veces, un extra de x dólares).

Pero si no hay nada que demuestre que tenía razón, entonces probablemente tenga que tomar una decisión (así como una lección que aprender): ¿Es el cambio tan grande que requerirá un cambio en la arquitectura actual o afectará otras características? Si no, probablemente sea mejor seguir adelante, hacerlo y tener al cliente a tu lado (pero con los ojos bien abiertos para que no vuelva a suceder). Si es así, una charla con el cliente será la mejor solución; no uno que se centre en "cómo tenías razón", sino en "cómo podemos solucionar el problema actual".

En cualquier caso, la mejor manera de evitar tener que hacer grandes modificaciones es ofrecer nuevas funciones breves en períodos cortos de tiempo. Por lo tanto, si hay que cambiar algo, probablemente no sea una gran transformación de lo que ya existe.

Sepa cuándo comprometerse con los plazos

Por último, pero no menos importante, uno de los mayores errores que puede cometer es darle a su cliente una fecha límite para que termine el proyecto. ¡Y te rogarán que cometas ese error!

Por supuesto, como cliente, desea saber cuándo podrá usar todas esas características agradables que ha estado discutiendo durante las últimas semanas (¿meses?). Pero, dado que un proyecto no es un producto definido, pueden pasar muchas cosas desde que comienza el desarrollo hasta que el software está listo para usar.

En primer lugar, uno no puede predecir lo impredecible. Es muy probable que tengas que lidiar con algo que no esperabas. Podría ser una licencia prometida por el cliente que no se compró a tiempo, o algún otro software interno que necesita usar pero que no se lanzó cuando debería haberlo hecho, o el entorno era diferente al acordado al principio, o el cliente cambió de opinión sobre algunas (algunas) características y tuvo que rehacer un par de cosas.

Nada de eso es realmente culpa del desarrollador y puede afectar profundamente la fecha límite de un proyecto. Pero si usted, dispuesto a complacer al cliente, le prometió que le entregaría todo en una fecha determinada y finalmente, por las razones correctas, no lo hizo, una cosa que puedo garantizar es que el cliente va a estar, al menos un poco , frustrado. Si eres autónomo, tienes que gestionar tu tiempo de forma eficiente, como explica este artículo del Blog de ingeniería de Toptal. No olvide que la gestión de las relaciones con los clientes también es su trabajo.

Entonces, hazte un favor a ti y a quien depende del proyecto y al menos dales un estimado de cuánto tiempo llevará desarrollar todo, pero siempre deja muy claro que es solo un estimado y no una fecha límite.

Además, sugiero encarecidamente (especialmente si ya ha dado un presupuesto) que siempre le informe al cliente cuando algo se está demorando más de lo esperado para que pueda actuar para ayudarlo.