Siempre que imparto un curso sobre gestión de proyectos de software, con independencia de la empresa a la que se lo imparta, con independencia del perfil de los asistentes, siempre surge la misma cuestión, básicamente lo que dicen los alumnos es: "Si, Rodrigo tu nos has enseñado un montón de técnicas, y algunas hasta me parecen utiles e incluso me gustaría implantarlas o implantar la metodología X, pero soy el único que de mi empresa/equipo de desarrollo que ha venido al curso, el resto no las conocen. Además me voy a encontrar resistencia. ¿Cómo empiezo a 'implantar' lo aprendido?"
Lo primero es que se de la precondición de realmente querer realizar esa 'implantación', de pagar el esfuerzo inicial que hemos de hacer para poder ahorrar, aun mucho más esfuerzo, a corto plazo. Simplemente protestar no vale.
A partir de aquí, en mi opinión, las tácticas que pueden funcionar para vencer la reticencia al cambio son pocas. Podemos buscar o comprar un sponsor, o actuar como caballo de troya.
Buscar un sponsor, consiste en encontrar alguien de mayor peso que nosotros en la organización, lograr que vea como algo interesante el realizar cambios en el proceso de desarrollo y lograr su respaldo a la hora de realizarlos. A menudo es dificil de lograr. Es dificil romper las innercias inherentes a toda empresa. Es dificil que alguien se preste a sponsorizar la implantación de las mejoras. Tambien es dificil que nosotros podamos abandonar nuestro trabajo diario para poder llevar a cabo las mejoras, aunque tengamos un sponsor y exista la consciencia de la necesidad de mejorar. Pero que sea dificil no quiere decir que debamos renunciar a intertarlo. Lograr un sponsor de peso (de cuanto más peso mejor) es algo vital para todo proyecto.
Comprar un sponsor, consiste en contratar a alguien y dotarle del poder suficiente para realizar los cambios necesarios. Y digo realizar, que no imponer. Debajo de toda mejora que necesita imposición se oculta a menudo burocracia, la verdaderas mejoras se imponen solas: simplemente demuestran su validad y se quedan. La ventaja es que curiosamente, y siguiendo el dicho de que 'nadie es profeta en su tierra', los equipos tienden a mostrar más respeto por alguien de fuera. Además el hecho de que sea alguien de fuera propicia que no sufra interrupciones en su trabajo de 'implantar' mejoras en el proceso de desarrollo. Sin duda tambien es algo dificil, más aun quizas que buscar un sponsor, porque generalmente, no se tiene acceso a la financiación necesaria.
Encontrar o comprar un sponsor es algo vital para implantar una metodología de cabo a rabo.
Existe un tercer camino, más ágil y sencillo, que no necesita del apoyo de nadie, consiste en actuar como un Caballo de Troya. Ir introducciendo pequeñas mejoras paulatinas que te ayuden en tu trabajo y que ayuden a los demás. Que el equipo no cuenta con un gestor de bugs: instalaló. Que no se lleva una gestión de riesgos y lo crees, interesante, realizala. Que crees que la calidad de tu proyecto es baja, escribe pruebas, realiza testeo. Tienes problemas de integración, automatiza la construcción de tu software y construye a diario. Estos cambios suponen un trabajo inicial, sin duda, pero los beneficios que tú y tu equipo de desarrollo obtendreís son muchos. Esta opción exige tambien asumir que no todas las técnicas sirven a todos los equipos o a todos los proyectos. Si pasada una fase inicial, en la que es imprescindible realizar cierta evangelización sobre las técnicas o herramients, el resto del equipo no las adopta de manera espontanea, es que no le sirven, luego no debemos empeñarnos. Aquello que sirve se queda de manera natural. De esta manera, podemos ir introducciendo poco a poco mejoras, descartando aquellas que no resulten evidentemente útiles, sin necesidad de realizar imposiciones y logrando el efecto buscado: mejorar cómo desarrollamos software. Esta via del caballo de Troya tambien tiene sus desventajas: es imposible de llevar a cabo de puertas afuera de tu equipo o para todo un departamento o empresa. Las ventajas son evidentes: el coste es bajo, no tienes que contar con nadie y puede que logres que tus compañeros de equipo mejoren como realizan su trabajo.
Algunas lecturas adicionales relacionadas:
- Sobre sponsors:
Project sponsorship
Getting the Sponsor You Need
Project Sponsor - Sobre 'caballos de Troya':
Logrando resultados cuando se es un peón
El Test de Joel: 12 pasos hacia un código mejor
Scrum es una metodología que me gusta mucho, los motivos principales son los siguientes:Es simple:
Últimamente he recibido esta pregunta en dos ocasiones, en un corto espacio de tiempo, por correo. Además
Leo en el blog Diario de Programación que su autor, a decidido abandonar Scrum , antes de ni siquiera