Sacando el máximo partido de los equipos de desarrollo de software

Contar con buenos equipos de trabajo es una tarea complicada, también en el mundo del software. Lo bueno es que no es necesario partir de cero. Hay una serie de normas o consejos que podemos aplicar. En este artículo se incluyen algunos de ellos.

No solo existen diferentes tipos de personas dentro de un equipo, sino también equipos que trabajan y operan de manera distintas. Esto es necesario para que el resultado final sea coherente y resuelva los retos de manera adecuada. Es aquí dónde entran en juego dos teorías sobre las organizaciones que nos pueden servir de punto de partida para el éxito en la configuración de equipo.

La Ley de Conway

En el año 1967, Melvin Conway determinó que las organizaciones cuando se enfrentan al reto de diseñar y construir nuevos sistemas se encuentran, de alguna manera, restringidas a construir sistemas que son reflejo de las estructuras de comunicación de la propia organización.

A veces un proyecto no termina de avanzar correctamente o se ve frenado y nadie entiende muy bien el porqué.  Lo cierto es que el diseño de la organización impacta de manera directa en la solución que vamos a construir, limitando las posibilidades del software. Por eso debemos pensar qué sistema queremos construir para disponer de una estructura de equipos que pueda soportarla.

el diseño de la organización impacta de manera directa en la solución que vamos a construir, limitando las posibilidades del software.

El número Dumbar

El antropólogo Robin Dunbar descubrió que solo podemos relacionarnos plenamente con 150 personas. Esto se debe a una característica biológica: el tamaño y la capacidad de procesar datos de nuestra neocorteza cerebral.

Tener como referencia esta limitación es esencial a la hora de dimensionar los equipos y las interacciones que se generarán entre los mismo. No siempre cantidad significa mayor calidad de trabajo. la cantidad puede incluso resultar contraproducente.

Aprender de la experiencia

A partir de estas dos teorías y nuestra experiencia de años en distintos entornos y con distintos equipos y configuraciones, nosotros hemos extraído algunos principios que creemos validos para sacar el máximo partido a los equipos que desarrollan soluciones de software. No son recetas infalibles, pero, sin duda, más de una organización podrá verse reflejada, y quizás les ayude a entender el acierto o fracaso de alguno de sus casos concretos.

8 principios útiles para conseguir el éxito en el desarrollo de software

  1. Error de código, error humano. Cuando el código “no funciona”, el problema suele tener su origen en el modo en el que los equipos están organizados, y en cómo interaccionan sus componentes.
  2. Objetivos realistas. Evita aquellos objetivos que excedan los límites de un equipo.
  3. Equipos estructurados. En lugar de estructurar equipos acordes a sus conocimientos técnicos o en base a las tareas asignadas, es preferible hacerlo de acuerdo con áreas del negocio. Esto permite unir personas que pueden aportar diferentes experiencias, conocimientos e incluso manera de aproximar los problemas.
  4. Concentración. Las organizaciones deben diseñarse para que ciertos miembros puedan aislarse del resto de trabajo en equipo para concentrarse en la solución de ciertas tareas complejas.
  5. Flexibilidad. Por mucho tiempo que dediquemos al diseño de nuestra organización, nunca va a ser la mejor posible, ya que el sistema evoluciona. Por lo tanto, la flexibilidad es primordial para lograr un diseño efectivo para cada fase del reto.
  6. Small teams, big results. En ocasiones se logra un efecto positivo en el rendimiento cuando creamos pequeñas unidades para incrementar la velocidad de adopción de nueva información.
  7. Fijar los canales de comunicación. Aunque pueda parecer lo contrario, exigir que todo el mundo se comunique con todo el mundo es una receta para el caos. Fijar las comunicaciones a través canales específicos, bien definidos, es lo que realmente ayuda a construir soluciones desacopladas y modulares.
  8. Carga cognitiva limitada. En algunas ocasiones puede ser positivo limitar la carga cognitiva que puede manejar el equipo. Este principio lo debemos tener presente cuando el sistema que estamos construyendo es de gran tamaño o desconocido respecto a tecnología o conocimiento del negocio. De esta manera podremos limitar el máximo de carga cognitiva que cada equipo pueda manejar.

Teniendo en cuenta todo lo anterior, y con la misión de resolver problemas complejos para poder alcanzar los objetivos y retos del negocio, los responsables deben buscar el equilibrio que existe entre la motivación y coordinación entre los miembros del equipo. Es decir, detectar cuando los procesos pueden ralentizar la generación del flujo de valor, así como las ocasiones en las que sea necesaria una correcta y completa cooperación de equipo para lograr un objetivo. Una meta y que solo un equipo es capaz de resolver.

Post relacionados

Navegando el Cambio: El Arte del Liderazgo Transformacional

Asier Ortiz

Design Thinking. Creatividad aplicada a la ingeniería de software

Corporate Communication

Be water. Organizaciones líquidas y sus beneficios en entornos cambiantes

Corporate Communication

Juntos hacia la excelencia. Software y trabajo en equipo

Asier Ortiz

Lo que nadie te contó sobre aplicar design thinking a la ingeniería de software

Asier Ortiz

El éxito en la gestión de proyectos no es una cuestión de suerte

Asier Ortiz