Los problemas de escribir un libro se parecen mucho a los de un proyecto de desarrollo

El otro día lo comentábamos por Twitter, no te puedes imaginar lo que se parece escribir un libro, entre dos o más personas, a un proyecto de desarrollo software.
Como alguien respondió en aquella conversación, ciertamente, casi todos los proyectos cuyo producto resultante es de componente intelectual (escribir, programar, hacer un plan de marketing, etc.) tienen problemas similares y les suelen encajar, salvando ciertas diferencias, las mismas estrategias y buenas prácticas.
De hecho, ya en su día comentamos este tema en aquel post de agilidad aplicada a contextos que no son de desarrollo software, donde comentamos su aplicación al marketing, a la educación, a los negocios, etc.
En este caso, el tema vino por aquello de que estamos a tope terminando los dos libros que os comenté hace unas semanas, el de Agilidad con JIRA® y el de Integración Continua, y cuando, de manera muy frecuente, nos surge algún problema de “gestión” no dejo de acordarme de mis participaciones en proyectos de desarrollo y de lo que veo día sí y día no en un montón de proyectos software (Después de pasar por 80 empresas). En casa de herrero…
En fin, ¿Quieres algunos ejemplos? Aquí tienes unos cuantos, que, además, los tenemos muy recientes:
1 – Síndrome del “está casi ya”. Como cualquier proyecto software, escribir un libro también está bajo la maldición del “está casi ya”. “Está casi ya” es aquella fase de un proyecto, o libro, en la que parece que está terminado… pero no, queda un poco, pero que no se termina. Cuentan los ancianos del lugar, que ha habido veces en las que la fase del “está casi ya” ha durado más que el propio proyecto. Veremos cuanto nos dura en los libros con los que estamos.
2 – Cualquier estimación es pura coincidencia. Como cualquier proyecto software, escribir un libro también está bajo la maldición de la estimación a ojo y los retrasos. Que más te voy a contar, “yo creo que esto son 6 meses” y ya vamos por 12…
3 – Los problemas del versionado. Como cualquier proyecto software, escribir un libro entre más de dos tiene, si no hay un proceso y cordinación mínima, muchos problemas de versionado. Al final hay más de dos personas tocando ficheros y pero al final debe haber sólo uno, alguien revisa la v 20 y mientras otro evoluciona la v 21, y la v 20 ahora no tiene los cambios de la v 21, uff, pero es que además…
4 – Los problemas de “mergeo”. Peor que en cualquier proyecto software, escribir tiene peores problemas de mergeo que un Subversion. Que sí, que es que además solemos escribir en formatos enriquecidos de texto y ahí no se mergea de otra manera que no sea… a mano.
5 – La complicación de las inspecciones caja blanca. Como cualquier proyecto software, escribir un libro también tiene, o debe tener, una ardua fase de inspección de texto, en vez de código, lo que suele llamarse revisión. Pero en los libros no hay PMDs, ni Checkstyles, que nos ayuden, nada nos da la complejidad ciclomática de lo escrito, y toca, como en los viejos tiempos (yo viví esa época)… inspeccionar a mano.
6 – El miedo de pasar a producción. Un clásico, que te voy a contar. Como cualquier proyecto software, escribir un libro también sufre de los pasos a producción. Un error en un paso a producción es durísimo. En este caso los pasos a producción de los libros se parecen a los del software embarcado… sólo podemos hacer un paso a producción, es decir, una vez enviado a la imprenta el libro… detectar un error una vez que se ha impreso… cuesta mucho, pero mucho, arreglarlo.

0 comentarios en “Los problemas de escribir un libro se parecen mucho a los de un proyecto de desarrollo”

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Share This
Ir arriba