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

https://stackoverflow.com/questions/315097

10-07-2019
|

Pregunta

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 responde en esta situación?

Solución

Qué debe 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 cree que deben estar incluidas cosas no especificadas, es decir, implícitas.
El desarrollador piensa que las cosas no especificadas no deberían estar incluidas.

Para las especificaciones futuras que tenga, debe tener una declaración catch all, que explícitamente indique que si algo no se especifica en este documento, se puede hacer después de que la especificación original se haga a un costo adicional.

Lo que debe hacer en la situación actual:

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

Ejemplo: Haré esta función que usted cree que es de sentido común, pero para todas las adiciones / cambios futuros tendrá que especificarse explícitamente.

I.e. 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 que su cliente firmará.

¿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 que esto abarque todas las declaraciones mencionadas anteriormente de forma clara y explícita en su especificación / contrato.

Otras formas de reducir el problema:

Involucre al cliente temprano, muéstreles los primeros prototipos. Incluso si no lo exigen.
Intente 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.

Otros consejos

Esta sería una de las muchas razones por las cuales cambié a una filosofía Desarrollo ágil . La única forma, en mi opinión, de evitar con éxito este escenario es ser omnisciente o involucrar al cliente en gran medida y liberarlo temprano / liberarlo a menudo para obtener comentarios lo antes posible. De esa manera, puede desarrollar el software que el cliente realmente quiere, no el software que el cliente le dice que quiere.

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 ha especificado el cliente; seguimos las especificaciones. Es tan importante NO implementar características no especificadas como implementar funciones especificadas. Nunca dudaremos de 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 es casi siempre 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 comprobable todas las características en la especificación, entonces se considera completo" y cualquier cosa adicional está fuera de la especificación y, por lo tanto, fuera del contrato.

El contrato en sí también puede tener algún aporte aquí, si no tiene un contrato firmado, no importa lo que contenga la especificación, todo hasta ahora se ha hecho en un apretón de manos y todo el trato (incluido pago) puede ir 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 margen de maniobra para pedirle que vaya más allá.

Ahora, en cuanto a la pregunta de si debe implementarlo:

AWESOME! Usted entregó un producto y solo tenían una one queja. Implemente la función, llámela 'regalo de promoción' (asegúrese de que entiendan que está trabajando fuera de las especificaciones y del contrato y envíeles una factura explícita por el trabajo con el descuento que se muestra en dólares) y pídales que firmen el proyecto en su conjunto. .

Demostrará explícitamente que el proyecto ha finalizado, que usted fue más allá del cumplimiento del deber, y que cualquier otra 'sorpresa' está fuera del contrato / especificación, lo que le brinda una buena capa de protección más allá de lo que ya está (aparentemente) tener.

Si es un problema de UI, entonces estás en aguas más turbias.

¿La especificación describe adecuadamente la IU? ¿Tiene maquetas? No criticaría a un cliente por esta queja sobre la interfaz de usuario si la especificación no describiera muy de cerca el diseño, el uso e incluye maquetas.

De cualquier manera, creo que puedes entender la posición del cliente; si no han jugado con maquetas de UI, entonces estarán decepcionados con el resultado, no hay forma, psicológicamente hablando, de que tú y tu cliente posiblemente podría haber tenido 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 piensa en revisar la interfaz de usuario antes de que finalice el trabajo, entonces es al menos parcialmente su culpa por no explicarles buenos procesos de diseño de interfaz de usuario. Esta es una característica clave para su aplicación, y está muy unida a lo que han imaginado: nadie puede estar satisfecho en tal situación a menos que hayan 'aumentado' su representación interna con el tiempo para que coincida con la realidad.

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

-Adam

Espere cambios de alcance de última hora: siempre ocurren, así que prepárese.
Revise el progreso con frecuencia con el cliente, para minimizar las sorpresas.
Contrato: Especificaciones funcionales, más tiempo y amp; Materiales con tapa inicial (para que el cliente sienta el control). Luego, cuando lleguen los cambios, renegocie el límite si es necesario.
Nunca diga 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 parte del mismo equipo que ellos. No acepte ser pintado legalmente como un adversario.
Pueden pensar en los contratistas como no leales, en comparación con los empleados. Muéstreles que está tan dedicado a su éxito como sus empleados, y que hará un esfuerzo adicional.

Caso clásico ...

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

Seguro, no puedes rehacer todo gratis.

Dos maneras: O decirles que se apaguen ** o que se encarguen de ello.

Si elige negociar:

Primero, empatiza, respeta al cliente.
Eche un vistazo a lo que se puede cambiar fácilmente.
Echa un vistazo a los contratos.
Quizás crear un nuevo acuerdo.
No hagas demasiado.
Haz que vean el progreso y el trabajo que lleva.
Encuentre soluciones para las funciones que faltan (tal vez utilizando otras funciones excelentes o herramientas disponibles)

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

Este es uno de los muchos inconvenientes de un acuerdo de oferta fija. Cada vez que cambian las necesidades o prioridades de la empresa, o incluso hay un simple malentendido, resulta en una situación incómoda como esta para llamar a abogados. Si tiene un acuerdo en el que le pagan por el tiempo de desarrollo, siempre puede reaccionar ante cualquier cambiar y recibir el pago por el tiempo que sea necesario para realizar ese cambio. Además, tener un acuerdo por horas no impide tener un plan o hacer una estimación.

Sin embargo, una vez que se encuentre en una oferta fija, sus opciones son: 1) Hazlo 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 tiene problemas más grandes. En ese punto, solo trata de evitar los laywers.

Un punto final: cualquier proyecto que tenga algo conocido como "La fecha de entrega" inevitablemente se encuentra 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 una liberación del producto al mismo tiempo 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 gran cantidad de expectativas. La diferencia potencial entre lo que el cliente está imaginando y lo que realmente existe es mucho menor. Sin sorpresas.

Buena suerte.

" ¿cómo reaccionas? "

Pregunta 1: ¿desea continuar esta relación con este cliente? Seriamente. Si van a afirmar que las características no especificadas son "sentido común", Esto 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 no cumplió y que juegue ese juego. Obtenga criterios de prueba específicos para cada característica que falta. Tire de los dientes. Sea confrontativo al determinar lo que falta. No preguntes por qué. Simplemente solicite todos los detalles por adelantado. Es lento y desagradable. Pero no los quieres de todos modos.

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

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

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

A corto plazo. Consigue algo con lo que estén contentos. Tienen que identificar cambios específicos. Debe puntuar cada cambio con un "costo por hacer" y se ajusta a la especificación.
- Algunas cosas son baratas y encajan bien. Haz eso.
- Algunas cosas son baratas de hacer, pero encajan mal con la especificación. Piénselo dos veces antes de permitir que una especificación incorrecta conduzca al reproceso. En cierto sentido, les compraste la especificación; es posible que también necesite elevar sus estándares.
- Las cosas caras que (lamentablemente) se ajustan a la especificación son un problema. Estás en problemas con estos y tienes que hacerlos.
- Las cosas caras que no encajan bien con la especificación son lecciones aprendidas para todos. Detalle un plan para estos, incluyendo reescrituras de especificaciones y aprobaciones.
A largo plazo. Asegúrate de que no vuelvas a tener PA. Revise temprano y con frecuencia, use técnicas ágiles. Comunicar más, crear prototipos más, liberar más.

Bueno, no se entregó con éxito. En algún lugar 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 inyectado por el desarrollador y que probablemente no se lo culpe al 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 en dominios 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 un problema similar en el futuro.

La forma en que maneja esto puede determinar muy bien 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 empresas optan por renovar totalmente todo lo que hacen, lo cual es un error, creo. Entonces lo está ignorando. Culpar a la gente por el problema también es un error.

Es un buen momento para analizar cómo sucedió esto, cuál es el proceso y tal vez cómo podría haber sido atrapado. No haría grandes cambios en las reglas o cambios en el proceso, pero presentar pautas para el trabajo futuro es una gran cosa. Su empresa tuvo una clara lección sobre una deficiencia. Perder la oportunidad de corregir este problema y corregir su proceso sería una pérdida de una buena oportunidad.

ZiG, he tenido que lidiar con este problema en varias ocasiones en mi lugar de empleo actual. Mi grupo (3 desarrolladores) trata de abordar las cosas de manera ágil. Estamos acostumbrados a recibir solicitudes intermedias e incluso de último segundo (que luego tratamos caso por caso).

Sin embargo, dejamos en claro que los recursos (particularmente el tiempo) son limitados y si no está en la especificación no podemos hacer promesas. Si se considera importante y no puede encajar en la versión actual, generalmente planificamos 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 la Especificación S en el Tiempo T. Sin embargo, en el Tiempo T + N, hacer que recuerden que aceptaron la Especificación S, o hacer que reconozcan que lo hicieron. (¡con la documentación que ha estado guardando, espero!) puede ser más complicado de lo que debería ser.

Hablando sobre el tema y la pregunta del OP:

