Soñando con el equipo técnico perfecto

Probablemente no diga nada nuevo si hablo de que conseguir equipos técnicos que funcionen es un camino muy complicado. Cada persona es un mundo complejo de características tanto personales como profesionales que afectan al correcto funcionamiento del equipo. Además, en los centros de formación tratan de enseñar a ser los mejores profesionales técnicos, pero no trabajan de igual manera la parte personal. Enseñan los mejores algoritmos de búsquedas, pero algo tan simple e imprescindible como la comunicación, no está ni tan siquiera evaluada.

La perfección de un equipo tiene un carácter muy subjectivo. Cada empresa puede requerir equipos de diferentes tamaños, de diferentes tecnologías, de equipos más o menos aislados entre ellos, etc.

El objetivo de este post es definir, a través de mi propia experiencia, cuál es la composición del equipo técnico base perfecto, con el que sería ideal trabajar en cualquier tipo de entorno y cualquier tipo de reto técnico.

Equipo técnico

Lo primero de todo, me gustaría explicar qué entiendo como equipo técnico. Un equipo técnico es un conjunto de personas (no sólo desarrolladores) cuya principal característica es la capacidad de resolver problemas a través de la tecnología. Como equipo, deben trabajar conjuntamente, haciendo ver que son un único elemento.

Me gustaría aclarar que no considero al equipo técnico como un equipo de producto. En los equipos de producto, el producto es el centro del equipo, dando más importancia a la experiencia en el manejo del producto en sí que a la propia experiencia técnica. En el equipo técnico, el producto es considerado como un conjunto infinito de objetivos (o de casos de uso) con un denominador funcional común (el producto), que se dará alcance a través del buen uso de la tecnología. Por tanto, la herramienta para alcanzar cada objetivo será la tecnología. Cuanta mayor capacidad técnica tengamos, más fácil será alcanzar el objetivo. Sí que considero que el equipo técnico deberá estar enfocado en un producto (para reducir la curva de aprendizaje del mismo), pero el equipo está perparado para cualquier tipo de reto funcional.

Tampoco me gusta usar la terminología de equipo de desarrollo. El equipo técnico no sólo está atado al desarrollo software. También cuenta con capacidades funcionales del producto (conocimiento del mismo obtenido a través de la experiencia). Así pues, equipo de desarrollo se me queda corto.

El principal reto del equipo técnico es el de reducir al máximo la curva de aprendizaje del producto. Es por ello que una de las principales características de los integrantes del equipo es la capacidad de aprendizaje y de enseñanza entre ellos. Debe estar muy comprometido con la formación, no solo técnica, sino de experiencia con el producto.

Imaginemos un incendio. El fuego sería el primer objetivo a abordar para el equipo técnico. Como nunca han combatido el fuego, la curva de aprendizaje para solucionar el problema será alto. Una vez sepan que el fuego se combate con agua, y dado que cuentan con las mejores herramientas, usarán la manguera para apagarlo. Es posible que con un extintor hubiera valido, pero eso será parte del aprendizaje. Cuando vuelva a salir otro fuego (segundo objetivo), el equipo ya tendrá la experiencia anterior, disminuyendo la nueva curva de aprendizaje. Nótese la diferenca con un equipo de producto: si el equipo hubiera sido experto en fuegos, la curva de aprendizaje inicial sería prácticamente nula, pero quizás no cuente con las mejores herramientas para dar solución al problema, y esto demore mucho más en dar solución al mismo.

Miembros del equipo

El equipo ideal se compondrá en torno a 5 personas:

• 1 analista: será la referencia funcional del producto. Tiene la mayor capacidad de comprensión de los objetivos. Sabe comunicar las necesidades al resto del equipo. No es solo un perfil funcional, sino que tiene capacidad técnica.
• al menos 1 perfil arquitecto del software, referente en el diseño de la arquitectura idónea para solucionar problemas.
• al menos 1 perfil de líder técnico, capaz de orquestar las necesidades técnicas del equipo.
• al menos 1 perfil QA, encargado de diseñar los casos de prueba y e capaz de detectar los puntos necesarios de automatización del producto.

En caso de ser necesario, se requerirá un experto en UX, diseño y/o maquetación, lo que podrá incrementar el número de integrantes del equipo en uno.

