Cuando alguien solicita un proyecto, debemos asumir que es muy importante y que se preocupan profundamente por el producto en el que trabajará. Por lo tanto, es seguro suponer que un cliente está obligado a construir una gran expectativa sobre el producto final y, por eso puede llegar a ser emocional cuando se trata de la entrega.
A lo largo del proyecto, un cliente puede sentirse muy emocionado por una función entregada y amarte, y al día siguiente puede descubrir que algo no funciona y el afecto desaparecerá. 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 se deben evitar para mantener una relación productiva y saludable con clientes que pusieron su confianza en tus manos.
No Falles en la Comunicación Básica con los Clientes
Imagínese 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 quien extienda su cortesía.
Si un viejo amigo visita su casa y tú aceptas disfrutar de un manjar local “en su hogar” al mediodía, unas semanas más tarde, ¿tan sólo te presentarías allí? ¿Podrían mantenerse en contacto mientras tanto, llamar para confirmar unos días antes? ¿O tal vez asumirías que está demasiado ocupado y no querrías molestarlo sin una buena razón? ¿Esperarías que te avise cuando lleguen?
No es probable que sigas chateando todos los días a menos que tenga un montón de información, pero mantendrás algún tipo de comunicación, por cortesía y practicidad: no quieres que la otra persona piense que te olvidaste de ellos, pero definitivamente no quieres conducir a mitad de camino por la ciudad sin una buena razón.
En algún momento, probablemente hayas experimentado situaciones similares en tu comunicación profesional también, incluso con socios y compañeros de trabajo de larga data. Algunos proyectos se ejecutan con la mínima comunicación, al igual que decir “lo habitual, al mediodía, nos vemos allí” para confirmar un almuerzo ligero. Incluso si surge algo, la otra parte seguramente le informará y aceptará reprogramarlo.
Sin embargo, las cosas no son tan simples o lineales en el mundo del desarrollo de software.
Si comienzas a trabajar en un proyecto, especialmente cuando estás tratando con un nuevo cliente, si nunca escuchan de ti, comenzarán a tener dudas sobre tu trabajo y compromiso. Incluso si aparece con un producto impecable después de unas semanas, los clientes pueden tener una percepción menos que ideal de usted.
Aunque a veces se sienta incómodo, no hace daño hablar con el cliente, incluso si no tienes nada fuera de lo común para informar. ¿Tienes alguna duda sobre un pequeño punto de la historia de un usuario? Si crees que es importante, házselo saber. ¿Estás llegando un poco tarde y no estás seguro si podrás cumplir esa fecha estimada en la que estuviste de acuerdo? ¡Llama al cliente lo antes posible! Es mejor que lo escuchen de inmediato.
¿No tienes dudas y el proyecto se ajusta a la perfección, pero el cliente no habla mucho? ¿Por qué no simplemente enviar un correo electrónico describiendo tu progreso cada pocos días? No hará ningún daño porque los correos electrónicos no serán una molestia para nadie, además documentarán tu progreso y mantendrán una comunicación regular con el cliente.
La Comunicación Defectuosa del Cliente Fomenta las Expectativas Poco Realistas
Al principio mencioné que el cliente seguramente tendrá muchas expectativas sobre el proyecto ¿verdad? Las tendrás. punto.
El cliente ya espera mucho del producto. Si no sale como lo imaginaron, los clientes inevitablemente se sentirán frustrados. Entonces, ¿por qué alguien podría prometer más de lo que puede ofrecer, creando así expectativas aún más irreales?
Aquí hay un paralelo rápido: Compraste una tableta en línea y nos prometieron una entrega de 10 días. El octavo día, la tienda le informa que hay un problema y demora la entrega por una semana. Para compensar los inconvenientes, las promesas del minorista le otorgan un crédito de $ 75 en la tienda.
Probablemente no necesites esa tableta en los próximos días, ¡así que crees que es un buen negocio! Ahora puedes disfrutar de la tableta, además de usar el crédito de la tienda para comprar algo lindo a tus hijos. Pero la tienda llama al día siguiente, diciendo que todo se solucionó de la noche a la mañana.
Obtendrás la tableta al día siguiente. Sin extras, sin crédito en la tienda. ¡Ahora estás frustrado!
“¿Qué? ¡Solo ayer me dijiste que obtendría un mejor trato! ¡No es justo! Ya se lo dije a los niños …”
Rebobina un par de días y todo lo que esperabas era la tableta de todos modos. Si nadie te hubiera prometido un mejor trato, habrías estado satisfecho con tu tableta cuando llegó al día siguiente. Pero ahora, sientes que te estás perdiendo de algo más por una buena razón, aparte de la decisión de la tienda de hacerte saber.
¿Cómo pueden los desarrolladores, especialmente los profesionales independientes, evitar situaciones similares en su comunicación con los clientes?
Al no enloquecer y decir todo lo que viene a su mente en primer lugar. Las sugerencias no están prohibidas; en realidad, son muy bienvenidos si crees 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”.
- Escucha al cliente.
- Analiza su problema.
- Analiza la solución propuesta.
- Asegúrate de que esté dentro del presupuesto/cronograma.
- Finalmente, sigue y presenta tu sugerencia.
Esta es la razón por la que las habilidades de comunicación con los clientes pueden ser complicadas, ya que fallar en solo uno de los primeros cuatro pasos significa que podrías terminar perdiendo el tiempo y, lo que es peor, el tiempo de tu cliente.
No Asumas que Sabes lo que el Cliente Necesita
Parafraseando a Mary Schmich, Señoras y señores de la clase del ‘17: Escuchen al cliente. Si pudiera ofrecerle solo un consejo para el futuro, escuchar al cliente sería eso.
Si te llamaron para un proyecto es porque alguien necesita algo. ¿Y quién sabría mejor sobre esa necesidad que tu 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. Tan pronto como lo veas, llegas a la conclusión de que lo que quieren es 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 acabando. valores.
Por lo tanto en su primera reunión, deseas mostrar que es eficiente y presentarles lo que ha preparado, las características propuestas, un diseño básico para ir con la identidad visual de la tienda y todo. Pero luego el desconcertado cliente dice que, en realidad, lo que necesita es un algoritmo para calcular cómo mostrar mejor los productos en los estantes, con el objetivo de aumentar los ingresos de marcas y productos específicos.
El error aquí fue simplemente no identificar qué problema se suponía que debías resolver. Por supuesto en este caso, ya 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. Incluso aunque no sea tan drástico como el ejemplo anterior, puede dañar el proyecto y/o su relación con el cliente.
Mi sugerencia es la siguiente: habla con sus futuros usuarios, mucho si es posible, y consulte a varias partes interesadas en el proyecto. Ellos son los que tienen una buena visión general de la situación y saben lo que necesitan. Trata de descubrir qué hacen actualmente, en cada paso del camino, y explica cómo el software sería útil. Me gusta decir que, cuando intento entender lo que desea un cliente, mi objetivo es casi poder realizar su trabajo yo mismo. Si te acercas a este punto entonces realmente has descubierto cuáles son sus necesidades.
No se Entiende lo que el Cliente está Pidiendo
No es raro recibir algún tipo de documentación sobre el problema en cuestión. Algunas 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 se puede hacer es simplemente asumir que todo lo escrito allí es la verdad absoluta.
¿¿¿Qué???
Exactamente. Primero, algo puede significar una cosa para alguien, en un cierto contexto, y una cosa completamente diferente para las personas que no pertenecen a esa realidad. Y si hay algo que tú y el cliente no tienen en común, ¡es el contexto!
Segundo, no todos son escritores muy hábiles; intentan decir A pero terminan describiendo a 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 querían decir? Bueno, podrás digerir todo, tomar notas, analizar todo y … llamar a una reunión. (¿Lo ves? ¡Todo se trata de comunicación!) En la reunión, hablarás sobre el problema y describirás lo que has entendido con tus propias palabras. En esta etapa, probablemente podrá identificar cualquier malentendido.
“Oh, pero en mi caso, no recibí 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 hayas entendido lo que significan 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 / vuelve a reunirte con el cliente para presentar lo que has entendido. Puede sonar repetitivo para ti, pero a veces incluso el cliente no tiene una visión completa de todos los procesos involucrados para realizar una tarea específica y verás cuán complejo tendrá que ser el software.
Al final, debes estar seguro de que no hay ambigüedad ni malentendidos.
Porqué no Debes Entregar Todo lo que el Cliente Pide sin Pensar
Bien, ahora que sabes que debes escuchar al cliente y confirmar lo que has entendido, puedes seguir adelante y hacer todo lo que te pidieron, ¿no?
¡Incorrecto!
Ahora es el momento en que finalmente puedes usar toda la experiencia que tienes y preguntarte: ¿Es lo que el cliente te pidió que resolvieras? ¿Es lo que te preguntaron realmente lo que necesitan?
Te sorprendería ver cuántas veces la respuesta es “no”.
Antes de solo entregar lo que el cliente solicitó, necesitamos analizar el problema y, si no estás de acuerdo con lo que el empleador propuso, entonces es tu trabajo y responsabilidad profesional dejar esto en claro. Por supuesto, deberías explicar por qué crees que su propuesta no es buena y cuál será tu enfoque alternativo para abordar estas deficiencias. Una vez más, la comunicación es la clave.
Si tú y el cliente son razonables, entonces procede con tu solución o ten una sesión de lluvia de ideas para encontrar una mejor (en caso de que tu idea no sea aceptable para el cliente por algún motivo).
Prototipo — No Escribas una Gran Cantidad de Documentación
Ya dije que tú y tu cliente generalmente no tienen la misma perspectiva, ¿verdad? Por lo tanto, así como afecta tu comprensión de su documentación, afectará su comprensión de lo que tú entregarás por escrito. Es una cuestión de contexto.
Por lo tanto, 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 elementos visuales no te servirá de mucho. El cliente se aburrirá de leerlo, dejará de prestarle atención y probablemente no podrá entender lo que quiere decir con esas complejas reglas comerciales, o interpretarán algo completamente diferente de lo que había imaginado.
Ten en cuenta que estos malentendidos pueden ser aún peores si el cliente no tiene formación técnica.
Todos estos factores pueden dar como resultado el mismo resultado problemático: los clientes se quejarán cuando entregue el producto porque es probable que no sea lo que tenían en mente.
Esto es lo que sugiero: Siempre prototipo, incluso si es solo un boceto para dibujar cuál es tu plan. Y cualquiera que sea la definición que tenga que hacer, comienza desde allí. Haz referencias y trate de mantenerlo simple.
Deja de Perder el Tiempo Intentando Convencer al Cliente de que Tienes la Razón
Casi puedo estar seguro de que cada desarrollador ha 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 debes lidiar con esto?
De hecho de nada servirá, en cualquier caso, insistir en que tenías razón y estaban equivocados. En todo caso, solo les dará a ti y al cliente un momento difícil.
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 es algo simple, puede enviar un correo electrónico al cliente diciendo: “Como acordamos en esa reunión, el fondo del sistema será amarillo”. Y si, en el futuro, el cliente cambia su tenga en cuenta que puede argumentar que lo hizo por esa reunión mencionada en el correo electrónico, pero si realmente necesita hacerse esa modificación, puedes ejecutarla, por un extra de x horas (y en ocasiones, x dólares extra).
Pero si no hay nada que demuestre que tú tenías razón, entonces probablemente tengas que tomar una decisión (además de aprender una lección): ¿El cambio es tan grande que requerirá un cambio en la arquitectura actual o afectará otras características? De lo contrario, 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 lo hace, una conversación con el cliente será la mejor solución; no uno que se centre en “cómo estaba en lo cierto”, sino en “cómo podemos solucionar el problema actual”.
En cualquier caso, la mejor manera de evitar tener que hacer grandes modificaciones es entregar nuevas breves características en cortos períodos de tiempo. Por lo tanto, si algo tiene que cambiarse, probablemente no será una transformación importante de lo que ya existe.
Aprender a Cuándo Comprometerte con los Plazos de Entrega
Por último, pero no menos importante, uno de los mayores errores que puedes cometer es darle a tu cliente una fecha límite para que termine el proyecto. ¡Y te suplicarán que cometas ese error!
Por supuesto, como cliente, quieres saber cuándo podrás usar todas esas características interesantes que has estado discutiendo en 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, no se puede predecir lo impredecible. Es muy probable que tengas que lidiar con algo que no estabas esperando. Podría ser una licencia que el cliente prometió que no se compró a tiempo, o algún otro software interno que necesites usar, pero que no fue lanzado cuando debería haber sido, o el entorno fue diferente al acordado al principio, o el cliente cambió de opinión sobre unas (pocas) características y tuvo que volver a hacer algunas cosas.
Nada de eso es realmente culpa de un desarrollador y puede afectar profundamente el plazo del proyecto. Pero si tú, dispuesto a complacer al cliente, le prometiste que entregarías todo para una fecha determinada y terminarías no pudiendo por la razón que sea, una cosa que puedo garantizar es que el cliente estará al menos un poco frustrado. Si eres un profesional independiente, debes administrar su tiempo de manera eficiente, como lo explica el artículo del Blog de Desarrollo de Toptal. No olvides que la gestión de relaciones con el cliente también es tu trabajo.
Por lo tanto, hazte a tí y a quien depende del proyecto un favor, y al menos bríndales una estimación de cuánto tiempo llevará desarrollarlo todo, pero siempre deja en claro que sólo es una estimación y no una fecha límite.
Además, sugiero fuertemente (especialmente si ya has dado una estimación) que siempre le digas al cliente cuando algo tardará más de lo esperado para que puedan actuar para ayudarte.
Fuente:
BY ANDREZA CRISTINA DA SILVA - FREELANCE SOFTWARE ENGINEER @ TOPTAL (TRANSLATED BY YESICA DANDERFER)
