¿Cuál es el Algoritmo del Éxito?

Crear una solución basada en software que resuelva problemas relevantes y ayude a lograr objetivos a un negocio es algo que puede conseguirse sin necesidad de poner mucho énfasis en la metodología ejercida para la creación de dicha solución. Hay casos así. Pero también hay casos en que el éxito de una solución previa provoca el aumento de la demanda por más y más funcionalidad y por más soluciones a problemas diversos. La complejidad aumenta debido a que los problemas a resolver implican muchos más factores o debido a que simplemente aumenta el número de proyectos simultáneos, o por una combinación de ambas circunstancias. La dificultad para repetir los logros previos aumenta en la medida en que se encuentran situaciones distintas y nuevas. El costo, tiempo y esfuerzo para mantener una pauta constante de entregas exitosas suelen aumentar con relativa rapidez si la complejidad no es administrada de manera habitual. Además, la calidad empieza a disminuir o verse afectada debido a los atajos que suelen tomarse en los intentos por lograr más entregas. A menor calidad, más defectos; por lo que aumenta el tiempo, costo y esfuerzo para entregar, y aumenta la presión para tomar aún más atajos que disminuirán aún más la calidad y se entra en una espiral descendente hacia posibles cancelaciones de proyectos o hacia deserciones masivas de clientes, usuarios y programadores por igual.

En algún punto en tal travesía, tarde o temprano, suele mencionarse la necesidad de “una metodología” que supuestamente ayude a aliviar o a evitar tanto los dolores de parto de entregas iniciales o de entregas incrementales como también los crecientes dolores de sostenibilidad en producción de entregas previas. En ese punto, incluso, suele mencionarse la necesidad de estrategias para lograr una cultura de “ingeniería de software”. Muy bien por tan buenas intenciones en tanto no se pierda de vista que muchos otros proyectos en muchas partes del mundo, a lo largo de muchos años, han hecho múltiples recorridos de ida y vuelta a partir de las mismas intenciones. Es decir, hoy 2015 no se justifica ignorar las lecciones aprendidas y reportadas por muchos acerca del tema de “metodologías” de desarrollo de software. Además, tampoco se justifica ignorar los esfuerzos metodológicos en otras disciplinas de trabajo análogo a la creación de software; es decir, disciplinas de trabajo intelectual como en las ciencias o en la literatura creativa, en cuya historia también se han formulado preguntas sobre su metodología respectiva.

La siguiente distinción básica resulta pertinente para evitar que las buenas intenciones descarrilen: una cosa es el esfuerzo metodológico —el estudio de los métodos— y otra muy distinta, aunque relacionada, es un caso particular del objeto material de estudio de la metodología; es decir, un método en particular. Si se confunde un método particular como si fuese metodología entonces aumenta el riesgo de intentar aplicar el mismo método a toda posible situación sin considerar los problemas relacionados con potenciales incompatibilidades entre el método y el objetivo general que se intenta lograr.

Un esfuerzo metodológico suele identificar el esquema subyacente que guarda un conjunto de métodos. En el caso de la creación de software se ha identificado, por ejemplo, que algunas familias de métodos se componen de los siguientes elementos:

1. un conjunto de conceptos interdependientes,

2. un proceso de desarrollo y

3. un conjunto mínimo de herramientas necesarias que soporten a dicho proceso.

Los métodos con estas características se denominan “métodos sistemáticos”; es decir, se derivan de una conceptualización de la creación de software como un conjunto de elementos interrelacionados (valores, principios, prácticas y patrones) que siempre estarían presentes en todo proyecto exitoso de desarrollo de software. La breve historia de aproximadamente 70 años de programación de computadoras ha visto varias familias de esos métodos sistemáticos. Tales familias han gravitado alrededor de la escuela de pensamiento estructurado, o la escuela de pensamiento orientado a objetos, o la escuela adaptativa (aproximaciones ágiles), o la escuela del practicante reflexivo, etcétera.