Cuando identifico perfiles, no identifico personas, es decir, una persona del equipo podría tener varios perfiles (por ejemplo, la persona con perfil de lider técnico también podría tener el perfil de arquitecto).

Características del equipo

Los perfiles han de tener cierta experiencia (llamémosle senior). No contemplo en el equipo más de una persona con poca experiencia (llamémosle junior), o con nula experiencia (llamémosle becario). Esto implica que a un junior o becario no se le debe asignar ningún perfil específico, y máximo 1 persona junior/becario por equipo.

Absolutamente todos los miembros del equipo deberán tener al menos conocimiento técnico de:

• Desarrollo de software: todos los integrantes saben programar en mayor o menor medida.
• Buenas prácticas de programación: al menos deben ser capaces de realizar código legible.
• Testing: son muy conscientes de la necesidad del testing automático, y por tanto programan cosas testables.

Todos los miembros del equipo son capaces de realizar testing manual, en caso de requerirse, para asegurar la calidad del software.

En el equipo, el concepto de responsabilidad propia existe, y no se diluye en el equipo. No hay una entidad “equipo” a la cual se le pueda culpar en caso de error. El error es bien recibido, y se considera parte del aprendizaje tanto personal como de equipo. Con ello, se pretende conseguir que cada miembro del equipo dé el 100% de sí mismo, dé la cara y no se esconda bajo ninguna barrera.

La formación es la base del equipo. Entre ellos son capaces de nutrirse para avanzar funcionalmente y mejorar técnicamente.

Flujo de trabajo

Antes que nada, el equipo ha de ser muy profesional, valora la metodología de trabajo que va a utilizar y cree en ella. No es una metodología impuesta por la empresa, sino que el equipo bajo un marco común ha conseguido definir su propio flujo de trabajo. Ve resultados positivos en comparación con marcos de trabajo anteriormente utilizados, y se apoya de métricas para mejorar como equipo.

Sí creo que el mejor marco de trabajo agile es Scrum (o al menos, el uso de sus herramientas, ceremonias, etc.), pero me gustaría hacer varias apreciaciones:

• El equipo trabajará en escenarios semanales para aportar el valor necesario al objetivo a abordar en dicha semana. Considero que más de una semana hace que el equipo tenga menos capacidad de precisión en las estimaciones de las tareas necesarias para lograr el/los objetivos, y menos de una semana no lo considero productivo. Además pueden manejar con mayor flexibilidad problemas venideros (un problema surjido durante la semana puede ser abordado la siguiente semana).

• Las reuniones son claras y bien definidas, en cuanto a qué se quiere abordar y qué se quiere conseguir. Todo lo acordado en la reunión deberá ser documentado.

• No veo necesario el uso obligado de la daily meeting. En caso de tener que levantar la mano al resto del equipo por algún problema, se realizará la reunión pertinente.

• Antes de finalizar el día, cada integrante del equipo deberá reservarse un espacio de tiempo de un máximo de 30 minutos. Será una reunión con otros compañeros del equipo. Se considerará un espacio formativo, donde se realizará pair programming, feedback técnico y aprendizaje funcional. Esto hará que cada miembro mejore técnicamente, funcionalmente y como equipo, mientras el objetivo semanal sigue su curso.

Como apreciación, he tratado de enfocarme en el trabajo del día a día de las personas. Dejo de lado entrar en detalle en procesos más específicos (QAs, UATs, CD/CI, …), ya que daría para un libro :)

Conclusiones

La complejidad de crear un equipo técnico que funcione en armonía es altísima, y supone el mayor reto de las empresas para poder abordar el gap que existe entre producto y tecnología. He tratado de documentar pequeñas píldoras que puedan ayudaros en el trabajo de vuestro día a día, siempre con la intención de mejorar como profesionales.

Obviamente esto son todo opiniones personales, derivados de mi propia experiencia. Con ello, no pretendo imponer ni mucho menos ningún tipo de esquema de trabajo. Como he comentado anteriormente, cada equipo es un mundo, así como cada empresa también lo es.

Para finalizar, este post no pretende ser un post muerto. Me gustaría poder retroalimentarlo y mejorarlo con el tiempo, con opiniones de cualquier persona que lo haya leido, ver pros y contras, etc.

Y como siempre, cualquier duda o sugerencia, estoy disponible en mis redes sociales :)