Cuando vi esta escena de la grandísima serie que es Halt and Catch Fire tuve que sobreponerme a las ganas de empezar a aplaudir, esta serie que en muchos momentos recoge lo mejor del mundo tecnológico lo había vuelto a conseguir y si a eso le sumamos este artículo que leí hace poco (los programadores son más importantes para las empresas que los directores de TI) la cosa se pone aún mejor.
Esta escena muestra bastante bien lo que muchos desarrolladores piensan sobre sus jefes de proyecto y posiblemente los jefes de proyecto pensarán aquello de “si te digo todo lo que pasa que no te quiero contar…”, esta situación acaba llevando a un sutil enfrentamiento y sectarismo entre “gente con traje vs gente sin traje”.
Siempre ha existido un miedo irracional hacia lo desconocido que confunde y a menudo irrita al ser humano haciéndole tomar actitudes que generalmente no son muy correctas o sensatas, más o menos la actitud que toma un jefe de proyecto ante un grupo de desarrolladores cuando estos le intentan explicar algo, generalmente el jefe de proyecto no es técnico -ni intención que tiene- solo le interesa saber cuándo se va a entregar algo y que no le engañen diciendo cuatro meses cuando pueden ser tres.
De todas formas, ante la duda el jefe de proyecto siempre sacará alguna queja –puede que sin demasiado sentido- y de paso te quitará dos semanas, -que seguro que ya será menos el tiempo que hace falta-, lo que el jefe de proyecto no sabe es que ante esto la próxima vez el desarrollador le meterá un mes más, como el lazarillo de Tormes si tu coges dos uvas yo cojo tres, pero no nos decimos nada, -y la rueda del absurdo sigue girando-.
Tomando una actitud “zen” -que llegado cierto punto es la mejor opción- la respuesta fácil sería decir, las probabilidades de que un proyecto se cumpla en plazo es inversamente proporcional a su tamaño, es decir que si dices que entregas en una semana puede que sea verdad, pero si dices que entregas en un año, seguro que al final es año y tres meses.
En cualquier caso esta sensación de “no sé qué me han contado” del jefe de proyecto también la tiene el cliente, el jefe de proyecto que no se acaba de enterar muy bien le habla a su cliente sobre el proyecto -y le transmite esta inseguridad-, este acaba haciendo lo mismo, realmente no se está enterando muy bien de que le están hablando pero tampoco va a parecerlo así que plantea dudas, quejas y plazos que igual no tienen nada que ver con el proyecto, y en particular con lo que el cliente realmente necesita -pero llegado ese punto el jefe de proyecto hace un «si a todo»-, lo cual se traslada finalmente al equipo de desarrollo que se queda pensando aquello de “hay días que no se para que me molesto”, -el grado de frustración pasa de lineal a exponencial-.
Algunos dirían que esto se arregla con un jefe de proyecto con antecedentes tecnológicos, el problema es que la tecnología avanza a veces demasiado rápido y es fácil quedarse atrás y acabar volviendo al punto anterior encima con la idea de “yo que fui desarrollador…” el desenlace final suele ser aún peor.
Sin embargo hay matices, depende de la empresa, del cliente, con quien trabajes… es posible que los plazos se puedan mantener y todo vaya bien, pero si la empresa no es muy grande y no tiene capacidad negociadora, o el cliente es demasiado importante o el presupuesto escaso… entonces los plazos se piden por cortesía pero es probable que acaben siendo otros –y volvemos al primer punto-.
Hace algún tiempo desde una empresa me contactaron para un proceso de selección que necesitaba a una persona que sirviera de enlace entre el equipo de desarrollo y el de gestión, que fuera capaz de “entender” a los programadores y luego “traducir” todo eso en plazos y tiempos de forma razonada, algo así como “no sé si los desarrolladores me engañan o es verdad, pero tengo que dar una fecha y plazos que tengan sentido y se cumplan».
Yo he de reconocer que me alegré, no porque me hubieran contactado –que también- sino que por fin después de años alguien se había dado cuenta que hace falta “un intermediario” que sea capaz de hacer ese trabajo, que por un lado sea técnico –generalmente de buen nivel- y ejerza como tal pero que también entienda que los proyectos se hacen para entregarlos y sea capaz tanto de trasmitir esa idea al equipo, así como a su vez transmitir a gestión por parte del equipo aquella gran frase de “nueve mujeres no paren en un mes”.
De hecho, yendo más allá en los últimos tiempos he tenido ocasión de observar empresas creadas solamente por desarrolladores y aunque es verdad que hace falta gente de todo tipo en una empresa- la verdad es que les está yendo muy bien.
Quizás lo que algunas empresas necesitan es un perfil así, no solo mejorarían su productividad, sino que la empatía entre “gente con traje vs gente sin traje” aumentaría, lo que posiblemente es el mayor beneficio.