¿Cómo reaccionar cuando la respuesta del cliente es negativa en la entrega?

project-management feedback (21)

Soy un programador junior. Como mi supervisor me dijo que me sentara con el cliente, me uní. Vi la cara insatisfecha del cliente a pesar de la entrega exitosa (¡desde la perspectiva de mi programador) del proyecto!

Cliente: ¡podría haber incluido esto!
Nosotros: ¡ No estaba en la especificación!
Cliente: ¡Sentido común!

Como programador, ¿cómo respondes en esta situación?

"¿como reaccionas?"

Pregunta 1: ¿desea continuar esta relación con este cliente? Seriamente. Si van a afirmar que las características no especificadas son de "sentido común", esta puede no ser una buena relación para mantener o mejorar.

Si quieres desconectarte, entonces eso es fácil. Pídales que resalten cada parte de la especificación que usted no cumplió y que juegue ese juego. Obtenga criterios de prueba específicos para cada característica que falta. Tire los dientes. Sea confrontativo al determinar lo que falta. No preguntes por qué. Solo pide todos los detalles por adelantado. Es lento y desagradable. Pero no los quieres de todos modos.

Si quieres participar, bueno, vas a tener que cambiar la relación. Actualmente, tiene un cliente pasivo agresivo. No dirán lo que quieran, pero dirán lo que no quieren.

Esto puede ser un hábito con ellos; esta puede ser la forma en que ganan las concesiones. O esta puede ser una especificación descuidada de su parte.

Si quieres la relación, tu reacción tiene dos partes.

Término corto. Consigue algo con lo que estén felices. Deben identificar cambios específicos. Debe puntuar cada cambio con un "costo por hacer" y "cumplir con las especificaciones".
- Algunas cosas son baratas y se ajustan bien. Haz ésos.
- Algunas cosas son baratas de hacer, pero un mal ajuste con la especificación. Piénselo dos veces antes de permitir que una especificación defectuosa lleve a un retrabajo. En cierto sentido, usted compró la especificación de ellos; es posible que necesite elevar sus estándares, también.
- Las cosas costosas que (lamentablemente) se ajustan a la especificación son un problema. Estás en problemas con estos, y prácticamente tienes que hacerlos.
- Las cosas costosas que no encajan bien con la especificación son lecciones aprendidas para todos. Detallar un plan para estos, incluyendo rescripciones y aprobaciones de especificaciones.
A largo plazo. Asegúrate de que no te vuelvan a pinchar. Revise temprano y con frecuencia, use técnicas ágiles. Comunícate más, protégete más, lanza más.

Bueno, no fue entregado con éxito. En algún momento a lo largo de la línea hubo una falta de comunicación. Sin conocer los detalles, sugeriría que este no es un problema que el desarrollador inyectó y que probablemente no sea culpable del cliente; la tarea de recopilación de requisitos fue insuficiente. Este es un ejemplo clásico de lo que sucede cuando el lado del software no tiene expertos de dominio o el proceso de descubrimiento de requisitos no hace todo lo que podría ...

Si fuera yo, corregiría el problema y descubriría cómo evitar problemas similares en el futuro.

Cómo maneja esto puede determinar el futuro de este contrato / negocio con el cliente. Asumir la responsabilidad y corregir el problema es una gran oportunidad para su empresa.

EDITAR: Este es un buen momento para evaluar cómo sucedió esto para ayudar a corregirlo. Algunas compañías eligen renovar totalmente todo lo que hacen, lo cual es un error, creo. Entonces es ignorarlo. Culpar a las personas por el problema también es un error.

Es un buen momento para ver cómo sucedió esto, cuál es el proceso y, quizás, cómo podría haber sido atrapado. No haría grandes cambios en las reglas ni procesaría los cambios, pero generar nuevas pautas para el trabajo futuro es algo grandioso. Su empresa tuvo una lección clara sobre una deficiencia. Perder la oportunidad de corregir este problema y corregir su proceso sería una pérdida de una buena oportunidad.

Caso clásico ...

No hay una respuesta definitiva a esta, pero todo gira en torno a la comunicación. Debieron haberse implementado medidas preventivas (como revisiones semanales o algo así).

Por supuesto, no puedes volver a hacer todo de forma gratuita.

De dos maneras: O para decirles que ** salgan o que se ocupen de eso.

Si eliges tratar:

