Delivery Team

5 de Julio de 2022 · 7 min de lectura

Photo by Jason Goodman, post its teal team

Hace nada en APSL cumplimos nuestros primeros 13 años de historia, con una plantilla de más de 100 personas. Hace 12 años éramos 4 personas, hemos ido creciendo y aprendiendo por el camino.

El crecimiento de la empresa ha venido acompañado de más burocracia (¡Gracias administración!),encuestas aleatorias del INE donde siempre parecemos tener todos los números, regulaciones varias que se aplican a partir de las 50 personas (¿Nadie se ha preguntado por qué hay tantas empresas pequeñas y tan pocas medianas?), etc. Al llegar a ciertos volúmenes hay que pasar una auditoría obligatoria por parte de una empresa auditora certificada. Con nuestros números esto nos tocará este año, el 2022, con lo que en el 2023 deberemos pasar esta auditoría.

Como uno se rodea de gente que da muy buenos consejos, decidimos pasar la auditoría del 2021, aunque no fuese obligatoria. Para los que no lo hayáis vivido, debo deciros que es una experiencia muy interesante, al menos con nuestros auditores, de la cual hemos aprendido mucho. Eso sí, lleva mucho más trabajo de lo que inicialmente habíamos supuesto.

En la auditoría explicamos cómo funcionamos, tipo de clientes, facturación, etc. Y eso nos lleva al objeto de este artículo, el concepto de Delivery Team formado por FTE (Full Time Equivalent). A nosotros nos parece lo más normal del mundo, pero al contarlo vimos que no era así. Por eso creo que es interesante explicarlo.

¿Qué queremos solucionar?

En APSL apostamos por las metodologías ágiles, cuyo foco fundamental es la aportación y entrega de valor al cliente. Las metodologías como Scrum suponen siempre que tienes un equipo multidisciplinar, capaz de hacer de todo y que es completamente autónomo. La figura del full stack llevada a su máxima expresión. Y eso directamente no funciona cuando el equipo es pequeño y el proyecto es muy especializado, con una capa de front y back, una de sistemas, o donde puede haber también una parte de ciencia de datos. Se necesita un equipo multidisciplinar, pero no pueden ser las mismas personas que hagan todo. Tenemos un problema y eso es lo que queremos solucionar.

Queremos llegar a un compromiso entre lo que es un equipo de proyecto Agile y la eficiencia en el desarrollo. Lo que hacemos es estimar la dedicación de cada perfil al equipo y en función de esto buscamos los perfiles que más encajen junto con su dedicación, formando así el equipo de proyecto.

Esto nos permite además ir gestionando los roles y la capacidad. Si la capa de front, por ejemplo, no va a participar en el desarrollo los primeros meses, se puede mantener a la gente que va a participar informada y cambiar la dedicación prevista por más componentes de desarrollo back.

Al final, la media de trabajo de cada uno de los perfiles será la que debe ser, pero podemos decidir la carga de trabajo e implicación durante toda la vida del proyecto. Un FTE es el tiempo equivalente a tener la capacidad de una persona, pero sin que esa persona deba ser siempre la misma.

De este modo tenemos un coste fijo mensual, gestión del presupuesto del proyecto y dedicación de perfiles adecuados, con un equipo totalmente orientado a la entrega de valor, que aprovecha lo mejor de cada uno.

¿Por qué no todo el mundo hace eso?

Si es tan bonito y eficiente, uno se puede preguntar porqué no hacen lo mismo todas las empresas a la hora de desarrollar. No todas las empresas están preparadas para organizarse de este modo. A nosotros nos ha llevado mucho tiempo conseguir esta manera de trabajar y la estamos adaptando y mejorando cada día, con todo lo que vamos aprendiendo en los proyectos. Esta forma de trabajar creemos que es la óptima para los proyectos ágiles, ya que siguiendo la filosofía de entrega de valor, también nos permite ser muy eficientes en lo que hacemos.

Desarrollar un producto de este modo necesita que se cumplan unos mínimos:

Tamaño

Este tipo de gestión y estructura solamente la podemos tener si tanto la empresa cliente como la empresa que ofrece el servicio tienen un tamaño de mediano a grande, aunque también encaja muy bien en el mundo de las startup. El cliente debe ser consciente de cómo se trabaja orientado a producto y a valor, donde los requisitos fluyen según va cambiando el negocio. El equipo tiene que ser capaz de gestionarse y ser lo suficientemente fluido para poder incorporar a nuevas personas según evolucione el proyecto. Esto supone que hay personas disponibles para incorporar según necesidad, lo que puede no ser así si la empresa de desarrollo es pequeña. Hace unos años nosotros mismos no habríamos podido estructurarnos de este modo.

