¿Cuánta información es suficiente?

Question

A lo largo de los años he tratado con algunos clientes que han querido, comprensiblemente, quedarse con el proyecto en todo momento. En la mayoría de los casos no he tenido problemas con eso, pero cuando empiezo a encontrarme con un error, a menudo me resulta difícil explicarles lo que está pasando. Podría entrar en detalles y escribir párrafo tras párrafo de todo lo que sé como desarrollador y todo lo que ha sucedido en mi vida que podría aplicarse aquí, pero eso es sólo una pérdida de mi tiempo y el de ellos. Por lo general, se lo explico a un nivel muy alto, sabiendo que si no lo entienden realmente pero creen que sí, todo se resolverá en un día o dos y no habrá servido de nada.

Eso funciona en la mayoría de los casos, pero a veces me encuentro con un correo electrónico en mi bandeja de entrada que dice algo parecido:

Sabemos que has tenido problemas con este problema, así que hemos hablado con un desarrollador amigo nuestro y le hemos dicho que te has enfrentado a esto, y te ha sugerido que pruebes esto.

Excepto que la explicación que les di era, aunque no era falsa, una forma bastante simplificada de lo que en realidad era un problema legítimo que merecía una reflexión real.

¿Cuánto tiempo hay que dedicar a explicar los problemas a los clientes, frente a resolverlos realmente?

Answer 1

No intente explicar más de lo que el cliente es capaz de comprender, pues de lo contrario la discusión no terminará nunca.

Al fin y al cabo, lo que debe importar al cliente es el impacto:

• ¿cuánto tiempo retrasará esto el proyecto?
• cuáles son las contrapartidas de las posibles soluciones
• cuáles son las soluciones alternativas si el problema no se puede arreglar

En sus conversaciones con el cliente, debe dedicar más tiempo a explicar las repercusiones y menos a los detalles específicos del problema.

Answer 2

Ahora bien, ¿cuánta información es demasiada? Lo ideal sería que los clientes estuvieran al tanto de todo lo bueno que ocurre en el proyecto y no supieran nada de lo malo, como los fallos o los cuellos de botella.

Esto se puede conseguir con algunos clientes, pero no con otros. Yo me encuentro en la misma situación que tú, y cuanto más hablo de los fallos y hago participar al cliente en los detalles de los mismos, más no me califican como experto. Digamos que me califican con un 4 sobre 5.

Así que, si puedes, evita los detalles sobre bichos u otras cosas malas. Si necesitas más tiempo, simplemente diles por qué, y utiliza palabras neutras como "optimización" o "refactorización" o "acelerar las cosas".

Sin embargo, hay casos raros en los que el cliente es también un desarrollador. Y en esos casos, puedes hablar con él sobre los problemas porque esa persona te entenderá, y esa persona puede ser capaz de ayudar también buscando en Google y enviándote buenos enlaces. Es cierto que necesitas la ayuda de un programador para resolver los problemas, pero no necesitas la ayuda de alguien que no sea programador.

Answer 3

No involucres a clientes no técnicos en temas técnicos, a menos que te paguen por ello formarse en temas técnicos .

Invariablemente, te tocará el cliente no técnico con pocos conocimientos y mucho ego. Este cliente te agotará tratando de demostrar lo mucho que sabe. Este cliente es un aspirante a técnico, pero nunca podrás diga que porque el cliente está ayudando a que te paguen las facturas. Hablará, y hablará, y hablará para buscar tu reconocimiento (es decir, para sentirse más inteligente) --- y perderás MUCHO tiempo.

Está bien explicar que tal o cual cosa no funciona correctamente. Pero deja de lado los términos técnicos en la medida de lo posible para que la persona no técnica no se aferre a la jerga y termine sugiriendo que permitas que el hijo/hija del cliente, el "experto en HTML porque tomó una clase en la escuela secundaria", se convierta en un colaborador no deseado de tu producto de trabajo.