La cara oculta de la gestión de proyectos

La gestión de proyectos en España es un caos enorme. Existe muchísima confusión y mucha habladuría y todo parte, ni más ni menos, de que en España cualquier Informático que quiera “ganar más” deberá de pasar inexorablemente por la gestión de proyectos.

Programador Junior, Programador Senior, Analista-Programador, Analista/Arquitecto y Jefe de proyectos. Ese es el plan de carrera que espera a todo Informático Español según empresas con diferentes colores o sabores, pero siempre está cortado con ese rasero. Y la realidad es otra. No todo buen desarrollador es buen Jefe de proyectos, ni todos tienen interés en gestionar un equipo de personas con diferentes formas de ser. Con lo cual, estamos haciendo que, o bien el que no valga para gestionar equipos se quede como desarrollador o analista cobrando menos de lo que se merece o bien hacemos que entren jefes de proyecto sin ganas.

Ahora bien, ¿Qué tareas haría un jefe de proyectos? Así a bote pronto se me ocurren:

  • Contactar con clientes y pasar presupuestos
  • Toma y análisis de requisitos
  • Gestión del equipo de trabajo
  • Optimización de tiempos
  • etc…

Podríamos añadir bastantes más, pero se entiende el concepto. En nuestra patria un jefe de proyectos es al final una máquina que se encarga de todo (Hasta de desarrollar cuando le falta equipo).

Bien, entonces sigamos analizando. Vamos a dividir las tareas de estos jefes de proyecto multitarea en dos grandes áreas:

  • Contacto con clientes
  • Gestión del equipo de trabajo

Y ahora, imaginemos que tenemos un mundo ideal y que somos los gestores del equipo y hemos conseguido que el contacto con clientes lo haga un perfil al que llamaremos “técnico comercial”, que no es ni más ni menos que ese tipo de persona que tiene un gran don de gentes y mucha empatía, que además ha estudiado informática o al menos conoce el proceso y es capaz de realizar una toma de requisitos y un análisis inicial para estimar el trabajo.

Dentro de este mundo ideal, como hemos dicho, vamos a centrarnos en la tarea de gestionar el equipo y, después de habernos quitado todo el trabajo de clientes (que es mucho), vamos a tener que tomar decisiones…. ¿metodología ágil o tradicional? Si elijo ágil… ¿XP, SCRUM, lean development…? ¿Las utilizo de manual o me las adapto? ¿Hago TDD? ¿Qué demonios es TDD? ¿Cómo he acabado aquí si yo quería ser piloto de aviones? Pues bien, de todas estas decisiones es de las que vamos a hablar (Menos de porqué has acabado aquí).

¿Metodología Ágil o Tradicional?

Ejemplo de tradicional: RUP, se centran especialmente en el control del proceso, mediante una rigurosa definición de roles, actividades, artefactos, herramientas y notaciones para el modelado y documentación detallada. Se suelen realizar con un modelo en cascada en el cual analizamos, documentamos, diseñamos, documentamos, desarrollamos, documentamos, probamos, documentamos y volvemos a empezar para solucionar los errores que hayamos encontrado por el camino.

Ejemplo de Ágil: SCRUM, son metodologías basadas en ciclos cortos de desarrollo, con una serie de puntos comunes que se detallan en el “manifiesto ágil” y que dicen cosas como que hay que valorar por encima de todo a los individuos y su interacción, que el software debe de funcionar y no centrarse en la documentación, hay que colaborar con el cliente y que hay que estar muy abiertos al cambio (El claim del libro extreme programming explained de Kent Beck –uno de los firmantes del manifiesto ágil– es, ni más ni menos, que “embrace change”).

Y el tema, ¿Cual seleccionamos? Pues bueno, cada cual tiene sus cosas buenas y malas, no os voy a mentir, siempre dependerá del proyecto pero en la mayoría de empresas de desarrollo de software y de startups se acabará cogiendo una metodología ágil. Las tradicionales se han quedado ya un poco atrás en el sentido de que exigen un análisis demasiado exhaustivo y después nos dan muy poca versatilidad si hay cambios de requisitos, ya que nos obligan a volver a empezar el proceso (en la práctica no es tan exagerado, pero casi).

Si elijo ágil ¿XP. SCRUM, lean… ? ¿Las utilizo de manual o me las adapto?

