Organización orientada a productos

0

Desde hace años se ha puesto de moda el pensar en los equipos de desarrollo como organizaciones orientadas a proyectos.  Si construyes tu organización sobre proyectos, la estás construyendo sobre cimientos que desaparecerán. Un proyecto es algo transitorio por definición. Cuando un proyecto acaba lo que queda es un producto, o una modificación a un producto. Así, si todo tu equipo está organizado por proyectos, sólo viven el hoy, no se acuerdan del ayer, ya que son proyectos pasados. En una constructora que entrega un edificio y se olvida de él, puede tener sentido. Usando una cita que me pareció muy divertida:

Yo soy de La Mancha. Y allí en La Mancha hay un montón de puentes de los Romanos. Y allí están. No les han añadido funcionalidad hace miles de años.

Javier Garzas

Esta claro que hay organizaciones donde puede puede funcionar. En una empresa que desarrolla software para terceros, también. Pero si los productos son tuyos, mejor que bases tu modelo operativo sobre productos, no sobre proyectos.

¿Quiere decir esto que pasamos de los poyectos? No. Los proyectos siguen siendo necesarios. Pero no deben ser la piedra angular sobre la que se centra la organización. Tener una PMO puede ser bueno. Tener un equipo dedicado a un proyecto o a proyectos, puede ser bueno. Pero orientar tu estructura completa a proyectos, no. Mejor oriéntala a productos.

Qué significa orientarse a productos

A menos que seáis cuatro personas en tu equipo, habrá que hacer subdivisiones. En mi anterior puesto de trabajo tenía a más de 30 desarrolladores a mi cargo, y no podía pretender que formasen un solo equipo. Así que se crearon áreas funcionales: equipos que se dedican a una tarea. En mi área había una serie de responsabilidades y había que repartirlas entre los equipos. ¿Cómo?

La opción orientada a proyectos conlleva el ir creando y destruyendo equipos a medida que pasan los proyectos. Se inicia un proyecto, se forma su equipo y sigue así hasta la finalización del mismo. Cada vez que entran nuevos proyectos, los equipos se reorganizan. En estas organizaciones los gestores de proyecto son dioses. Son amos y señores de sus equipos. O si lo vemos desde un prisma ágil, en estas organizaciones los product owners suelen asumir responsabilidades de gestor de proyecto (cosa mala) y se convierten en dioses.

La opción orientada a producto consiste en dividir el catálogo completo de productos entre tus equipos. Cuando entran proyectos nuevos pueden ser cambios a un producto o productos nuevos. Si es un cambio a un producto, tendremos claro el equipo que asumirá el proyecto. Si es un producto nuevo, tendremos que ampliar responsabilidades a un equipo, o crear un equipo nuevo.

La segunda opción, la de orientar a producto, creo que es la recomendable, ya que el equipo se hace responsable de su resultado. El único problema es que a veces este equipo sufre de urgencias (incidencias en producción) derivadas de sus productos que hace muy complicado predecir la evolución de otros proyectos.

Incluso creo que sería sano tener un equipo de líbero. Que hiciese proyectos, aunque luego entregase el producto a otro. Un equipo sin responsabilidades sobre producción y que se enfocase a un portfolio de proyectos. No hablo de ir creando equipos por proyecto, sino a tener un equipo dedicado a esa tarea. Tendría su propio backlog. Esto permitiría un trade-off entre los proyectos habituales que caerían en los equipos orientados a producto, y aquellos proyectos estratégicos con restricciones de tiempo fuerte, que podrían usar al líbero.

Aspectos clave al orientarse a producto

Equipos semi-estáticos

Los equipos deben ser estáticos en la medida de lo posible. Pero también las necesidades de negocio van cambiando. Así tenemos que asumir cierto dinamismo. Será habitual que los miembros de un equipo puedan pasar a otro, porque hace falta más “gasolina” en sus productos.

De la misma manera las responsabilidades de los equipos pueden ir cambiando. El producto que hoy lleva un equipo, mañana lo puede llevar otro. Es posible que ese producto pase a primera línea, y se planteen tantos desarrollos sobre él que se desee tener un equipo exclusivo. Los otros productos que llevaba ese equipo, a lo mejor deben pasar a otros equipos o crearse uno nuevo.

Responsabiliades claras

