Master Plan — un modelo de trabajo para distribuir conocimiento y agilizar equipos de desarrollo
Con la especialización de las actividades y la separación de roles en el desarrollo web, a saber: los títulos desarrollador senior y junior, desarrollador frontend y backend, jefe de proyectos, arquitecto de software y más, nos encontramos con algunos problemas que friccionan las búsquedas de los equipos de trabajo para alcanzar la agilidad en sus procesos de desarrollo.
El primer problema es el acaparamiento de conocimiento, donde los especialistas de cada área son los que se encargan de realizar las tareas que les competen, concentrando con ello el saber técnico a lo largo del tiempo. Esto trae efectos nefastos en la creación de productos, uno de sus síntomas es tener un “truck factor” muy bajo, donde típicamente se reduce a 1 en equipos pequeños. Así mismo, cuando en el equipo tenemos a “dueños del código” el equipo completo deposita su fe en esa persona desconociendo muchas veces como está escrita la solución, siendo doblemente peligroso si el mismo “dueño del código” es también quien realiza el diseño del sistema.
En ese estado de cosas el desarrollador sólo tiene un conocimiento fragmentado del producto que construye. Ahí justamente donde se especializa, atrofia su capacidad de manejarse en las distintas capas de su producto, restringiendo así su capacidad sólo a las tareas descritas por su especialidad o por su rol en la organización.
Master Plan: Un modelo de trabajo colectivo
Master Plan es una idea de modelo de trabajo, que permite a cada integrante del equipo alcanzar un conocimiento holístico de su propio producto. Esto a través de una metodología orientada a alternar los roles de forma cíclica y con ello distribuir el conocimiento. Así mismo, Master Plan™ busca que los integrantes del equipo sean capaces de operar en todas las capas de desarrollo. Generando equipos de desarrolladores “full stack”.
A primera vista esto suena poco viable pues mucho se ha hablado de la figura mítica del “full stack developer”. Aparentemente este tipo de desarrollador es poco común y pareciera que últimamente en el mercado sólo existiesen, por así decirlo, “cirujanos” y no “médicos generales”. Sin embargo esta es una construcción ficticia de la industria del desarrollo de aplicaciones que tiende a la especificidad de roles. Pero vamos, no estamos hablando de ciencia de cohetes, estamos hablando de desarrollo web. Siendo 2016, es un “desde” que un desarrollador sepa ir del backend al frontend, y poder resolver problemas en todos los flancos más allá de la maestría en tal o cual tecnología. Con esto, el desarrollador “full stack” no es mas ni menos que un “desarrollador web con experiencia” que puede construir una aplicación en su totalidad, todo lo demás es mito.
Implementación del modelo Master Plan
El procedimiento es simple, imagínese un tren de sushi como una mesa de trabajo, en el que cada uno de los comensales es un desarrollador y donde cada plato es una unidad de trabajo, un laptop, un problema, una tarea. El tren avanza y a cada paso definido por un intervalo de tiempo cambia el contexto para todo el equipo, al unísono, haciendo circular las tareas una y otra vez.
Condiciones ideales de implementación
Modo mesa de trabajo
Lo primero que pasa al poner a todos en una mesa a trabajar en algo especifico es que se genera un ambiente de foco, al igual que en el pair programming. Con la diferencia que Master Plan opera como una estrategia de programación colectiva con rotación de tareas.
Ciclos de desarrollo
Un intervalo en “Master Plan” lleva consigo un cambio de contexto. Depende del equipo cuanta es la duración de su intervalo: 15 min, 1 hr, 1 día, 1 semana. Este es un punto álgido pues el cambio de contexto tiene un costo, un costo alto. Sin embargo la hipótesis es que ese costo debería disminuir a lo largo del tiempo. Prácticamente porque los integrantes van ganando experiencia en las distintas capas en cada iteración.
En Master Plan, como regla, se pueden desarrollar múltiples proyectos a la vez. En teoría, si un equipo es de 5 personas, se podrían desarrollar hasta 5 proyectos de forma simultánea, donde cada persona toma un solo proyecto a la vez.
La particularidad de Master Plan, al ser cíclico, es que una iteración completa supone que un proyecto pasó por las manos de todo el equipo y vuelve al punto de partida. Por lo tanto en cada iteración cada integrante del equipo absorbió algo de conocimiento y aportó en el desarrollo del producto. Esto a la larga permite que el equipo completo conozca todos los contextos del producto y el conocimiento de los expertos sea distribuido al equipo.
A diferencia de la idea clásica del “sprint”, Master Plan sigue la misma figura de ciclos, pero en una suerte de “carrera de postas o relevos” donde todos son parte de la misma carrera y avanzan por la misma pista.
Nuestra hipótesis es que con esta metodología luego de unos ciclos tendremos a un equipo entrenado para enfrentar cualquier parte del producto ya sean aspectos de infraestructura, diseño o desarrollo. Conocimiento distribuido.
Conclusiones generales
En Prey creemos que no es necesario seguir los modelos de desarrollo al pie de la letra. Pues como dijo Frank Zappa: “sin desviarse de la norma el progreso es imposible”.
Master Plan, al ser un modelo hipotético, nunca implementado antes, podría adoptarse no necesariamente como lo describimos aquí, a saber: con un modo de “mesa de trabajo” o con una persona por tarea. Tal vez podría funcionar en contextos de trabajo remoto, o bien armar equipos de más de una persona por cada tarea.
Creemos que la forma en que se integre esta práctica dependerá necesariamente de la cultura de la organización y de la disposición que tengan los equipos de desarrollo a aprender más y jugar.
Como equipo de tecnología de Prey hemos adoptado, entre otras prácticas, algunos aspectos de distribución de conocimiento tales como:
- Rotación de liderazgos en la “propiedad” del código.
- Salir de zonas de confort en cuanto a las experticias y entrar en lugares donde nadie quiere entrar.
Si bien estos puntos no son necesariamente parte de una metodología como la descrita en este documento tienden a ser precedentes que condicionarían positivamente el ambiente para la implementación de Master Plan en un futuro cercano en nuestra organización.
Ya les contaremos cómo nos va con esto. Y usted señor lector , ¿cómo hace para distribuir conocimiento en su equipo de trabajo? ¿le hace algún sentido esto de Master Plan?.
