archivo

Archivos diarios: diciembre 2, 2009

En un artículo que publicaré más adelante, comentaré mi visión sobre la organización de empresas o equipos de proyecto en estructuras verticales y horizontales. En el presente post me voy a centrar en la necesidad de que el perfil profesional de un determinado empleado no sea un departamento estanco, de manera que si se aprecia que el empleado está capacitado para realizar otras tareas que están por encima de su perfil actual (“permeabilidad vertical”) y/u otras tareas diferentes a las que suele realizar dentro de su perfil (“permeabilidad horizontal”) y las circunstancias de la organización y del proyecto lo permiten, dar la posibilidad a que pueda realizar esas funciones.

El estancamiento en tareas concretas de un empleado, no sólo termina por crearle fustración si ya domina perfectamente las mismas o si siempre se tiene que enfrentar a los mismos problemas, sino que además le supone un bloqueo en su proyección profesional. Por este motivo considero muy importante que siempre que se pueda se le proporcionen a los empleados retos nuevos, tareas que permitan sentirse desarrollados y válidos.

Cuando un empleado se siente fustrado puede pasar que su productividad empiece a bajar o bien que decida buscar nuevas oportunidades profesionales en otro sitio.

He hecho hincapié en el que “siempre que se pueda”, ya que desgraciadamente no siempre los jefes de proyecto, responsables de personal, etc… pueden tener la posibilidad de dar a aquellas personas que están capacitadas para asumir otros retos, el aire fresco que necesitan. Por este motivo, es necesario que los empleados tengan paciencia y entiendan que no siempre las cosas se pueden hacer tan rápido como uno quiere, la duración de dicha paciencia dependerá de la confianza y satisfacción que tenga el trabajador respecto a su organización, compañeros, jefes, etc… y de que se le explique y/o entienda por qué no puede afrontar otras tareas durante un tiempo determinado.

En el mundo del desarrollo de software el trabajo en equipo es esencial, ya que por regla general los proyectos son lo suficientemente grandes como para que trabajen varias personas y además el equipo es extensible a los usuarios que participan en la definición del proyecto y en el caso de que se haya externalizado el desarrollo a los técnicos que controlan/orientan el trabajo realizado por el proveedor de software.

En este post me voy a centrar en lo que es el equipo de proyecto, si bien podría ser perfectamente extensible a los otros agentes que intervienen en el proyecto.

Ya he comentado en diferentes artículos lo importante que resulta el compromiso a nivel de proyecto y a nivel de empresa, pues bien, una de las variables que me parecen fundamentales para que ese compromiso sea efectivo es la existencia de buen rollo entre los miembros del equipo de proyecto, ya que esas relaciones interpersonales permiten crear unos lazos de unión y compromiso que trascienden incluso a la empresa en la que se trabaja, es decir, puedes pensar que la empresa no te trata bien y que es injusta contigo y sin embargo tener una relación de amistad con los miembros del equipo de proyecto que haga que por el bien de todos los que forman parte del mismo tu implicación en el proyecto sea al 100%.

Por lo anterior, veo interesante que las organizaciones fomenten actividades que favorezcan el estrechamiento de los lazos entre los miembros de la empresa, ya sean externas o internas.

Y, por supuesto, como he comentado en otros artículos, a la larga no solo es necesario que exista buen rollo entre los miembros del equipo para fomentar el compromiso, sino que es importante que la organización tome decisiones dirigidas a que los empleados se sientan también comprometidos con la misma. La suma de ambos compromisos (compromiso con los compañeros y compromiso con la empresa) resulta una fórmula que augura buenos resultados para la organización, evidentemente no son las únicas variables que aseguran el éxito, pero desde mi punto de vista resultan importantes para la consecución del mismo.

Más de una vez he comentado que a toda empresa de desarrollo de software le conviene tener alianzas con otras empresas del sector y con otras de fuera (hay proyectos mixtos), ya que andar siempre sólo es complicado en un mundo tan competitivo como este. Estas alianzas se pueden traducir en acuerdos y colaboraciones de todo tipo, pero no todo debe valer con tal de conseguir una alianza porque si hay algo peor que ir sólo es ir con malas compañías. A veces se conoce antes y se puede evitar la alianza y en otras te das cuenta después cuando el que se supone aliado se convierte en tu enemigo.

Evidentemente más vale tarde que nunca en darse cuenta, pero por regla general las alianzas que no funcionan terminan siendo tremendamente negativas sobre todo en aquellas donde la apuesta fuerte la hace tu organización y no la otra.