docs.microsoft.com y el futuro de la documentación técnica

Si hubo un tema en el mundo de la redacción técnica que ocupó blogs y discusiones de Twitter en 2017 este fue, sin duda, Docs Like Code. Esta metodología, promovida inicialmente por Patrick Arlt (@patrickarlt) y desarrollada después por Anne Gentle (@annegentle), plantea un tratamiento de la documentación técnica con las mimas herramientas y métodos aplicados en el desarrollo de software. La atención suscitada por este nuevo planteamiento resulta llamativa en un espacio tan poco dado al cambio como el de la redacción técnica.

docs.microsoft.com

Y sin duda el ejemplo más destacado en la adopción de Docs Like Code es Microsoft, con su nueva plataforma documental docs.microsoft.com. La importancia de Microsoft no es solo cualitativa, por lo que el fabricante de Redmon representa en el ámbito tecnológico, es también cuantitativa, si tenemos en cuentas la cantidad y diversidad de documentación que desarrolla.

Tradicionalmente, la documentación técnica se ha asentado en los siguientes puntos:
  1. El desarrollo de contenido estructurado (encabezado por iniciativas como DITA).
  2. El uso de XML, como lenguaje para dar soporte a este contenido.
  3. La adopción de gestores de contenido, para su transformación y tratamiento.

docs.microsoft.com supone un cambio fundamental a este modelo -llamémoslo tradicional-, con una apuesta por artículos ligeramente estructurados, Markdown como lenguaje y GitHub como gestor de la información.

Si el paso del manual de usuario impreso al manual electrónico y de este al formato web son el resultado de sucesivos avances tecnológicos, el paso a este nuevo modelo documental solo puede explicarse por la irrupción de una nueva tecnología. Pero antes de entrar en ello, conviene repasar algunos conceptos.

Contenido estructurado

Explicar de qué hablamos cuando hablamos de contenido estructurado no es fácil. Esta dificultad radica en que “estructurado” es un concepto que ha cambiado considerablemente a lo largo del tiempo. Antes de la generalización del ordenador personal, todo contenido conforme a un cierto patrón podía considerarse como estructurado. Pensemos por ejemplo, en una receta de cocina donde, con pocas variaciones, se sigue una misma estructura: dificultad de la receta, tiempo de preparación, ingredientes y pasos.

Con la generalización del ordenador personal se presenta la necesidad de que el contenido pueda ser procesado por máquinas, con el objetivo de transformarlo e intercambiarlo más fácilmente con otras máquinas. Ya no basta con usar una sencilla plantilla de trabajo, es necesario que esta plantilla y las normas sean más rígidas, para que el contenido sea más uniforme y más fácilmente procesable por las máquinas (algoritmos, para ser más exactos).

Los escritores técnicos comenzamos así a escribir el contenido dentro de complejas plantillas, donde cada elemento (una lista, una tabla, un párrafo, una imagen, etc.) está perfectamente identificado y delimitado. El resultado es un contenido rigurosamente estructurado y que evita cualquier tipo de ambigüedad, facilitando su tratamiento y transformación por medios digitales.

XML

XML se convierte en el lenguaje de marcas que da soporte a este modelo de redacción técnica con un contenido altamente estructurado. Se dice que es un lenguaje de marcas porque emplea una serie de elementos, que diferenciamos con los símbolos < y >, para definir el contenido. Estas marcas representan la meta-información o semántica del contenido; en otras palabras, información sobre la información. Tomemos el siguiente ejemplo donde se describe una tarea usando el lenguaje XML:
Como se puede ver, la información de la tarea se mezcla con marcas que definen qué representa cada elemento, pero que hacen tremendamente difícil la lectura del texto.

Gestores de contenido

XML no fue diseñado para ser utilizado como lenguaje de escritura. Los textos escritos en XML son difíciles de leer o editar directamente. El que haya sido adoptado como lengua franca en documentación técnica se explica sólo por la necesidad de automatizar el tratamiento del contenido por máquinas.

Esta complejidad, inherente a XML, hace a su vez difícil gestionar la información escrita en este lenguaje. Como solución a este problema, hace varios años comenzó a popularizarse el uso de Gestores de Contenido (conocidos normalmente por su siglas en Inglés CMS, o Content Management Server). El gestor de contenido es, en síntesis, una base de datos en la que se almacenan y clasifican fragmentos de texto XML, y donde se automatiza el tratamiento de la información.

Hacia un nuevo modelo

Es innegable que XML, el lenguaje estructurado y los gestores de contenido han facilitado el avance de la redacción técnica, pero también lo es que este avance corre paralelo a una mayor complejidad en el tratamiento de la información. Estas tecnologías han hecho el contenido más fácil de procesar para las máquinas pero, al mismo tiempo, más difícil de procesar por las personas. La promesa de los gestores de contenido como solución a esta complejidad no siempre se ha visto cumplida. En este contexto no resulta extraño que empresas como Microsoft abandonen el modelo de gestión tradicional.

Por un lado, en docs.microsoft.com, Microsoft sustituye el uso de XML por Markdown, un lenguaje de marcas ligero cuyo uso y popularidad no ha dejado de crecer en los últimos años. La principal ventaja de Markdown es su sencillez y legibilidad. Hay que tener en cuenta que leer o escribir un texto en XML resulta muy complejo. La redacción en XML se apoya en programas especializados que ocultan las etiquetas del lenguaje, y la revisión de textos requiere su transformación a un formato intermedio (como PDF) que pueda ser interpretado por el revisor. Este hecho se traduce en numerosas horas de trabajo para transformar el fichero XML y ajustar el resultado final. No es extraño que muchos redactores técnicos tengan la sensación de trabajar más tiempo en transformar documentos que en la mejora de su contenido. La sencillez de Markdown rompe con este esquema y permite al redactor hacer un uso más eficiente de su tiempo.

Una de las principales críticas al uso de Markdown en documentación técnica es que carece de capacidades semánticas. Es decir, no podemos definir, como hacemos con las etiquetas en XML, la meta-información del contenido. La consecuencia inmediata es que no es posible trabajar de forma estructurada (en sentido estricto) con Markdown. Del mismo modo, tampoco existe la necesidad de trabajar con un gestor de contenido tradicional. Esto permite a Microsoft optar en docs.microsoft.com por una gestión simplificada del contenido, donde los ficheros se organizan en la plataforma de desarrollo GitHub siguiendo una estructura simple de carpetas, muy similar a lo que podemos encontrar en nuestro ordenador. Se diría que Microsoft da un paso atrás, al ignorar los procesos establecidos y probados en documentación técnica. Personalmente, creo que este es un paso muy calculado.

Google y la inteligencia artificial

Si buscamos imágenes del término “flor” en Google, el resultado será un enorme listado de fotos de flores. Esto no deja de ser obvio. Pero pensemos en ello por un momento. ¿Qué hace que esto sea posible?

El contenido que existe en internet no se encuentra meticulosamente clasificado con etiquetas que permiten identificarlo como una flor o como cualquier otro objeto. De hecho, es difícil imaginar un contenido más dispar y desestrucutrado que la web. Clasificar el contenido de internet con reglas de procesamiento estrictas resulta imposible. La única forma de enseñar a Google qué es una flor, es exponiendo este motor de búsqueda a muchas imágenes de flores, y asociando esas imágenes al término “flor”. Las máquinas han empezado así a aprender conceptos del mismo modo que nosotros: por asociación y repetición. Esto es, en síntesis, a lo que llamamos inteligencia artificial.

Durante años los seres humanos nos hemos dedicado a modelar la información para que pudiera ser fácilmente procesada por las máquinas. Pero mientras nos afanábamos en esta tarea, las máquinas han aprendido a adquirir conocimiento como humanos a mayor velocidad. El comunicador Mark Baker (@mbakeranalecta) explica de forma excepcional esta idea en su artículo Quality in Structured Writing.

La inteligencia artificial no es solo una nueva tecnología que mejora y sustituye a la anterior; es un cambio tecnológico fundamental que transformará nuestra manera de relacionarnos con las máquinas. Este es, precisamente, el salto tecnológico que permite a Microsoft el paso de un modelo de redacción técnica tradicional, al modelo Docs Like Code. Si las máquinas parecen haber desarrollado capacidades avanzadas para interpretar el contenido no estructurado que les ofrecemos, ¿qué sentido tiene seguir invirtiendo cantidades enormes de tiempo en estructurar ese contenido?

Tiendo a pensar -es una mera especulación- que Microsoft hizo este razonamiento durante el desarrollo de docs.microsoft.com. ¿Es XML un lenguaje más potente y robusto que Markdown? Sin duda. ¿Son los gestores de contenido herramientas que facilitan las tareas documentales? Absolutamente. ¿Es la escritura estructurada clave para el tratamiento eficaz de la información? Cierto. Todas estas son soluciones válidas, pero su justificación pierde fuerza cuando las máquinas comienzan a razonar como nosotros y, en ocasiones, mejor que nosotros.

Usuarios que escriben

Visto con el prisma de la Inteligencia Artificial, la adopción de un modelo documental Docs Like Code parece un paso lógico para Microsoft. Pero esta no es la única razón. Uno de los objetivos de docs.microsoft.com es hacer accesible la documentación al usuario final, permitiendo que este proponga cambios o mejoras o, incluso, que añada nuevo contenido.

Los gestores de contenido, el lenguaje estructurado y XML son herramientas especializadas que requieren de un conocimiento fuera del alcance del usuario final. En la práctica, la participación del usuario en el desarrollo de la documentación resulta imposible con el modelo tradicional. La simplicidad del modelo Docs Like Code, por contra, fomenta esta participación al simplificar todo el proceso de autoría. En palabras del comunicador y redactor técnico Tom Johnson (@tomjohnson):

No resulta práctico pedirle a las personas de la comunidad -que no son escritores técnicos y que no tienen las herramientas y conocimientos necesarios- que escriban en formatos estructurados. Tomar contribución de las masas requiere que simplifiques tu modelo de autoría. Termina convirtiéndose en una elección. O tomas la ruta de creación de contenido estructurado o tomas la ruta de la colaboración.

El crecimiento del número de artículos en docs.micrsoft.com, y la incorporación continua de mejoras, parecen indicar que Microsoft ha dado con las solución correcta. Una solución que simplifica enormemente el desarrollo y gestión de la documentación técnica, que permite al redactor centrarse en la mejora del contenido y la incorporación continua de cambios, y que ofrece al usuario final un canal de participación accesible durante todo el proceso.

Documentación sin fricción

En marketing, fricción se define como la resistencia psicológica del consumidor a realizar una compra. Los consumidores queremos obtener el producto deseado, pero sin vernos obligados a un tedioso proceso para ello. Una página web poco intuitiva o una larga cola de clientes en un mostrador pueden echar atrás a un comprador inicialmente convencido. De igual forma, los usuarios buscan poder resolver sus dudas en el manejo de herramientas, pero -cada vez más- sin recurrir al manual de instrucciones.

El manual