Primero, empatízate, respeta al cliente.
Echa un vistazo a lo que se puede cambiar fácilmente.
Eche un vistazo a los contratos.
Tal vez crear un nuevo acuerdo.
No hagas demasiado.
Hágales ver el progreso y el trabajo que lleva.
Encuentre soluciones provisionales para las características que faltan (tal vez utilizando otras funciones excelentes o herramientas disponibles).

Usa tu sentido común, es tan común, ni siquiera es divertido.

En términos de su pregunta literal, cómo reaccionar, la mejor manera es ignorar su ego ("¿qué ?! Después de que trabajé tan duro en esto y conocí las especificaciones ?!") y en su lugar centrarme en escuchar activamente y trabajar para lograr el consenso .

Cliente: ¡podría haber incluido esto!

Nosotros: ¡No estaba en la especificación!

Cliente: ¡Sentido común!

Nosotros: entiendo que no está satisfecho de que no hayamos superado los límites de la especificación. Al ver cómo te sientes al respecto, ¿cómo podemos hacerte feliz? Veamos si hay un proceso que podamos crear juntos que ayude a todos.

Esencialmente, no desea convertir esto en un "muerte" dijo "yo dije". La única manera de resolver eso involucra a abogados y luego nadie gana. Si puede aceptar que la especificación o el proceso fueron defectuosos, trabaje en conjunto para solucionarlos.

Es por eso que los equipos con los que trabajé siempre usaron un enfoque de estilo prototipo , eso significa:

después de recopilar los requisitos, le muestra al cliente una versión inicial y básica del software
el cliente dice " podrías haber incluido esto " / " es sentido común "
Cambias tu diseño para reflejar el deseo del cliente
iterar desde el punto 1 hasta el lanzamiento oficial

Esta sería una de las muchas razones por las que cambié a una filosofía de desarrollo ágil . La única manera, en mi opinión, de evitar con éxito este escenario es ser omnisciente o involucrar al cliente en gran medida y lanzarlo a tiempo / liberarlo a menudo para obtener retroalimentación tan pronto como sea posible. De esta forma, puede desarrollar el software que realmente quiere el cliente, no el software que el cliente le dice que quiere.

Este enfoque realmente funcionó para mí: espera que el tipo que no le gusta que tu software se vaya y sea reemplazado por el tipo que le gusta .

Obviamente, no puedes confiar en esto, pero si estás seguro de que hiciste un buen trabajo y de que tu software realmente satisfará las necesidades comerciales de las personas que te contrataron, pagar es esperar. A veces la reacción inicial del cliente no será la última, especialmente si puede incorporar rápidamente sus inquietudes.

Este es uno de los muchos inconvenientes de un acuerdo de oferta fijo. Cada vez que cambian las necesidades o prioridades comerciales, o incluso hay un simple malentendido, se produce desde una situación incómoda como llamar a un abogado. Si tiene un acuerdo en el que se le paga por el tiempo de desarrollo, siempre puede reaccionar ante cualquier cambia y te pagan por el tiempo que sea necesario para hacer ese cambio. Además, tener un arreglo por hora no impide tener un plan o hacer un presupuesto.

Sin embargo, una vez que está en un pickle fijo de oferta, sus opciones son: 1) Hacerlo a un costo adicional. 2) Hazlo gratis. 3) No lo hagas

La opción 3 es la peor, y la opción 1 es la mejor. Si tiene una buena relación de confianza y una comunicación decente con el cliente, generalmente es fácil llegar a la Opción 1. Si la relación es mala, entonces usted tiene problemas mayores. En ese punto, solo trata de evitar a los arrendatarios.

Un punto final: cualquier proyecto que tenga algo conocido como "La fecha de entrega" se topa inevitablemente con el problema descrito. Los proyectos con dicha fecha generalmente implican retirarse a una cueva durante varios meses para desarrollarse en la clandestinidad seguido de un lanzamiento del producto de una vez frente a las partes interesadas. Esto es abrupto y deja mucho tiempo para que las expectativas del cliente y el producto real se separen. Si, en cambio, muestra versiones intermedias del producto y recopila comentarios cada pocas semanas, suceden dos cosas. Primero, obtienes mejores comentarios, minimizas los malentendidos y haces un mejor producto. En segundo lugar, no hay un solo punto en el tiempo en el que se establezca una enorme cantidad de expectativas. La diferencia de potencial entre lo que el cliente está imaginando y lo que realmente existe es mucho más pequeño. No hay sorpresas.

