Inexplicablemente en el mundo ibérico apenas encontramos información acerca de la gestión de equipos de desarrollo de software, y menos adaptados a nuestra idiosincrasia, sociedad y circunstancias. Ni se puede gestionar un equipo de software como si fuera una fábrica de producción industrial en serie como en modelos antiguos, ni tampoco es prudente calcar a ciegas modelos anglosajones que tan bien parecen funcionar en otros entornos sociales muy diferentes al nuestro.
En nuestro país ni siquiera encontramos traducciones de libros clásicos acerca de este tema que son éxitos de ventas en varios países. ¿A qué se debe este hecho?.
Es por ello que este artículo está escrito intencionadamente en castellano: ya existen abundantes weblogs y bibliografía sobre el tema en el mundo aglosajón (indico algunas referencias interesantes al final). Al referirme a manager, hablo más específicamente de un manager frente a un equipo de software, en unos casos puede coincidir con lo que en España conocemos como "jefe de proyectos" y en otros puede ser algo más general, que no sólo vela por el desarrollo del producto a corto plazo sino por el desarrollo del equipo y de la empresa en general.
Tengámoslo claro desde un principio: el papel fundamental de un buen manager es conseguir que los trabajos salgan adelante. Esto es indiscutible. No en vano uno de los mayores éxitos de ventas sobre gestión de proyectos, anteriormente titulado "The art of project management", va a pasar a titularse sencillamente "Making things happen" en su segunda edición. Sin embargo, para que las cosas "ocurran" se requiere otra serie de cualidades que van más allá de las puramente técnicas, como bien saben los promotores de las metodologías más modernas.
Desde el punto de vista humano, este puesto de responsabilidad conlleva muchas implicaciones. Existen detalles sutiles no siempre tenidos en cuenta, generalmente eclipsados por las cuestiones técnicas y el trabajo del día a día, que no pueden pasarse por alto.
Algunos de ellos, son asegurarse de que el equipo de software:
- Siente que el manager conoce y aprecia su trabajo. Si bien un manager no puede conocer tantos detalles técnicos como su equipo, sí debe tener un bagaje técnico suficiente para poder apreciar y valorar lo que se está haciendo, así como para demostrar y justificar sus decisiones y que el equipo las entienda. En caso contrario, el equipo tomará las decisiones tomadas como una manía o un capricho sin sentido, incluso pudiendo llegar a tomárselo (con razón o sin ella) como algo en su contra.
- Se sienta como una parte más de la organización. Debe conocer sus responsabilidades, éxitos y fracasos y sobre todo, sentir que el manager delega completamente las tareas encomendadas al equipo. Un manager que no sabe delegar hace sentir a su equipo de segunda; un equipo que jamás se esforzará al máximo puesto que sabe que las decisiones ya están tomadas de antemano aunque se respire un falso clima de cooperación y democracia. Este punto está estrechamente relacionado con el primero.
- Se sienta valorado y atendido tanto desde el punto de vista económico como humano. Los humanos tenemos la necesidad de sentirnos a gusto en el trabajo, de respirar un buen ambiente y de ser recompensados en la medida en que creemos que debemos serlo. El porcentaje depende de cada uno, pero un ambiente artificial o enrarecido y unas condiciones económicas mediocres son un desamparo seguro. La indiferencia y el trato calcado y deshumanizado hacia diferentes empleados, más habitual conforme mayor es la empresa, no contribuyen a mejorar este aspecto.
- Entienda qué tiene que hacer. Muy relacionado con lo anterior, ideas contradictorias por parte del manager o por parte de diferentes departamentos, desembocarán en estrés, retrasos y una calidad deficiente, seguramente por el temor que sienten muchos desarrolladores a preguntar y aclarar lo que se espera de ellos. Temor a que, en un entorno altamente competitivo y con constantes demostraciones de superioridad, se tenga la sensación de que preguntar, aunque sea para aclarar dudas o compartir soluciones, implica reconocer que no se está a la altura.
- Esté en un lugar tranquilo y con un cierto nivel de intimidad. Un equipo de desarrollo de software es un equipo de lo que en el mundo anglosajón se ha dado en denominar "trabajadores del conocimiento". Como para cualquier escritor, músico, deportista o simplemente un estudiante, la concentración es imprescindible y requiere su tiempo. Sin concentración no hay productividad. Un ambiente de trabajo con charlas entre compañeros, llamadas telefónicas, música de fondo o con constantes interrupciones son garantías seguras de una productividad nula o terriblemente deficiente.
- No se dedique a "tapar agujeros", pero tampoco esté encasillado. Está comprobado que la dispersión de tareas reduce la productividad; las personas no trabajamos bien alternando constantemente de tarea en tarea, consiguiendo no sentirnos parte de ninguna. Sin embargo, tampoco debemos encasillar a un equipo o a una persona con una sola tarea, lenguaje de programación o especialidad, porque puede haber agradables sorpresas detrás de un desarrollador.
- Entienda y justifique tu posición como manager. Si un equipo o alguno de sus miembros siente que está haciendo tareas que no le corresponden a él (esto es, trabajo como manager) además del suyo propio, sin ningún tipo de recompensa (no necesariamente económica), se sentirá infravalorado. Curiosamente también puede darse el caso contrario: que el manager se exceda en sus responsabilidades y colisione con tareas en las que debería haber delegado (labores de análisis, documentación, pruebas...) eclipsando así al equipo de desarrollo y quitándoles la escasa parcela de terreno libre que poseen para poder sentirse orgullosos y útiles.
- No sufra de agravios comparativos. La administración pública dispone de unos baremos y unas categorías laborales cuantificables. En la empresa privada ocurre generalmente lo contrario: nadie tiene ni la más remota idea de lo que cobra la gente a la que ve todos los días, salvo alguna rara excepción donde existe una carrera profesional definida. ¿Alguien puede explicar por qué?. El secretismo y la discriminación salarial (generalmente asociados) o el disfrute de otro tipo de beneficios siempre acaba saliendo a la luz y es la causa principal de crispación del ambiente laboral, especialmente si los beneficiados siempre son amigos, conocidos, familiares... En el ambiente se generan envidias y competitividad, haciendo que el desarrollador se preocupe más de saber cuánto cobra un compañero o por qué a otro se le condeden siempre determinados beneficios que de hacer bien su trabajo.
- Sea educado hacia la independencia y la responsabilidad. Un buen manager no debe crear obstáculos ni frenar a su equipo de desarrollo, ni tampoco tratarlo como a ese niño consentido al que jamás se exige responsabilidad ni se explica el alcance de sus actos y cómo puede corregirlos por sí mismo. Aunque parezca una buena estrategia a corto plazo porque proporciona una visión placentera y divertida, educar en la dependencia genera una gran inseguridad (o una falsa sensación de seguridad, según el tipo de personalidad) que puede llegar a impedir el desarrollo personal y profesional.
Alguien que, como el buen maestro, realmente desea que los miembros de su equipo sean independientes y se desarrollen al máximo sin ponerles obstáculos. Para que, si sus capacidades se lo permiten, llegue ese gran día en que el alumno supere al maestro.
Blogs recomendados:
Artículos recomendados:
Bibliografía recomendada:
- The Art of Project Management / Making Things Happen
- Peopleware: Productive Projects and Teams
- Leading a Software Development Team: A Developer's Guide to Successfully Leading People and Projects
