Trabajar con clientes que no saben lo que quieren.

Recientemente comencé un trabajo que me tiene trabajando en un sistema existente. Requiere ajustes y actualizaciones, así como un nuevo código. He realizado varios proyectos de mantenimiento / adición de características ahora, y varios de ellos han terminado siendo significativamente diferentes de lo que realmente se solicitó. Entonces, tuve que programar el artículo varias veces para llegar al lugar que el solicitante quería.

Ahora, no me importa reprogramar la función si eso es lo que hay que hacer. Sin embargo, me gustaría disminuir el tiempo de respuesta en mis proyectos. El cuello de botella parece estar en la percepción del solicitante de lo que hay que hacer. ¿Tiene alguna idea sobre lo que podría hacer para averiguar qué necesita el solicitante más rápidamente?

Algunos puntos de consejo:

• Escuche los problemas, no las soluciones . A muchos clientes les gusta decirte cómo resolver sus problemas. No los escuches. Usted es el programador y es su trabajo encontrar soluciones a los problemas. En su lugar, escuche qué problemas tienen los clientes y descubra la mejor manera de resolverlo. Como han dicho otros, los clientes realmente no saben lo que quieren, a veces hay que mostrárselos primero.

• Hacer preguntas . Cuando haya terminado de hacer preguntas, haga un poco más. Los clientes rara vez reciben detalles, ya que realmente no piensan en ello. La única forma de obtener la información que necesita es extraerla.

• Ponga las cosas por escrito Dependiendo de la situación con el cliente, esto puede ser realmente importante más adelante cuando empiecen a quejarse de cómo lo que entregó "no es lo que pidió". y si nada más, escribir especificaciones detalladas puede ayudarlo a asegurarse de tener toda la información que necesita y a aclarar las ambigüedades entre usted y el cliente.

• La comunicación es clave . no solo hable con el cliente, obtenga información, elimine algún código y no le hable hasta que termine. Mantente siempre en contacto con el cliente. Haga preguntas durante todo el proceso. muéstreles el progreso que ha realizado y obtenga comentarios. A la larga, facilitará la vida de todos.

Casi cualquier libro de autoayuda que recoja sobre comunicación le dará alguna variación de esto:

• Busca primero entender, después ser entendido

Eso viene del libro de 7 hábitos, pero todos son una variación del método de " escucha activa ". El objetivo no es solo comprender, sino comunicarles lo que usted entendió.

Una vez que creo que tengo una buena idea de lo que necesitan (manténgase alejado de lo que quieren, especialmente si comienzan a describir los detalles de implementación, ese es su trabajo, no el suyo), les doy ejemplos de historias de varias personas que usan el sistema, y ​​veo si que bromea con ellos.

Luego lo implemento, esperando que una vez que vean la función, se den cuenta de que no es exactamente lo que quieren. Mantén todo flexible. Lo único constante es el cambio. Por lo general, la mayoría de los bordes ásperos se resuelven después de la segunda actualización rápida después de la inicial, pero siempre encuentro que me estoy acercando asintóticamente a un ideal que nunca puedo alcanzar. Eventualmente, debe dejar ir las cosas sin importancia y pasar a objetivos de mayor valor.

Siento tu dolor....

La mala noticia es: dependiendo de exactamente con qué tipo de clientes está tratando, esto podría ser lo de siempre.

Un problema general común es básicamente que los clientes no saben lo que quieren . Usualmente saben lo que quieren lograr, en términos de un objetivo comercial, pero a menudo no tienen idea de cómo debería verse en términos de la solución de software. Entonces, en muchos casos, se encontrará en este ciclo iterativo en el que un proyecto rebota cinco veces más que la estimación inicial, porque el cliente cambia de opinión y quiere que la solución se modifique y modifique. Y sí, no es inusual que el resultado final se transforme en algo completamente diferente a cómo se veía el objetivo inicial.

Tuve un ejemplo épico de que esto sucedió hace un par de años: un proyecto que inicialmente tardó 10 semanas en codificarse se convirtió en una rutina de repetición de 15 meses. En ese caso, se debió principalmente a que los diferentes gerentes y departamentos de la empresa cliente querían cosas diferentes, por lo que siguieron enviando el trabajo, para que se modificaran y se modificaran nuevamente (nuestro software está basado en suscripción y este era un cliente importante, por lo que este no era una piel financiera de nuestra espalda, solo una gran molestia técnica realmente).

Así que básicamente mi consejo es este:

Si así es su industria en particular y estos clientes (eso es un gran FI), simplemente acostúmbrese. Piense en ello como un trabajo ágil y orientado al mantenimiento (así es mi trabajo actual, más o menos). :)

Si esta no es la forma en que deben hacerse las cosas, y usted es el culpable de los largos cambios, entonces hable con sus jefes. Explíqueles que hay problemas de comunicación y que las especificaciones que le llegan de los clientes no son lo suficientemente claras para que pueda implementar la solución deseada. No desea encontrarse en la situación en la que está culpando por no dar a los clientes lo que quieren, si no obtiene toda la información requerida para darles lo que quieren.

En primer lugar, debe aceptar el hecho de que los clientes realmente no saben lo que están buscando hasta que lo ven. Es posible que en este momento le digan que necesitan la función X. Muéstreles la función X y se darán cuenta de que lo que realmente necesitan es la función Y u otra variación de la función X.

Una buena manera de descubrir lo que el cliente realmente quiere más rápidamente es abrazar y seguir el Manifiesto Ágil , que se centra en la comunicación y la colaboración con el cliente. Divida el ciclo de desarrollo en iteraciones y muestre al cliente un prototipo de la característica en cada extremo de la iteración. De esa manera, obtendrá comentarios inmediatos y los cambiará, de acuerdo con los comentarios del cliente, sin tener que invertir demasiados recursos en la función. De esa forma, tanto usted como el cliente estarán contentos con el resultado del producto.

Estoy bastante seguro de que la transición será difícil para su equipo o su empresa, pero es una de las mejores maneras de hacer frente a los requisitos que cambian rápidamente.

Muchas, y muchas historias similares se pueden encontrar aquí . Nunca, incluso trabajando como subcontratista para otra empresa de desarrollo, encontré un cliente que supiera exactamente lo que quería.

Estoy lo suficientemente feliz de trabajar con alguien que tiene una muy buena idea de lo que NO quiere o quiere evitar. Por lo general, puedo trabajar desde allí para hacer algo con lo que estén contentos.

Sin embargo, mi experiencia es principalmente en el desarrollo de aplicaciones / plataformas. Afortunadamente, rara vez tengo que lidiar con problemas de estética como lo hacen los diseñadores web.

Después de muchas reescrituras molestas, ahora opero lo que llamo divulgación completa.

Entonces, después de discutir los requisitos y deseos de los clientes, siempre escribiré lo que percibo que quieren y cómo procederé para cumplir con ese requisito. Luego les enviaré lo que he escrito y esperaré hasta que respondan afirmativamente antes de comenzar a trabajar.

Si se trata de un proyecto grande (más de 5 días de trabajo), también haré un prototipo. Esto les da la oportunidad de cambiar de opinión sin grandes cambios de código a mi fin.

No siempre funciona, pero al menos estoy en una posición en la que el cliente sabe que están cambiando de opinión y no yo implementando incorrectamente.