Liderazgo en un equipo de desarrollo de software
Toda empresa depende de la tecnología para desarrollar sus actividades y competir en el mercado actual, altamente tecnológico e innovador. Dependiendo del giro de negocio y el tamaño de la organización, es muy probable que en determinado momento la gerencia o dirección general decida formar un equipo de programadores que diseñen e implementen las soluciones de software que surjan.
Es necesario aclarar que formar un equipo de desarrollo de software puede que sea una tarea un tanto peculiar y diferente en todas sus fases (reclutamiento, entrenamiento, integración y, por supuesto, la dirección), debido a la diversidad de roles que se pueden definir y las actividades que se realizan.
Además, se puede mencionar que dentro de los equipos de desarrollo (aunque sean pequeños) encontraremos que cada persona posee habilidades diferentes (abstracción, resolución de problemas, asociación, comprensión, atención a los detalles, autoaprendizaje, adaptabilidad, etc.).
Teniendo un equipo de desarrollo que puede llegar a ser multidisciplinario, agregando la diversidad de conocimientos y habilidades desarrolladas por cada uno de sus integrantes, ¿Qué debemos saber para dirigirlos? ¿Cómo los motivamos? y ¿Cómo podemos lograr que se convierta en un equipo ágil?
I. Liderazgo en un equipo de desarrollo de software
Robert L. Glass, es un importante ingeniero y escritor, conocido por su trabajo y amplia experiencia en la ingeniería de software. En el año 2003 se realizó la publicación de su libro “Facts and fallacies of software engineering” en el que se recompilan “55 hechos y 5 + 5 falacias” del desarrollo del software.
Una de las frases más famosas de dicho libro es: “el factor más importante en el desarrollo de software es la calidad de los programadores”, esta frase (por si sola) puede llegar a no ser cierta ya que se debe considerar que en el desarrollo de software no intervienen únicamente los programadores.
Según Mario Pérez (2015), quien brinda servicios de capacitación profesional en la Ciudad de México, en un equipo de desarrollo pequeño puede que una misma persona cubra múltiples roles (funciones), mientras que en equipos más grandes es más común tener funciones dedicadas.
El éxito o el fracaso del equipo no es relacionado directamente a la cantidad de personas que lo conforman, mucho menos a las hazañas que una sola persona pueda realizar. Más bien, es relacionado a la interacción de los miembros del equipo (multidisciplinario) normalmente guiada por un coordinador designado.
Pérez (2015) menciona al menos trece roles que pueden ser definidos en un equipo de desarrollo de software, sin embargo, nos concentraremos en analizar las funciones de los roles considerados como principales y esenciales (el analista, el desarrollador, el control de calidad, el capacitador y el gerente de proyecto).
II. Definición de funciones o roles
Los equipos que llevan a cabo el desarrollo de un proyecto son multidisciplinarios, cada persona desempeña distintas funciones según el rol que tenga asignado. Es importantísimo que el líder conozca y tenga claras las funciones de cada miembro del grupo, de esta forma sabrá con quién avocarse cuando surja un inconveniente o que requiera que se realice un cambio.
A. El analista
Se relacionan directamente con los demás roles, son personas con una gran capacidad analítica, creativa y de investigación. Además, poseen facilidad de comunicación verbal y escrita, ya que son los encargados de reunirse con los clientes, entender sus necesidades y plasmarlas en un documento (requerimiento) que es entendido por los desarrolladores y el cliente.
En equipos grandes los analistas se tienden a especializar en un área, por lo que se vuelve necesario utilizar una figura que los coordine (lidere), el perfil necesario es el de un “Arquitecto de Software”.
B. El desarrollador
Son quienes producen el software que los analistas han documentado en sus reuniones con el cliente, tienen un pensamiento lógico y pueden llegar a ser mucho más especializados que los analistas debido a la amplia variedad de herramientas y opciones que existen para crear software.
Es muy común encontrar que los desarrolladores sean introvertidos y altamente racionales, por lo que para poder dirigirlos hay que entenderlos y motivarlos según los intereses de cada uno.
Cuando el equipo de desarrollo es grande, también tiende a definirse un “Jefe de Desarrollo” que, a diferencia del “Gerente de Proyectos”, dirige y plantifica solamente el trabajo de los desarrolladores.
Según Garzás (2012) y basado en su experiencia, suelen haber tres tipos de líderes para los desarrolladores:
- Liderar un equipo de desarrollo como jefe comandante.
- El “couch” para liderar un equipo de desarrollo.
- Liderar un equipo de desarrollo mediante un equipo auto-organizado.
Duarte (2015) hace énfasis en lo rápido que avanza la industria y el sector de desarrollo de software. Desde los años 80, en los que el software giraba alrededor de las PC de escritorio y los conocidos como Mainframes, hasta la actualidad en donde la tendencia es encontrar soluciones para dispositivos móviles y la web.
Para que un programador pueda mantenerse en la industria por un largo periodo de tiempo, y ser así exitoso, Duarte (2015) ha definido algunas características que considera necesarias para los programadores y que también considero debe conocer la persona que debe dirigirlos. Dichas características se encuentran recompiladas en el artículo: Diez habilidades que todo programador debe tener.
C. El control de calidad
Las personas que tienen el rol de control de calidad son las encargadas de realizar pruebas al software hecho por los desarrolladores y asegurarse que el mismo cumpla con lo requerido por el cliente.
Aunque el equipo sea pequeño no es recomendable que el mismo desarrollador tome las funciones de control de calidad, debido a que al hacer pruebas siempre se verá influenciado por la forma en que el programa fue creado.
Sin embargo, en algunas ocasiones se puede solicitar que los desarrolladores apoyen en pruebas de algo que desarrolló otra persona o que los analistas tomen alguna función de control de calidad.
D. El capacitador
Se refiere como capacitador a las personas que conocerán el producto final hecho por los desarrolladores y que, por lo mismo, son ideales para dar capacitación a los usuarios o las personas que el cliente indique.
Deben tener una alta capacidad de comunicación y ser capaces de resolver las dudas que puedan surgir sobre el uso del software desarrollado.
En equipos pequeños es posible que los mismos analistas apoyen en las capacitaciones, ya que ellos tienen el conocimiento de lo que se les solicitó a los desarrolladores a través de los requerimientos.
E. El gerente de proyecto
Idealmente, todos los involucrados en el proyecto deben ver al gerente de proyecto como su líder, sin embargo, en la práctica sucede mucho que el gerente de proyectos conoce poco la realidad y la situación por la que pasa un proyecto, llegando al punto de realizar estimaciones y planificaciones fuera de la realidad con recursos y tiempos inalcanzables.
Según el Instituto Argentino de Administración de Proyectos (IAAP) en todas las organizaciones existe el nombramiento de un gerente de proyecto, pero nunca existe el nombramiento de un líder. Existe un gerente de proyecto por decreto, pero no hay un liderazgo por decreto.
Muchos gerentes de proyecto no son líderes, y esto la mayoría de las veces se traduce en una mala integración de todos los componentes del proyecto (y de los roles que hemos mencionado).
Úbeda (2016) menciona que son nueve las cualidades que debería tener un gerente de proyecto que también es líder, las mismas son recompiladas en el artículo: Nueve cualidades que debería tener un gerente de proyectos.
III. Motivando a un equipo de desarrollo
Antes de hablar sobre cómo motivar a un equipo de desarrollo puede ser más importante entender las razones por los que las personas pueden desmotivarse, ya que cada persona y equipo son distintos (por los que sus motivaciones cambian). Un buen líder debe fijarse qué es lo que motiva y desmotiva al grupo antes de plantearse realizar acciones correctivas o motivantes.
Es muy probable, debido a los inconvenientes que se pueden dar durante la creación e implementación de software, que un equipo de desarrollo se vea trabajando horarios extendidos de lunes a viernes o hasta fines de semana de corrido y sin descanso.
Este sobre trabajo puede darse también por otros motivos, como la falta de balanceo del trabajo dentro del equipo, la falta de capacidad de algunos miembros de cumplir con lo requerido, la falta de confianza del líder hacia la capacidad de algún miembro del equipo (por lo que no le asigna el trabajo a él y termina sobre cargando de trabajo a alguien más), la falta de recursos para realizar el trabajo, un cambio en la dirección del proyecto a última hora (o una dirección escasa), entre otros.
La experiencia me dice que si una persona aún no ha formado una familia es probable que esté dispuesta a trabajar horas extras. Sin embargo, en cualquiera de los casos, es natural que sientan que las horas extras laboradas deban ser compensadas por sus ingresos económicos.
En Guatemala son muy pocas las empresas que registran las horas extras del equipo de desarrollo y que están dispuestas a realizar pagos adicionales por dichas horas, aunque las mismas empresas si paguen las horas extras a personas de otros departamentos (como contabilidad o personal operativo).
Además, durante el proceso de desarrollo de software es muy probable que los miembros del equipo se vean enfrentados con opiniones distintas (en programación nunca existe una única forma de hacer las cosas). Por lo tanto, las personas podrían llegar a desmotivarse si las ideas de otras personas son tomadas en cuenta antes que las ideas que ellos mismos aportaron.
La desmotivación no se da solamente al momento de que los desarrolladores realicen su trabajo, también se puede dar una desmotivación hacia aprender y probar cosas nuevas. Caer en una rutina en donde un desarrollador ya no deba analizar y se dedique a realizar tareas operativas puede ser lo más peligroso para que las personas dejen de buscar desarrollarse, aprender algo nuevo y crecer profesionalmente.
Es importante que la persona que lidere el equipo este en constante comunicación con los miembros del equipo para identificar y, de alguna forma, evaluar las posibles soluciones a cualquier aspecto que pueda estar desmotivando a los desarrolladores, pero es más importante aún que vea como está el agotamiento de todos los miembros del equipo.
Si se está dando una sobre carga de trabajo sólo en algunos miembros del equipo es totalmente seguro que habrá disgustos en el equipo y que las cosas no avanzarán tan bien, una posible solución sería revisar la delegación de actividades y la capacidad de todos los miembros.
Quizá no todas las personas cuenten con el mismo nivel de responsabilidad, lo que las hace desentenderse de algunas tareas que luego deben ser realizadas por otra persona a la que originalmente no le recaía la responsabilidad, así que, lo mejor es hacer a cada miembro del equipo consiente de las tareas que le son asignadas, siendo claros en definir cuál la responsabilidad a la que deben responder.
En resumen, el líder debe estar pendiente de cada uno de los miembros del equipo, equilibrando las tareas y evaluando su nivel de motivación, brindar acompañamiento en los casos que sea necesario para que las personas tomen la responsabilidad necesaria y, por supuesto, establecer canales de comunicación hacia cada uno de los miembros del equipo.
IV. Formando un equipo de desarrollo ágil
Mucho se habla en la actualidad sobre las metodologías ágiles de desarrollo (como Scrum) -que prometen adaptabilidad y respuesta ante los cambios frecuentes en las organizaciones- frente a las metodologías tradicionales que pueden llegar a ser calificadas como “burocráticas”
Sin embargo, es un error considerar las metodologías tradicionales como sinónimo de la burocracia (aunque se sienta que los procesos se vuelven pesados molestos, rígidos, etc.)
La verdad, es que las metodologías y procesos de desarrollo ideales dependen directamente del equipo de desarrollo que tengamos. En un equipo pequeño podría funcionar perfectamente la metodología XP (Extreme Programming), mientras que, en organizaciones más grandes, en donde hay procesos definidos para todos los departamentos, definitivamente la metodología XP se convertiría en una mala estrategia.
A. Scrum
Scrum puede ser una de las metodologías ágiles que más fama posee. Esto puede ser, según mi experiencia, porque está demostrado que aumenta la adaptabilidad de un equipo y, en sí misma, la metodología es adaptable.
Es decir, cuando se implementa Scrum en un equipo de desarrollo debemos tener presente que Scrum no dicta normas y procesos a seguir al pie de la letra, más bien, dicta una serie de buenas prácticas y recomendaciones para “adaptar” la metodología al equipo de desarrollo que tengamos, sin importar el tamaño, experiencia y madurez del equipo o procesos que la empresa tenga definidos.
Por esa razón, es que vemos que cada vez más equipos de desarrollo implementan algunas características de Scrum (se enfocan en las que consideran que son aplicables dentro de su equipo y que realmente aportarán un valor agregado) y, aunque no implementen Scrum al 100%, les es funcional y les ha ayudado a volverse más ágiles.
Por lo que he visto en los equipos que he trabajado y se ha decidido implementar Scrum (no han sido equipos mayores a cinco personas), algo que no se puede dejar de implementar a la hora de pensar en Scrum es la realización diaria de reuniones cortas.
Es esencial que dichas reuniones sean cortas (no más de 15 minutos) y que el equipo esté enfocado en el objetivo de la misma, de lo contrario, podría convertirse en una reunión diaria para beber café, platicar sobre alguna película, discutir alguna noticia, etc. (perdiendo totalmente el sentido de la misma).
En las reuniones diarias se plantean tres cuestionamientos que cada miembro del equipo debe responder:
- ¿Qué hiciste ayer?
- ¿Qué harás hoy?
- ¿Hay algún impedimento?
Considero que la tercera pregunta puede ser la más importante, ya que como equipo pueden tomar las decisiones necesarias para sortear los impedimentos que aparecen a lo largo del proyecto.
Además, las preguntas uno y dos ayudan a que las personas expresen su compromiso ante los demás, el efecto de esto es que todo el equipo conoce y comparte su compromiso.
Una vez las personas definan “lo que harán hoy” deben mantener el enfoque en esa actividad, y no deberían de cambiar sus planes a mitad del día para dedicar sus esfuerzos a otra actividad. Sin embargo, en la práctica, los proyectos están llenos de actividades que surgen en momentos inesperados, por lo que es posible que no siempre se pueda cumplir con dicha “norma”. Como líderes del proyecto de desarrollo debemos evitar que esteo suceda frecuentemente.
B. Otras metodologías ágiles
Si bien se ha hecho mención de dos metodologías ágiles: Extreme Programming (XP) y Scrum, existen otras más como: RUP, Metodología Crystal, Modelo V, entre otras.
Cada una de las metodologías ágiles que existen ha nacido debido a un planteamiento distinto de las necesidades, objetivos y recursos de algún proyecto en específico, por lo que podríamos decir que no existe una metodología ideal y universal para todo tipo de proyectos.
Sin embargo, el fin principal de todas las metodologías ágiles es permitir a los desarrolladores que se concentren en la tarea de desarrollar software y será responsabilidad del líder del equipo documentarse sobre las mejores prácticas y actualizaciones de las mencionadas metodologías ágiles.
Quizá el líder del equipo del desarrollo, luego de documentarse sobre varias metodologías ágiles, decida implementar algunas prácticas de una y otras recomendaciones de otra, esto está bien, siempre y cuando no se pierda el objetivo que es hacer del equipo un equipo más ágil.
Para finalizar, como líderes de un equipo de desarrollo, debemos estar conscientes de la velocidad en la que avanza, no solamente la tecnología, sino también los lenguajes de programación, las metodologías ágiles, la definición de buenas y malas prácticas (entre otras cosas), y no debemos descartar que las grandes ideas futuras nazcan de los miembros de nuestro equipo, debemos fomentar la comunicación y confianza, así como también estar dispuestos a escuchar las ideas de todos los miembros de nuestro equipo y valorarlas por igual.
Conclusiones
Existen, al menos, cinco roles bien definidos dentro de un equipo de desarrollo de software, los cuales indican las funciones y actividades que debe realizar cada miembro del equipo.
Cada uno de los roles definidos interactúa con los demás roles, intercambiando información valiosa entre ambos y que aporta a que el proceso de desarrollo de software se lleve a cabo.
La motivación de un equipo de desarrollo puede ser afectada por múltiples razones, cada equipo y cada individuo es distinto, por ejemplo: puede suceder que exista sobre carga y desbalance de trabajo, que los miembros sientan que su recompensación economía no es justa, entre otros.
No solamente se debe velar por motivar a que el equipo de desarrollo cumpla con sus actividades, si no, también que estén motivados a aprender y tomar nuevos retos.
Existen varias metodologías de desarrollo ágil, sin embargo, ninguna de ellas es universal y la decisión de implementarlas o no debe ser tomada por el líder del equipo luego de documentarse sobre las ventajas y desventajas de cada una.
Recomendaciones
Como líderes de un equipo de desarrollo debemos saber identificar cuáles son las funciones que cada uno de los roles define para los miembros del equipo, así como también lograr que los miembros se sientan comprometidos con sus actividades.
El líder del equipo de desarrollo debe saber a qué persona avocarse cuando necesita realizar una tarea específica del proyecto, así como conocer las limitaciones de su equipo y de los recursos para que sus estimaciones presentes y futuras sean lo más cercano posible a la realidad.
Antes de intentar motivar al equipo, el líder debe de tener la capacidad de fijarse en las razones que desmotivan al equipo e implementar alternativas buscando lograr que la motivación regrese al equipo.
El líder del equipo debe mantenerse en constante capacitación y no oponerse a nuevas ideas y retos, de esta forma se le da al equipo el ejemplo para que sigan capacitándose y desarrollando sus habilidades profesionales.
Actualmente existen varias metodologías de desarrollo ágil y es probable que se desarrollen nuevas metodologías en el futuro, debido a estos cambios es necesario que el líder esté actualizado y siempre dispuesto a evaluar e implementar las buenas prácticas que pueden contribuir a convertir al equipo en un equipo ágil de desarrollo.
Referencias
Duarte, E. (2015). 10 habilidades que todo programador debe tener. Obtenido de http://blog.capacityacademy.com/2015/04/15/10-habilidades-todo-programador-debe-tener/
Garzás, J. (2012). Las 3 maneras más típicas de liderar un proyecto de software. Obtenido de http://www.javiergarzas.com/2012/07/liderar-un-proyectosoftware.html
Glass, R. L. (2003). Facts and Fallacies of Software Engineering. Addison Wesley.
IAAP. (s/f). La función de Líder del Gerente de Proyecto. Obtenido de http://www.deltaasesores.com/articulos/autores-invitados/iaap/2317-lafuncion-de-lider-del-gerente-de-proyecto
Perez, M. R. (2015). Roles y Responsabilidades en un Equipo de Desarrollo de Software. Obtenido de http://www.marioperez.com.mx/equipos-dedesarrollo/roles-y-responsabilidades/
Úbeda, Ó. (2016). Las 9 cualidades de liderazgo del jefe de proyecto. Obtenido de https://pmi-mad.org/index.php/socios/articulos-direccion-proyectos/1011-las9-cualidades-de-liderazgo-del-jefe-de-proyecto
