La idea para este post me la dio un comentario en el post de víctimas de la moda, alguien dijo que un arquitecto era visto como 5 programadores por parte de los gestores de proyecto. Ésto me hizo pensar en escribir una serie de posts abordando como se suelen montar los equipos de desarrollo y el efecto de éstos en el éxito de los proyectos. En este post daré mi opinión sobre los roles en un proyecto típico.
Muchas veces viendo como se organizan los equipos de desarrollo me da la impresión de contemplar un sistema social basado en castas, más propio de eras anteriores que de un entorno de alta tecnología. En mi opinión en muchos entornos empresariales los roles de los miembros de un equipo típico se asemejan más a clases sociales que a otra cosa. Esto es una tendencia muy peligrosa que hace que el equipo no actúe como tal, sino como una jerarquía señor/vasallo, y se transforme en varios grupos que desconfían los unos de los otros y se desprecien mutuamente. ¿Cómo se llegó a esta situación? Es difícil de saber, pero creo que hay varias causas:
- El mal entendimiento por parte de los gestores en muchos clientes de lo qué es un proyecto software. Ésto es comprensible ya que la mayoría de los clientes no saben construir software, no es su negocio, ¡ si lo supieran no necesitarían subcontratar ! Esta falta de entendimiento fue explotada por algunas empresas del sector, lo que ha creado desconfianza ¿Recordais cómo era todo antes del crack de las punto com…?
- El concepto de gestor universal. Un gestor universal es alguien que cree que puede gestionar un proyecto de un área que no entiende usando herramientas genéricas. Tal gestor aplicará las mismas técnicas de gestión a un proyecto de software que a un proyecto de construcción de vivienda que a la organización de un equipo de administrativos. Obviamente esto es una concepción errónea que lleva al desastre. Si creemos en este principio terminamos con jefes de proyecto que no saben informática y que no se enteran de lo que ocurre de verdad en su proyecto.
- Derivado del punto anterior nace la concepción errónea de que los informáticos son intercambiables, como si fueran piezas mecánicas de una maquinaria. Ciertamente esto puede ser real en otras áreas de gestión, pero no en la informática. El resultado típico es que los gerentes ven a los técnicos como simples obreros que no dan valor añadido y no son muy distinguibles de un administrativo, generando actitudes altivas y poco colaborativas y dialogantes. Además este prejuicio puede llegar a hacer que se considere que un técnico deba cobrar poco comparado con otros roles. Como reacción el técnico pensará mal del jefe de proyecto y lo considerará un opresor. Esta creencia es falsa, entre otras cosas porque un técnico tiene mucha información en su cabeza sobre el proyecto que uno recién llegado no tiene, y la productividad de los técnicos varía en función de su talento de una forma mucho más acusada a como varía ésta entre dos personas que realizan tareas mecánicas y repetitivas.
- Carrera profesional. Como cada rol pertenece a una casta, es normal pagar más dinero a las castas más altas. Como la casta más baja es la de programador entonces será la que menos cobre. Te puedes encontrar con un jefe de proyecto sin nada de experiencia que cobre mucho más que un desarrollador con mucha experiencia y que produzca por diez desarrolladores normales. Lo que es peor, este desarrollador experto y talentoso tendrá un sueldo similar al de un desarrollador sin iniciativa ni talento. Esto hace que los desarrolladores se desincentiven, y no quieran seguir siendo desarrolladores, sino jefes de proyecto. Al fin y al cabo nadie va a reconocer nuestra capacidad como tales. Esto genera una dinámica que lleva a que escaseen los desarrolladores expertos y arquitectos, disminuyendo la calidad del equipo y aumentando la dificultad de contratar a un nuevo desarrollador que sepa lo que hace.
Todo esto puede generar dinámicas muy dañinas y un sistema de trabajo vicioso:
- Alta rotación. Los miembros de las castas más bajas se sienten maltratados y deciden marcharse. Ésto genera a su vez que el conocimiento escape del equipo y la productividad baje. Como reacción el gerente para reemplazar esta baja puede decidir contratar. Como éste y RRHH no saben distinguir a un buen técnico de otro que no lo es, le resulta muy golosa la opción de contratar más barato. De esta forma podrá tener más miembros en el equipo con lo cual todo va a ser más productivo, ¿verdad? Y además al ser más barato se lo tendrá «menos creído y será más dócil». Total, tampoco es muy importante la cualificación, porque no es más que un «obrero». Para escribir en un teclado no hace falta saber mucho. Por este camino puedes llegar a terminar con un equipo bastante grande, lleno de gente sin capacidad técnica y/o sin iniciativa.
- Sabotaje. El técnico está tan quemado que simplemente realiza código de baja calidad, no hace pruebas, copy&paste, etc. Al fin y al cabo al jefe de proyecto sólo le interesa llegar en fechas, y tener terminado tal funcionalidad para la reunión de seguimiento tal, que si no le riñe el cliente. Además el jefe de proyecto no es técnico con lo que no puede detectar estas malas practicas. El que se introduzcan defectos en el software no es evidente en el momento, lo que hace que el jefe de proyecto piense que todo va bien hasta que la situación explota.
- Más madera. Como tenemos problemas, pongamos más gente. Hay que presionar a RRHH para que contraten rápido y barato. RRHH ante esa presión contrata rápido y barato, es decir mal. Tu equipo crece sin mesura y se llena de técnicos sin capacidad.
- Zombis. Ya que contratamos barato, puedo convencer al cliente de que su proyecto va mal y necesita «más madera». Yo le vendo que le contrato 10 técnicos de los buenos más, a tarifa buena y contrato 10 cadáveres para que calienten la silla. Los cadáveres son baratos y el volumen del proyecto aumenta, con lo que es más rentable. Realmente esto es un técnica propia de consultoras sin ética ni escrúpulos, que es posible debido a que el cliente no sabe diferenciar entre zombis y desarrolladores.
- Proyecto cerrado y horas extras como recurso común. La defensa del cliente ante «más madera» y «zombis» es cerrar el proyecto en tiempo y dinero. De esta manera no puede ser engañado por empresarios sin escrúpulos. Esto genera que cualquier sobrecarga de trabajo se termine ejecutando como horas extras y la consiguiente bajada de productividad y «quemamiento» del equipo, lo que aumenta la rotación.
- Metodología pesada. Debido a «más madera», tienes un equipo muy grande. No sabemos como hacer que muchas técnicas del agilismo escalen bien a equipos grandes. Además los malos resultados del proyecto hacen que el cliente desconfíe. Como conclusión los gestores se sienten reafirmados en su metodología pesada, ya que el agilismo es «para proyectos de juguete» y «tenemos que controlar a todos estos sinvergüenzas».
Si pensáis que lo que cuento es una exageración, yo he conocido proyectos en los que los jefes de proyectos no sabían manejar un ordenador pero si hablaban un inglés de nivel. He visto zombis atestar salas de trabajo, sí, lo he visto en alguna gran consultora, aunque afortunadamente nunca he trabajado para ellos y no todas son tan malignas como las pintan.
Lo peor es que esta dinámica se refuerza a si misma con lo que es muy difícil de romper y se transforma en el modelo mental por defecto de las personas involucradas en la informática. Lo aceptan como una verdad evidente y no se plantean que las cosas pueden ser de otra forma y te dicen «olvídate del agilismo, es un cuento de hadas«. Cuando alguien llega nuevo a este negocio, los que ya están en él, y metidos en esta dinámica viciosa, te cuentan que las cosas son como son y que no se pueden cambiar. Que se contrata barato y mal porque no te puedes fiar de un desarrollador y el proyecto siempre se sale del presupuesto; que se hacen proyectos cerrados para que el presupuesto no se vaya de madre y no nos engañen; que te olvides del TDD que eso lo que hace es quitarte productividad y nadie te lo va a agradecer; que te olvides del pair programming, que lo único que hace es disminuir la productividad a la mitad, y encima cuando viene el cliente ve la mitad de sillas ocupadas… No se dan cuenta que esta dinámica ineficiente no es una propiedad intrínseca de los proyectos software sino causados por una mala gestión y por muchas concepciones erróneas. Ésto es una de las causas más importante de resistencia al agilismo, el pensar que el desarrollo de software es así y no se puede hacer de otra forma.
Precisamente en el agilismo se intenta eliminar este ciclo vicioso. Para ello usa diversas técnicas:
- Tener una persona que actúe como puente entre el cliente y el equipo. Sepa defender los intereses del cliente pero de forma razonable e interaccione frecuentemente con el equipo. Debe filtrar y priorizar los requisitos del cliente y ser capaz de pasárselos al equipo. Es como tener un cliente a tu lado continuamente, es el Producto Owner.
- Enseñar resultados frecuentemente al cliente. Resultados tangibles, demos, pruebas de concepto, prototipos, la aplicación parcialmente construida, etc. El cliente puede no entender de software pero si que va a entender la demo. Al permitir un mejor seguimiento, evita recelos por parte del cliente y aumenta la confianza con lo que la dinámica social del proyecto mejorará.
- Persona que actúe como jefe de proyecto, actuando como enlace principal con el Product Owner, siguiendo el desarrollo del proyecto día a días, y encargado, de forma principal, de eliminar cualquier impedimento para el buen avance del proyecto. Al contrario que el jefe de proyecto tradicional, debe tener la suficiente capacidad técnica como para entender problemas de índole técnica, además de problemas organizativos. De esta forma será capaz de tomar decisiones cabalmente y detectar malas prácticas. Además debe hacer una labor de enseñanza del método de trabajo que se esté siguiendo. En SCRUM, por ejemplo, a este rol se le denomina Scrum Master.
- Tener siempre en el equipo a un miembro de gran talento y experiencia que además de trabajar y producir en el día a día, se encargue de evitar pitfalls típicos, de plantear soluciones problemas difíciles y que actúe además como mentor del resto del equipo. Tradicionalmente lo más parecido a esto es un arquitecto. La diferencia está en que es un arquitecto que trabaja continuamente con su equipo, produciendo código y enseñando a los demás. No es alguien que aparece para arreglar un incendio y desaparece. Ni tampoco alguien que desprecia a los desarrolladores, se dedica a pintar cajitas y citar a gurús. Si la carga de trabajo lo permite, este mentor y el Scrum Master pueden ser la misma persona.
- Motivar a los desarrolladores. Pagarles justamente y evitar horas extras como recurso común, escuchar lo que tengan que decir (daily meetings, retrospectivas, reuniones de planificación, …) Esto evita la rotación y aumenta el entusiasmo del equipo. También evita el cansancio de las horas extras.
- Si se necesitan horas extras, que sea de forma excepcional, y que todo el mundo las sufra, desarrolladores, jefes de proyecto, etc.
- Contratar a personal competente y eliminar de tu equipo a personas sin motivación para hacerlo bien y sin capacidad de hacer su trabajo. Esto normalmente implica hacer una buena selección de RRHH, lo que a su vez es incompatible con las prisas.
Un error común al implantar el agilismo es usar como Scrum Master a un jefe de proyecto con la mentalidad tradicional, y contratar como miembros del equipo a personas sin motivación y sin capacidad técnica. Esto hace que al final no se haga agilismo, por mucho que los roles parezcan ágiles. El desarrollador sin motivación y capacidad producirá poco, no escribirá código con calidad suficiente, no tendrá iniciativa, etc. El jefe de proyecto que siga pensando que está por encima del resto de los miembros del equipo y que no entiende el proyecto, generará la misma dinámica viciosa de siempre.
Otro error clásico es hacer que el Product Owner o no exista o sea el mismo jefe de proyecto. Esto es un error porque el primero representa al cliente y el segundo al equipo, si hacemos coincidir los dos roles en el jefe de proyecto corremos el riesgo de no atender a las necesidades y prioridades reales del cliente y caer en prácticas no éticas. Si hacemos coincidir ambos roles en una persona del cliente el proyecto se convierte en barra libre y nadie atiende a las necesidades y problemas reales del equipo.
En el fondo de todo esto está la enseñanza que creo más valiosa del agilismo: lo más crítico no es el proceso sino la gente que componen el equipo y dan vida a ese proceso. No gastes pues tanto en procesos, y preocúpate porque la gente que contrates sea apta para su puesto y sobre todo que sepan jugar en equipo, al fin y al cabo el desarrollo de software es un juego de equipo, no de individualistas.
Buen post Enrique.
Por desgracia, existen muchas malas prácticas en los procesos de construcción de software, y dar con una metodología que englobe y satisfaga todas las casuísticas es prácticamente imposible.
Mi opinión para que un proyecto salga bien, independientemente de su tamaño, es la coherencia, la lógica, y la implicación a todos los niveles, ligado a las buenas prácticas que se han ido identificando con el paso del tiempo, y que sería absurdo no cumplir.
Por ejemplo, de nada sirve transmitir la importancia de un proyecto a tu equipo, si cuando hay un problema no te involucras. El equipo debe ser uno, desde la cabeza a los pies, independientemente de los roles, que sigo considerando necesarios (la experiencia es un grado y se debe hacer notar), pero todos trabajando en una misma dirección y fomentando el buen ambiente en el grupo.
Un error que se suele presentar con demasiada asiduidad es la presencia de personal que no cumple con su cometido, y que por desgracia no se suelen tomar acciones correctivas para evitarlo, sobre todo cuando el trabajo sigue saliendo a costa de los demás. En este caso, soy partidario de prescindir de esa persona, al menos el grupo no se verá ninguneado.
En cuanto a los problemas de selección de personal, creo que es un grave error que no se cuente con la opinión de la persona que liderará el equipo de trabajo, pues al fin y al cabo conoce el entorno en que se va a mover el nuevo miembro del equipo, tanto en lo tecnológico como en lo humano. De esta manera se evitarían muchos «fracasos» en la contratación de personal.
La coherencia y la flexibilidad al final te permiten actuar acorde a las necesidades. Al fin y al cabo, ese son uno de los pilares de las metodologías ágiles, aunque tal vez en un sentido más etéreo. Por muy grande que sea un proyecto, siempre se pueden realizar subdivisiones del mismo, bien por módulos, funcionalidades… que te permitan realizar lo mismo con el equipo de trabajo, y realizar distintos mini-proyectos con sus propios mini-equipos que te faciliten el trabajo, seguimiento, y éxito del proyecto.
Un saludo.
Sgnieto, en próximos posts pienso explorar como hacer escalar el tamaño y estructura de un equipo conforme aumente el tamaño del proyecto abordado. A ver si entre todos podemos llegar a una conclusión.
Un gran post.
Y lo mejor es la conclusión. Un jefe de proyecto, se convierte en buen jefe de proyecto, cuando entiende que su principal responsabilidad es sacar lo mejor de cada componente de su equipo, velar por la estabilidad del proyecto y atender a todos y cada uno de los problemas que surjan en el día a día.
Como bien comentabas, si deben hacerse horas extras, él estará el primero, dando apoyo a su equipo.
Lo importante del agilismo, es que realmente ubica el concepto de equipo donde le corresponde, como una pieza fundamental para conseguir el éxito en el desarrollo de software.
AD9, parece que ya por fin algunos gerentes y jefes de proyectos se están dando cuenta que hay que cambiar la situación, aprender a jugar en equipo y apoyar a su gente. Sin embargo todavía veo empresas tradicionales con un esquema muy rígido y jerárquico. Estas sufren mucho a la hora de hacer software, o si son clientes, les venden con más facilidad equipos «tradicionales» con una mala dinámica de trabajo.
Aun recuerdo cierto responsable que decía que: «…por supuesto los desarrolladores web no deben tener acceso a internet, que luego pierden el tiempo mirando tonterias, son unos sinvergüenzas…» Claramente había un problema de desconocimiento y desconfianza.
Acabas de describir a la perfección la situación actual de muchos proyectos y empresas por las que he ido pasando. En una gran mayoría es imposible mejorar tu salario si no es cambiando también tus funciones, da igual la experiencia que tengas, y muchas veces pierden un excelente programador para ganar un mal jefe de equipo, pero es la única opción que ha tenido esa persona para mejorar su salario y no sentirse infravalorado o directamente engañado.
A los que nos gusta programar estamos jodidos porque es como al que le gusta poner ladrillos, da igual la experiencia que tengas y lo bien que lo hagas, que vas a cobrar el sueldo más bajo, aunque esa persona pueda ser el pilar en el que se apoya el proyecto a nivel técnico.
Una auténtica pena el desperdicio de talento que generan estas mentalidades en las empresas. Sin contar la fuente de destrucción de motivaciones y vocaciones en que se convierten.
Scherzo