Buena suerte.

Falla total por parte de la persona a cargo de la recopilación de requisitos, sin duda al respecto. Falla adicional de la administración del proyecto para no repetir el entregable y tener reuniones de registro con el cliente.

Sin embargo, tiene una especificación firmada, y lo que ha entregado coincide con la especificación. Por lo tanto, su empresa tiene dos opciones: cancelar el costo en nombre del desarrollo comercial y realizar el cambio de forma gratuita, o cobrar por la solicitud de cambio.

Hablando al tema y pregunta del OP:

Si usted es un programador empleado, entonces espero que haya otros recursos en la reunión con usted. Posiblemente "superiores" en la organización.

Si este es el caso, entonces su trabajo es responder preguntas DIRECTAS y mantener sus emociones bajo control. Sí, puedes sentirte herido porque no aman tu código, pero mostrar cualquier emoción con los jefes presentes no es algo bueno. Más bien, trate de parecer neutral y deje que los demás manejen la sesión.

Ahora, si "te cuelgan para secar", entonces recomendaría las siguientes preguntas:

a) "OK. Ya veo. ¿Para qué exactamente siente que es de sentido común incluir esta función? Me gustaría descubrir por qué no la incluimos". (obligarlos a explicar su proceso de pensamiento. El sentido común para una persona rara vez es de sentido común para otra persona).

b) "Bueno, estoy seguro de que podríamos incluir eso en la próxima versión. Dejaré que XXX (los jefes) lleguen a un acuerdo mutuo" (es decir, no hables de costos o regalos con los jefes presentes) . NUNCA.)

De nuevo, esto supone que usted es un programador que TRABAJA para una compañía que entregó el producto. Ahora, si son más que eso, es decir, usted es uno de los superiores, muchas de las sugerencias aquí son excelentes.

Sin embargo, si usted es el más alto o es un programador consultor, entonces primero y más

a) Discúlpese por el proceso que no cumplió con este requisito. Promete trabajar con el cliente para evitar que esto vuelva a ocurrir.

Luego, a las otras estrategias. Realmente no importa si cobra por la corrección o no, la disculpa es la acción más importante para el cliente. Una vez más, vale la pena repetir: no se está disculpando por la función perdida. Se disculpa por el proceso de diseño defectuoso que lo dejó escapar. Los clientes suelen ser muy serviciales cuando comienzas de esta manera y luego buscan una solución.

Aclamaciones,

-Ricardo

No intente hacer que el cliente sienta que es su culpa. Puede ser su culpa, pero hacer que se sientan de esa manera no producirá resultados constructivos, y podría molestarlos.

En cambio, debe darse cuenta de que los clientes solo se quejan del software que usan, en la mayoría de los casos porque les gusta. Nadie se queja por el software que nadie usa. Es inevitable que un cliente se queje del software que entrega, incluso si entrega exactamente lo que solicita. Así que no te preocupes. El software nunca termina.

No puede saber lo que piensa su cliente en su cabeza. Esta situación ocurre a menudo con el cliente que no tiene ninguna experiencia con el proyecto de programación. Lo que sugiero es simplemente mostrarle que el "sentido común" no es muy preciso como respuesta en ingeniería (o programación, si lo prefiere).

Muéstrele otro ejemplo en la vida que le muestre que no puede construir algo que no está escrito. Ejemplo: construyendo una casa nueva, el tipo que construye la casa necesita un plan con todos los detalles ... no pondrá un enchufe eléctrico opcional porque en la sala de estar es más "de sentido común" tener algo más ...

Si no está en la especificación, no está en la especificación. Como desarrollador sin conocimiento específico del dominio, el "sentido común" es un concepto irrelevante. Diferentes industrias trabajan de diferentes maneras y un enfoque puede ser bastante apropiado para un dominio particular pero completamente inaceptable para el otro.

Escribir buenas especificaciones es una forma de arte. OMI, puede adoptar un enfoque ágil de "analista / programador" en el que realice pequeñas iteraciones o escriba y mantenga una especificación detallada e inequívoca . Ambas son tareas altamente calificadas, y aún son iterativas. Aún debe evolucionar la especificación.

De cualquier manera, no es tan fácil como parece y ambos requieren la capacidad de establecer una buena relación de trabajo con el cliente.