Metodologías ágiles hay tantas como modelos de zapatillas y lo más normal es que cada uno las adapte a sus necesidades ya que las metodologías no son más que guías de formas de hacer las cosas que han funcionado en otras ocasiones a otras personas. Así que la decisión es “fácil” aprende de todo lo que puedas y haz tu propia versión adaptada simplemente porque cada equipo es diferente, así como cada cliente y proyecto también lo son y no porque a otro le haya funcionado una metodología específica a tí también te va a funcionar.

Hay cosas que casi siempre encajan, por ejemplo el desarrollo incremental, la interacción con el cliente, refactorización de código, integración continua, …..
Y hay otras que no encajan bien en todos los equipos de trabajo, como son la programación por parejas, la propiedad compartida del código o las pruebas unitarias continuas.

El reto del jefe de desarrollo está en conocer a su equipo y el proyecto en el que está y elegir una metodología que se adapte a ellos. Posiblemente no lo consiga a la primera, sobre todo en equipos jóvenes, pero por eso es también importante el contar con un jefe de desarrollo con cierta empatía con la gente, que sepa reconducirlos y alentarles sin oprimirlos.

Al trabajar con metodologías ágiles es muy importante valorar al equipo y mantenerlo con ganas de trabajar.

¿TDD?

TDD, para quien no lo sepa es lo que se llama Test-Driven Development. TDD es un proceso de desarrollo de software mediante el cual lo que hacemos es crear “Unit tests” para probar nuestra funcionalidad. Lo gracioso del asunto es que es obligatorio escribir el test ANTES de escribir el código, de manera que si al escribir el código los tests fallan es que hay algún problema. Digo que es lo gracioso, porque a cualquiera le puede parecer “normal” el escribir código y luego escribir una prueba para ver que funciona bien, pero empezar a hacerlo al contrario suele chocar.

Es un proceso de desarrollo muy seguro, y está muy unido a las metodologías ágiles, ya que permite que la integración continua sea real y no genere problemas (si ejecuto los tests al integrar y los míos funcionan, pero no funcionan los del código anterior es que algo he roto).

El problema que se suele encontrar casi siempre en empresas españolas es que el equipo de trabajo casi siempre tiene muy pocos desarrolladores senior que puedan gestionar estos tests y definir cómo han de funcionar, etc… de manera que el jefe de desarrollo se acaba pasando más tiempo realizando estos mini-análisis de los módulos que realmente gestionando el equipo.

Lo normal es encontramos con empresas que más de un 70% de su plantilla de desarrolladores son becarios o júniors y no en todos los equipos existe la fuerza suficiente de séniors o analistas para cubrir esa deficiencia y ayudar a ese equipo a crecer, con lo que al final se escriben menos tests de los necesarios y se acaba por dejar de lado TDD porque da la impresión de no ser tan bueno como se prometía. Cuando realmente el error ha estado en no escribir los tests que hacían falta.

El hecho de no utilizar bien TDD acaba inevitablemente por llevar al equipo a pensar que no sirve de nada, con lo cual se va dejando cada vez más de lado y finalmente se abandona. Que quede claro, TDD mal utilizado es peor que no utilizar TDD.

Para hacernos una idea, como mínimo, un módulo sencillo deberá tener del orden de unos 10 tests, ya que hay que probar TODO, es decir, que funciona bien con los parámetros correctos, que funciona mal con los parámetros equivocados, que saltan las excepciones como toca cuando le paso lo que las hace saltar, que no saltan si no se lo paso, etc…. Es decir, es un trabajo que, si no has trabajado nunca con TDD y no has visto realmente lo que aporta, puede parecer hasta una perdida de tiempo, pero yo os insto a probarlo y juzgar por vosotros mismos 🙂

¿Y qué pasa después?

Al final, elegiremos nuestra metodología y la tendremos que aplicar, pero en el momento de aplicarla nos surgirán muchos más problemas por el camino, veamos qué puede pasar.

