Los equipos modernos de desarrollo son multifuncionales, así disparan la velocidad y la productividad

Esto es un tema que debería interesarte mucho, ya que si no eres consciente de él… puede que la competencia de tu empresa si lo sea y puede que por ello os gane la partida, porque serán (o ya son) mucho más veloces, productivos y con un equipo de personas menor.

Un equipo multifuncional es aquel equipo que posee todas las competencias necesarias para lograr completar el trabajo, sin depender (o dependiendo mínimamente) de otros equipos, áreas, o roles fuera del mismo.

No significa que todo el mundo dentro del equipo sepa hacer de todo, significa que el equipo en su conjunto es autosuficiente y tiene el conocimiento y habilidades necesarias para construir la parte del producto que le toca y que la especialidad de cada miembro puede ser complementada por algún otro miembro del equipo.

¿Es tu equipo es lo suficientemente multifuncional? ¿Lo sabes?

Vamos a verlo. Utiliza esta técnica (adaptada de Crisp). Escribe en las columnas de una tabla las principales competencias necesarias para construir el producto (módulo, conjunto de funcionalidades, etc.). Pon en las filas de esa misma tabla los nombres de las personas del equipo. Puntúa dentro de la tabla el grado de habilidad de cada persona respecto a cada competencia.

Pon un asterisco allá donde la persona es experta. Pon un  punto donde la persona no es experta pero podría desenvolverse con dicha competencia. Deja en blanco competencias que una persona desconozca por completo (o se niegue a entrar en ellas).

 

Habilidades necesarias para construir el producto

Equipo

Web

C++

Testing

BBDD

Leonard

*

.

 

*

Sheldon

.

*

   
Howard

*

     
Rajesh    

*

.

Stuart      

*

Tabla de comprobación de lo “multifuncional” que es un equipo

Cada columna debería tener como mínimo un asterisco y, al menos, un punto u otro asterisco.

Si un equipo no tiene una persona que desempeñe una habilidad importante para implementar un requisito en el producto tendrá una dependencia.

Dependerá de un área de soporte o de un recurso externo, es decir, se perderá tiempo en coordinación con otros departamentos, peticiones, asignación de recursos, etc., siendo esta la situación clásica en muchas empresas de desarrollo.

Equipos multifuncionales vs equipos clásicos

La visión más clásica de una empresa de desarrollo suele ordenarse por departamentos. Como muestra simplificadamente la figura 1, en el ejemplo, tres departamentos, uno de QA, otro de desarrollo y un tercero de sistemas.
equiposNormales

 Figura 1. Empresa ordenada por departamentos.

Para completar un proyecto es necesario contar con personas de los tres departamentos, lo que implica lentitud, pedir recursos de un responsable al otro, pausas, papeleo con peticiones de trabajo de un equipo al otro, etc. Aquí el trabajo se ordena por actividad en vez de por necesidades a introducir en los productos.

Un departamento con CMMI, otro con ITIL, un comité de cambios en medio, un «pull» de recursos, hay que entrar en la cola para testing… ¿te suena?

La visión ágil promueve equipos multifuncionales, es decir, equipos autónomos, capaces ellos solos de tomar un requisito y dejarlo listo en el producto software. La figura 2 es un ejemplo.
equipoMultifuncional

 Figura 2. Equipo multifuncional.

En esta segunda figura, tenemos equipos multifuncionales. Tres equipos capaces de completar tareas ellos solos, de manera autónoma, de principio a fin.

Este tipo de organización dispara la velocidad y elimina multitud de “desperdicios” hablando en terminología Lean, es decir, elimina cosas que no aportan valor. Además, reduce el número total de personas necesarias.

Lo sé, esto no es fácil, ni está al alcance de cualquiera

Si trabajas en una organización estructurada de manera clásica, antes de que lo pienses, déjame que lo diga yo: la restructuración hacia una organización ágil es un reto, para algunos… imposible.

