En realidad, la propia existencia de un manual indica una deficiencia de un programa. Los programas tendrían que poderse usar sin leer las instrucciones. ¿O no? No leemos apenas las instrucciones del coche, excepto en caso de avería, pero sí que aprendemos a conducir previamente y hasta tenemos que examinarnos. Un piano no tiene manual de instrucciones; quizá por eso hacen falta varios años de estudios para dominarlo. Un programa de ordenador que no sea trivial, como Presto, no es una máquina con una sola función. Es una enorme caja de herramientas, cuya potencia radica en la combinatoria. Ya no es posible escribir un programa complejo que se base solo en procesos predefinidos. Por ejemplo, en Presto existía antes la opción «Copiar precio de presupuesto a objetivo», cuyo significado es muy claro; pero una vez que existen varios tipos de precios, es imposible añadir todas las opciones que copian unos precios en otros, con sus correspondientes filtros y selecciones. Es mucho más sencillo enseñar al usuario a disponer los precios en columnas paralelas y usar los recursos estándar de Windows para copiar y pegar. El tópico publicitario que dice que tal o cual aparato se maneja con solo apretar un botón siempre ha sido poco creíble: sí, pero ¿qué botón? Quienes diseñan saben que hay un compromiso inevitable entre funcionalidad y tamaño de mercado. Los usuarios requieren funciones. Tal vez no las usen, pero compran más los aparatos que más teclas tienen, o pagan más por ellos. Si no fuera así, los móviles tendrían las diez teclitas con los números y un botón de colgar y descolgar, como siempre fue el teléfono fijo, y nadie echaba de menos más complicaciones. Tampoco se saben por adelantado las funciones que resultarán cruciales. Joel Spolsky, un desarrollador de programas que escribe habitualmente sobre sus experiencias, comenta que una vez recibió un editor de textos muy sencillo para publicar una reseña en el periódico. El programa destacaba por su sencillez, aludiendo los autores a que solo habían dejado las funciones realmente necesarias. Cuando Spolsky empezó a escribir, se dio cuenta de que el programa no contaba palabras, por lo que no le servía ni para escribir su propia reseña. El teorema de Pareto (el ochenta por ciento de la gente solo usa el veinte por ciento de las funciones) queda sustituido por el principio de Peter (las funciones que necesitas están en el otro ochenta por ciento). Por eso hace falta un manual, porque hay una multiplicidad de opciones para una gran diversidad de usos, y la visualización de una pantalla por las buenas no puede orientar sobre todas las tareas que se pueden realizar en un momento dado. ¿Y por qué un libro adicional, por qué no es suficiente el manual que viene con el programa? Esta pregunta es más fácil. Todo el mundo sabe que los manuales de los programas son malos. La razón es que existen diferentes tipos de usuarios. Algunos usuarios quieren que se les cuenten las interioridades del programa, la base conceptual, la forma en que el programa modela o simplifica la realidad, de lo cual en general se pueden deducir casi todos sus comportamientos. Este usuario prefiere conocer la lista de entidades soportadas, la estructura de la base de datos, las propiedades de cada elemento de información, y es capaz de deducir casi todo lo demás a partir de esos datos básicos. Otros usuarios se interesan por los comportamientos en sí, quieren saber qué opción tienen que usar en función de su problema concreto, pero no les gusta profundizar. Hay usuarios que van a dedicarle una parte importante de su tiempo al programa, y están dispuestos a leer y a practicar. Otros solo son usuarios casuales, que realizan tareas muy concretas, como visualizar ciertos datos o exportar a otro programa. El manual del fabricante tiene que presentar la información básica necesaria para entender el programa, pero no puede enfocarse exclusivamente en los intereses de un tipo de usuario ni le es posible atender a todos. El manual tiene que explicar todo aquello que no se puede detectar mirando la pantalla a simple vista, y debe hacerlo con claridad, pero no puede recrearse en el detalle ni en las alternativas. A veces, la explicación se puede realizar de forma muy sintética y correcta. Por ejemplo, se indica que «el precio real se calcula como precio medio ponderado de los suministros válidos», y se remite a otro lugar donde se enumeran las reglas de los suministros válidos. Algunos usuarios preferirían que estas reglas aparecieran repetidas en ese punto del manual; otros tal vez no entienden el concepto de precio medio ponderado y necesitan ver ejemplos numéricos; algunos, incluso, no aceptan que el coste real se calcule como un precio medio, y para ellos habría que añadir una explicación de por qué se ha tomado esta decisión, y de qué manera se puede manejar al programa para que calcule con otro criterio. Todo esto no se puede hacer sin alargar el texto, lo que dificulta la lectura y la búsqueda para el conjunto de usuarios, resultando todos perjudicados. Gracias a autores como Rodolfo de Benito y Ana Jesús Sánchez Granda es posible superar nuestras limitaciones, las de los autores de Presto. Este enorme esfuerzo de aprenderse el programa y proponer una forma distinta de describirlo supone una enorme ayuda para los usuarios, pero también para nosotros, porque nos descubre nuevas formas de utilizar el programa que nunca habríamos identificado; y porque nos alegra mucho saber que alrededor de Presto hay una comunidad de usuarios, desarrolladores y creadores de valor añadido que lo convierten en un eco-sistema productivo y fructífero para la comunidad de profesionales de la construcción, en todas sus especialidades. Mientras deseamos al libro tanto éxito como en ediciones anteriores, agotadas una y otra vez, seguiremos trabajando incansablemente para que no sea necesario reescribirlo en el futuro, sabiendo de antemano que hemos perdido esta batalla. Por más que intentemos simplificar el uso de Presto, la gestión de la construcción es cada vez más compleja; los documentos escritos del proyecto, más numerosos; y su peculiar modelo de costes –que permite a las empresas constructoras ofertar en pérdida y que luego la obra sea rentable– sigue siendo, con mucho, el más complicado de la industria de fabricación.

Fernando Valderrama Arquitecto por la UPM, Arquitecto técnico por la UEM, MBA por el IESE Director General de Soft Madrid, 29 de abril de 2009

No hay notas del Autor