“Los usuarios no leen documentación”. Esta afirmación, muy popular entre los redactores técnicos es, sin embargo, incompleta. Como señala el comunicador Mark Baker en su artículo Usersʼ Advocate: Nobody Reads Documentation, los usuarios no leen documentación, de la misma forma que tampoco leen recetas de cocina o diccionarios. Los usuarios consultan:

Hay una gran diferencia entre consultar una fuente de información y leerla. La lectura puede tomar horas o días. La consulta lleva minutos o segundos. La lectura requiere tiempo para la actividad de leer. La consulta tiene lugar en el contexto de otra actividad.

Pero consultar la documentación obliga, en cualquier caso, a detener la tarea que llevamos a cabo para realizar la consulta. Si la ayuda no está integrada en el producto, nos encontramos con el problema añadido de encontrarla. No resulta extraño que todos recurramos a Google o al compañero más cercano para resolver nuestras dudas. 

Pensemos por un momento en la última vez que apareció un error en el panel de nuestro electrodoméstico o el salpicadero del coche. ¿Cuál fue nuestra primera reacción? Google. Consultar internet para resolver una duda se ha convertido ya en un acto reflejo. Y si no obtenemos una respuesta satisfactoria, la mayoría de nosotros contactará con el servicio técnico. Buscar información sobre el error en el manual es siempre nuestra última opción.

Consumidores y fricción

Pero, ¿por qué ocurre esto? En marketing se habla de puntos de fricción para analizar los factores que se interponen entre el consumidor y la adquisición de un producto o servicio. La fricción puede tener un origen interno (nuestra conciencia recordándonos que no podemos permitirnos ese coche nuevo) o externo (una larga cola en el supermercado). Cuantos menos puntos de fricción, más posibilidades de compra. 

Las empresas conocen bien este hecho, y buscan eliminar -o reducir- la fricción proporcionando a los clientes la mejor experiencia de compra posible. No es casualidad que aquellas empresas que mejor entienden estos factores sean líderes en su sector. Veamos solo unos ejemplos que nos ayudarán a entender mejor este concepto:

Amazon. Mediante el uso de su botón “1-click”, Amazon elimina instantáneamente el tedioso proceso de completar nuestros detalles durante el pedido (dirección, forma de pago, método de envío, etc.). Pero Amazon va más allá en este proceso, con lo la posibilidad de pedir productos con nuestra voz usando el asistente Alexa, o usar un simple botón físico para, de manera instantánea, hacer la compra del detergente o el papel higiénico.

Apple. La calidad y la atención por el detalle y el diseño de los productos de Apple es difícil de cuestionar. Pero para muchos consumidores estos factores no justifican el alto precio que es necesario pagar para adquirir estos productos. Apple conoce este hecho, y por ello ofrece la posibilidad de ver y tocar sus productos en las diferentes tiendas físicas Apple Store repartidas por todo el mundo (unas 500 en la actualidad). Esta posibilidad, junto con una experiencia de compra cuidada y un entorno que permite experimentar libremente con el producto, reducen considerablemente la oposición inicial del comprador. 

Uber. Independientemente del dilema ético que a muchos nos supone usar Uber, el éxito de este servicio de transporte privado es innegable. En muchas capitales del mundo, Uber es ya el medio de trasporte privado por defecto. Como señala Scott Galloway (@profgalloway) en su libro “The Four”, el éxito de Uber no se debe a su sofisticado sistema de seguimiento por GPS, ni tampoco al menor coste del servicio en comparación con un taxi tradicional, sino a la facilidad de pago. El coste se carga automáticamente usando el método de pago seleccionado en la aplicación, sin que sea necesario buscar monedas y billetes apresuradamente en la oscuridad del asiento de atrás.

El momento del pago es un punto de fricción frecuente. Empresas como Uber han sabido entenderlo; otras fallan estrepitosamente. Un buen ejemplo son las compañías aéreas: ¿por qué tengo que pagar en el momento de pedir un café durante un vuelo si la compañía aérea tiene ya todos mis datos (asiento, nombre, dirección de correo electrónico, tarjeta de crédito)?

Documentación sin fricción

Los redactores técnicos podemos aprender mucho de las estrategias empleadas por estas empresas. Si la fricción es la barrera que separa a nuestros usuarios de la documentación, la solución no puede ser otra que buscar fórmulas que la hagan más accesible. Planteo aquí algunas de estas fórmulas. 

Internet

Señalar la importancia de tener la documentación en formato web en internet puede sonar fuera de lugar en 2018. Pero es sorprendente la cantidad de productos que carecen de una documentación publicada en formato accesible, como HTML. Merece la pena recordar que tener la documentación en internet no significa colgar un manual en PDF en una página web.

Internet es ya (desde hace tiempo) el medio en que todos nos movemos y nuestros teléfonos móviles, el vehículo para navegar en él. Disponer de la documentación de un producto en internet, de forma accesible, es el mínimo exigible a cualquier fabricante.

Ayuda integrada y contextual

Pero no basta con que la ayuda esté en en internet. Si el usuario ha de abandonar su medio de trabajo para consultar la documentación, estamos añadiendo un punto de fricción. En este sentido, es fundamental integrar el manual en el uso del producto. En resumen, llevar la ayuda al usuario y no al revés.

La ayuda tiene que ser, además, sensible al contexto. En otras palabras, capaz de responder a las acciones que se desarrollan en la pantalla. La ayuda contextual mostrada por herramientas como Google Sheets o Smartsheet cuando editamos una fórmula es un buen ejemplo de esto. Integración y contextualización son las claves.

Ayuda multicanal

Los redactores técnicos seguimos pensando en la documentación en términos de formato (PDF, Word, HTML, etc.) y no en términos de medio, olvidando la importancia de que la información sea accesible desde cualquier lugar donde el usuario desarrolla su tarea. Para el trabajador de una fábrica este medio puede ser un manual físico, para el empleado de oficina puede ser internet, y para la enfermera que asiste un paciente en un domicilio, el teléfono móvil.

Un ejemplo de esto lo tenemos en la cadena de cosméticos Sephora. Sephora brinda a sus clientas una experiencia de compra multicanal, donde la tienda actúa como el espacio lúdico, pero donde la posibilidad de probar, reservar y pagar el producto se puede realizar desde distintos medios: página web, aplicación para el móvil o un chatbot integrado en un programa de mensajería como Messenger.  Sephora ha sabido entender que la forma más eficaz de llegar a sus clientas es estando disponible donde ellas centran su ocio. Y ese ocio se desarrolla (cada vez más) en la pantalla de nuestro teléfono móvil.

Realidad aumentada

La realidad aumentada (conocida por las siglas en inglés AR, de Augmented Reality) no es un concepto nuevo, como tampoco lo es su aplicación en la documentación técnica. Pero esta tecnología no ha sido una realidad palpable hasta hace pocos meses. La razón es simple: la tecnología necesaria aún no estaba disponible. La novedad es que ahora esta tecnología, limitada inicialmente a entornos muy concretos y con un alto coste de producción, se ha generalizado.

Gracias a la realidad aumentada (no confundir con la realidad virtual) nuestro teléfono móvil puede reconocer los elementos del mundo real (dimensiones, distancia entre objetos, iluminación, etc.) y superponer en este objetos no reales. Un buen ejemplo de esto es la aplicación de Ikea, que nos permite probar cómo quedarían los muebles en casa.

En 2017 Apple presentó ARKit, un conjunto de herramientas mediante las cuales los desarrolladores pueden crear aplicaciones de realidad aumentada para dispositivos iOS. Pocos meses después Google hizo lo propio con ARCore, destinado al desarrollo de aplicaciones Android. Estas herramientas, junto con los teléfonos móviles de última generación, ponen esta tecnología en nuestros bolsillos.

La realidad aumentada brinda posibilidades de asistencia y formación al usuario que no habían sido posibles hasta el momento. Pensemos por un momento en la capacidad de enfocar un objeto con nuestro teléfono móvil o tableta y obtener una visualización superpuesta de la ayuda para cada una de sus partes.

Chatbots

En el artículo ¿Son los bots el futuro de la documentación? hablé ya de las posibilidades que los asistentes conversacionales (o chatbots) ofrecen para comunicar con el usuario en su propio lenguaje y medio. Estoy convencido de que los chatbots, junto con la realidad aumentada, tendrán un papel clave en la documentación de productos de software y productos físicos respectivamente.

Un buen ejemplo de la aplicación de estos dos elementos lo encontramos (de nuevo) en Sephora. Desde las aplicaciones de esta cadena de cosmética, las clientas pueden conversar con un chatbot para obtener información sobre productos, reservar una sesión de maquillaje o pedir recomendaciones acerca de los colores más apropiados para el tono de piel. Sephora brinda también la posibilidad de probar los productos directamente en la aplicación, a través de una interfaz de realidad aumentada que emplea reconocimiento facial.

Empresas como Sephora, Amazon o Uber han entendido que eliminar fricciones es la clave para facilitar el acceso a un producto o servicio. Los redactores técnicos debemos de entender los puntos de fricción generados por la documentación, y realizar la transformación necesaria. Si no lo hacemos, corremos el riesgo de que la documentación deje de ser relevante. O peor, que el usuario abandone nuestro producto en favor de otra empresa que sí ha llevado a cabo esta transformación. 

The Cathedral and the Bazaar

The shift towards agile software development models, with continuous integration processes and publication of new features, forces us as technical writers to review our own working methods. Leaving behind the model imposed by the traditional CMS and integrating documentation tasks into the development cycle is now more necessary than ever.

The Cathedral and the Bazaar

In 1999, Eric S. Raymond, one of the leading representatives of the open source initiative, published his essay entitled The Cathedral and the Bazaar. In this popular essay, Raymond writes about his experiences during the development of open code software, at the same time as he encourages programmers and companies to embrace this work philosophy.

Raymond uses the concepts of cathedral and bazaar to exemplify two quite distinct development models. The cathedral represents the development of proprietary software, where the source code is only accessible to a small group of programmers. The bazaar, on the other hand, represents the development of open source software, where the code is accessible to collaborators. The rigidity of a cathedral stands as a metaphor for a closed, centralized system, whereas the dynamism of a bazaar represents an open, collaborative system. Raymond maintains that the possibility of incorporating improvements and eliminating errors is much more extensive in a collaborative model than in a centralized one. The conclusion is that the software resulting from a collaborative model has fewer errors and is necessarily of higher quality.


The thesis explored in The Cathedral and the Bazaar has given rise to lots of discussions among those defending and criticizing open source software. The collaborative model is not free from problems, but offers advantages that make it attractive to many software development companies. It is not unusual to see such companies looking nowadays for formulas enabling them to adopt their own open source methodologies without renouncing their control of the code and intellectual property over the same.

In parallel, software development tools are incorporating more and more features that enable the principles of collaborative development to be extended to teams of workers. Together with this, the process of continuous integration and continuous delivery (known by the initials CI/CD) enables new features to be rolled out and errors to be resolved relatively quickly. Suffice to think just about the frequency with which many of the apps on our mobile telephones are updated.

The problem with content management systems

