Como parte del Proyecto de Dole Latin BI, el equipo de manejo de proyectos definió un plan de carrera profesional que buscaba la mejora continua de las competencias técnicas del equipo de desarrollo. Este trabajo se realizó durante varios meses y tuvo un importante impacto en la cultura ágil del proyecto. En este posteo hago un recuento del plan, para que sirva de punto de partida a equipos de metodologías agiles (Kanbam, Scrum u otros), a gerentes de proyecto o a directores de tecnología. Espero les sirva como punto de partida, para ayudar a su equipo a desarrollar nuevas competencias.

El plan en su concepción original tenía tres fases:

Primera Fase: Clasificación

En la primera fase, asignamos a cada uno de los miembros del equipo desarrollo, un nivel para cada una de las tecnologías, tomando en cuenta su comportamiento técnico. Nótese que no usamos solamente el conocimiento como referencia, ya que realmente tratábamos de evaluar las competencias de los individuos, y de forma indirecta también evaluar si los equipos se adecuaban a las tareas que debian realizar. Es importante notar que estas competencias son el producto de una combinación de: conocimiento, habilidades, destrezas y actitudes. El conocimiento es solo es una parte de la solución.

Para la clasificación usamos tres diferentes taxonomías. Primero buscamos una clasificación por tecnología, en este caso: SQL Relacional, SSIS- ETL (SQL Server Integration Services) y SSAS-Multidimensional (SQL Server Análisis Services). Y agrupamos estas tecnologías, en tres grandes secciones de acuerdo a las tareas de desarrollo:

• Carga del Data Warehouse: incluye las tareas de diseño de base de datos, construcción de consultas de SQL y construcción de ETLs. Estas tareas exigen conocimiento de SQL Relacional avanzado y de SSIS-ETL avanzados.
• Carga del Datamart: comprende construcción de consultas de SQL, Construcción de SSIS. Estas tareas exigen conocimiento de SQL relacional fundamental y SSIS-ETL fundamental.
• Modelamiento de Cubos Multidimensionales: diseño de base de datos (Kimball), diseño y construcción de cubos multidimensionales y lenguaje MDX.

Note que, el diseño de la Base de Datos del Data Warehouse estaba asociado con la carga (ETLs) en primer grupo de tareas. Por otra parte, el diseño de bases multidimensionales (cubos) y del Datamart están agrupados en la tercera sección. Por esto la segunda tarea es la que menos conocimiento/destrezas técnicas demanda.

Clasificamos los miembros del equipo en cuatro niveles:

• Iniciados (Initates): Son los que conocen poco de la tecnología y requieren un alto grado de supervisión, por lo que se sugiere practiquen “peer-programming”. Como consecuencia, se exigia que la revisón del código de los iniciados previo antes de hacer check-in del código para integrarlo en la solución.
• Padawan: Conoce bien la tecnología y la práctica de forma eficiente. Puede escribir código sin ayuda; usualmente no necesita “peer-programming”. En este caso, también se pidió que la revisión del código ocurriera antes del check-in.
• Jedi: Experto en la tecnología y capaz de asumir las tareas más complejas y de diseño de las bases de datos o de procesos complejos. En este nivel el desarrollador puede hacer check-in del código sin revisión previa, la revisión se hace después del check-in. Dentro de sus responsabilidades está el apoyo de los iniciados, y se sugiere que hagan “peer-programming” con ellos. Aunque son expertos en tecnología, su conocimiento de los procesos de negocio de Dole es bajo o medio.
• Master Jedi: Tiene un alto conocimiento de los procesos de negocio y experto en múltiples tecnologías y sabe como usar estas tecnologias para resolver los problemas planteados. Puede asumir las tareas más complejas, diseños de base  datos y modelamiento de procesos. Pueden diseñar y revisar de forma efectiva el código ajeno, pueden retroalimentar a los miembros del equipo y tienen la capacidad para guiar y enseñar a los demás. Apoyan a iniciados en “peer-programming”, y deben revisar código escrito por los Padawan y Jedi.

