Me encuentro en la Oulanka Research Station de la Universidad de Oulu en Kuusamo, un lugar perdido de Finlandia, a 25 km del círculo polar. Donde Cristo perdió el gorro, vamos. El sitio es precioso: cientos de lagos, miles de arboles, renos en medio de la carretera y una paz que invita a pensar.
En el marco del proyecto ITEI, subvencionado por la Unión Europea, un puñado de ingenieros, académicos y gente de la empresa estamos buscando desarrollar una metodología y un soporte informático abierto para la gestión de la innovación en el desarrollo de sistemas de software. Hay es nada. De este proyecto deben salir una especie de libro blanco de la innovación en el marco del desarrollo de software (SinnoBok) y el diseño de un ecosistema de software que soporte esta proceso de innovación (CyberRoom).
Mi participación, en representación de Sisteplant, es como empresa que está innovando en el desarrollo de software usando metodologías ágiles. Debo aportar que requisitos tenemos en nuestro proceso de desarrollo e innovación para que sean incorporados como parte del proyecto y actuar como caso de uso de la puesta en marcha de lo que sea que salga del proyecto.
El motivo de este mail, es comentar la esencia del proyecto. ¿Es posible definir un proceso de innovación? ¿Es la innovación algo que se puede materializar en un proceso? ¿Hay una serie de pasos que se pueden dar que faciliten la aparición de productos, servicios o vías de comercialización innovadoras en el marco del desarrollo de software? ¿Existe al menos un conjunto de patrones que podamos detectar y describir?. Yo creo que no. Pero también creo que es un camino que es interesante explorar, sobre todo por que hay mucha gente que cree que si y lógicamente yo puedo estar equivocado (es altamente probable).
Lo que quiero comentar es por que creo que no existe un proceso de innovación definible y repetible (¡como les gustaría a la gente de CMMi esto!). Mis argumentos son los siguientes:
1) No hay dos productos de software iguales, no hay dos proyectos iguales, no hay dos equipos iguales, no hay dos empresas iguales. Si tenemos en cuenta que el marco del desarrollo de software es tan diferente y cambiante, es sumamente difícil encontrar un marco que funcione en todas. Esto ocurre con las metodologías, que para funcionar necesitan un fuerte proceso de ajuste e implantación. Si añadimos a esto, que por su propia naturaleza, una innovación es radicalmente diferente de cualquier otra cosa existente, la cosa se complica aun más.
2) Viendo la historia de las innovaciones recientes: el procesador, el ratón, el compilador, las redes, el ordenador personal, la web, las listas de correo, el chat, las redes sociales, las metodologías ágiles… no hay dos que hayan surgido de una manera similar. Es imposible trazar un patrón. En cada situación se partía de unas condiciones iniciales diferentes, se siguió un proceso diferente, se llegó al final del proceso y se comercializo la idea de manera diferente. Pensad en como surge el concepto de Wiki, por poner un ejemplo, base de algo tan rompedor en la cultura moderna como Wikipedia: Ward Cunningham uno de los padres de los patrones, arto de recibir mails pidiéndole que corrija tal o cual detalle en su catálogo de patrones, decide añadir un simple botón que permita a cualquiera editar el html de la página. Una innovación radical, algo nuevo, que nadie ha hecho antes, que no era especialmente ambicioso, que podría haber concluido en un desastre de gente haciendo el vándalo en su sitio y que acaba cambiando el modelo de enciclopedia que se conocía desde la ilustración francesa. Impresionante. ¿Pero como catalogarlo? ¿Cómo sistematizar los ocurrido para facilitar que surjan nuevas innovaciones?. Imposible.
3) No hay una receta para desarrollar software, menos para desarrollar software innovador. Aunque Joel Spolsky incluso tiene un receta para hacer que tu software sea el número 1 ;). El desarrollo de software es un arte. Generalmente detrás de cada gran innovación en este campo hay una persona que actual como un gran catalizador, un artista o un grupo de ellos: La WWW y Tim Berners-Lee, Linux y Linnus Torwalds, GNU y Stallman, C++ y Stroustroup, C# y Gunnerson, los patrones y la Gang of Four, Google y Larry Page y Sergei Brin… Ningún proceso garantiza que ese catalizador va a aparecer, más bien al contrario. Parece que la sensación general es que los procesos definidos tienden a encorsetar la creatividad necesaria para innovar. Muchos creen que Microsoft a perdido su capacidad de innovar y que Google la está perdiendo precisamente por esto.
Tom Simpson, ingeniero de IBM y uno de los padres del OS/360 escribió una algo que aplica perfectamente a lo que comento, en un excelente ensayo breve suyo, escrito en 1968, Masterpiece Engineering. Tom escribe la siguiente sátira, que he traducido muy libremente, sobre como un grupo de ingenieros de software estaba buscando los criterios a establecer para diseñar un sistema operativo:
“Estudiando el problema de como lograr establecer el diseño para producir ‘Mona Lisas’ …la Conferencia decidió que se debía establecer un Instituto para trabajar con más detalle sobre los problemas en el campo de la producción de obras maestras. Así que salieron a las calles de Roma y seleccionó unos cuantos conductores de carros, algunos luchadores y otros artesanos y los sometieron durante un período de cinco semanas (a media jornada) a un Curso de creación de obras maestras, y luego todos fueron puestos en una gran habitación y se les solicito que comenzaran con la creación de obras maestras.
Pronto se dieron cuenta de que no estaban consiguiendo los resultados esperados del Instituto, por lo que se trato de equipar a los trabajadores en la producción de obras maestras con algunas herramientas más eficaces para ayudarles a crearlas. Se inventaron cinceles a motor, pistolas de pintura y así sucesivamente, pero todo esto se limito a provocar una protesta ruidosa de los maestros: "Todas estas técnicas se dan en los pintores de técnica descuidada", dijeron.
La producción aún no estaba llegando a niveles satisfactorios por lo que se amplió la gama de técnicas de producción de obras maestras con algunas medidas adicionales. Una idea fue tener un lienzo y que pasase rápidamente de pintor a pintor. Mientras uno estaba aplicando el pincel los demás tenían tiempo para pensar.
El siguiente paso natural a tomar fue, por supuesto, duplicar el número de pintores, pero antes de tomarlo, adoptaron un mecanismo más interesante. Se decidió establecer alguna métrica adecuada de la productividad. Se emplearon dos semanas en el Instituto contando el número de pinceladas por día producidas por un grupo de pintores, y este criterio fue inmediatamente aplicado para calcular valor aportado a la empresa por el resto. Si un pintor fracasaba en lograr sus veinte pinceladas por día sería claro que se trataba de alguien claramente improductivo.
Lamentablemente ninguno de estos avances en el conocimiento parecía tener un impacto real sobre la producción de obras maestras y así, al fin, el grupo decidió que la dificultad básica era claramente un problema de gestión. Uno de los más brillantes estudiantes (con el nombre de Leonardo da Vinci) fue inmediatamente promovido a gerente del proyecto, poniéndolo a cargo de la adquisición de pinturas, lienzos y pinceles para el resto de la organización.”
Evidentemente no lograron producir una obra maestra.
Entiendo que el mensaje puede ser poco esperanzador, que sueno muy pesimista, pero si que es cierto que hay cosas que podemos hacer para mejorar la innovación. Muy generales, pero hay están. Y son precondiciones. Sin estas precondiciones, no surge la innovación. Quizás facilitar la eliminación de estas barreras de entrada a la innovación sea la innovación que debemos esperar de este proyecto. La gente del VTT y de Sirris ha propuesto unas áreas clave de la innovación que ellos han llamado, en un claro reconocimiento de la naturaleza artística del problema, El Arte de…:
… mantenerse enfocado.
… experimentar.
… optimizar el impacto de tus recursos de alto impacto (tus artistitas vamos…).
… abrirse al mundo (openness tiene una traducción difícil…).
… estimular la innovación.
… de mejorar la innovación.
… de la incubación de ideas.
… de la recolección de ideas.
… de la evaluación de ideas.
A mi me suena que Scrum puede dar una respuesta a algunas de estas preguntas 😉 ¿pero realmente si conseguimos responder estas respuesta, estamos consiguiente ser innovadores? No en vano uno de los objetivos de Scrum y de las metodologías en general es ser capaz de incorporar el cambio y la innovaciones que surgen al proceso de desarrollo. Al fin y al cabo: ¿no es toda innovación un proceso de cambio radical?.
Espero que os animéis a dar vuestra opinión, ya que todos los que estáis en el mundo del software sois innovadores por naturaleza. Con cada línea de código que escribís, estáis haciendo algo nuevo. Esto nos diferencia claramente de otras industrias.
¡Un saludo!