Confianza e implicación del cliente

Orientado también con el tamaño de la empresa, la confianza y la implicación del cliente es muy importante. No se trata de un proyecto cerrado y de discutir alcances, se trata de generar valor para el negocio y quien sabe que aporta valor y que no, es el cliente. Así que la labor del equipo es ir evolucionando con el cliente, adaptarse a las priorizaciones y crear una arquitectura lo suficientemente robusta como para poder hacer frente a las necesidades del cliente. Esto choca frontalmente con proyectos a precio y características fijas. En nuestro caso somos también gestores del presupuesto, procurando que nuestro trabajo tenga la máxima aportación de valor para el cliente y avisando a tiempo de posibles desviaciones.

La gente no puede estar 100% ocupada

Trabajar con un delivery team implica que parte del equipo va a ir cambiando y que para poder hacerlo la empresa no puede estar al 100% de su capacidad, ya que si lo está podría pasar que la incorporación de la persona o personas que el equipo necesita retrase el proyecto en lugar de acelerarlo.

Trabajar en este modelo significa que la empresa proveedora, APSL en este caso, no va a maximizar el tiempo facturable, sino que se orienta es a minimizar el tiempo de espera y a aumentar el valor de los entregables.

Foco y especialización

La elección tecnológica es fundamental. Muchas veces tendremos que decir que no a proyectos que no nos encajan tecnológicamente para poder mantener el foco en las tecnologías en las que la empresa es experta. Nosotros hemos optado por muy pocas tecnologías y decimos que no a muchos proyectos que, aunque sean interesantes, implicarían perder el foco en lo que somos buenos.

Nos hemos centrado en desarrollos en Python, utilizando Django para las tareas de back y creación de APIs y Vue o React en la capa de presentación y desplegarlo sobre la plataforma cloud de AWS.

Este foco nos ha permitido procedimentar los sistemas de integración y despliegue continuo, tener un sistema de alarmas tanto para la aplicación como para el sistema, y en definitiva ser más eficientes en el trabajo. La gente sabe qué se puede encontrar cuando aborda un proyecto, ya sea en fase inicial o que ya se está desarrollando. Disminuimos así la carga cognitiva, la ansiedad de enfrentarse a lo desconocido. Cada proyecto es único, pero tener ya una base tecnológica común y definida nos permite centrarnos en el problema más que en la herramienta.

Formación

La coordinación en los equipos es fundamental y además todo el mundo debe ser consciente de las capacidades y fortalezas de cada persona del equipo. Debe haber una base amplia de conocimiento común y para lograrla se debe pasar antes por una etapa de formación y aprendizaje. Es lo que estamos haciendo también en APSL Academia, donde además de la parte tecnológica nos enfocamos también en los procesos y metodología, en lograr esta base común que permita empezar a trabajar en un equipo sin fricciones.

Gestión e información

Un equipo de estas características requiere ser del todo transparente con el cliente. Es decir, cuando se necesita un perfil más especializado es el propio equipo el encargado de hacer las gestiones para tener este soporte adicional.

Además nuestro cliente debe estar siempre informado de las tareas que vamos realizando, de la capacidad que se está reservando y utilizando en cada momento, para que también pueda tomar sus propias decisiones respecto a la eficiencia del equipo.

Es un trabajo que se debe hacer como parte del día a día y que sirve tanto para poder tener visibilidad de lo que se está haciendo, como para poder tener un histórico de complejidad de tareas y así poder ir estimando cada vez mejor.

¿Encaja en mi proyecto?

Si habéis llegado hasta aquí, seguramente os preguntaréis si este tipo de equipo encaja en vuestro proyecto. Se debe evaluar caso por caso, depende mucho de si la empresa está preparada para trabajar focalizada en valor y no en presupuesto.

La flexibilidad que da tener un equipo líquido, con perfiles que pueden cambiar a lo largo de la vida del proyecto, pero que mantienen el conocimiento de lo que se está haciendo y las buenas prácticas compensa el esfuerzo extra de gestión y coordinación entre proveedor y cliente. El proveedor se convierte en partner, en socio del cliente, aportando valor a través de experiencia y conocimiento.

No encaja cuando se busca únicamente ampliar equipo con un perfil determinado, no encaja con la modalidad de body shopping.

Cada empresa es un mundo, en APSL creemos que esta modalidad de trabajo es la más adecuada para minimizar el riesgo inherente a todo proyecto y lograr que el cliente tenga lo que necesita, que algunas veces no es lo mismo que lo que se pensó al iniciar el proyecto.

¿Te interesa saber más? ¡Hablemos!

Comparte este artículo
Etiquetas
Artículos recientes