Todo bien, pero ¿cuál método es el más adecuado para un proyecto en particular? ¿Quién está en posición para prescribir los valores, principios, prácticas y patrones a observar por parte de los integrantes de ese grupo particular de proyecto, que tienen en sus manos la encomienda de resolver un tipo de problema en específico?

El esfuerzo metodológico es muy importante para un proyecto de desarrollo de software a gran escala. Eso no está en duda. Sin embargo, la dimensión de su importancia es tal que ese esfuerzo no debe dejarse principalmente en manos de alguien externo a dicho proyecto. Lo que sí está en duda, por cordura, es el intento de normar y prescribir desde fuera lo que debe pensar y hacer un grupo de proyecto encargado de crear una solución de negocio basada en software.

Los grupos de proyecto que ejercen por sí mismos el pensamiento metodológico suelen auto-gestionarse e interactuar con sus clientes y usuarios en términos del valor de negocio entregado en producción con una pauta continua y con un nivel de calidad sostenido; es decir, el patrón de confianza construido sobre los hechos de la experiencia de clientes y usuarios habla de la calidad de lo entregado. Para tales grupos de proyecto no hay necesidad de intentar una prescripción desde el exterior acerca de sus métodos internos y sus procedimientos de interacción con sus clientes y usuarios, sino que ellos mismos practican la autocrítica de manera habitual y adaptan su mentalidad y su proceder con base en la retroalimentación tanto interna como externa, que ellos mismos buscan con interés propio.

Pero, ¿cómo ayudar a un grupo de proyecto que no ejerce ni cultiva el pensamiento metodológico sino que pretende basar su proceder en la mera obediencia a prescripciones externas? Por otro lado, ¿qué ayuda sería efectiva para un grupo de proyecto que no piensa de manera metódica pero tampoco ofrece mecanismos de visibilidad, gobierno y predictibilidad para sus esfuerzos?

Así como no hay un camino seguro hacia la madurez profesional, tampoco hay una respuesta segura a tales preguntas. Aun así, ante tales casos se podría intentar diseñar un conjunto de métodos para su propio éxito. A continuación, para empezar, seis aspectos a considerar por parte de cada grupo responsable de crear soluciones de negocio basadas en software en su intento por diseñar su propio conjunto de métodos.

Aprender a ejercer por sí mismos el pensamiento metodológico. Indagar diversidad de métodos para entender sus esquemas subyacentes y su relación con el tipo de problemas para el cual es más adecuado cada método. Aprender a distinguir entre la descripción de un método y la prescripción del mismo. Aprender cómo pensar de manera metódica y sistémica: no sólo aprender qué pensar, sino cómo pensar. Aprender a realizar examen crítico de las ideas, con independencia de quién las haya dicho; es decir, reconocer que las ideas son algo distinto que las personas —las personas merecen respeto, pero las ideas merecen evaluación crítica.

Evitar el pensamiento ilusorio (wishful thinking). Desechar la noción de que una sola “metodología” es la solución a todo tipo de proyecto. Si se cuenta con un algoritmo o un procedimiento preciso para resolver problemas o lograr objetivos de negocio entonces no se requiere un proyecto con humanos para la solución sino basta que algunas computadoras ejecuten tal algoritmo una y otra vez para resolver cada problema. Para los casos en que no se cuente con tal “algoritmo del éxito”, entonces cada proyecto requiere su propia combinación de métodos que sean adecuados para el tipo de problema a resolver. Cada método conlleva un esquema subyacente de valores, principios, prácticas y patrones, si tales no están presentes el método simplemente no funciona. Por ejemplo, si un método requiere la práctica constante para examinar las ideas y las conductas, pero un grupo de proyecto carece del valor humano de la autocrítica, entonces tal método simplemente no funcionará para dicho grupo de proyecto. No tiene ningún sentido efectivo intentar un método sin antes reflexionar si los valores humanos y principios profesionales requeridos están realmente presentes. En tal caso sería pertinente empezar no por el método sino por los valores y los principios profesionales. Dar el ejemplo sigue siendo una buena manera para enseñar valores y principios profesionales.

