Este es un proyecto cancelado que no recibe actualizaciones. No obstante, puedes acceder a su archivo como referencia.

Versión Cero

Más de lo que se espera.

José Alberto Hernandis

La pasión por el trabajo y la implicación con el proyecto es lo que verdaderamente diferencia a un programador excelente de otro mediocre.

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.
Comentarios
1 Albin
18 julio 2005, 11:42

Lo que observo últimamente (quizás es casualidad, quizás por el tipo de trabajo que hacemos Web) y me afecta bastante es que el cliente es el primero que no quiere saber de su proyecto. Se implica si quiere vender comida para animales vía Internet, pero no se implica si la empresa es media-grande y tienen más cosas en la cabeza, como mucho delegan en alguien que con suerte solo añadirá lio … así que “El cliente debería participar en todas las reuniones que afecten a su proyecto” me parece inviable, aunque sería buena idea.
2 martin
18 julio 2005, 12:51

Puf, yo estoy implicado en un proyecto grandísimo, de gran importancia, de mucho, mucho dinero, y a nivel de toda la comunidad autónoma. Tendría mucho que decir sobre esto de personas no implicadas, clientes que se desentienden, y trabajo realizdo por una única persona (ya que ese proyecto lo he hecho única y exclusívamente yo durante los últimos años).

Una de las cosas que más he escarmentado es el trabajo dentro del cliente. Definitivamente, siempre en mi opinión, no -a no ser que sea un simple trabajo de cesión de personal. Si vas a hacer un proyecto desde cero, en mi opinión, el hacerlo en la empresa cliente sólo trae problemas: entras en otro mundo posiblemente con montones de problemas internos, peleas contra diferentes departamentos, pierdes con casi toda seguridad la propiedad de tu software, es muy posible que te “roben” a los empleados que metas en la empresa, etc. etc.

Las reuniones con el cliente son muy importantes y necesarias, como también lo es el visitar de vez en cuando para aprender el modo de trabajar o el contratar gente que esté en ese mundillo con conocimientos de dicho dominio, pero meterse dentro del cliente… cuidadín cuidadín.
3 Juan Palacio
18 julio 2005, 17:00

Hola José Alberto.
La implicación entre el cliente y los desarrolladores es muy importante y, estamos de acuerdo, esa voluntad de implicación en el negocio del cliente no siempre se encuentra en los programadores; pero no me atrevería a decir que es la que marca la diferencia entre los mediocres y los excelentes.
Para mi la excelencia de un programador debe medirse por la calidad de su trabajo.
¿Volarías en una avión cuyo sistema informático de aterrizaje lo hubiera programado fulanito?.
Si dices que sí, sin duda calificas a fulanito de excelente.
Conozco a programadores que son prácticamente autistas con los clientes pero sin embargo me subiría sin dudarlo a un avión programado por ellos.
También conozco a muchos a los que les encanta el trato con los clientes y conocer su negocio, pero que sin embargo no me convencerían para “volar en su avión”.
4 Juanjo Navarro
18 julio 2005, 17:23