It is strange to see how this change in development methodologies has had scant repercussion on software documentation. This field continues to be founded on tasks of drafting, review, and publication that, in essence, have changed little in recent years. For writing, XML is still the standard markup language. More often than not, reviewing is still done using PDF files or, even worse, over email. And publication, which has gradually shifted to the web, often requires hours of adjustments to generate the correct PDF or HTML file.

This workflow is today sustained by complex Content Management Systems (CMS) that aim to solve the documentation needs of many different organizations at one fell swoop, but end up not entirely solving the needs of any of them.


But the fundamental problem lies in the fact that a traditional CMS understands the drafting, review, and publication tasks as actions that follow each other in orderly fashion over time and not, as so often seen in experience, all at the same time. An added problem is that the possibility of incorporating improvements from collaborators is limited to the review phase, with the documentation effectively ring-fenced for most of its development cycle.

“Ditch your CMS”

In 2014, Patrick Arlt (@patrickarlt), in the context of the Write the Docs conferences, gave a presentation titled Ditch Your CMS With Git and Static Site Generators. In this presentation, Arlt advocates abandoning the use of content management systems in favour of open code tools that favour collaboration and reduce the complexity oy documentation project.

A year later, in April, 2015, Anne Gentle (@annegentle) described the documentation process adopted by the OpenStack software manufacturer in her article entitled Git and GitHub for open source documentation. The model proposed by Gentle (subsequently developed in greater detail in her book Docs like code) proposes that technical writers should work alongside the development teams, adopting their same tools and methodologies. Because, if a software’s documentation is an integral part of the product and is produced in parallel, isn’t it more consistent to use the same workflows? In this new paradigm, writing documentation is not that different from writing code.

In summary, the Docs like Code methodology proposes:

  • Ditching the use of traditional CMS systems in favour of collaborative tools like GitHub (a code repository very popular with developers).
  • Adopting lightweight markup languages, abandoning complex languages like XML. The best-known example of these languages is Markdown.
  • Incorporating continuous review processes where reviewers can record changes at any time using pull-request mechanisms offered by GitHub.
  • Publishing product documentation regularly through the use of static page generators that enable the texts in Markdown format to be transformed into HTML code.

GitHub

Millions of developers all over the world use GitHub as the repository for their application code. But what makes GitHub such an attractive environment for amateur coders, independent developers and companies? The commercial success of GitHub has been born out of its ability to simplify the use of the Git tool (a software utility originally created to manage the development of Linux) in an easy-to-use web interface. In addition, GitHub facilitates the collaboration of multiple people on the same project in a relatively straightforward way. The complexity and scalability needs of modern software have made this feature essential.

Yet this change in software development methods is not so far away from what is happening in the documentation arena. While a manual was the responsibility of a single technical writer in the past, nowadays, with growing technological complexity and the constant integration of changes, the final result requires collaboration and co-ordination involving multiple individuals. The cathedral model imposed by content management systems has not been able to respond to this change.

The time has come