Aprender de la evolución de los métodos sistemáticos del pasado. Las familias de métodos conocidos como sistemáticos se componen, decíamos, de conceptos, proceso y herramientas. La evolución a la fecha de tales métodos incluye:

1. preferir una notación ejecutable para representar los conceptos del método en lugar de sólo documentos estáticos con narrativas en lenguaje natural,

2. preferir el control empírico del proceso con estrategias y tácticas «a posteriori» ejecutadas continuamente y en lotes pequeños en lugar de intentar controlar el proceso sólo con racionalizaciones «a priori»,

3. preferir herramientas que procesen automática y directamente la notación ejecutable mencionada en el primer punto.

Distinguir entre el uso de métodos diseñados para tareas repetitivas (ej. manufactura) y métodos diseñados para tareas creativas (ej. crear software). Las computadoras son adecuadas para la ejecución de tareas repetitivas y mecánicas, de ahí que la automatización computarizada de procesos en la manufactura moderna de productos físicos tiene un lugar preponderante en la fábrica contemporánea. Se requiere de humanos para diseñar esa fábrica automatizada, pero cada vez menos para actuar como máquinas dentro de la misma; un buen diseño de fábrica evita colocar humanos en tareas repetitivas y mecánicas. Asimismo, se requiere de humanos para diseñar una fábrica de software, pero un buen diseño también evita colocar humanos en tareas repetitivas y mecánicas. El producto final efectivo en software es la ejecución productiva de las instrucciones dadas a la computadora del usuario final, y la fábrica de ese producto final es el sistema operativo mismo. Los planos de fabricación de ese producto final son los artefactos ejecutables que se copian a dichas computadoras cuando se hace una liberación. En otras palabras, lo que hace un programador es diseñar los planos de construcción que serán tomados por la fábrica de software, i.e., el sistema operativo, para construir el producto final cada vez que es ejecutado en la computadora del usuario.

Considerar métodos centrados en la premisa de que el código fuente es el diseño. Como implicación directa del punto anterior, un enfoque realista de calidad en desarrollo de software hace girar el esfuerzo metodológico en torno al diseño de los mejores planos de construcción posibles para el software, pues ahí, en dichos planos, y en las propiedades emergentes de los mismos, debe concretarse todo requerimiento, toda especificación, todo esfuerzo de pruebas, todo análisis tanto del problema como de la solución y, en fin, toda metodología realista. De otro modo, los esfuerzos que no tienen una relación con dichos planos, con esa forma de documentos técnicos también llamados «código fuente», permanecen sin materializarse. Por tanto, en el ejercicio metodológico conviene distinguir a los métodos que ayudan a lograr mejor código fuente de aquellos que tan sólo están centrados en otros tipos de documentación no ejecutable.

Preferir métodos de aproximación a la realidad. No hay método infalible, pero son preferibles aquellos que ayudan a explorar y descubrir aspectos de la realidad del caso entre manos, con independencia de cómo quisiéramos que fuese esa realidad, que aquellos métodos que sólo mantienen ilusiones, como la ilusión de control, o la ilusión de avance, sin escrúpulo alguno sobre cuál podría ser la realidad subyacente. Por ejemplo, hay métodos que prescriben gráficas de Gantt para varios meses por delante en un proyecto con condiciones nunca antes combinadas, y a eso lo llaman “gobierno de proyecto”, pero con frecuencia eso tan sólo persigue una ilusión de control. Por otro lado, son preferibles los métodos que ayuden a evaluar de continuo la dirección del proyecto con respecto a la realidad productiva desde una perspectiva de valor de negocio entregado por unidad de tiempo.