[cadius] proceso vs. producto

[César Astudillo González]

A mí me parece una encarnación más del clásico debate "reduccionista versus
holista". Si prestas atención exclusiva al proceso, y lo haces en tal grado
que te haces acreedor de caricatura, acabas siendo demasiado cartesiano
(aquello de trocear el problema complejo en varios problemas más simples y
creer que con eso ya lo has hecho todo), y caes en el peligro de la sinergia
negativa: cuanto ensamblas las partes, te encuentras con que la suma de las
partes es menos que el todo. Problemas de integración, estrategia
psicológica de limitación de los daños ("eso no era mi responsabilidad"),
producto Frankenstein que no satisface a nadie, "un camello es un galgo
diseñado por un comité", etcétera. De eso hay que huir como de la peste. La
sangre huye de tus miembros y se te pone la piel gris y cerúlea. Y empiezas
a caminar dando tumbos y a comer cerebros. Tengo un amigo aeronáutico que me
cuenta cosas flipantes del proyecto del Airbus 380 en ese sentido: ¡ríete tú
de la web 1.0!

Por el contrario, si te centras en el producto (y eres lo bastante
competente como para recorrer el camino sin "lastres metodológicos" <-- ¡qué
peligro esta concepción!), y lo haces en tal grado que eres objeto de
caricatura, acabas dependiendo demasiado del "talento" (esa cosa tan
inasible e intermitente) de personas individuales que "lo tienen todo en la
cabeza". El resultado acaba dependiendo demasiado de los biorritmos de las
personas que intervienen en el equipo, y tu "truck number" (el número de
personas que, si se mataran en un camión, fastidiarían tu proyecto) se hace
alarmantemente bajo. Por otra parte, y esto último lo digo con cierta
timidez, porque generalizar es errar, me da en la nariz que si llevas más de
tres proyectos consecutivos centrados en el producto, y te están saliendo
más o menos bien, una de dos: o la fluidez con que desarrollas obedece a
cierta autosimilitud de los proyectos que permite la reutilización de
conocimiento y/o activos, en cuyo caso quizás estés transitando por caminos
demasiado familiares (¡corre Forrest! ¡huele a factoría!) o es que has
encontrado, por primera vez en la historia de la computación, la famosa
"bala de plata". Y cuando oigo hablar de una bala de plata, siempre me
pregunto qué peaje estás pagando (aunque puede que creas que ninguno: hay
hipotecas que tienen periodo de carencia).

Por otra parte las metodologías son como el Flash: deben su mala fama a la
mucha gente que las usa mal. Si quieres innovar, o te gusta jugar a la
ruleta rusa o tienes que usar metodología (implícita o explícita), lo que
pasa es que a lo mejor inventas una nueva casi cada vez. No se me ocurre
otra manera de adentrarte en caminos inexplorados. Como dijo Roosevelt, "en
la guerra he aprendido que los planes no sirven para nada, pero la
planificación es imprescindible". Y como dicen los ingleses, "no hay nada
más práctico que una buena teoría". Lo que necesitas es agilidad para
adaptar la metodología a los descubrimientos que vas haciendo, saltarte
pasos si crees que no van a aportar valor, dinamitar un problema inesperado
con un barreno metodológico que a lo mejor no habías puesto en tu equipaje
de partida. Y estar habilitado para justificar tus decisiones si al final se
revelan erróneas: la mayoría de los clientes no se conforman con el "en
aquel momento parecía una buena idea". O sí se conforman, lo que pasa es que
luego no repiten.

De todos modos, seguro que la gente de Knapp en el fondo usa mucha
metodología y la usa con flexibilidad y sentido común. A mí con Alberto me
pasa que creo tanto en él como para, a veces, no creerme lo que dice :-)

César Astudillo