Una mala lista de preguntas y respuestas frecuentes (FAQ[1].) es aquella compuesta a partir de las preguntas que el autor de la FAQ desearía que la gente hiciese, en lugar de las preguntas que la gente hace realmente. Quizás haya visto una de estas antes:
P: ¿Cómo puedo usar Glorbosoft XZY para maximizar la productividad de mi equipo?
R: Muchos de nuestros clientes desean saber cómo maximizar su productividad a través de nuestras innovaciones patentadas de software para trabajo en grupo. La respuesta es simple: primero, haga clic en el menú “
Archivo”, baje hasta “Incrementar productividad”, entonces…
El problema con FAQs de este estilo es que no son, en un sentido literal, FAQs en absoluto. Nadie llamó nunca a la línea de soporte técnico y preguntó, “¿Cómo podemos maximizar la productividad?”. En su lugar, la gente hizo preguntas altamente específicas, como, “¿Cómo podemos modificar el sistema de calendario para enviar recordatorios con dos días de antelación en lugar de uno?” y similares. Pero es mucho más fácil inventar preguntas y respuestas frecuentes que descubrirlas de verdad. Compilar una verdadera hoja de preguntas y respuestas frecuentes requiere una esfuerzo sostenido y organizado: durante el tiempo de vida del software las preguntas realizadas deben ser rastreadas, las respuestas monitorizadas, y todo ello recogido en un todo coherente e indexado que refleje la experiencia colectiva de los usuarios en ambientes de producción. Requiere de la actitud paciente y observadora de un naturalista de campo. Sin grandes hipótesis ni discursos visionarios—ojos abiertos y tomar notas con detalle es lo que más se necesita.
Lo que me encanta de este libro es que creció justo de un proceso similar, y se puede apreciar en cada página. Es el resultado directo de los encuentros que tuvieron los autores con los usuarios. Comenzó con la observación de Ben Collins-Sussman, que las mismas preguntas básicas estaban siendo realizadas una y otra vez en la lista de correo de Subversion: ¿Cuál es el flujo de trabajo estándar recomendado con Subversion? ¿Funcionan las etiquetas y ramas del mismo modo que en otros sistemas de control de versiones? ¿Cómo puedo averiguar quién ha hecho un cambio en particular?
Frustrado por ver las mismas preguntas día tras otro, Ben trabajó intensamente durante un mes en verano del 2002 para escribir El Manual de Subversion [2], un manual de sesenta páginas que cubría el uso básico de Subversion. El manual no tenía pretensiones de ser una obra completa, pero fue distribuido con Subversion y ayudó a los usuarios a superar ese bache inicial en su curva de aprendizaje. Cuando O'Reilly y Asociados decidió publicar un libro completo sobre Subversion, el camino del mínimo esfuerzo era obvio: expandir el manual de Subversion.
A los tres coautores del nuevo libro se les presentó una oportunidad sin igual. Oficialmente, su tarea consistía en escribir un libro de arriba hacia abajo, comenzando a partir de una tabla de contenidos y borrador inicial. Pero también tenían acceso a un flujo constante—de hecho, un géiser incontrolable—de material práctico. Subversion ya estaba en manos de miles de usuarios, y éstos estaban proporcionando toneladas de retroalimentación, no sólo sobre Subversion, sino también sobre la documentación existente.
Durante el tiempo que llevó escribir este libro, Ben, Mike y Brian frecuentaron las listas de correo y sesiones de chat de Subversion incesantemente, anotando cuidadosamente los problemas que estaban teniendo los usuarios en situaciones de la vida real. Monitorizar tal respuesta es de todos modos parte de la descripción de su puesto de trabajo en CollabNet, y les dio una gran ventaja cuando comenzaron a documentar Subversion. El libro producido está firmemente establecido sobre unos cimientos de experiencia, no en las arenas movedizas de las puras ilusiones; combina las mejores características de un manual de usuario y una lista de preguntas y respuestas frecuentes. Esta dualidad quizás no sea advertida durante una primera lectura. Leído en orden, de principio a fin, el libro es simplemente una descripción directa de una pieza de software. Hay una visión general, el obligado tour guiado, un capítulo sobre administración, algunos temas avanzados, y por supuesto una referencia de los comandos y una guía para resolver problemas. Sólo cuando se vuelve a revisar se ve brillar su autenticidad: los detalles que sólo pueden resultar de encuentros con lo inesperado, ejemplos extraídos de casos de uso genuinos, y sobre todo la sensibilidad hacia las necesidades del usuario y su punto de vista.
Por supuesto, nadie puede garantizar que este libro responderá
cualquier pregunta que tenga sobre Subversion. A veces, la
precisión con la que se anticipa a sus dudas le parecerá
misteriosamente telepática; pero ocasionalmente, se
topará con un agujero en el conocimiento de la comunidad
de usuarios y se quedará con las manos vacías. Cuando
esto ocurra, lo mejor que puede hacer es mandar un correo electrónico
a <users@subversion.tigris.org> y exponer
su problema. Los autores aun siguen ahí, observando, y
esto no sólo incluye a los tres que aparecen en la portada,
sino muchos otros que contribuyeron correcciones al material
original. Desde el punto de vista de la comunidad de usuarios,
solucionar su problema es meramente un agradable efecto colateral de un
proyecto mucho mayor—en concreto, ajustar ligeramente
este libro, y en definitiva Subversion, para que se adapte
mejor a la forma en que la gente realmente lo usa. Están
deseosos de escucharle, no únicamente porque le pueden ayudar,
sino porque usted puede ayudarles a ellos. Con Subversion,
como con todos los proyectos de software libre en activo,
usted no está solo.
Deje que este libro sea su primer compañero.
— , Chicago, 14 de Marzo, 2004