Cada equipo debe tener claro qué productos tiene a su cargo. Es fácil tener esos muertos en el armario que hace años que nadie toca y “no son de nadie”. Deben asignarse a algún equipo. Todo debe tener un dueño. O luego nos encontraremos con incidencias que nadie atiende y nadie se preocupa de que funcionen correctamente.

Two-pizza-team

Lo ideal es tener equipos ágiles. Que cubran todas las áreas de conocimiento necesarias para esos productos. Y que el tamaño no llegue a los dos dígitos (que se les pueda dar de comer con dos pizzas). No es sano tener equipos de 3 personas ni equipos de 20. Tampoco es sano que un equipo para hacer determinadas tareas necesite pedir a un experto a otro, porque se ha quedado sin maquetador.

Gestores de proyecto de negocio

Hoy en día pensar en TI como un ente autónomo es bastante retro. TI debe ir de la mano de negocio. Los proyectos no deben pensarse como proyectos de TI, sobretodo si son cambios a productos o nuevos productos. Son proyectos de negocio y muchas veces implican mucho más que un desarrollo. Hay cambios en la forma de trabajar de negocio, nuevas oportunidades, etc. El gestor de proyecto del futuro debe estar cubriendo no sólo TI, sino también negocio. En una organización orientada a producto, el gestor de proyecto no es un dios, sino un elemento de ayuda. El gestor de proyecto coordina, da servicio a los equipos  de producto, organiza la agenda, revisa riesgos, controla recursos y dinero, … es decir, lo que viene siendo un gestor de proyecto de libro y no los semi-dioses que se pueden ver por algunos sitios.

Es decir, en un entorno en el que hay múltiples equipos dedicados a múltiples productos, la organización tendrá cambios que afectarán a múltiples productos y áreas de negocio. Ahí es donde un coordinador puede ser de gran ayuda. Y dado que ese cambio es un proyecto, hablamos de un gestor de proyectos.

Avalanchas

Los equipos orientados a producto están en su día a día con su backlog priorizado por su product owner. Pero de repente se aprueba un gran proyecto, que deben asumir ellos. Un proyecto de gran tamaño. Pongamos por ejemplo un equipo de 6 personas que controla unos productos para los que se pide un proyecto que implica a 12 personas durante 6 meses. Hay que añadir 12 personas, pero sólo 6 meses. Es decir, tenemos una avalancha. Una organización orientada a proyectos, supera estos retos fácilmente (luego tiene otros problemas). Pero para una orientada a producto, es un problema.

Aquí tendremos casos en los que otros equipos deberán “ceder” personal para este proyecto. O tendremos otros casos en los que vendrá una tropa de externos a ayudarnos. O simplemente se dividirán las tareas y otro equipo asumirá parte de ellas. En estos casos el equipo de producto debe asumir su responsabilidad y exigir que el conocimiento quede en el equipo (aunque lo desarrolle un equipo nuevo recién creado o el equipo de proyectos que os hablaba antes). También debe controlar, en el caso de externos, cómo son esos contratos ¿Documentarán? ¿Seguirán nuestras reglas de desarrollo? ¿Estarán allí si luego falla en producción y nos hacen falta?

Conclusiones

¿Tu organización a que se dedica? ¿A ejecutar proyectos o a crear productos? Esta pregunta te dará la respuesta a como debes organizarte.

Sobre el autor

Jose M. Huerta

Jose es Gestor de Proyectos y Gestor de Servicios en Mallorca. Es Ingeniero de Telecomunicaciones y obtuvo el Master of Advanced Studies durante su etapa como investigador. Pero no tardó en abandonar ese mundo y meterse de cabeza en el mundo de las Tecnologías de la Información. Está certificado como ITIL Expert. Tiene amplia experiencia en gestión de servicios, clásica e integrada con desarrollo, gestión de proyectos, usando metodologías clásicas y ágiles, gestión de programas y portfolios, gestión de grandes grupos de personas, localizadas y off-shore, sin dejar de perder de vista el lado técnico y freak del sector. Ha trabajado en varias empresas del sector con distintos roles en áreas tanto de gestión de servicios de soporte como de equipos de desarrollo. Actualmente trabaja en Sunhotels, como responsable del equipo de operaciones TI.

Sin comentarios