(#2) martín, efectivamente ese es uno de los problemas prácticos que se le achaca a la programación extrema, que es difícil que el cliente se implique y eso es algo que tu no puedes controlar.
5 Jose Alberto
19 julio 2005, 07:50

Evidentemente, cada uno “cuenta el baile según le ha ido”.

En los proyectos en los que he participado si que ha habido implicación por parte del cliente, quizás debido a la implicación inicial por parte de los desarrolladores que ha llevado a la otra parte a comprometerse sin darse cuenta.

Martín: Lo de “estar en casa del cliente” no tiene porque ser full-time, con un par de mañanas a la semana, las mismas en las que les podemos entregar revisiones, puede ser suficiente.

Juan Palacio: NO se trata de evaluar las capacidades técnicas del programador, eso ya se comenta, sino de como afronta el trato con el cliente, como un mero trámite o como algo más.
6 martin
19 julio 2005, 09:33

Quiero aclarar que en mi comentario anterior me pongo en el papel de empresa que desarrolla software. Porque a mi me ha ido fantástico en el cliente, porque tenía un horario fantástico, porque me daban una fenomenal formación, porque aprendí muchísimas cosas, etc. etc.

Pero volviendo al tema que tratamos, para una empresa la cosa no es tan sencilla. Meter programadores dentro de un cliente es algo que puede resultar peligroso. Yo soy un gran defensor de las metodologías ágiles, pero usándolas con precaución, porque muchas veces no se ajustan a la realidad empresarial. Por ejemplo, las metodologías ágiles no te dicen que después de meter a tus dos mejores programadores en un cliente, resulta que éstos se van de la empresa porque el cliente les da mejores condiciones; o no te dicen que si haces un proyecto en el cliente, el cliente te podrá presionar más respecto a la propiedad de los proyectos; o que los proyectos que desarrolles tenderán a seguir los intereses del cliente y no los de la empresa; o que tus desarrolladores pueden terminar realizando horas para proyectos ¡incluso de otras empresas externas! porque estén más cualificados; o que … en fin, o que muchísimas cosas del mundo real.

En la actualidad, las dos únicas razones de mundo real que veo para meter gente en el cliente y no buscar otra solución son: meter una “avanzadilla” en ese cliente para sacar más proyectos a posteriori, o ganar dinero en base a vender carne. En cualquier otro caso, las reuniones de 1 mañana que apunta Jose Alberto, podrían ser una solución.
7 Juan Palacio
20 julio 2005, 12:22

José Alberto, creo que das en el clavo en que mantener las relaciones como un puro trámite, sin implicación real, perjudica al proyecto.
Pero a Martín (#2) tampoco le falta razón en los riesgos que ve.
Cuando los proyectos no son grandes y se trata de uno o dos programadores, desde luego, si no se implican mal.
Algo que no tengo muy claro, pero que he probado en un par de proyectos de cierto tamaño, y creo que puede funcionar es implicar en estas funciones la figura del gestor. Gestor de proyecto si se sigue una metodología más pesada, o la de un “scrum master” si se aplica una gestión ágil.
Una persona con perfil técnico/comercial, parte del equipo del proyecto que entre sus responsabilidades está la de la “inmersión” en el problema del cliente. (?)
8 jose luis
21 julio 2005, 17:51

Es un artículo muy interesante, y en gran parte estoy de acuerdo con el. Pero he de decir que, desde mi humilde experiéncia de programador, lo que falla generalmente en el proyecto no es el esfuerzo o implicación del programador o programadores, sino la presencia activa y vinculante de un interlocutor válido por parte de la empresa cliente. En mi caso, estoy “cansado” de que los usuarios “decidan”. Porque el proyecto en cuestión no afecta a un único usuario, pero todos quieren tirar hacia lo que les afecta. El equipo de desarrollo puede proponer una solución que deje contento/descontento a todos, pero funcionará. Pero en última instáncia es el cliente quien decide.
Saludos.
9 Xian
27 julio 2005, 18:17

La verdad es que, como en casi todo en esta vida, la virtud están en encontrar el punto medio.

Los extremos se tocan, y tener al equipo de desarrollo en una burbuja en las oficinas de la empresa tiene tantos inconvenientes como desplazarlos a todos al cliente.
Tal y como comenta Martín lo mejor es un modelo mixto (IMHO), en el cual el analista/jefe de proyecto se desplaza a las oficinas del cliente para la toma de requisitos y seguimiento del proyecto.

Es muy importante que el jefe de proyecto sea capaz de transmitir en ambos sentidos: al cliente la implicación del equipo y al equipo las inquietudes del cliente.

En mi experiencia profesional he sido testigo de más proyectos que fracasan por la falta de implicación del cliente (o aquel en quien delega) que por falta de implicación de los desarrolladores.

My two cents…
10 Jose Alberto
28 julio 2005, 16:19

Lo que expongo en el artículo no se centra exclusivamente en “trabajar dentro del cliente”, eso es una recomendación.

El artículo gira entorno a que el programador se implique en el desarrollo, lo sienta, lo haga suyo, pueden sonar como un discurso típico de motivación, pero es que es real, si los que forman parte del equipo no se implican no se consigue un trabajo excelente, sólo un buen trabajo (cosa que muchas veces es suficiente, no lo niego).
11 elmaska
30 agosto 2005, 18:47

Está clarisimo (siempre que se tenga un mínimo de materia gris y se use en cantidad adecuada junto con el sentido común) que la implicación es la clave del éxito de los proyectos (incluso como diría mi abuelo también para todo en esta vida).

Que la implicación la deba poner el cliente, el/la desarrolladora, la mujer/marido de éste/a es una cuestión de sutilezas. Como dicen los clásicos Fuente ovejuna, y todos a una.

Una lanza quiero romper a favor de los desarrolladores (espero que se me perdone esta predilección) y es que debido a la naturaleza “cuasi” artística o artesanal (ver articulos en este mismo blog sobre el asunto) de su trabajo, la implicación se le presupone (como la valentía al soldado). ¿Acaso el pintor no ama su obra?. Pues en cierta medida los desarrolladores (sean de la tipología que sean) tienden a amar sus “creaciones”.?Y qué es el amor sino implicación?. El cliente, como ente abstracto qu e es, puede ser desde el sr. que pone la pasta (implicación suprema por otro lado) hasta el sr. al que le han soltado el marrón del proyecto de marras (implicación dudosa en función de lo que él gane en un concepto amplio).

Respecto a si dentro o fuera, mi predilección personal es: NINGUNA. Para mí que un proyecto se haga dentro o fuera depende de otras cuestiones inherentes a las tareas del proyecto y no de las personas (disponiblidad de entornos de desarrollo/preproducción/terceros sistemas en casa de los desarrolladores, etc.).

Las reuniones y la comunicación, amén de otras cuestiones citadas dentro del artículo, vienen dadas en función de la implicación, por lo que no entraré a valorarlas.

Y por aportar mi modesta experiencia en este sentido, yo he participado (para bien o para mal) en proyectos que han fracasado y han tenido éxito con involucración y sin ella, desarrollando dentro y desarrollando fuera, con entregas parciales continuas y sin ellas, etc. Así que como dice J.Alberto tomemos su articulo como él dice: recomendaciones.
Acerca - Contacto - Información legal y técnica - Condiciones de uso - Noticias sobre el mundo del Desarrollo de Software.