Vale la pena rescatar que, bajo este esquema, un desarrollador puede ser Padawan en Carga de Data Warehouse, pero Jedi en Carga de Datamart e Iniciado en Multidimensional.

Para clasificar a los desarrolladores hicimos tres evaluaciones independientes, para dar un sentido de evaluación de 360 grados:

• Equipo Director: Conformado por los administradores de proyecto, Product Owners, consultor de administración de proyectos y el arquitecto de software. El equipo por consenso clasifico a los desarrolladores de acuerdo al desempeño observado.
• Compañero: Se les pidió a los desarrolladores de mayor experiencia de cada equipo (lideres técnicos) que evaluaran a cada uno de sus compañeros.
• Autoevaluación: Finalmente, cada uno de los miembros del equipo hizo un examen de autoevaluación. Para buscar que la autoevaluación fuera lo más honesta posible, desarrollamos un cuestionario que tenía preguntas que le permitían al desarrollador autoevaluar sus habilidades en múltiples sub-tareas. Incluimos 36 habilidades de SQL-Relacional, 32 de SSIS-ETL y 25 de OLAP-Multidimensional. Las preguntas eran de selección simple y el desarrollador podía clasificar su habilidad en 3 niveles: A) No sé cómo hacerlo; B) Puedo hacerlo con esfuerzo; C) Puedo hacerlo con maestría/facilidad.

El dividir las tareas en sub-tareas mucho más pequeñas es la forma más efectiva de construir habilidades. Nadie pasa de un golpe de “No se cómo” hacer un Data Warehouse a “construir con maestría” un Data Warehouse. Pero en cambio si es posible, incluso en algunos días, generar experticia en: “Construir una expresión CASE para crear lógica condicional.”

Las idea de la subdivisión de tareas y los niveles de clasificación de habilidades la tomamos de un excelente libro llamado “Badass: Making Users Awesome” de Kathy Sierra. Un libro recomendado para cualquiera que diseñe productos y para cualquiera que quiera gestionar conocimiento de equipos.

Segunda Fase: Evaluación de Brechas

En esta fase buscamos crear un plan grupal que contemplo las necesidades individuales de cada miembro del equipo, para ayudarles a crear una práctica deliberada que les permita aumentar sus competencias. Esta evaluación de brechas también permite entender las limitaciones del equipo y las tecnologías debíamos invertir más tiempo. En el plan original incluimos:

• “Peer Programming” para los niveles Iniciado y Padawam (principalmente para modelamiento o cuando se requería conocimiento de negocio).
• Estudio auto-gestionado de acuerdo a su brecha, por medio de lecturas y análisis de documentación técnica (horas fuera del proyecto). Más adelante esta sección se convirtió en un programa semanal con tópicos de autoestudio y pruebas.
• Centros de estudio y reforzamiento en sesiones grupales de 1 o 2 horas para evacuar dudas y obtener consejos de mejores prácticas, atajos o trucos que los desarrolladores con más experiencia usan.
• Evaluación para comprobar conocimiento o ejercicio reales supervisados, en el proceso de desarrollo de funcionalidades de acuerdo al o los módulos en que su equipo está trabajando.

Tercera Fase: Seguimiento

En esta última fase el objetivo era establecer puntos de control y evaluar los resultados para ajustar el plan mejorarlo.

En Conclusión

La idea de este artículo es compartir la experiencia y ayudar a entender que una  ventaja de las metodologías agiles es que son solo un marco de referencia que nos da mucha libertad para agregar nuestros propios elementos. En este caso específico, buscamos una forma agradable de influenciar la cultura del grupo, y que al final tuvo como beneficios:

1. Que algunos miembros “aprendieran” lo que no sabían y motivarlos para que expandieran sus conocimientos.
2. Promover el liderazgo de algunos miembros del equipo que tenían las cualidades técnicas, pero les faltaba confianza para liderar.
3. Promover una cultura de mejora continua, no solo del software sino también de los participantes del equipo.

¿Crees que en tu organización se beneficiaria de algún programa equivalente? ¿Qué agregarías o que quitarías, para adaptar y mejorar este programa?