Cambiando la forma de trabajar con un cliente

En la empresa donde trabajo, en una época hubo un contrato con una empresa para la cual se le suministraban doce desarrolladores y ellos estaban en contacto cliente con los líderes del cliente, que estaban en Estados Unidos.

Esta modalidad de trabajo fracaso, debido al bajo nivel de inglés de los desarrolladores, a la baja capacidad de comprensión que tenían ante los pedidos del cliente, y a las expectativas fallidas sobre el conocimiento o seniority del equipo de desarrollo.

Ese proyecto no fracaso del todo, ya que los clientes eligieron solo dos desarrolladores, tal vez no los mejores, pero si los que estaban siempre, los bomberos en realidad.

El problema fue la forma con que se encaro este contrato. Darle contacto al cliente a desarrolladores sin experiencia no fue buena idea.

Les dejo parte del mail donde proponía una nueva forma de trabajo luego de la reducción de personal pedida por el cliente, ya que me pidieron a mí que diera una charla de buenas prácticas y de trabajo organizado a los que quedaron afuera, para que entren en otros proyectos:

Luego de dar la charla y escuchar el “feedback” de los chicos, estuve pensando una forma de que lo de este cliente llegase a funcionar, aunque no sé si es tarde. El tema importante es que todos los procesos presentados son muy lindos y todos más o menos los entendieron, pero necesitan a alguien que los guie en su uso, los aliente y los ayude.

En mi humilde opinión, me parece que lo mejor sería tener un PM local, que se abstraiga de todas las tareas de desarrollo (esto lo recalco y me parece muy importante), y sea el punto de contacto de los PMs del cliente, para que ellos minimicen o completamente anulen el contacto con los desarrolladores.

Además de ser el dueño de los requerimientos y tener una idea general de todos los sitios, crearía una base de conocimiento de todos estos proyectos, en trac podría ser, y alentaría y ayudaría a los desarrolladores que lo ayuden a llenarlo, con cualquier cosa que pueda hacerle la vida fácil a alguien en el futuro que tenga que arreglar algo o agregar nueva funcionalidad en el sitio.

Otra de las ventajas que tendría esto, seria aislar a los desarrolladores de las dudas y tareas que mandan los PM del cliente,, ya que escuche que a veces no están muy al tanto de lo que hacen. Esta persona, podría filtrar estas cosas, evitando posible retrabajo en el futuro. También seria alguien que se comiese la presión de los PMs, para que el equipo de desarrollo este más tranquilo. Digamos que transmitiría las tareas con tranquilidad y cordialidad, y seria alguien que defienda al equipo de desarrollo.

Tal vez esto sea muy caro y el cliente no lo acepte, pero hay que hacerles entender que tendrían una “knowledgebase” muy importante de todos sus proyectos, y otras cosas como métodos, passwords, etc. Supongo que es una posible solución.

La historia continua con que el cliente contrato unos rusos, y están muy contento con su desempeño. Se mantuvieron a los dos desarrolladores acá, pero no se logro aumentar el tamaño del equipo.