Tienes que comenzar desde el principio; Dígale al cliente, temprano y con frecuencia, que las especificaciones / casos de uso / historias de usuarios son un contrato que define qué se entregará. En un entorno ágil, hay muchas oportunidades para que el cliente observe alguna característica de "sentido común" que desea y la solicita, que es una de las ventajas de un enfoque ágil, pero si comienza a aceptar adiciones de "sentido común" en el fin, te estás preparando para infinitas extensiones, probablemente a costa tuya.

Algunos clientes esperan esto; cuanto más y mejor les digas que no pueden, más fáciles serán los argumentos finales.

Como chico junior, me doy cuenta de que todavía no puedes hacer esto, pero una de las lecciones difíciles pero necesarias es que a veces tienes que despedir a un cliente.

Tuve esto una vez. Y afortunadamente no fui yo quien creó el diseño porque ese fue el problema.

Es de vital importancia que la comunicación entre su empresa y el cliente sea lo más perfecta posible. Asegúrate de que te entiendes. Haga preguntas y permítales hacer preguntas. No dejes que nada se abra en el diseño. Este será el punto problemático en la entrega. Y tener reuniones regulares durante el proyecto (preferiblemente con una presentación preliminar).

Desafortunadamente, muchos desarrolladores son malos en la comunicación, y muchos clientes no son conscientes de sus propias necesidades. Pero si puede minimizar la brecha, se ha encontrado un cliente feliz (y que regresa).

Utilice enfoques tipo SCRUM para evitar esta trampa mortal: involucre al cliente en el proceso de desarrollo de manera temprana, con frecuencia y en comités informales y restringidos -> reducción de riesgos y agilidad mejorada.

ZiG, he tenido que lidiar con este problema en varias ocasiones en mi lugar de empleo actual. Mi grupo (3 desarrolladores) intenta abordar las cosas de forma Agile. Estamos acostumbrados a recibir solicitudes a mitad de camino e incluso de último segundo (que luego trataremos caso por caso).

Sin embargo, dejamos en claro que los recursos (particularmente el tiempo) son limitados y, si no están en la especificación, no podemos hacer promesas. Si se considera importante y no cabe en la versión actual, generalmente planeamos una versión de seguimiento. Si no es importante, va en una lista.

Una cosa que he encontrado es que puede hacer que los usuarios acepten Spec S en el tiempo T. Sin embargo, en Time T + N, hacerles recordar que aceptaron Spec S, o lograr que reconozcan que lo hicieron (con el documentación que has estado guardando, ¡espero!) puede ser más complicado de lo que debería ser.

Aprendes : todo está aprendiendo y nada es personal.
Somos expertos en nuestra área, sabemos mejor que el cliente lo que necesita. Y la próxima vez para el próximo cliente sugeriremos todas las funciones útiles por adelantado y lo haremos feliz y le haremos pagar más dinero porque somos expertos y sabemos mejor.

Cliente: ¡podría haber incluido esto!

Nosotros: ¡ No estaba en la especificación!

Cliente: ¡Sentido común!

Nosotros: no intentamos ir más allá de lo que el cliente especificó; seguimos las especificaciones. Es tan importante NO implementar las características no especificadas como lo es implementar las características especificadas. Nunca adivinaremos a nuestros clientes, quienes valoran el hecho de que pueden depender completamente de nosotros para implementar correcta y completamente la especificación a tiempo y por debajo del presupuesto.

Como otros señalan con razón, la situación casi siempre es más compleja que el simple intercambio que describí anteriormente.

Sin embargo, lo anterior es válido si el implementador tiene una especificación con la firma del cliente que esencialmente implementa un acuerdo que dice "una vez que el software implementa de manera demostrable todas las características en la especificación, entonces se considera completo", y cualquier cosa adicional está fuera del especificación y por lo tanto fuera del contrato.

El contrato en sí también puede tener algo de información: si no tiene un contrato firmado que no importe lo que figura en la especificación, todo lo que hasta ahora se ha hecho en un apretón de manos, y todo el trato (incluido el pago) puede baje al baño en función de cualquier insatisfacción en ambos lados.

Pero si tiene un contrato y una especificación, y el cliente ha visto y firmado ambos, entonces no tienen espacio para pedirle que vaya más allá.

Ahora, en cuanto a la cuestión de si debe implementarlo:

