Saltar al contenido

Caso práctico: Roles en un proyecto de desarrollo de software

Los roles en un proyecto de desarrollo de software

Durante la ejecución de un proyecto, la pieza clave es el equipo ejecutor. Un equipo organizado, con los roles adecuados, compacto, remando todos hacia los entregables, hitos y objetivos, hará que el plan sea un éxito. En el desarrollo de software, los roles se suelen suelen ser técnicos y se encargan de hacer un conjunto de tareas específicas. Esto es un problema. Si los roles se identifican por funciones, se parte de un equipo segmentado.

Lista básica de roles tradicionales

Para la construcción de una solución tecnológica en donde necesitamos que se desarrolle software, vamos a tener roles muy ligados a las fases de la metodología tradicional en cascada:

  • Desarrollador: Construyen o programan el código. Usualmente en uno o varios lenguajes de programación.
  • Analista funcional: Es la persona que hace de nexo entre los requerimientos y las funciones que se deben implementar. Digamos que ayuda a entender al equipo técnico la solución a implementar en el negocio.
  • Analista técnico: Es aquella persona responsable de hacer una arquitectura técnica de la solución. Partiendo de las funciones determinadas por el analista funcional, descompone en módulos, enumera requisitos técnicos y detalla el cómo se debe de enfocar la construcción del código para implementarlas.
  • Tester: Para asegurar la calidad del código y que se cumplen las funcionalidades determinadas, se deben de testear los módulos y procesos necesarios para poder asegurar que lo que se ha pedido, es lo que se ha implementado y funciona correctamente según los parámetros de calidad esperados.
  • Técnico de sistemas: Es la persona responsable de que la infraestructura de la solución esté funcionando adecuadamente para asegurar el rendimiento esperado.

El problema de estos roles es que por mucho que los unamos en un equipo de trabajo, van a trabajar en cascada y cada uno en su cubículo. La consecuencia será una cadena de producción donde la comunicación sólo es posible entre los eslabones contiguos, no de todos a todos. Además, es fácil que se monten embudos que generen los temidos retrasos en la implantación de la solución

Lista básica de roles de equipo

Un equipo que es productivo, según Belbin, tiene que tener los siguientes roles:

  • Impulsor, implementador, finalizador. Estos on roles de ejecución de acciones.
  • Cerebro, monitor evaluador, especialista. Estos son roles mentales de análisis y toma de decisiones.
  • Coordinador, cohesionador, investigar de recursos. Estos son roles sociales de comunicación.

Hay multitud de artículos en internet que hablan de la aplicación de estos roles en los equipos y su aumento de productividad. Sin embargo, aunque no deja de ser una apreciación coherente y que tiene todo el sentido del mundo, en un equipo de trabajo de desarrollo de software no se tiene porque disponer fácilmente de personas que cumplan con los requisitos que se exponen como parte de estos roles.

Lista definitiva de roles de equipo

Según mi experiencia lo que funciona es más tener en el equipo personas en general. Personas que quieran trabajar. Para ello, recomiendo una estructura de equipo que cumpla con las siguientes características:

  • Todas las personas tienen que ejecutar acciones y tienen que estar capacitadas para realizar cualquiera de ellas, independientemente de si les gusta más una cosa u otra. Un desarrollador tiene que poder operar los sistemas, tiene que entender por qué está construyendo un software y para qué. Tiene que poder participar en decisiones funcionales y de arquitectura. Incluso asistir a la reunión de inicio de proyecto y a la de cierre.
  • Tiene que haber un líder en el equipo. El líder es importante. Tiene que cumplir con unas características concretas, y los demás le deben ver así.
  • El equipo tiene que tener espacio para poder comunicarse. Si las cosas van bien, hay que felicitarse, y si van mal hay que aprender de los errores. Hay que compartir la información en el equipo y tiene que fluir la comunicación como algo básico.

Conclusión del caso práctico

No encasillar a las personas en sus funciones y extender éstas a todas las de los roles del desarrollo de software ayudará a que la responsabilidad del equipo con el proyecto sea una realidad. No descuidemos espacio para la comunicación y dejemos al líder que ejerza su papel cuando sea necesario.

Deja una respuesta

Puedes añadir un comentario o responder a otro.

Información básica sobre protección de datos Ver más

  • Responsable: Antonio Gutiérrez Martín.
  • Finalidad:  Moderar los comentarios.
  • Legitimación:  Por consentimiento del interesado.
  • Destinatarios y encargados de tratamiento:  No se ceden o comunican datos a terceros para prestar este servicio.
  • Derechos: Acceder, rectificar y suprimir los datos.
  • Información Adicional: Puede consultar la información detallada en la Política de Privacidad.

Esta web utiliza cookies propias y de terceros para su correcto funcionamiento y para fines analíticos y para mostrarte publicidad relacionada con sus preferencias en base a un perfil elaborado a partir de tus hábitos de navegación. Al hacer clic en el botón Aceptar, acepta el uso de estas tecnologías y el procesamiento de tus datos para estos propósitos. Configurar y más información
Privacidad