Lo primero para hablar sobre esto es distinguir las empresas de diversas maneras:

  • Empresa con pocos clientes (1 o 2 máximo): Este sería el perfil de una Startup, en la cual se trabaja normalmente sobre un único proyecto. O también el perfil de una empresa que no es de desarrollo, pero que tiene un departamento de informática realizando sus proyectos. El número de proyectos internos da un poco igual, ya que al final el cliente con el que tratamos es uno o dos máximo y es muy fácil negociar los tiempos. En este caso, la mejor opción es utilizar a todo el equipo de trabajo aunado y repartir las tareas entre ellos equitativamente. Con sprints semanales e incluso, si hablamos de un equipo relativamente pequeño (2-3 personas) se podría trabajar sin sprints reales y simplemente gestionar a cada persona a su velocidad. No es lo deseable, pero para entregas muy rápidas (1-3 días) y con equipos que integren a gente con mucha diferencia de nivel puede servir, ya que se puede ir realizando seguimiento individual.
  • Empresa con muchos clientes y muchos recursos: La mejor manera de trabajar con este tipo de empresas es dividir los equipos de trabajo, de manera que cada uno realice sus sprints con su lista de tareas de manera independiente. Se podría llegar a poner a uno o varios recursos en diversos proyectos a la vez, pero es una práctica que es peligrosa y más en el caso de que esos proyectos los gestionaran diferentes responsables de desarrollo ya que se le pasa al trabajador la decisión de priorizar y esto puede generar problemas.
  • Empresa con muchos clientes y pocos recursos: Como imaginaréis es la más dificil de gestionar ya que los recursos suelen estar repartidos entre varios proyectos y, en caso de retrasarse un proyecto al final se acaban retrasando casi todos. En este tipo de empresa es muy fácil que ocurra que un trabajador reciba tareas distintas con prioridades altas y no sepa con cual empezar. La única opción para este tipo de empresas es escalar los equipos de trabajo, el problema es que estos picos de trabajo suelen ser puntuales, de manera que al final hay dos opciones: se hacen más horas (malo para el espíritu del equipo si se alarga) o se escala mediante freelances. La opción buena es esta última, aunque es peor económicamente en primera instancia es mucho mejor en cuanto a la carga de trabajo que gestionan nuestros trabajadores.

En todos los casos es muy importante aclarar que existirá un peligro muy alto de retrasos siempre que un recurso pueda recibir tareas de varios responsables, ya que se pierde totalmente el hilo de la carga real de trabajo que está soportando esta persona.

Situación actual en España

Por mi experiencia previa, en la gran mayoría de empresas de desarrollo de España se implementa el peor de los modelos posibles, que es básicamente tener una sola persona que realiza la tarea de gestión con clientes y gestión del equipo de trabajo y además en la mayoría de los casos esta persona no es el filtro por el que pasa todo, sino que existen otros agentes (comerciales, responsables de otras áreas, …) que le dan trabajo directamente a los trabajadores. En teoría es una práctica muy fácil de solucionar (todo tiene que pasar por el jefe de proyecto) pero en la práctica se ve que siempre se acaban haciendo excepciones a la regla y si no se pone mucho cuidado acabaremos teniendo un completo desorden.

Por otro lado, el modelo ideal creo que habréis sabido sacar la idea de cual es:

  • Un responsable con los clientes (técnico comercial o jefe de proyectos).
  • Un responsable del equipo.
  • El responsable del equipo es el único con potestad para repartir las tareas.
  • Un equipo puede asumir tantos proyectos como le quepan en la cabeza (excel o project) al responsable del equipo y/o tantos como pueda asumir el equipo de desarrollo en los tiempos que se negocian con los clientes.
  • Esta forma de gestionar los proyectos puede parecer demasiado cara para empresas pequeñas ya que, de alguna manera, estamos duplicando el sueldo de gestión de proyectos. La realidad es que esta forma de gestión es la única que funciona y, obviamente, en los presupuestos se deberá de reflejar este coste indirecto (es el precio de crecer, ni más ni menos).

    ¿A dónde ir desde aquí?

    Pues desde aquí yo os recomiendo que si habéis decidido orientar vuestra carrera a la gestión de equipos de trabajo os leáis algunos libros de metodología como “Extreme programming explained” o “Essential SCRUM”. Que leáis el manifiesto ágil si no lo habéis hecho ya. Y, sobre todo, que practiquéis. Si vuestro jefe no os da la responsabilidad sed proactivos y convertios en líderes “de facto” (sin bypassear a vuestro responsable :P).

    Sigamos aprendiendo.

Post a comment

You may use the following HTML:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*