Si usted es un programador empleado, espero que haya otros recursos en la reunión con usted. Posiblemente " más altos ups " en la organización.

Si este es el caso, entonces su trabajo es responder preguntas DIRECTAS y mantener sus emociones bajo control. Sí, puede sentirse herido porque no aman su 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 a secar", entonces recomendaría las siguientes preguntas:

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

b) " Bueno, estoy seguro de que podríamos incluir eso en la próxima versión. Lo dejaré hasta XXX (los jefes) para que adopten un enfoque de mutuo acuerdo '' (es decir, no hable de costos o regalos con jefes presentes. NUNCA.)

Nuevamente, 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, ERES uno de los superiores, muchas de las sugerencias aquí son excelentes.

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

a) Disculpe 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 solución o no, la disculpa es la acción más importante para el cliente. Una vez más, vale la pena repetirlo: no te estás disculpando por la función perdida. Te disculpas por el proceso de diseño defectuoso que lo dejó pasar. Los clientes suelen ser bastante complacientes cuando comienzas de esta manera y luego buscas una solución.

Saludos,

-Richard

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

En términos de su pregunta literal, ¿cómo reaccionar, la mejor manera es ignorar su ego ("¡¿qué ?! ¡Después de haber trabajado tanto en esto y cumplir con las especificaciones!!") y, en cambio, centrarme en algo activo escuchando y trabajando por consenso.

Cliente: ¡Podría haber incluido esto!

Nosotros: ¡No estaba en la especificación!

Cliente: ¡sentido común!

Nosotros: entiendo que no está contento de que no hayamos ido más allá de 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 " usted dijo / yo dije " combate a muerte. La única forma de resolverlos involucra abogados y luego nadie gana. Si puede aceptar que la especificación o el proceso fallaron, trabajen juntos para solucionarlos.

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

Obviamente, no puede confiar en esto, pero si está seguro de que hizo un buen trabajo y que su software realmente satisfará las necesidades comerciales de las personas que lo contrataron, vale la pena esperarlo. A veces, la reacción inicial del cliente no será la última, especialmente si puede incorporar rápidamente sus preocupaciones.

No intentes hacer que el cliente sienta que es su culpa. Podría ser su culpa, pero hacerlos sentir 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 del software que nadie usa. Es inevitable que un cliente se queje sobre el software que entrega, incluso si entrega exactamente lo que pide. Así que no te preocupes. El software nunca se hace.

Fallo total por parte de la persona a cargo de la recopilación de requisitos, sin duda. 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 cobrarles por la solicitud de cambio.

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

Escribir buenas especificaciones es una forma de arte. En mi opinión, puede adoptar un enfoque ágil de 'analista / programador' donde realiza pequeñas iteraciones o escribe y mantiene un especificación detallada, 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.

No puede saber lo que piensa su cliente en su cabeza. Esta situación ocurre a menudo con clientes que no tienen experiencia con proyectos de programación. Lo que le sugiero es que simplemente le muestre que el "sentido común" no es muy precisa como respuesta en ingeniería (o programación si lo prefiere).

Muéstrele otro ejemplo en la vida que le mostrará que no puede construir algo que no esté escrito. Ejemplo: al construir una casa nueva, el tipo que construye la casa necesita un plan con todo detalle ... no pondrá un enchufe eléctrico opcional porque en la sala de estar es más '' sentido común '' tener algo extra ...

Tuve esto una vez. Y afortunadamente no fui yo quien creó el diseño porque ese resultó ser 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 entenderte. Haga preguntas y deje que hagan preguntas. No deje que nada se abra en el diseño. Este será el punto problemático en el momento de 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 convertido en un cliente feliz (y que regresa).

Es por eso que yo / los equipos con los que trabajé siempre usamos un enfoque prototipo-estilo , eso significa:

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

Tienes que comenzar desde el principio; dígale al cliente, temprano y con frecuencia, que las especificaciones / casos de uso / historias de usuario son un contrato que define lo que se entregará. En un entorno ágil, hay muchas oportunidades para que el cliente observe algo de "sentido común". característica que desean y la solicitan, que es una de las ventajas de un enfoque ágil, pero si comienza a aceptar "sentido común" adiciones al final, te estás preparando para extensiones infinitas, probablemente a tu costa.

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

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

Usted aprende : todo es aprendizaje 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 características útiles de antemano y lo haremos feliz y le haremos pagar más dinero porque somos expertos y sabemos más.

Licenciado bajo: CC-BY-SA con atribución

No afiliado a StackOverflow