Una de las personas de las que más he aprendido fue el primer jefe que tuve en mi organización, de hecho como he comentado en algún que otro artículo buena parte de las forma en que hago las cosas vienen heredadas de él, otras no, bien porque no estuve el tiempo suficiente con él (se marchó a otro sitio con un puesto mejor), porque con el paso del tiempo uno entiende las cosas de manera distinta o bien porque los caracteres son diferentes.
Ya comenté también en este blog un comentario que me hizo una vez y que era que ante cualquier problema con un tercero que afectase a su departamento el principal culpable iba a ser él y que él daría la cara y que ya internamente se encargaría él de depurar las correspondientes responsabilidades.
En lo que a los proyectos de desarrollo de software se refiere, yo comparto totalmente su perspectiva. De cara a los usuarios, si yo soy el responsable técnico del proyecto, si el problema es de índole informática (sea cual sea) el responsable soy yo, para lo bueno y para lo malo. Después tocará repartir elogios (o entregarlos por completo, ya que acumular elogios no produce ningún tipo de interés y transferirlos completamente al equipo de colaboradores y equipo de proyecto sí que produce buenos resultados) o repartir responsabilidades, ya que una cosa es que se dé la cara aún sabiendo que la mayor parte de la culpa no es tuya y otra es que no tenga consecuencias este hecho.
Comerse estos marrones está en el sueldo y es parte de la responsabilidad de los que tenemos asignadas este tipo de tareas. Muchas veces se será injusto con nosotros y no se valorará adecuadamente el trabajo que se ha realizado o se nos echará las culpas de cosas que no son responsabilidad nuestra. Cuando esto sucede nos tocará explicarnos, dar nuestra versión y tratar de ofrecer soluciones (si todavía es posible), si aún así (y teniendo razón nosotros) no se atiende a razones y surgen conflictos, no se soluciona con poner el ventilador y aplicar la misma injusticia con el equipo de proyecto y el equipo de personas que han colaborado contigo en el proyecto, tocará tragar y punto. Asumir esto no es fácil, pero una vez que se hace se gana mucho respeto y credibilidad, tanto por parte de quiénes trabajan contigo como por la parte que no está de acuerdo con lo que se ha hecho, ya que estos últimos se dan cuenta de que no se quiere evadir la responsabilidad y se da la cara.
Hay un aspecto que quiero dejar claro y es que no se trata de tragar por tragar, ya que si se hace así no se ganará respeto, sino que muchos lo interpretarán como una debilidad. Lo que quiero decir es que hay que intentar explicar las cosas, aunque no se entienda por parte del interlocutor y este nos muestre su disconformidad y respetar (aunque no se comparta) lo que se nos diga, ahora bien, esto no quiere decir que se deba decir a todo que sí, ya que hay que dejar claro cuáles son los límites y éstos deben ser fijados por nuestra responsabilidad real en el problema y por nuestra estrategia de cara al interlocutor (lo mismo puede interesar, relajar los límites o eliminarlos, ya sea porque sea un buen cliente o porque haya otros aspectos en juego). Poner límites puede significar fuentes de conflicto, pero si no se hace, más adelante en este proyecto o en otro, volverá a pasar lo mismo y las consecuencias serán las mismas, entrando en un bucle nada beneficioso.
Jummp 