El reto está en la cultura, el cambio organizativo, y en que la propia arquitectura del producto no esté tan acoplada que lo haga imposible.

Pero quienes ya trabajan con equipos ágiles, disparan la velocidad respecto a cuando trabajan de manera clásica, disparan la productividad y lo hacen además con menos gente. Y puede que tu competencia ya haya caído en ello hace tiempo.

Javier Garzás

8 comentarios en “Los equipos modernos de desarrollo son multifuncionales, así disparan la velocidad y la productividad”

  1. Pingback: Bitacoras.com

  2. Os recomiendo echar un vistazo al libro «handbook for employees» de valve que se puede encontrar en la sección «jobs» de su web. No sé si la realidad será tal y como la presentan pero se describe un gran ejemplo de equipos auto-organizados y multidisciplinares.
    Un ejemplo: las mesas tienen ruedas para que en cada momento los miembros del equipo se coloquen físicamente donde les convenga para su proyecto actual. También hacen autocrítica y conocen las desventajas de su sistema.

    1. A mi cada vez que pienso en este tema de los equipos autosuficientes me surge la siguiente duda. ¿Como haces cuando no tienes carga de trabajo para tener una persona?
      Es decir, por ejemplo en un equipo no tienes carga de trabajo para tener una persona con un perfil de testing. En ese caso entiendo que lo tienes que compartir con el resto de equipos.

      1. Soy tester/QA y trabajo en equipos agiles. Creo que la carga de trabajo de un tester debería existir desde el sprint 1. Un tester debería siempre validar el código diseñado en cada sprint porque debería ser algo entregable al cliente y para eso debería verificarse siempre antes de ser enseñado al cliente.
        Entiendo que cuando se crean los equipos de trabajo, se deberían crear con las necesidades que se requieran para implementar lo que el cliente quiere, de tal forma, que los equipos sean lo más independientes y multifuncionales posibles. Si sobra alguna disciplina entonces es que no se requiere dicha disciplina en ese equipo.
        Yo creo que los equipos no son fijos, solo deberían ser fijos durante la vida del proyecto, cuando termina el proyecto, pueden recolocarse las personas dependiendo de las necesidades que se necesiten en cada momento. Al menos es lo que hacemos nosotros, ya que tenemos diferentes disciplinas y no todas se usan siempre en todos los equipos de trabajo.

      2. Alejandro Guerra

        Tambien es necesario re-plantear si definitivamente es necesario personal que QC (Quality Control o Testers si prefieren), por que en teoría los desarrolladores deberían al menos garantizar pruebas unitarias y quizás hacer uso de TDD y ATDD, por tanto dicho rol podría ser innecesario o en su defecto, durante los tiempos «valle» de un rol como éste, podría entonces explotarse otra habilidad que posea ya fuese en el mismo equipo u otro. Es mas facil cuando todos los miembros del equipo son propios, por que si hacen parte de un proveedor es mas complejo tener a una persona el doble o triple de cara, «mirando para el techo» esperando que se le asigne una tarea de su expertise.

      3. Los equipos se ensamblan al iniciar un proyecto, finaliza el proyecto y finaliza el equipo.
        Lo que se plantea acá es que los equipos al iniciar un proyecto deben ser multifuncionales. Esto no implica que los equipos sean fijos y no exista la posibilidad de cambio de rol o de equipo

  3. Cuál sería la estratégia para seleccionar o armar a un equipo que sea de largo vida? Entendiendo que los equipos de alto rendimiento (ejemplo real Madrid no se arma pensando en un partido o proyecto sino para ser los mejores en el año o para ganar la champions y liga) entonces si los equipos dura en que puedan madurar tiene su proceso y los vamos a cambiar según el proyecto nunca tendremos equipos de alto rendimiento o confiables para ser altamente competitivos , que estrategia o experiencia tienen para ayudar en ese plan de pensar en equipos de larga vida en las organizaciones sobre todo las grandes como bancos ejemplo. Gracias.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Ir arriba