¡INCREÍBLE! Usted entregó un producto y solo tuvieron una queja. Implemente la función, llámelo gratis (asegúrese de que entienden que está trabajando fuera de la especificación y contrato y explícitamente envíeles una factura por el trabajo con el descuento que se muestra en dólares) y pídales que firmen el proyecto como un todo .

Demuestrará explícitamente que el proyecto ha finalizado, que cumplió su deber más allá y que cualquier otra "sorpresa" está fuera del contrato / especificación, lo que le proporciona una buena capa de protección más allá de lo que ya tiene (ostensiblemente) tener.

Si se trata de un problema de UI, entonces estás en aguas turbias.

¿Las especificaciones describen adecuadamente la IU? ¿Tiene maquetas? No culparía a un cliente por este reclamo sobre la UI si la especificación no describía muy de cerca el diseño, el uso y las maquetas.

De cualquier manera, creo que puedes entender la posición del cliente: si no han jugado con las maquetas de la interfaz de usuario, estarán decepcionados con el resultado, no hay forma, psicológicamente hablando, de que tú y tu cliente puedan posiblemente tenía la misma idea en mente (¡no importa el hecho de que el sentido común no lo es!).

Francamente, si esta es la primera vez que el cliente ha pensado en verificar la interfaz de usuario antes de que el trabajo haya finalizado, es al menos parcialmente su culpa por no explicarles los buenos procesos de diseño de la interfaz de usuario. Esta es una característica clave de su aplicación, y está estrechamente relacionada con lo que han imaginado: nadie puede estar satisfecho en tal situación a menos que haya "desarrollado" su representación interna a lo largo del tiempo para que coincida con lo que es la realidad.

Esta desconexión se resuelve solo a través de frecuentes pruebas de usuarios y clientes, que obviamente no se encuentran. Este es un problema con respecto a la educación y comunicación del cliente, no si se cumplió o no con la especificación.

-Adán

Qué debes hacer para evitar esta situación:

Especifique explícitamente qué se incluirá y qué no se incluirá.

El problema probablemente se reduce a las partes no especificadas de la especificación:

El cliente piensa que debería haber algo no especificado, es decir, estaba implícito.
El desarrollador piensa que las cosas no especificadas no deberían estar.

Para futuras especificaciones que tenga, debe tener una instrucción catch all, que indique explícitamente que si algo no está especificado en este documento, puede hacerse después de que la especificación original se haya realizado a un costo adicional.

Qué debes hacer en la situación actual:

Además de aprender de sus experiencias, debe llegar a un compromiso con el cliente.

Ejemplo: Haré esta característica que consideras de sentido común, pero para todas las adiciones / cambios futuros deberá especificarse explícitamente.

Es decir, tendrá que hacer un poco más de trabajo, pero vale la pena a cambio de la captura de todos los acuerdos explícitamente especificados en los que entrará su cliente.

Mala especificación?

¿Era necesariamente una mala especificación? No.

Es imposible mencionar todo lo que sus clientes pueden esperar, por lo que es fundamental tener esta declaración de catch all anteriormente mencionada de forma clara y explícita en su espec. / Contrato.

Otras formas de reducir el problema:

Involucre al cliente temprano, muéstrele los primeros prototipos. Incluso si no lo exigen.
Trate de no venderle al cliente un producto final, sino más bien un servicio para trabajar en su producto.
Considere un modelo de desarrollo ágil o algo similar para que las tareas estén bien definidas, sean pequeñas, pagas e indiscutibles.

Espere cambios de alcance de último minuto: siempre suceden, así que prepárese.
Revise el progreso con frecuencia con el cliente, para minimizar las sorpresas.
Contrato: especificación funcional, más tiempo y materiales con límite inicial (para que el cliente sienta el control). Luego, cuando aparezcan los cambios, renegocie el límite si es necesario.
Nunca digas que no pueden tener lo que quieren. ¡Pueden obtener esa respuesta gratis!
Siempre dales un poco más de lo que pidieron, para que sepan que tienes una actitud positiva.
Relacionarse con el cliente como si estuviera en el mismo equipo que ellos. No acepte ser legalmente pintado como un adversario.
Pueden pensar que los contratistas no son leales, en comparación con los empleados. Demuéstrales que estás tan dedicado a su éxito como sus empleados, y harás un esfuerzo adicional.