Far from being a mere concept, Docs like Code is also a reality for software companies as important as Microsoft, Amazon, or Twitter. In May, 2016, Jeff Sandquist (@jeffsandannounced Microsoft’s new documentation platform docs.microsoft.com in the following terms:
All documentation is designed to allow community contributions. Every article has an Edit button that takes you to the source Markdown file in GitHub where you can easily submit a pull request to fix or improve content.
A large part of the manufacturer’s documentation is already located on this new documentation platform in a clear wager in favour of the adoption of open systems. Other companies such as Amazon have followed this trend and it is now possible to see an “Edit on GitHub” button on many of the articles intended for developers.



In an article on the I’d Rather Be Writing blog, the specialist in documentation and technical writer Tom Johnson wrote a comment that goes to the root of the problem of using CMS:

No more black boxes that handle your content. No more expensive, proprietary systems to submit to. No more impossible-to-adjust-outputs. You can integrate it all simply, easily, and inexpensively.

The enormous influence these companies have in the world of software will, sooner or later, bring about the adoption of open bazaar-type documentation models to the detriment of rigid cathedral-type models. If effective and agile software development is the result of a collaborative process of continuous integration and publication, then documentation projects must necessarily adapt to this new reality.

(This article was originally published in Spanish and translated into English)

¿Es LinkedIn prescindible?

“Hay mucho talento fuera de LinkedIn”. Así resumía mi buen amigo José Manuel su experiencia con esta plataforma para profesionales en una conversación reciente. Esta afirmación no pasaría de un simple comentario si no fuera porque muchos -entre los que me incluyo- encontramos cada vez menos razones para participar en esta red.

Misión frente a realidad

LinkedIn, con más de 500 millones de usuarios, se define en su página Sobre nosotros como “la mayor red profesional del mundo”. Junto a esta afirmación, podemos leer:
Nuestra misión es sencilla: conectar a los profesionales del mundo para ayudarles a aumentar su productividad y rendimiento. Al unirte a LinkedIn obtienes acceso a personas, empleos, noticias, actualizaciones e información que te ayudará a destacar en tu campo profesional.
Pero basta un simple vistazo a esta plataforma para comprobar que la realidad dista mucho de esta noble misión. Y es que lejos de ser una red profesional, LinkedIn se ha convertido en una red social más. El problema fundamental es que en esa socialización LinkedIn está dejando de ser relevante para su masa de usuarios. Estas son solo algunas de las razones que ponen en evidencia la pérdida de valor del portal:

Las conexiones son irrelevantes. Las sugerencias de contactos se basan fundamentalmente en personas de nuestra propia empresa o de empresas en las que hemos trabajado anteriormente, pero resulta mucho más difícil encontrar contactos de nuestra profesión en otras empresas (algo sin duda mucho más interesante). Ocurre además que tras establecer una conexión de interés, rara vez se produce un intercambio de experiencias o ideas, precisamente porque la plataforma no ofrece ningún medio para ello. ¿El resultado? un simple engorde del número de conexiones sin ninguna utilidad real.

El sector tecnológico lo es todo. LinkedIn se ha posicionado claramente como una red para profesionales de IT. La explicación es sencilla si tenemos en cuenta el nuevo auge del sector tecnológico, con una demanda cada vez mayor de desarrolladores. Este factor se traduce en un número creciente de visitas (en otras palabras, impactos publicitarios) a contenidos y ofertas de este sector, relegando a un segundo plano al resto de contenidos.

Sin conexiones las publicaciones no tienen repercusión. LinkedIn da relevancia a los artículos y publicaciones de aquellas personas con mayor número de conexiones. Este hecho resulta obvio, pero tiene como consecuencia una pérdida del diferencial profesional de la red. La razón es que muchos usuarios buscan establecer conexiones con el único objetivo de incrementar el impacto de sus publicaciones, echando por tierra el valor profesional de estas conexiones, y de la plataforma en general.

El contenido de valor es casi inexistente. Si dejamos de lado las frases inspiradoras y célebres -repetidas hasta la saciedad-, los enlaces de autobombo, o las noticias que pueden encontrarse en cualquier otro sitio, los artículos jugosos o las actualizaciones que merecen la pena son casi inexistentes.

Instagramificación de la plataforma. En un intento por atraer un público más joven, LinkedIn ha introducido recientemente cambios que pretenden hacer más social su uso. El nuevo diseño, la aparición de las actualizaciones de estado, la incorporación de vídeo en directo o la ventana persistente de chat son muestras de ello. Pero es dudoso que LinkedIn consiga con esta estrategia atraer a un público más joven sin alienar su base existente de usuarios.


Titulitis y postureo. Estos son solo algunos de los títulos que podemos encontrar en esta red: Digital Transformer, Motivational Coach, Inno-Líder, Profesional 360°, Líder coach, Impulsor del bienestar integral, Über Tech Lead, etc.

Es difícil expresar la vergüenza ajena que provoca ver estos títulos en personas que -estoy seguro- son perfectamente válidas para realizar su trabajo, pero que no han dudado ni un instante en sumarse a la espiral de titulitis que inunda esta red. Lamentablemente, esta competición por el título más original esconde en no pocos casos la inseguridad de quien lo usa. Tampoco podemos pasar por alto el postureo de mostrar en el perfil un largo listado de grupos en los que jamás hemos hecho una aportación.

Me ahorro aquí muchas otras razones por las que pienso que el beneficio que se obtiene de LinkedIn es muy cuestionable, como el valor nulo de los endorsements, o una configuración de las opciones de privacidad intencionadamente abierta y confusa que consigue justo lo contrario: la falta de privacidad.

Peligros

Pero si LinkedIn fuese solo eso, una red social más, no pasaría de un entretenimiento inocuo. Lejos de ser así, nuestra presencia (activa o pasiva) conlleva ciertos riesgos:

Privacidad. Exponemos una gran cantidad de información personal, sin que quede claro quién es el destinatario de esta información y qué uso se hace de ella. La sentencia resuelta recientemente por un tribunal de EE.UU. a favor de una empresa que comercia con nuestros datos en LinkedIn, pone en evidencia este peligro.

Sexismo. Las actitudes sexistas contra las mujeres dentro de la plataforma se están convirtiendo en habituales, y no son pocas las que reciben solicitudes de contacto con fines no profesionales. La orientación de este portal hacia el sector tecnológico (donde los hombres son una abundante mayoría) solo puede acrecentar este problema. Los últimos cambios en la red, con un giro evidente a lo social, no parecen ser la forma más adecuada de atajar un sexismo rampante.

Distracción. Las alertas sobre visitas a nuestro perfil, las actualizaciones de nuestra red de contactos y un largo etcétera de notificaciones, disminuyen nuestra capacidad de atención y concentración. Y lo que es peor, ponen en peligro nuestro propio desarrollo profesional. Como indica Carl Newport (autor de títulos como So good they can’t ignore you o Deep work) “el valor en la nueva Economía no está en nuestro número de seguidores o likes, sino en la capacidad para enfocarnos intensamente en nuestro trabajo y ofrecer un valor único”.

“¿Qué hacen los cazatalentos en LinkedIn?”

Una vez más, José Manuel daba en la diana con esta pregunta durante nuestra conversación. Y es que si el valor de la plataforma es dudoso para los candidatos, resulta aún más difícil entender qué hace un cazatalentos en LinkedIn. Antes de LinkedIn y la popularización de las redes sociales, estos profesionales creaban una base de datos de perfiles. El cazatalentos funcionaba así como un curator de los candidatos más adecuados para las distintas ofertas de cada cliente, alimentando su base de datos con nuevos candidatos y manteniendo reuniones para conocer mejor las inquietudes profesionales y objetivos de los mismos.

LinkedIn se ha convertido hoy esa base de datos, y las reuniones han dado paso al envío indiscriminado de mensajes desde las cuentas Premium de la plataforma. El listado casi infinito de posibles candidatos y la facilidad para contactar con ellos hacen de LinkedIn la solución más lógica. Pero si todo se reduce a dar de alta una cuenta Premium y usar las capacidades avanzadas de búsqueda y envío de mensajes, ¿para qué necesito contratar a una empresa de cazatalentos? ¿Cuál es el valor añadido? Bajo este nuevo paradigma, el cazatalentos ha pasado a convertirse en un intermediario, y si hay algo nos ha enseñado internet es que los intermediarios son prescindibles y quien sobrevive es quien aporta un valor añadido.

Maury Hanigan (@rethinkhiring), en su artículo How LinkedIn Fundamentally Ruined Recruitmentexplica en más detalle esta situación y apunta:

Lo que falta en la contratación en la era de LinkedIn es la conexión personal. Fue la profunda comprensión de los candidatos lo que hizo a los cazatalentos tan exitosos.

¿Qué hago yo en LinkedIn?

La mayoría de nosotros pensamos que mantener nuestra red activa nos deparará, más tarde o más temprano, el trabajo o proyecto soñado. Pero las posibilidades de que esto ocurra son extremadamente remotas. Si echo la vista atrás, me doy cuenta de que los cambios que han marcado mi carrera profesional han sido siempre fruto de una interacción en la vida real con otras personas. Los conocidos (o conocidos de conocidos) son casi siempre las casualidades que nos llevan a nuestro siguiente empleo o proyecto. No creo que LinkedIn sea una herramienta inútil, pero sí estoy convencido de que es un medio al que otorgamos mucha más importancia y tiempo del que merece.

Volviendo a la pregunta que abre este artículo, ¿es LinkedIn prescindible? Mi conclusión es que no es imprescindible. Si buscamos en Google una persona o empresa, es muy probable que uno de los primeros resultados sea un enlace a LinkedIn. Si estoy en una situación de búsqueda de empleo o pretendo dar a conocer mi empresa al mundo, desaprovechar el posicionamiento de esta plataforma en los motores de búsqueda carece de sentido. En cualquier otra circunstancia creo que su utilidad es muy limitada.

¿Puede LinkedIn convertirse en una red profesional verdaderamente útil? No pondría mis esperanzas en ello. Los cambios incorporados recientemente a la plataforma están claramente dirigidos a los millennials, que no parecen encontrar razones para crear o mantener un perfil en esta red. Es probable que estos cambios se traduzcan en una mayor cuota de usuarios a medio plazo, pero sin duda convertirán a LinkedIn un servicio aún más irrelevante. Los usuarios de mi generación (+40) ven cada vez menos sentido en este posicionamiento hacia lo social, y los más jóvenes necesitan establecer conexiones reales que les permitan acceder al mundo laboral y progresar en su carrera, no una mala copia de Facebook.

La catedral y el bazar

El cambio hacia modelos de desarrollo de software ágiles, con procesos continuos de integración y publicación de nuevas funcionalidades, nos obliga como redactores técnicos a revisar nuestros propios métodos de trabajo. Abandonar el modelo impuesto por el gestor de contenidos tradicional e integrar las tareas documentales en el ciclo de desarrollo es ahora más necesario que nunca.

La catedral y el bazar

En 1999, Eric S. Raymond -uno de los principales representantes de la iniciativa de código abierto- publicó su ensayo La Catedral y el Bazar. En este popular ensayo, Raymond relata su experiencia durante el desarrollo de software de código abierto, a la vez que anima a los programadores y empresas a adoptar esta filosofía de trabajo.

Raymond utiliza los conceptos de catedral y bazar para ejemplificar dos modelos de desarrollo bien diferenciados. La catedral representa el desarrollo de software propietario, donde el código fuente es accesible solo a un reducido grupo de programadores. Por el contrario, el bazar representa el desarrollo de software de código abierto, donde el código es accesible a colaboradores. La rigidez de una catedral sirve de metáfora de un sistema cerrado y centralizado, mientras que el dinamismo de un bazar representa un sistema abierto y colaborativo. Raymond defiende que la posibilidad de incorporar mejoras y eliminar errores es mucho más amplia en un modelo colaborativo que en uno centralizado. La conclusión es que el software resultante de un modelo colaborativo incorpora menos errores y es, necesariamente, de mayor calidad.


La tesis expuesta en La Catedral y el Bazar ha sido motivo de discusión entre defensores y detractores del software de código abierto. El modelo colaborativo no está exento de problemas, pero ofrece ventajas que lo hacen atractivo para muchas empresas de desarrollo. No resulta extraño ver cómo estas empresas buscan hoy fórmulas que les permitan adoptar metodologías propias del código abierto sin renunciar al control del código y de la propiedad intelectual del mismo.

Paralelamente, las herramientas de desarrollo de software incorporan cada vez más funcionalidades que permiten llevar los principios de desarrollo colaborativo a los equipos de trabajo. Unido a esto, el proceso de integración y entrega continua (conocido por las siglas en inglés CI/CD, o continuous integration/continuous deployment) permite publicar nuevas funcionalidades y solucionar errores con relativa rapidez. Pensemos solo en la frecuencia con la que se actualizan muchas de las apps en nuestros teléfonos móviles.

El problema con los gestores de contenido

Resulta extraño ver cómo este cambio en las metodologías de desarrollo ha tenido escasa repercusión en la documentación de software. Este campo sigue asentado en tareas de redacción, revisión y publicación que, en esencia, han cambiado poco en los últimos años. En la escritura, XML sigue siendo el lenguaje de marcado estándar. La revisión en muchos casos se realiza aún mediante archivos PDF o, lo que es peor, a través del correo electrónico. La publicación, que progresivamente ha pasado al medio web, requiere en muchos casos de horas de ajustes para generar el archivo PDF o HTML correcto.

Este flujo de trabajo está hoy sustentando por gestores de contenido (conocidos por las siglas en inglés, CMS) complejos, que pretenden resolver las necesidades documentales de muchas organizaciones a la vez, pero que terminan por no resolver enteramente las necesidades de ninguna.


Pero el problema fundamental reside en que el gestor de contenidos tradicional entiende las tareas de redacción, revisión y publicación como acciones que se suceden ordenadamente en el tiempo y no, como demuestra la experiencia, de forma conjunta. Como problema añadido, la posibilidad de incorporar mejoras por parte de los colaboradores está limitada a la fase de revisión, quedando la documentación efectivamente cerrada durante la mayor parte de su ciclo de desarrollo.

"Tira tu CMS"

En el año 2014 Patrick Arlt (@patrickarlt), en el marco de las conferencias Write the Docs, realizó la presentación Tira tu CMS (titulada originalmente Ditch Your CMS With Git and Static Site Generators). Arlt plantea en esta presentación abandonar el uso de gestores de contenido en favor de herramientas de código libre que favorecen la colaboración y reducen la complejidad del proyecto documental.

Un año después, en Abril de 2015, Anne Gentle (@annegentle), describía el proceso documental adoptado por el fabricante de software OpenStack en su artículo Git y GitHub para una documentación fuente abierta (originalmente, Git and GitHub for open source documentation). El modelo propuesto por Gentle -que posteriormente desarrollaría con más detalle en su libro Docs like code- propone al redactor técnico trabajar de manera conjunta con los equipos de desarrollo, adoptando las metodologías y herramientas de estos equipos. Porque si la documentación de un software es parte integral del producto y se realiza en paralelo, ¿no resulta más coherente que los flujos de trabajo sean los mismos? Bajo este nuevo paradigma, escribir documentación no dista mucho de escribir código.

En síntesis, la metodología Docs like Code propone:
  • Abandonar el uso de gestores de contenido tradicionales en favor de herramientas colaborativas como GitHub (un repositorio de código muy popular entre los desarrolladores).
  • Adoptar lenguajes de marca ligeros (del inglés, lightweight markup languages) como formato, abandonando lenguajes complejos como XML. El ejemplo más conocido de estos lenguajes es Markdown.
  • Incorporar procesos de revisión continuos donde los revisores puedan registrar cambios en cualquier momento mediante los mecanismos de pull-request ofrecidos por GitHub.
  • Publicar regularmente la documentación del producto mediante el uso de generadores estáticos de páginas, que permiten transformar los textos en formato Markdown en código HTML.

GitHub

Millones de desarrolladores en todo el mundo usan GitHub como repositorio para el código de sus aplicaciones. Pero, ¿qué hace de GitHub un entorno tan atractivo para los aficionados, desarrolladores independientes y empresas? El éxito comercial de GitHub nace de su capacidad de simplificar el uso de la herramienta Git (una utilidad de software creada originalmente para gestionar el desarrollo de Linux) en una interfaz web fácil de usar. GitHub facilita además que múltiples personas pueden colaborar en un mismo proyecto de manera relativamente sencilla. La complejidad y diversidad del software actual convierten en imprescindible esta capacidad de la plataforma para escalar fácilmente.

Pero este cambio en los métodos de desarrollo de software no dista mucho de lo que ocurre en el ámbito de la documentación. Si en el pasado un manual era responsabilidad de un único redactor técnico hoy en día, con la creciente complejidad tecnológica y la integración continua de cambios, el resultado final precisa de la colaboración y coordinación de múltiples personas. El modelo de catedral impuesto por los gestores de contenido no ha sido capaz de dar respuesta a este cambio.

El momento es ahora

Lejos de ser solo un concepto, Docs like Code es también una realidad para empresas de software tan importantes como Microsoft, Amazon o Twitter. En Mayo de 2016 Jeff Sandquist (@jeffsand) anunciaba la nueva plataforma documental de Microsoft docs.microsoft.com con las siguientes palabras:

Toda la documentación está diseñada para permitir contribuciones de la comunidad. Cada artículo incorporar un botón de edición que te dirige al fichero fuente de Markdown en GitHub, donde puedes crear un pull request para reportar un error o mejorar el contenido.

Una buena parte de la documentación del fabricante reside ya en esta nueva plataforma documental, en una clara apuesta por el uso de sistemas abiertos. Otras empresas como Amazon han seguido esta tendencia y hoy es posible ver el botón Editar en GitHub en muchos de los artículos destinados a desarrolladores.


El especialista en documentación y redactor técnico Tom Johnson (@tomjohnson) escribía en un artículo del blog I’d Rather Be Writing, en un comentario dirigido a la raíz del problema del uso de gestores de contenido:

No más cajas negras para gestionar tu contenido. No más sistemas caros y propietarios que mantener. No más formatos-de-salida-imposibles-de-ajustar. Puedes integrarlo todo de manera simple, fácil y barata.

La enorme influencia que estas empresas tienen en el mundo del software propiciará, más tarde o más temprano, la adopción de modelos documentales abiertos tipo bazar en detrimento de modelos rígidos tipo catedral. Si el desarrollo más efectivo y ágil del software es el resultado de un proceso colaborativo de integración y publicación continua, el proyecto documental tiene necesariamente que adaptarse a esta nueva realidad.


Por qué es difícil documentar errores

Documentar errores de software es una labor compleja. Los departamentos de soporte reclaman una gestión ágil y precisa de esta información que no siempre encaja bien con los flujos establecidos en otras tareas documentales. En este artículo expongo por qué los errores requieren un tratamiento diferenciado y propongo algunas ideas para mejorar su gestión documental.

El problema con los errores

El desarrollo de cualquier aplicación va necesariamente ligado a la aparición de errores. Cuando el número de posibles errores es pequeño -como ocurre, por ejemplo, con el software incorporado en muchos electrodomésticos modernos- su tratamiento se reduce a un breve apartado de resolución de problemas en la guía del usuario. En productos de software más complejos, la posibilidad de encontrar errores aumenta considerablemente. En su libro Code Complete, Steve McConnell, estima que la media de errores en la industria es de entre 15 y 50 errores por cada 1000 líneas de código. Cualquiera que sea la cifra final, puede llegar a ser muy alta si consideramos la extensión en líneas de código de muchos programas.

Tratar estos errores resulta complejo porque, como veremos más adelante, la naturaleza de este tipo de información es particular. Cuando el número de errores conocidos es pequeño, los redactores técnicos creamos una sección dedicada a la resolución de problemas en el propio manual del producto, o advertimos de la ocurrencia de problemas en forma de notas de texto. Pero el alcance de este planteamiento es limitado. Es, además, una solución que no contenta a nadie: los técnicos no tienen una forma directa de buscar esta información y los autores entendemos que funcionalidades y errores deben de ocupar sitios distintos en la documentación. Es por ello que muchos fabricantes de software diferencian entre funcionalidades y errores en su documentación. Vemos un ejemplo de ello en el área de soporte del fabricante Red Hat, donde estas dos áreas están claramente diferenciadas:

Otro ejemplo lo tenemos en la documentación de Microsoft, donde los contenidos de soporte (support) y funcionalidad de producto (library) son independientes:

Pero, ¿por qué resulta necesaria esta división?

Funcionalidades y errores

Hay 2 razones fundamentales que explican la separación entre la documentación de funcionalidades de producto y errores.

1. El origen y tratamiento de la información es distinto

Cuando describimos el funcionamiento de un software, los redactores técnicos lo hacemos en colaboración con el especialista (habitualmente un desarrollador o analista). La información facilitada por esta figura, junto con la documentación interna del producto (casos de uso, especificaciones de producto, wireframes, etc.) son la materia prima del artículo técnico. Nuestra función como redactores es destilar toda esta información y trasladarla a la documentación del producto de una manera ordenada.

Sin embargo, en el tratamiento de errores, el origen de la información reside en la figura del especialista de soporte. Él es -después del cliente- el primero en detectar y evaluar la gravedad del problema, y es también el primero en registrar los detalles del error en la herramienta de gestión de casos (en síntesis, una base de datos con los errores de producto reportados). A diferencia de lo que sucede con la documentación del producto, esta información no se encuentra ordenada, y puede ser difícil de encontrar por otros especialistas que trabajan con la misma herramienta. Solo la información de algunos de estos errores llega a la documentación final del producto como boletines de seguridad o artículos de soporte.

2. Los tiempos de publicación son distintos

La documentación de funcionalidades sigue un proceso de desarrollo constante, pero que viene pautado por la publicación de cada nueva versión del producto. Por el contrario, los errores se producen de forma intermitente durante todo el ciclo de vida del software. La información de soporte, por su propia naturaleza, requiere de un tratamiento ágil que le permita llegar al mayor número de especialistas de soporte posible. Esta diferencia en los ritmos de publicación explica también por qué funcionalidades y errores ocupan lugares distintos en la documentación del producto.

La siguiente tabla resume las diferencias entre uno y otro tipo de información:

Tratamiento de errores

Considerando estas diferencias ¿cómo podemos mejorar la gestión de errores en documentación? Propongo aquí dos ideas básicas.

1. Vincular el tratamiento de errores y funcionalidades

Salvo excepciones, son pocos los errores reportados que llegan a la documentación de usuario. En algunos casos, las herramientas de soporte no permiten extraer y analizar la información de una forma sencilla. En otros, no existen los flujos de trabajo para explotarla eficientemente. Este hecho resulta paradójico si pensamos en el valor que tiene esta información.

Sea cual sea la aplicación para la gestión de casos, debe permitir hacer búsquedas e, idealmente, puntuar (por ejemplo, a modo de like/dislike) el valor que cada caso tratado aporta para resolver un problema similar. El redactor técnico podrá así identificar los casos más consultados o mejor valorados internamente e incorporarlos a la documentación final del producto, que es ya accesible al usuario final. Los casos más críticos se publicarán como boletines de seguridad, mientras que los más populares se integrarán en área de soporte de la documentación (normalmente, en la base de datos de conocimiento o knowledge base).

Por último, la herramienta de gestión de casos usada por el especialista debe permitir realizar búsquedas en diferentes bases de datos y presentar un resultado unificado. Esto es esencial en grandes entornos, donde es común que cada área de soporte o país mantenga su propia solución.

La propuesta es, en definitiva, romper los silos de información y establecer flujos que permitan al redactor técnico descubrir los errores más comunes e incorporarlos, ya de una forma ordenada, a la documentación del producto.

2. Facilitar la creación de contenido de soporte

También se puede promover el desarrollo de nuevo contenido de soporte mediante plantillas de documento que el técnico pueda usar de forma sencilla. Elaborar estas plantillas no es complejo porque los artículos de soporte se ajustan a un patrón muy sencillo (normalmente Síntomas-Causa-Resolución). Los especialistas suelen agradecer estas iniciativas. Si el área de soporte puede generar la información en un formato predefinido, nuestra labor revisando, adaptando o traduciendo esa información será mucho más sencilla.

Desde hace varios años, Microsoft permite crear artículos en su Knowledge Base a cualquier especialista de soporte de la compañía. Este tipo de artículos, que pasan por un proceso de revisión interna antes de su publicación, abundan en la web del fabricante bajo el epígrafe de FAST PUBLISH (del inglés, publicación rápida):

Saber cómo tratar y gestionar la información de errores resulta más sencillo si entendemos las particularidades de esta información. Hemos visto que estas particularidades requieren de un tratamiento diferenciado pero no aislado. Bajo este escenario, los redactores técnicos debemos poner en marcha iniciativas que permitan mejorar el intercambio de información con el área de soporte.

Forma y función del artículo técnico: el meta-artículo

En la última parte de esta serie de tres (ver entradas anteriores aquí y aquí) sobre el desarrollo del artículo técnico, se introduce el concepto de meta-artículo como elemento funcional básico de la información. El meta-artículo constituye la pieza de unión entre el artículo técnico (la forma) y la tarea del usuario (la función).

El manual de usuario “electrónico”

El paso del manual de usuario físico a la documentación web que hoy acompaña a muchos productos de software no ha estado libre de problemas. Con la popularización del ordenador personal, y años antes de la generalización de internet, los fabricantes de software comenzaron a sustituir las ediciones impresas de sus manuales por versiones electrónicas. Los ficheros de ayuda de Windows se generalizaron como la forma más efectiva y económica de hacer llegar al usuario la documentación de producto. Los primeros manuales electrónicos, con un contenido escasamente enlazado y motores de búsqueda limitados, se convertían muchas veces en una mera copia digital del manual en papel.


Estos manuales de ayuda electrónicos -a los que el comunicador técnico Mark Baker llamó acertadamente frankenbooks- incorporaban todas las limitaciones de un libro físico, pero sin aprovechar ninguna de las ventajas del nuevo medio electrónico. La tabla de contenidos -y no la búsqueda- continuaba siendo clave en el descubrimiento de información y cada entrada se fragmentaba frecuentemente en múltiples subentradas. El resultado era un manual de ayuda electrónico con tablas de contenido extensas, difíciles de manejar y donde abundaban apartados con poca información.

El salto final desde el manual electrónico hasta el manual web ha obligado a los redactores técnicos a replantear la manera de agrupar y enlazar el contenido. El cambio en los patrones de lectura y descubrimiento de la información que trajo consigo internet hacen que organizar la información en la web siguiendo el modelo de libro físico carezca de sentido. Si la tabla de contenidos había sido hasta entonces un elemento fundamental, las capacidades de búsqueda en la web junto con estos nuevos patrones de lectura (que discutimos ya en el primer artículo de esta serie) convertían a este elemento en secundario.

Escritura técnica orientada al artículo

Junto con la transformación del manual de ayuda físico en manual en formato web, uno de los avances más importantes en el desarrollo de documentación técnica ha sido el paso al modelo de documentación orientada a artículos. Si anteriormente el redactor técnico trataba al manual como un todo, la tendencia ahora es, claramente, organizar el contenido en torno a bloques discretos de información a los que llamamos artículos. La popularización de modelos de información como el propuesto por la especificación DITA han cimentado esta transformación.

A pesar de este avance, modelos como DITA siguen sin dar respuesta a cómo los artículos, entendiendo estos como bloques primarios de información, se relacionan entre sí de forma lógica para el lector. De hecho, en la teoría de la escritura orientada al artículo, la agrupación de artículos se desaconseja o se considera que va en detrimento de la capacidad de asimilar información por parte de lector (en una palabra, de su usabilidad). Tal como expone el comunicador técnico Tony Self en su artículo Desarrollo de información basada en artículo (originalmente en inglés, Topic-based Information Development):
Los cambios en los patrones de lectura y adquisición de información sugieren que los lectores ya no quieren leer en profundidad textos largos y lineales. En su lugar, la investigación sugiere que quieren leer de forma superficial, y leer sólo el mínimo que les permita realizar una tarea. Las estructuras de información basadas en artículos son más apropiadas para estos lectores impacientes.
Pero si, como definen estos modelos, cada artículo representa únicamente un tipo de información (tarea, referencia, concepto, etc.), ¿no corremos el riesgo de volver a aquellos manuales electrónicos del pasado, con múltiples entradas aisladas y difíciles de manejar? ¿No tendría más sentido agrupar funcionalmente aquellos artículos relacionados entre sí, incluso aunque pertenezcan a categorías distintas?

El hecho de que los patrones de lectura y adquisición de información hayan cambiado con la aparición de internet no está reñido con la creación de contenido de mayor longitud. Muy al contrario. De hecho, la extensión de un artículo, por sí sola, no debería ser un criterio válido para fragmentar el contenido. Muchas entradas de la Wikipedia incluyen artículos extensos, lo que como lectores no nos impide navegar por su contenido en busca de la información o dato necesarios. Sin duda, esta organización resulta mucho más útil que presentar la información en bloques discretos y discontinuos, obligando al lector a moverse de un nivel de contenido a otro, y rompiendo el patrón de lectura habitual.

Modelo A frente a modelo B

Los modelos de desarrollo de información basados en DITA, en un empeño por maximizar la capacidad de reutilizar el contenido (uno de los principales objetivos de la escritura orientada a artículos) son incapaces de dar respuesta al modo en que estos bloques se agrupan (tanto es así, que algunos autores no consideran DITA como un verdadero modelo de información).

El modelo A (ver imágen) ejemplifica el modelo propuesto por DITA. Bajo esta concepción, cada tipo de artículo se presenta como un elemento final y reutilizable de información. El modelo B, por el contrario, plantea que los distintos artículos se combinan en elementos de mayor entidad, a los que me he dado en llamar meta-artículos. Si el artículo supone el elemento constructor de la información, el meta-artículo constituye el elemento funcional.

El modelo A aconseja aislar las tareas de autoría de las de presentación. En palabras de Tony Self:
El formato y presentación son consideración posteriores a la autoría, y actividades posiblemente no realizadas por el autor técnico.
Pero, ¿es esto cierto? En mi opinión, este planteamiento ignora que la presentación del contenido (el cómo se relacionan entre sí los diferentes tipos de artículos) condiciona en gran medida el acceso a la información por parte del lector. El redactor puede y debe aislarse de elementos formales como el uso de fuentes, colores, espacios entre párrafos, etc., pero no puede ignorar la estructura final del artículo.

El decidir entre un modelo u otro dependerá de factores que, como redactores técnicos, deberemos sopesar para cada tipo de contenido y audiencia. Veamos dos casos para ilustrar esta idea. Pensemos por un momento en una aplicación ofimática como Microsoft Word. Las preguntas que un usuario de esta aplicación puede plantearse se resuelven normalmente con una breve explicación (añadir formato a una tabla, compartir un documento, insertar una ecuación, etc.). En estos casos, la información de contexto resulta innecesaria porque el objetivo del usuario es muy específico y el número de posibilidades muy reducido. Pero pensemos ahora en una caso más complejo, como puede ser la instalación y configuración de un servidor web. El técnico que se enfrenta a esta tarea requiere una información de contexto suficiente para entender aquello que va a llevar a cabo y evitar errores comunes. ¿Tiene sentido aquí separar la tarea en sí de la información de contexto? Separando ambas (por ejemplo, en dos artículos enlazados) perdemos la posibilidad no solo de atraer la atención del lector, sino también de facilitarle la información necesaria en el lugar donde se lleva a cabo su acción.

Usabilidad frente a reutilización

El problema se reduce, por tanto, a cómo presentar el contenido al usuario de una forma que sea coherente con su flujo de trabajo, y que a su vez permita reutilizar la información. DITA no cierra la posibilidad de agrupar diferente artículos, pero advierte contra los peligros de hacerlo, como podemos leer en la propia especificación de DITA 1.2:
Los artículos pueden definirse dentro de otros artículos. Sin embargo, la unión requiere un cuidado especial porque puede dar lugar a documentos complejos que son menos utilizables [en el sentido de usabilidad] y reutilizables.
Como enfatiza Mark Baker, el problema es que DITA prioriza la posibilidad de reutilizar un contenido sobre la usabilidad del mismo. El argumento de que la agrupación de los artículos hace el documento menos usable no parece sostenerse. De hecho, si nos fijamos, la usabilidad de un documento (en otras palabras, la capacidad de ese documento de aportar la información relevante para la tarea del usuario) es contraria en muchos casos a las posibilidades de reusar el contenido. Pensemos en las imágenes o los vídeos. Aunque la tendencia es ahora la de incorporar cada vez más elementos gráficos en la documentación técnica, durante mucho tiempo este contenido fue relegado por los costes de producción asociados y su escasa reutilización. Pero, ¿es este un contenido usable? ¿Da soporte a la tarea en cuestión que el usuario realiza? Claramente, la respuesta es sí. Usabilidad y capacidad de reutilización son, en muchos casos, elementos contrapuestos.

El meta-artículo da respuesta a la necesidad de desarrollar documentación que sea a la vez usable y reutilizable, y comienza a estandarizarse como la forma más adecuada de hacer llegar la información técnica al usuario, especialmente en tareas complejas como las que se llevan a cabo en los departamentos de IT.

Céntrate (o cómo sobrevivir en un mundo de distracción)

Vivimos expuestos a un asalto constante de estímulos y notificaciones que, minuto a minuto, se apoderan de nuestra atención. Esta atención, necesaria para avanzar en nuestra carrera y en nuestra vida, se ha convertido en un bien escaso. Recuperar el terreno perdido no es una tarea fácil.

Respira


Observa tu respiración. Obsérvala por un instante. La mayoría de nosotros, al trabajar con la pantalla de nuestro ordenador o teléfono móvil, retenemos inconscientemente la respiración en un acto que la escritora Linda Stone bautizó como apnea del correo electrónico (originalmente, email apnea). Este hecho, aparentemente inocuo y que repetimos cientos de veces a lo largo del día, no pasa inadvertido para nuestro organismo. En su artículo Just Breathe: Building the case for Email Apnea (Solo respira: Argumentos acerca de la apnea del correo electrónico) publicado en Agosto del 2008, Stone describe en detalle algunas de las consecuencias que a largo plazo puede tener este comportamiento sobre nuestra salud. No resulta extraño que una de estas consecuencias sea el estrés y las enfermedades derivadas del mismo.


Dejando de lado el factor puramente biológico, la respiración juega un papel determinante en nuestra capacidad de atención y concentración. Las técnicas de mindfulness y meditación se basan en gran medida en un reaprendizaje y control consciente de la respiración. Estas prácticas, cada vez más populares y demandadas, llegan a la sociedad occidental como herramientas para conseguir una vida más centrada en cada momento y más plena. No son necesarias grandes dotes de observación para darse cuenta de cómo las actividades de nuestro día a día nos sitúan justamente en el extremo opuesto.

La meditación ha dejado ya de tener el estigma de práctica mística que se le atribuía hace solo unos años. Los cursos de meditación y mindfulness se han popularizado y cada vez es mayor el número de personas que incorporan estas herramientas con normalidad en su vida. La aceptación y difusión de estos recursos ha sido notable en estos últimos años, algo que solo se puede explicar como la respuesta de nuestra sociedad a una creciente ansiedad y dispersión de nuestra atención.


Una respiración controlada y consciente, como la que se realiza durante la meditación, mejora nuestra capacidad de atención y fija el marco para un desarrollo cognitivo sano, como puede concluirse de los resultados de diferentes estudios y meta-estudios. En palabras de la propia Stone, “en el corazón de la atención deliberada se encuentra la respiración deliberada. Respiración, atención y emoción, son conmutativas”.

Atención y productividad

En una sociedad donde las interrupciones son casi constantes, la atención se ha convertido en un recurso escaso. Como explica el filósofo Byung-Chul Han en La sociedad del cansancio (Edit. Herder, 2016), el exceso de estímulos, informaciones e impulsos “modifica radicalmente la estructura y economía de la atención”, y nos reduce a máquinas capaces de reaccionar a cualquier estímulo pero incapaces de reflexionar sobre sus propias acciones. Han señala además lo contradictorio de que esta fragmentación de nuestra capacidad de concentración se produzca precisamente en una época en la que “el aumento de la carga de trabajo requiere una particular técnica de administración del tiempo y la atención”.

Solo necesitamos echar un vistazo a nuestro alrededor para darnos cuenta de esta realidad. Contestamos a los correos electrónicos en el tren y el metro, interrumpimos cualquier tarea para revisar la última notificación de nuestros teléfonos móviles y pasamos frenéticamente de una reunión a otra -revisando más notificaciones por el camino- sin apenas tiempo para sacar conclusiones de aquello que hemos discutido. Este estado, que Han describe como “pura agitación que no genera nada nuevo, [solo] reproduce y acelera lo ya existente” es aceptado hoy como símbolo de productividad. Asumimos que todo aquello que nos mantiene alerta y ocupados nos hace productivos, sin pararnos a pensar en cómo repercute toda esta actividad en nuestras vidas, y llegamos al absurdo de afirmar que la ansiedad y el estrés son beneficiosos porque nos mantiene alerta y nos hace máquinas de trabajar más eficaces.


En esta situación, no resulta extraño que aquellas tareas que requieren un esfuerzo mental ininterrumpido y durante varias horas queden relegadas siempre a un segundo lugar, justo porque en ese estado de agitación solo podemos reaccionar a la crisis del momento, al último correo electrónico o a la última notificación. Nos hemos acostumbrado a ver como un hecho normal perder dos terceras partes de nuestra jornada laboral en la bandeja de entrada. Ponemos todo el énfasis en tareas puramente mecánicas como reuniones, trabajo administrativo o almacenar y compartir información, convirtiéndonos así en el animal laborans -eficiente pero irreflexivo- que la filósofa Hannah Arendt describe en La condición humana (Edit. Paidós, 1993). La actual cultura del trabajo promueve y ejemplariza esta falsa productividad provocando que para muchas personas esta actividad febril sea la única forma de demostrar su valor en la empresa. La dispersión y la multitarea son ahora la norma, pero ¿a qué coste? El estrés es solo uno de los subproductos que trae consigo la sociedad del animal laborans. La desilusión, la insatisfacción, el miedo al fracaso y en último término, la depresión, son también consecuencias naturales.

Hemos dejado de lado la reflexión necesaria para el desarrollo de nuestras capacidades y el verdadero progreso en nuestra vida y nuestra profesión. Mindfulness significa conciencia plena, y supone un estado mental en el que nuestra voluntad está dedicada enteramente a una actividad y no se ve interrumpida por ninguna otra cosa. Y es solo en este estado de atención donde la productividad bien entendida se manifiesta.

Trabajo profundo

Para el profesor Carl Newport, autor de varios libros sobre técnicas de estudio y productividad personal, el salto de una actividad profesional mediocre a una sobresaliente solo puede venir dado por la dedicación consciente y focalizada de nuestro tiempo. Esta dedicación, a la que el autor llama trabajo profundo (originalmente en inglés, deep work) require una gran fuerza de voluntad y un elevado esfuerzo. El trabajo profundo no es divertido, pero es la única forma de obtener avances verdaderos en aquello a lo que nos dedicamos. Como explica el propio autor en su libro Deep Work (Piatkus Pub., 2016), “si no has dominado esta habilidad fundamental [del trabajo profundo] tendrás dificultades para aprender cosas complejas o producir a un nivel superior” (2016, p.32) .Las afirmaciones de Newport nos llevan inevitablemente a un reflexión y un replanteamiento de nuestra forma actual de trabajar o estudiar.

Esta reflexión está en consonancia con lo apuntado por Geoff Colvin en Talent is overrated (El talento está sobrevalorado. Portfolio-Penguin Pub., 2008). En el estudio The role of deliberate practice in the acquisition of expert performance (El papel de la práctica deliberada en la adquisición de un rendimiento de élite. KA Ericsson, RT Krampe, C Tesch-Römer. Psychological review 100 (3), 363) llevado a cabo con varios violinistas de un prestigioso conservatorio alemán y ampliamente comentado por Colvin en su libro, se pone de relieve que el factor decisivo para diferenciar a los buenos violinistas de los mejores no es tanto las horas de práctica como las horas de lo que los autores del estudio llaman práctica deliberada. Se entendiende por deliberada aquella práctica repetida en el tiempo, que supone un elevado esfuerzo intelectual y que requiere de toda nuestra capacidad de atención. En definitiva, alcanzar las metas deseadas en cualquier actividad no pasa solo por dedicar más tiempo a esa actividad sino también por dedicar un tiempo de mayor calidad. Se rompe así con la afirmación -basada precisamente en el mismo estudio de Ericsson, Krampe y Tesch-Römer- del escritor Malcolm Gladwell en Fuera de serie (Ed. Taurus, 2009 y publicado originalmente en inglés como Outliers), donde se afirma que para sobresalir en una actividad son necesarias al menos 10.000 horas de dedicación. La excelencia en cualquier campo no está determinada tanto por la cantidad, como por la calidad de nuestro tiempo.

Lo cierto es que existe una relación entre la atención, la calidad del tiempo de trabajo y nuestra motivación. Poner toda nuestra atención en aquellas actividades que consideramos importantes en nuestra vida o en nuestra profesión se traduce en un tiempo de mayor calidad (trabajo profundo). Este tiempo es precisamente el que nos permite progresar cualitativamente en estas actividades y a su vez nos motiva para seguir realizándolas. Como apunta Newport, conseguir la concentración necesaria para un tiempo de calidad  nunca ha sido sencillo, pero las empresas de medios y redes sociales han hecho nuestra labor mucho más difícil. El bombardeo constante de noticias y notificaciones resulta demasiado atractivo y el temor a “perderse algo” demasiado angustioso. Saber reconocer estas situaciones y actuar contra ellas es fundamental.

Consejos para una vida más centrada

Internet y las mejoras en inteligencia artificial y robótica han hecho obsoletos muchos tipos de trabajo tradicional. Pero la realidad es que una gran mayoría de los trabajos que realizamos hoy en día no pueden ser reemplazados por máquinas o por un software. Y no pueden serlo fundamentalmente porque el valor que aportamos como individuos se realiza en un nivel cognitivo que no puede ser programado en un software. En un mundo laboral contradictorio, donde las empresas buscan la uniformidad del individuo a la vez que reclaman innovación, el trabajo deliberado y profundo en nuestra actividad profesional puede convertirse en el factor diferenciador. Este trabajo no es divertido, pero como apunta Colvin “tiene que ser así. Si las actividades que llevan a la excelencia fueran fáciles y divertidas entonces todo el mundo las haría y no se distinguiría a los mejores del resto”. Pero, ¿qué estrategias podemos poner en marcha que nos permitan avanzar verdaderamente en nuestra profesión?

Organiza tu tiempo

Enfocar nuestra vida en aquello que de verdad importa y evitar las distracciones requiere una planificación. Diariamente debemos luchar contra todas aquellas cosas que reclaman nuestra atención: redes sociales, notificaciones, televisión, videojuegos, etc. Nuestra mejor arma en esta lucha es nuestra voluntad y nuestro calendario. Si de forma rutinaria bloqueamos horas en nuestra agenda para reunirnos con otras personas, ¿por qué no bloquear tiempo para reunirnos con nosotros mismos? Si necesitas tiempo para pensar en esa importante presentación, en ese nuevo plan de márketing o en la solución para el problema que lleva meses persiguiéndote, bloquea el tiempo necesario en tu calendario para estas tareas. Bloquea ese tiempo y comprométete a cumplirlo de la misma forma que lo harías en una reunión con otra persona.

Una objeción común para no llevar a cabo esta práctica es que las actividades del día a día no permiten bloquear el periodo de tiempo enfocado e ininterrumpido necesario. Resulta paradójico, sin embargo, que en esa escasez de tiempo, sí hemos sabido encontrar el hueco para dedicar varias horas a las pantallas de nuestro teléfono móvil o televisor en una distracción que mucha veces resulta vacía.

Reduce la ingesta de información

En su libro The information diet (La dieta informativa. O'Reilly Media, 2012), Clay A. Johnson compara la información que recibimos y consumimos actualmente con la comida basura. Esta información no está hecha para hacernos conscientes de la realidad del mundo a nuestro alrededor sino que, de forma análoga a la hamburguesa de las cadenas de comida rápida, es fabricada por los grandes medios de comunicación para ser de apetitosa, de rápido consumo y -sobre todo- adictiva.



El consumo constante de información convenientemente procesada no solo distorsiona nuestra capacidad de concentración, también reduce nuestra tolerancia a medios que requieren un mayor esfuerzo intelectual. El propio Johnson relata así este hecho en su libro: “hace algunos años, me encontré completamente incapaz de leer más allá de mil palabras. No había manera de que pudiera leer un artículo extenso o un libro. El concepto de leer de un libro, mucho menos escribir uno, era completamente ajeno a mí”.

Optar por una dieta informativa supone, ante todo, cambiar la relación que mantenemos con nuestro teléfono móvil. Acciones tan sencillas como eliminar aplicaciones, borrar nuestra presencia en redes sociales, o sustituir algunas horas de televisión y YouTube por un libro favorecen nuestra capacidad de atención a largo plazo y disminuyen progresivamente nuestra dependencia del teléfono móvil. Especialmente en lo referente a redes sociales, resulta inquietante cómo en apenas unos pocos años estos servicios se han adueñado por completo de nuestros días. Pensemos por un momento si la forma en la que empleamos nuestro tiempo es la que queremos y la que nos hace sentir bien.

Medita

Afortunadamente, practicar la meditación ya no es visto como algo esotérico y está cada vez más normalizado. La meditación proporciona, entre otros muchos beneficios que están ampliamente documentados, un aprendizaje de técnicas respiratorias y una mejora de la capacidad de concentración que son claves para la ejecución del trabajo profundo.

Aprender a meditar es, además, sencillo y no requiere de ningún equipo, instalación o material especial aparte de nuestra voluntad para llevarlo a cabo. Aunque existen muchas aplicaciones para iniciarse en el mundo de la meditación y el mindfulness, mi recomendación es no utilizar estas aplicaciones como punto de partida. Existen multitud de centros que imparten cursos y organizan monográficos sobre estas técnicas donde encontraremos un asesoramiento adecuado. Iniciarnos en estas prácticas con otras personas nos permitirá también compartir experiencias y ver con mayor normalidad estas actividades.

Practica el trabajo profundo

El trabajo administrativo al que nos enfrentamos hoy en día no parece tener fin. Podríamos estar trabajando durante días sin agotar todas las tareas administrativas que se nos demandan. Pero es justamente este trabajo administrativo el que nos impide desarrollarnos en nuestra profesión. Como apunta Newport, la única escapatoria que tenemos los trabajadores es la de ser conscientemente irresponsables: decir no a ciertas reuniones, no a ciertas actividades y no a ciertos correos electrónicos. En definitiva, convertir el trabajo profundo en la prioridad y no en algo que nunca llegamos a realizar por falta de tiempo.

Bloquea periodos de tiempo ininterrumpidos de 2-3 horas en la tu agenda para pensar y profundizar en aquellos temas que resultan importantes en tu profesión -o en tu vida. Comprométete a emplear este tiempo enteramente en la actividad en cuestión, dejando de lado cualquier posible distracción. Y si la cultura de la empresa o el puesto de trabajo no nos permite realizar las acciones que nos hacen avanzar profesionalmente, es quizás el momento de plantearse si estamos en el mejor sitio para desarrollar nuestra carrera.

Planificar el contenido en el artículo técnico

Si en el primer artículo de esta serie se mostraba cómo dotar de estructura al documento técnico, en este segundo se describe un método para planificar su contenido. Como en cualquier otra labor con un cierto grado de complejidad, una preparación adecuada nos ahorrará tiempo durante el desarrollo del contenido e influirá positivamente en la relevancia del documento final.

Forma y función en el artículo técnico

La calidad de un artículo técnico depende de muchos factores, algunos de los cuales suelen encontrarse fuera de nuestro control. Si la herramienta de edición es excesivamente compleja o restrictiva, o si el gestor de contenidos dificulta las tareas de distribución y revisión, es poco lo que el redactor técnico puede hacer para superar estos obstáculos. Pero la calidad final del artículo depende, ante todo, de su capacidad para empatizar con la tarea el usuario y proporcionarle la información necesaria -o el acceso a otra información cuando la nuestra ya no es de interés. Y es justo aquí donde más puede aportar el redactor.

Mientras que en la entrada anterior de este blog se trataba la estructura del documento (su forma), esta se centra en el contenido (su función) o más concretamente, en la planificación de ese contenido. En documentación técnica la separación entre forma y función es puramente formal, ya que en la práctica ambos aspectos están íntimamente ligados. Vimos ya que la estructura de un documento es esencial en la búsqueda y el descubrimiento de la información por parte del usuario, pero una vez hemos captado su atención es imprescindible mostrar datos relevantes en el contexto de su tarea.

También se ha discutido la importancia de que los manuales describan tareas, y no interfaces. Debemos desterrar la idea de que la principal función de un manual es explicar minuciosamente la interfaz y opciones de un producto, dejando siempre al usuario la difícil labor de entender cómo encaja esa información en su tarea. Si hasta no hace mucho tiempo era habitual basarnos en la descripción de las pantallas y opciones para redactar un documento técnico, ahora debemos preguntarnos ¿es esto lo que el usuario necesita?

Estas descripciones -este contenido- siguen teniendo su lugar en la documentación, pero no como eje central de la misma, sino en la forma de artículos de referencia a los que el usuario pueda acceder desde la descripción de la tarea. Del mismo modo que las notas al pie y referencias de un libro nos ayudan a completar y entender mejor la historia, pero no sustituyen la historia en sí. La documentación técnica que no sustenta las acciones del usuario es, en gran medida, responsable de la mala fama que tienen los manuales entre muchos usuarios.

Etapas en la planificación de contenido

He dividido la planificación de un artículo técnico en 4 etapas, que pueden resumirse gráficamente de la siguiente forma:

Para cada etapa, se indican a continuación las herramientas recomendadas, los materiales de trabajo, el resultado esperado y las acciones correspondientes en esa fase.

Etapa 1: Analizar las tareas del usuario

Herramientas: Pizarra o software para elaborar mapas conceptuales (también llamados mapas mentales).

Materiales de trabajo: Ámbito de la tarea, especificaciones del producto, prototipos (lo que comúnmente se conoce como mockups o wireframes), entrevistas con usuarios y cualquier otra fuente de datos que podamos tomar como punto de partida.

Resultado: Mapa conceptual con análisis de tareas.

Acciones:

  • Analizamos las distintas tareas que el usuario puede completar con el software en el contexto que se quiere documentar.
  • Definimos las tareas más genéricas primero, y las más específicas después.
  • El análisis se hace sobre la base del flujo de acciones del usuario, no de las pantallas y opciones del software.
  • El foco aquí son las tareas y sus relaciones, no la jerarquía de las tareas.

Etapa 2: Definir los artículos que integran el documento

Herramientas: Pizarra o software para elaborar mapas conceptuales.

Fuentes de trabajo: Mapa conceptual con análisis de tareas (etapa 1).

Resultado: Mapa conceptual estructurado con análisis de tareas

Acciones:

  • Tomamos como referencia los 4 tipos de artículos definidos para categorizar cada una de las entradas que conforman el mapa conceptual.
  • Usamos un tipo de artículo para cada entrada.
  • Modificamos el mapa conceptual dividiendo o juntando elementos cuando sea necesario para adaptarlos a alguno de los 4 tipos.

Etapa 3: Crear la tabla de contenidos

Herramientas: Pizarra y editor de textos.

Fuentes de trabajo: Mapa conceptual estructurado (etapa 2).

Resultado: Tabla de contenidos.

Acciones:

  • Creamos una tabla de contenidos que reflejará la estructura final del documento.
  • El foco aquí es la agrupación lógica de conceptos y la jerarquía.
  • Si es preciso, cambiaremos la estructura de la tabla de contenidos durante el desarrollo del contenido (esta fase es iterativa).
  • Evitaremos exponer más allá de dos niveles en la tabla de contenidos. Es decir, nivel 1, nivel 2 y también nivel 1.1 y 1.2, pero no niveles 1.1.1, 1.1.2, etc.

Etapa 4: Desarrollar el contenido

Herramientas: Herramienta de edición o gestor de contenidos.

Fuentes de trabajo: Mapa conceptual estructurado (etapa 2) y tabla de contenidos (etapa 3).

Resultado: Borrador o documento técnico final.

Descripción:

  • Desarrollar nuevo contenido para cada artículo definido en la fase anterior.
  • Reutilizar secciones que son comunes a distintos artículos (como por ejemplo, explicar las acciones en la interfaz del usuario para abrir una aplicación o ejecutar un comando).
  • Actualizar la tabla de contenido si es necesario durante del desarrollo (esta fase es iterativa).

Durante la planificación, la tendencia es imaginar en nuestra cabeza el aspecto final del documento. Esto nos lleva a poner excesivo énfasis en la tabla de contenidos. Pero la propuesta aquí es precisamente no pensar en términos de tabla de contenidos hasta bien avanzado el análisis de las tareas. La tabla de contenidos nos limita porque solo nos permite movernos en dos dimensiones: de arriba hacia abajo, añadiendo nuevas entradas o de izquierda a derecha, añadiendo profundidad a cada entrada; pero durante el análisis inicial nuestro cerebro trabaja en múltiples direcciones, no solo en dos.

No he mencionado deliberadamente los integrantes de cada etapa porque estos dependerán del proyecto. En proyectos de gran envergadura, la colaboración de los equipos de diseño y usabilidad, analistas y desarrolladores, formadores y equipos de soporte técnico es fundamental y puede facilitarnos el análisis de las primeras etapas. En proyectos menores, como los desarrollados por el redactor técnico ocasional, es normalmente una sola persona quien lleva a cabo todo el trabajo.

El mapa conceptual como herramienta de análisis

Precisamente porque la tabla de contenidos nos limita en el desarrollo de ideas, resulta más eficaz usar mapas conceptuales en las fases iniciales de planificación. Estos mapas, ideados originalmente por Tony Buzan, son una representación gráfica de ideas que se van añadiendo -a modo de ramas de árbol- a partir de un concepto central. Cada una de estas ideas puede dividirse a su vez en otras de menor entidad, pasando así de los conceptos más generales en el centro del mapa a los más específicos en la periferia.

En nuestro caso el centro del mapa estará ocupado por el tema sobre lo que vamos a escribir (normalmente, una nueva funcionalidad del software). A partir de este elemento central vamos dibujando otros que representan las acciones que el usuario puede realizar con el software. Vemos que, a diferencia de la tabla de contenidos, el mapa conceptual se adapta mejor a la forma de pensamiento durante la fase de ideación al permitir desarrollar y enlazar elementos libremente.


Quien no haya utilizado antes los mapas mentales puede sentir la tentación de pasar por alto este sistema. Mi recomendación es no hacerlo. La conveniencia de usar este método frente a otros se encuentra ampliamente documentada, su aprendizaje es rápido y la inversión en tiempo se verá compensada con creces. Tampoco es necesaria ninguna herramienta especial, podemos usar un cuaderno, una pizarra o etiquetas adhesivas. Podemos también usar uno de los muchos programas que existen para elaborar mapas conceptuales, aunque no importa lo rica en funcionalidades que sea la aplicación de software, siempre nos limitará en mayor medida que una pizarra durante el análisis. Una vez el mapa mental está ya maduro, podemos utilizar un programa para almacenarlo digitalmente, editarlo y compartirlo.


La última entrada de esta serie tratará con mayor detalle el concepto de artículo. Veremos cómo los 4 tipos descritos (concepto, referencia, tarea y resolución de problemas) puede relacionarse entre sí para dar lugar a elementos de mayor entidad a los que llamaré meta-artículos. El meta-artículo constituye la pieza de unión entre el artículo (la forma) y la tarea del usuario (la función).

Organizar la información en el artículo técnico

La estructura del artículo técnico tiene un papel clave en la búsqueda y descubrimiento de información por parte del lector. Los artículos deben mostrar elementos comunes que den soporte a esta búsqueda, pero también elementos diferenciadores que permitan identificar si la información es relevante en el contexto de la tarea.

Estructura y búsqueda de información

Cuando analizamos a los usuarios -o a nosotros mismos- utilizando documentación técnica, observamos que el patrón de lectura dista mucho de el que el lector adopta con una novela. Inicialmente, con un vistazo general a la estructura, juzgamos ya si la información que contiene el documento responde o no a nuestras necesidades. Una vez hemos decidido que la información que tenemos delante puede sernos útil, hacemos un análisis -aún muy superficial- de elementos como títulos, listados, imágenes o tablas. Solo entonces centramos nuestra atención en párrafos o elementos particulares que consideramos relevantes. Este análisis está en sintonía con lo que Nielsen describió como information foraging (literalmente, tratar la búsqueda información como la búsqueda de alimento o forraje por parte de un animal).

Este mecanismo de búsqueda y descubrimiento, aparentemente errático, sigue un patrón determinado muy similar al que empleamos al leer cualquier otro tipo de información en internet. De esta observación podemos concluir que no basta con que la información sea completa y correcta, es necesario además que su estructura permita identificar dónde está el contenido de interés -informacion suculenta, siguiendo con la idea de Nielsen- mediante una organización predecible y sencilla. Recordemos que la documentación no busca entretener al lector, sino facilitarle el acceso a la información en sus propios términos.

Especialmente en el caso del redactor técnico accidental -aquel cuya principal tarea no es la redacción técnica-, la experiencia y las herramientas que permiten organizar adecuadamente la información no siempre están disponibles. Este artículo, el primero de una serie de tres, propone una forma estandarizada y sencilla de estructurar un texto técnico, independientemente del método y herramienta de desarrollo.

Tipología del artículo técnico

La clasificación que aquí se presenta está basada en DITA, una especificación XML muy popular en el desarrollo de documentación. Pero esta clasificación no pretende llegar al nivel de complejidad y detalle que alcanza DITA sino, bien al contrario, servir de referencia rápida y accesible para el redactor.

Al analizar diferentes artículos técnicos, observamos que la inmensa mayoría responden a uno de los siguientes tipos:

  • Concepto
  • Tarea
  • Referencia
  • Resolución de problemas

Estos 4 tipos constituyen la base sobre la que se articula la información. No entraremos aquí en cómo estos elementos se combinan entre sí para construir artículos de mayor entidad. Esta explicación se deja para el último artículo de la serie, donde se desarrolla en más detalle el concepto de artículo. Es suficiente con decir ahora que la mayoría de los escritos técnicos resultan de combinar estos tipos. Veamos un ejemplo. Supongamos que nuestro encargo consiste en redactar un artículo sobre cómo configurar una solución de alta disponibilidad para un sistema en el que nuestro departamento de IT está trabajando. El texto final podría tener el siguiente esquema:

  1. Introducción a la solución de alta disponibilidad (concepto).
  2. Explicación sobre el modo de instalación y configuración (tarea).
  3. Lista de comandos especiales para operar la solución (referencia).
  4. Problemas más comunes (resolución de problemas).
Vemos en este ejemplo que el trabajo final está conformado por los 4 tipos de artículos descritos, siguiendo un orden lógico de acciones.

Elementos básicos del artículo

Cada tipo de artículo está compuesto por un conjunto ordenado de elementos. Varios elementos son comunes a los 4 tipos, otros son particulares. El siguiente esquema muestra los elementos comunes:

Los elementos con un asterisco (*) son necesarios en la estructura del artículo, mientras que aquellos con un signo de cierre de interrogación (?) son opcionales. El siguiente listado es una descripción de los elementos comunes:

  • title: título del artículo.
  • shortdesc: breve introducción a la información que se va a tratar en el artículo. Puede ser una frase o un párrafo.
  • keywords: términos o palabras clave en el artículo que son normalmente empleados por los motores de búsqueda.
  • toc: tabla de contenidos. Aunque opcional, es recomendable en artículos extensos compuestos por varias partes.
  • body: representa el cuerpo del artículo, donde se encuentra la información que lo compone (texto, imágenes, tablas, listas, etc.). El elemento body marca la diferencia entre los distintos tipos de artículo.
  • related-links: enlaces a otros artículos relacionados.
Veamos ahora con más detalle los 4 tipos de artículo mencionados.

Concepto

El concepto proporciona la respuesta a la pregunta Qué es. Este tipo de artículos presenta la información necesaria para entender otros conceptos o realizar una tarea. Es común incluir este tipo antes de explicar tareas complejas o que requieren información de contexto para poder ser completadas. Un artículo de este tipo muestra la siguiente estructura:


En este caso el contenido se desarrolla dentro del elemento descbody. El concepto es además el único tipo de artículo que puede incluir todos los demás tipos. Un ejemplo esquemático de este artículo sería el siguiente:

Tarea

La tarea da respuesta a la pregunta Cómo. Este tipo de artículo muestra paso a paso cómo completar una acción determinada. Los artículos que describen tareas incluyen los siguientes elementos:

Como podemos ver en la imagen, las tareas pueden a su vez incluir otras tareas. El contenido particular de este artículo se encuentra en el elemento taskbody. Cada tarea se compone de una serie de pasos ordenados (steps) que pueden venir o no precedidos de uno o más requerimientos (req). Los requerimientos hacen referencia a otras acciones que han de completarse con anterioridad o a materiales necesarios durante el proceso.

El artículo debe contener la información necesaria sin extenderse en explicaciones. Un error común es el de incluir información en la descripción de la tarea. En la medida de lo posible, esta información debe desarrollarse en el artículo de tipo concepto. Este artículo muestra la siguiente estructura:

Referencia

Una referencia incluye un listado de opciones y parámetros que son útiles para completar una tarea o para usar una función específica de un software. Ejemplos de referencia son los artículos donde se muestran las opciones de un comando, los parámetros de configuración de un determinada aplicación o la descripción de una API (interfaz de programación de aplicaciones). En muchos casos se utilizan tablas o listados para presentar la información. Estos elementos se incluyen en el apartado refbody. Los artículos de referencia se componen de los siguientes elementos:

Al igual que ocurre con las tareas, un mismo artículo puede contener varias referencias, aunque los artículos de referencia demasiado extensos son difíciles de usar incluso con una tabla de contenidos. El artículo de tipo referencia atiende la siguiente estructura general:

Resolución de problemas

El artículo de resolución de problemas detalla información de un problema o error en el software. La información debe permitir al lector identificar el problema con el que se encuentra (symptoms), entender las causas que lo originan (more-info) y mostrar los pasos requeridos para eliminar o mitigar el problema (tasks). Este tipo de artículo se caracteriza por incluir los siguiente elementos:

y muestra la siguiente estructura general:


Tanto la clasificación como los elementos discutidos aquí son comunes a una gran cantidad de documentos técnicos. No se busca en ningún caso ofrecer un planteamiento original, precisamente porque las estructuras familiares y comúnmente aceptadas son clave en el descubrimiento y consumo de la información.