por José Alberto Hernandis, 18 julio 05

Un día se recibe una llamada en una empresa de software, un posible cliente quiere que les desarrollen un sistema de gestión a medida. El trabajo recae en un programador, que durante un tiempo trabaja codo con codo con los responsables de la empresa cliente, se desarrolla el sistema y se pone en marcha. Pasa el tiempo y por diversas circunstancias el programador deja la empresa. Se pone a trabajar por su cuenta, se hace autónomo, tiene unos cuantos clientes, la cosa va funcionando, unos meses después recibe una llamada de uno de los jefes de la empresa cliente para la que hizo el desarrollo a medida, le pedía que fuera a hablar con ellos, se acerca al día siguiente y le piden que desarrolle un nuevo sistema. El programador se extraña, ¿como una empresa que tiene un cierto tamaño decide que un sólo programador les desarrolle el sistema que gestionará la empresa? La respuesta: implicación.

Lo que hizo a dichos directivos seleccionar al programador independiente respecto a otras soluciones, empresas grandes del sector, no fue el coste (aunque tuviera su importancia), no fue la capacidad técnica (que ya la había demostrado), fue que era una persona que se implicaba en lo que hacía, que entregaba más de lo que se le pedía, que no se limitaba a hacer lo correcto si veía que podía hacer más por su cliente.

Eso lo encuentro a faltar en muchos “profesionales”, y lo pongo entre comillas, no veo implicación, no veo pasión por lo que se hace, veo mediocridad muchas veces, no tanto en los conocimientos, si no en las formas, en vivir lo que se está haciendo.

Muchos programadores devoran libros, hacen decenas de cursos, conocen todos los recovecos de los lenguajes que manejan, las librerías, los sistemas, pero no conocen a sus clientes, a sus usuarios, viven en su jaula de cristal, no son capaces de ponerse en la piel de quien va a utilizar su aplicación, de entender porque se le pide una cosa y no lo que técnicamente sería más acertado, no entienden que al cliente puede que eso le de igual, que lo que desea es que comprendas lo que necesita y que seas capaz de plasmarlo en un programa, da igual que hayas hecho doscientos diagramas UML, cincuenta E/R, trescientos diagramas de estado, si al final la persona que va a manejarlo no encuentra lo que esperaba.

Desde hace unos años se está consolidando el desarrollo ágil donde se aboga por centrarse en las necesidades de las personas, en fomentar la participación del usuario en el diseño de la aplicación, en acercar al programador a la realidad del cliente. Todo eso, para mi es implicarse más en lo que uno está haciendo.

Recomiendo seguir las indicaciones de los métodos ágiles, es difícil hacerlo al pie de la letra, pero sí es posible adoptar algunas prácticas para mejorar la relación con el cliente y conseguir que se sienta parte del desarrollo, aunque lo que propongo yo es que también el desarrollador se sienta parte del cliente.

Prácticas recomendadas:

• Trabajar dentro del cliente, es decir, físicamente estar en casa del cliente, al menos un periodo de tiempo, por ejemplo 2 días a la semana.
• Informar continuamente al cliente de los progresos y de los problemas, establecer una comunicación plana y directa.
• El cliente debería participar en todas las reuniones que afecten a su proyecto.
• Entregar revisiones y mejoras de forma periódica y constante, que el cliente note que se le hace caso y que las cosas se resuelven rápidamente.