Como programadores constantemente nos vemos en la necesidad de tratar con diferentes tipos de clientes, si bien una de las más importantes tareas es realizar las preguntas correctas acerca de la problematica del mismo, hay muchas veces o al menos a mi me han tocado muchas veces en las que, el cliente no tiene una idea clara de lo que en verdad quiere con su proyecto.

Ejemplo de los problemas que conlleva una mala especificación

Sabemos muy bien que para hacer nuestro trabajo tenemos que tener claro lo que el cliente quiere, y según sus peticiones, hacerle sugerencias de lo que le conviene usar para esa tarea, pero cuando el cliente no sabe que es lo que quiere resolver, ahí vienen los problemas.

Bien, se que muchos dirán que si el cliente no da toda la información por no saber, siempre podemos sacar nuestras propias conclusiones de como ha de funcionar el proyecto y terminarlo de acuerdo a nuestros propios conocimientos sobre como funcionaría en forma «general».

Que si, que podemos preveer muchas situaciones que pudiera haber querido nuestro cliente y no nos especificó, pero existen tantas posibilidades que, sigo diciendo, no es lo correcto, esos los dejamos como un extra que podemos agregarle y no como funciones primarias del proyecto en cuestión.

Viendo las cosas de esta manera podemos pensar que todo esta bien, pero el mayor inconveniente es a la hora de entregarlo donde pueden ocurrir 3 escenarios:

  1. El feliz : El cliente queda contento con el trabajo y comienza a usarlo.
  2. El modificar, modificar, modificar : «Está bien, pero es que esto en mi empresa funciona diferente, ¿Puedes cambiarlo?», «¿No se puede hacer para que el cliente pueda subir sus archivos?», «¿Le puedes agregar otro campo?»;
    Todos sabemos que muchas veces hacer algún cambio conlleva más tiempo y por tanto más dinero que no se tomó en cuenta en las cotizaciones iniciales, y ahí entra otro problema, y es que quien queda mal parado en esa situación somos nosotros porque no hicimos lo que él queria y le queremos cobrar más por adecuarle nuevas funciones.
  3. El «Esto no es lo que quería» : Creo que el peor escenario de todos donde por una muy mala comunicación o especificaciones terminamos haciendo algo que nosotros creíamos que era lo que el cliente necesitaba pero no es así; lo que de nuevo nos deja muy mal parados a nosotros.

Estas situaciones se presentan muy a menudo y es por lo mismo que siempre prefiero poder hablar bien con los clientes y que me digan exactamente lo que necesitan que haga su proyecto, para que en base a ello pueda hacer un análisis y abstracción del problema, no hablo de preguntarle «Que campos necesita que lleve su sistema», hablo de preguntarle el ¿Cómo quiere que funcione? y en base a esas necesidades buscar la mejor solución.

Con clientes formales esto casi nunca me ha sucedido, pero con muchos otros un poco más informales casi siempre, hasta el punto que llegan a decirme «Hazlo como tú consideres», vamos que comenzamos mal ahí.

 

¿Les ha sucedido algo similar?