El Año Nuevo es siempre una buena oportunidad de reanudar contactos y me ha llamado alguien a quien no había estado hablando durante bastante tiempo. Como tenemos el mismo trabajo de consultoría, compartimos nuestros puntos de vista sobre cómo van las cosas y le pregunté acerca de una empresa en la que habíamos trabajado juntos.

Me dijo que sus proyectos habían ido tan caóticos que decidieron externalizar sus aplicaciones. Reconocieron que no pudieron mantener el código fuente: demasiado complejo, muchas dificultades para implementar cualquier evolución sin generar una gran cantidad de defectos, no cumplen presupuestos y la imagen y la credibilidad del departamento TI muy dañadas.

Mi primer pensamiento fue que habían dado un gran paso adelante: saben que no saben.

Hay una matriz de aprendizaje que describe las 4 etapas que van desde del estado del no conocimiento hasta la competencia más avanzada. Esta matriz se ha utilizado en muchos ámbitos, y últimamente, la he visto en un video enseñando cómo jugar y ganar al póker.

Por lo general, cuando alguien empieza a jugar al póker, piensa que conocer las reglas y algunas estrategias básicas es suficiente. Algunos jugan de forma agresiva porque han visto un campeon ganando grandes sumas de dinero o torneos, aplicando una presión constante sobre sus rivales y usando líneas espectaculares de farol. Otros siguen el básico «tight is right”, es decir practicando un juego apretado con sólo las mejores manos. La mayoría de las veces, todos juegan de acuerdo al valor de sus cartas y no van a reconocer situaciones en las que podrían ganar con un par baja y cuando estarán muertos con dos ases.

Me gusta la analogía con el póquer, porque es un juego de información imperfecta: hay que tomar decisiones con poca información, como ocurre con la mayoría de las situaciones de gestión de proyecto. Ahora vamos a ver otro ejemplo.

Siempre has sido impresionada por una amiga que es una muy buena cocinera, su capacidad para realizar platos de compleja y sabrosa comida sin ningún esfuerzo, o nunca te pierdas este programa de televisión donde un famoso chef enseña a cocinar. Así que decides dar el primero paso, compras un par de libros, algunos utensilios de cocina y un hermoso delantal. Incluso si tus primeras experiencias son agradables y alentadoras, pronto te das cuenta que no es tan simple y que te faltan unos conocimientos que simplemente no están en los libros.

Etapa 1 – Inconsciente / No conocimiento

Sabes que no sabes. Has pasado de la primera etapa del no conocimiento inconsciente al segundo estado cuando sabes que te faltan unos conocimientos (tratemos de evitar el término ‘incompetente’, demasiado despectivo):

1. Entiendes que son necesarios más conocimientos de lo que pensabas.
2. Entiendes que no serás capaz de mejorar sin adquirir estas nuevas competencias.

Hacer este paso suele ser el más fácil, pero algunas personas nunca van a esta etapa 2. Muchos jugadores de póquer siempre hablan de cuando tomaron una decisión difícil para ganar un montón de dinero, pero suelen atribuir sus pérdidas a la mala suerte. O podrías decidir que no vas a escuchar a las personas que no saben nada acerca de la cocina.

Cuando se trata de la gestión de proyectos y la calidad de las aplicaciones, hay tantos diferentes programadores, del ‘geek’ muy motivado por cualquier novedad hasta el gruñón cansado, que es difícil hacerles conscientes de las oportunidades de mejora y hacer que empujan el botón ‘aprendizaje’. Algunos incluso consideran que la programación es un arte que muy pocos pueden entender y son muy reacios a cualquier cosa que pudiera ser interpretada como un intento de controlar su trabajo.

Etapa 2 – Consciente / No conocimiento

Ahora, la verdadera dificultad empieza en la etapa 2, porque la mayoría de las veces, no sabes lo que aprender para mejorar. Puedes comenzar a buscar algunos libros y, finalmente, ahogarte en un montón de textos, artículos y teorías. Puedes pasar mucho tiempo navegando en internet o en foros, y descubrir ideas muy interesantes, pero sin saber cómo ponerlas en práctica. Puedes buscar y probar herramientas diferentes y, finalmente, acabar desilusionado y desalentado por su complejidad, la falta de integración, y la cantidad de esfuerzos necesarios para ponerlas en práctica.

¿Recuerdas la última vez que no podías encontrar las llaves de tu coche? Empezaste a mirar a los lugares más usuales donde por lo general les dejas, pasando por toda la casa hasta que te das cuenta de que es la tercera vez que estás buscando en los cojines del sofá y que esto no es muy productivo. Entonces, decides tomar un enfoque más sistemático y racional, que por lo general significa:

• Analizar los acontecimientos más recientes – ¿Cuándo fue la última vez que viste estas malditas llaves, dónde, y luego qué hiciste después.
• Buscar a fondo todos los lugares más probables y eliminar uno tras uno.

No hay un camino fácil y no hay recetas milagrosa secreta, pero en el caso de esta empresa, sin saber mucho más de su dificultad para mantener el código fuente, yo recomendaría el mismo enfoque que en este post:

• Analizar el código fuente con el fin de tener una idea de lo que está mal.
• Hablar con los ‘stakeholders’ y los equipos del proyecto con el fin de definir las prioridades y el alcance: ¿cuáles son los objetivos? ¿Reducir los defectos y mejorar la calidad? ¿Reducir costes y mejorar el time to market? ¿Hay otros objetivos?
• Definir un plan o un proceso para alcanzar los objetivos.

No todo es compatible, o como ya sabes: mejor, más rápido y más barato no es de este mundo. Así que hay que comenzar simplemente.

Por ejemplo, identificar a los mejores 10 a 15 prácticas de programación que no son muy respetadas y más peligrosas para la aplicación en términos de robustez y rendimiento. Poner en marcha una tolerancia cero para estos defectos y hacer análisis de código frecuentes para identificarlos.

También se puede hacer algún tipo de formación: le gusta a todo el mundo, pero mejor evitar “formaciones-vacaciones”. Una formación eficiente se basa en un programa basado en los objetivos y se pone en práctica inmediatamente. Y a todo el mundo le gusta una certificación, siempre bueno para adornar un CV.

Etapa 3 – Consciente / Conocimiento

La tolerancia cero no significa que vayas a castigar al desarrollador que se olvida de una buena práctica.

Esto no es falta de conocimiento, esto es falta de atención. En esta etapa, cada uno tendrá que concentrarse y recordar las buenas prácticas para mejorar.

En el video para aprender póker, uno de los consejos para ir de la fase 2 a la fase 3 consistió en definir un rango de cartas que jugar de forma consistente, de acuerdo a algunos factores como el tipo de juego de póquer o la posición en la mesa.

En un primer momento, la aplicación de esta recomendación no es automática y requiere pensárselo antes de jugar una mano, También hay que seguir haciendo ‘reviews’ de manos con el fin de ver si el juego y los resultados se han mejorado.

Proporcionar feedback es importante. Analizar el código fuente de forma regular, elaborar informes y la lista de los nuevos defectos a corregir. Pronto, deberías ver algunas mejoras. Es importante definir pequeños objetivos alcanzables para mantener la motivación y evitar el fracaso.

Sin embargo, las etapas 2 y 3 son aquellas en las que vamos a pasar la mayoría de tiempo, porque tenemos que ir de principiante para el aprendizaje y la práctica hasta …

Etapa 4 – Inconsciente / Conocimiento.

La habilidad se ha convertido en una segunda naturaleza y se puede utilizar de forma automática, sin siquiera pensar en ella.

Un desarrollador ha dominado por completo todas las buenas prácticas de programación que se encontraban en la lista de tolerancia cero. El jugador de póker sólo necesita echar un vistazo a sus cartas para decidir si puede jugarlas de forma rentable. Ahora estás capaz de cocinar en tu horno cualquier tipo de carne de cualquier tamaño y peso y será perfectamente a punto o en el grado exacto de cocción que complacerá a tus invitados.

Puedes efectuar esta tarea sin esfuerzo, y si todavía estás luchando con algunos otros aspectos de tu juego, tu cocina o del proyecto, sabes que puedes aprender a resolverlos.

Es importante consolidar lo que se ha logrado mediante la presentación de los resultados a los miembros del equipo y los stakeholders: mejores conocimientos deben resultar en una mejor calidad del código, menos defectos, un mejor time-to-market y la satisfacción de los usuarios.

Saber cómo aprender mejora tu capacidad de aprendizaje y tus habilidades de manera más eficiente. Cuanto más lo practiques, más cómodo será.

Para un director de proyecto o un consultor de calidad, los análisis de código nos ayudan a definir lo que no conocemos y donde poner nuestro esfuerzo. Objetivos alcanzables, una escucha activa y revisiones regulares nos ayudarán hasta que todo encaje en su lugar. Algún tipo de formación podría ayudar.

De nuevo, el más importante en mi opinión es que la mejora de las competencias debe resultar en una mejora de la calidad de las aplicaciones y un mejor imagen de TI, y estas mejoras deben ser reconocidas.

Esto no es sólo una cuestión de recompensa. Se podría evitar perder el control de tus proyectos y ver tus aplicaciones externalizadas.

Esta entrada está disponible también en Lire cet article en français y Read that post in english.