Es ya recurrente en mis posts el insistir sobre el tema de la calidad en nuestro trabajo como único recurso para crearnos de verdad un buen currículum y una buena carta de presentación.

Aunque la calidad no deja de ser un concepto demasiado interpretable, en software viene a ser equivalente a que el sistema o aplicación que se entrega funciona según los requerimientos del cliente y, por supuesto, que no tenga fallos, que sea fácil de mantener, evolucionable, etc. Esto a mí me parece evidente aunque no siempre se tiene en cuenta en el día a día de un desarrollador.

Ahora bien, no siempre se ve claramente la relación entre la gestión de un proyecto software y el resultado final de este. En mi opinión no sólo es importante sino también determinante.

Desarrollar software no es sentarte ante un ordenador y pasarlo bien escribiendo líneas de código (bueno, también, pero lo que quiero decir es que no sólo es eso). Cuando tenemos que entregar algo para una fecha determinada, hay que planificar, cuando trabajamos en equipo las tareas hay que repartirlas coherentemente, o sea, hay que gestionar la carga de trabajo, cuando se ponen las bases de un nuevo sistema hay que tomar decisiones de diseño y antes de todo eso hay que tomar, interpretar y traducir al lenguaje del desarrollador las especificaciones de un cliente que en ocasiones no tiene del todo claro lo que quiere o necesita.

Todos esos puntos no son más que la punta del iceberg y absolutamente todos están relacionados con la gestión de un proyecto software, sin hablar de la responsabilidad que conlleva ya que ciertas malas decisiones pueden tener efectos catastróficos.

Ingenuamente hay quien piensa que eso de gestionar consiste en ordenar y mandar lo que otros tienen que hacer para sentarnos cómodamente a esperar que las cosas se hagan solas porque sí. Bajo esa concepción, el desastre de un proyecto software está asegurado.

Aunque hay tantas particularidades como proyectos y puesto que un proyecto de software tiene su propia idiosincrasia, básicamente cuando alguien se enfrenta a la gestión por primera vez no tiene una idea clara de lo que se espera de él.

Se aprende por mucha prueba y error (y estos a veces se pagan caro), pero, entre las habilidades esenciales que debe contar un buen gestor software están en mi opinión las siguientes:

  • Saber dar prioridad a la funcionalidad que se debe implementar en cada momento.
  • Mantener un equipo de trabajo coherente sabiendo cuáles son los déficits y mejores habilidades de cada miembro del equipo.
  • Potenciar las capacidades de cada miembro del equipo presionando (que no ahogando) lo suficiente de modo que una meta se convierta en un aliciente.
  • Crear una planificación con el tiempo suficiente como para compartirla con el equipo.
  • Nunca, absolutamente nunca, romper esa planificación (salvo ocasiones muy puntuales y con razones de peso), es decir, los desarrolladores debemos saber en cada momento qué tareas tenemos que hacer a un tiempo vista.
  • Mantener la suficiente paz de trabajo para que los desarroladores puedan estar concentrados de la mejor manera posible, lo que implica a veces pararle los pies a un cliente díscolo o discutir incluso con tu propio jefe (el jefe del gestor, digo). En ocasiones también supone no compartir esas ansiedades o inseguridades relacionadas con tu propia responsabilidad como gestor en donde existen otro tipo de problemas en relación al resto de la compañía que pueden no ser bien entendidas por los desarrolladores que diriges.
  • Mantener al cliente a raya, esto es, vigilar que este no cambia de opinión continuamente y que cualquier cambio en la especificación no está fuera de presupuesto, si es que se gestiona también el proyecto a este nivel.
  • Comprobar que se utilizan las herramientas elegidas y los flujos de trabajo definidos.
  • Conseguir que los desarrolladores trabajen en las mejores condiciones posibles, buenos equipos, formación adecuada, etc.
  • Comprobar que se mantiene la metodología de desarrollo elegida.

Y un larguísimo etcétera...

Cuando un proyecto software falla, el único responsable es el gestor del mismo, no hay más. Pocas cosas hay realmente que no se vean venir y parte de la responsabilidad de un gestor de un proyecto software es también gestionar riesgos, de incumplimiento, de calidad de lo entregado, etc. Si la cosa al final se tuerce, entonces tener la actitud valiente de reconocer los errores, aprender de ellos y asumir la responsabilidad. Tampoco es que te vayan a crucificar, pero si en momentos así somos inteligentes, aprenderemos mucho de los errores cometidos.

Lamentablemente no son pocos los casos en los que la única forma de ascenso laboral consiste en conseguir un puesto de gestión para el que quizá no se tienen las aptitudes adecuadas.

Se confunde en ocasiones un puesto de gestión (la verdad, qué mal me suena esto) con estar en una silla desde la que la gente hace lo que uno diga, cuando la realidad es que no tiene nada que ver con eso:

La responsabilidad de un gestor es gestionar recursos técnicos, humanos, formativos, etc. para conseguir que un producto se entregue correctamente. No tiene nada que ver con ser respetado con un autoritarismo medieval, sino con ganarte una cierta autoridad para que tus decisiones sean respetadas porque has demostrado tu experiencia y tus aciertos así como tu aceptación de los errores (sin colgarle a otros el muerto, cosa lamentablemente bastante común).

Hay muchos proyectos software que terminan con un éxito maravilloso gracias a la pericia de los desarrolladores del equipo en quienes un gestor incompetente ha delegado gran parte de sus responsabilidades; cuando esto ocurre, les recomiendo a estos desarrolladores que busquen otro jefe o incluso que cambien de compañía, ya que seguramente estarán mucho menos recompensados económicamente que su gestor, jefe, coordinador o lo que sea, injusto, pero esta situación se vive cada día y en todo tipo de compañías.

Del mismo modo que se busca un tipo de empresa para la que trabajar, ¿por qué no también buscar rodearte de un ambiente creativo con gente competente que te permita avanzar todavía más en tu desarrollo profesional? ¿Estás rodeado de gente a la que criticas y con la que tienes que trabajar, que consideras incompetentes y que no te aportan nada salvo algunos ji-ji y ja-ja en la hora del café? Pues toma nota, estás perdiendo el tiempo.

Si eres desarrollador y quieres gestionar proyectos software, busca trabajar con un buen gestor que te transmita su experiencia, lee libros al respecto y déjale claro de paso que estás preparado para asumir nuevas responsabilidades (pero ojo, no de palabra, sino con un trabajo de calidad en tu día a día).

Un gestor de proyectos aprende continuamente (el que crea que ya lo sabe todo estará fuera del mercado en unos años) y los desarrolladores con los que trabaja deben también ser capaces de aprender de él todo lo posible para el mejor desempeño de su profesión.

Si trabajamos como freelance casi todo lo anterior sigue siendo igualmente válido, ya que en ese caso seremos gestores de nuestro propio trabajo y al mismo tiempo seremos desarrolladores de un proyecto que también se tiene que hacer en orden y con calidad.

Comparte esta entrada...

¿Por qué leer El Libro Negro del Programador?

Adquirir desde:
Amazon (kindle eBook / papel)
CreateSpace (papel)
PayHip (epub / mobi / pdf)

El libro negro del programador.com
Segunda Edición - 2017

El libro negro del programador.com
Now available in english!

Archivo

Trabajo en...

Mis novelas...