Los entregables (deliverables), como concreción de los hitos en proyectos tecnológicos, son huesos duros de roer, tanto para el que los emite y desea cobrarlos, como para el que los contrató y tiene que validarlos. Si los entregables son piezas de código no se genera tanta tensión, pues, salvo contadas y honrosas excepciones, se espera que el software entregado funcione, por lo que con tal prueba (y con independencia de la bondad de los procedimientos, unitarios o funcionales, que corroboren este “buen comportamiento”) se libera la ansiedad entre contratante y contratado, que viene a ser sustituida por otra, tal vez más agobiante, relacionada con los plazos. Pero, ¡ay!, si los entregables son documentos, entonces… ¡que San Tito nos asista, a todos!
Para intentar lidiar con esta inquietud (“desinquietud”, que diría mi madre) los documentos de un proyecto tecnológico/software (especificaciones, requisitos, escenarios, análisis, diseños, etc.) han sido sometidos históricamente a distintos enfoques asociados a su evolución respecto del ciclo de vida total de los proyectos mismos. Tales enfoques, esencialmente pasados por agua, se pueden resumir en los siguientes:
Cascada [entregables rígidos]: cada fase pre-establecida genera documentos que se asemejan a cubos de platino-iridio (incluso en el precio), pues pueden ir cayendo por la cascada, entre piedras y fases, y no modificarse en absoluto. Resulta ideal para los contratados, pues siempre se puede elaborar un documento correcto cuyo alcance no cubra su presupuesto, pero el contratante nunca podrá validar que está completo ni que, por tanto, se ajusta a sus necesidades.
Fuente [entregables flexibles]: los documentos son bien rocas bien trozos suficientemente sobados de plastilina, con cierta intención de forma inicial, y se espera que limen sus aristas y adquieran su forma de cantos rodados tirándolos muchas veces arriba y abajo, contra el suelo, contra ellos mismos. Se trata de un modelo similar al de la cascada, a la que se ha añadido un costoso procedimiento para subir las piedras y lanzarlas de nuevo, desde el principio o desde cualquier parte de la cascada. Para los consultores, tal costo adicional (de subida) debiera asumirlo el cliente, así que se parapetan en una política clara: la cascada es suya y las piedras son del cliente una vez que las aprueba, así que si hay que realizar cualquier esfuerzo posterior… ¡que lo pague el contratante, pues se deberá a su propio error de apreciación! Así que el resultado final de estas técnicas, asociadas a OORA/OOA/OOD suele ser… ¡el mismo que en el enfoque de cascada! Pero, eso sí, se admiten pequeños cambios en los documentos que no supongan costes significativos para el contratado.
Granizo [micro-entregables rígidos]: como consecuencia del esquema intermedio anterior, los clientes deciden limitar su riesgo troceando las piedras grandes en gravilla, que podrá ser así controlada mejor y validada con mayor seguridad: tal es lo que proponen los Métodos Ágiles. El problema es que, por tratarse de documentos tan cortos (micro-escenarios de negocio, objetivos concretos, etc.), se establece de antemano que una vez aprobados cualquier cambio supondrá… ¡un nuevo documento! Así que no hace falta motor hidráulico para devolver las piedrecitas a la cascada: se trata de granizo que cae del cielo, sólo desde arriba hacia abajo. Y, usualmente, causa parecido daño.
Al final uno no sabe qué es peor (o mejor); sobre todo en las AAPP, que por sus características de contratación tienen que anticipar los métodos en los que enmarcar los entregables. ¿Hay solución? ¡Pues claro! El problema reside, precisamente, en que los anteriores esquemas se centran en el marco metódico de composición, entrega y validación de los documentos, en lugar de centrarse en su generación práctica (no metódica); así que si cambiamos el foco de atención y lo dirigimos hacia objetivos prácticos, tal problema deja, en muchas casos, de tener sentido.
Lo que aquí propugno es la imposición de “frecuentregables”: es decir, de entregas frecuentes de documentación, ¡pero no de documentos!, configurando así una suerte de [micro-entregables flexibles]. Pasemos, sin más, al lado luminoso de La Fuerza.
El mayor problema de los documentos es que una vez terminados de redactar difícilmente pueden ser reformulados o cambiados esencialmente –al menos por sus autores–, sino tan sólo levemente modificados o matizados. Por otro lado, para el revisor, leer un documento implica asumir paulatinamente su estructura, de forma que finalmente se introducen correcciones pequeñas, que el consultor solventa y vuelve a presentar, de forma que a cada corrección resuelta se torna más difícil echar atrás un documento. Por fin, la tarea de revisión se realiza a golpes, sobre mucho trabajo anterior, sobre muchas páginas y bajo demasiado riesgo. Para evitar esto hay que forzar a que el contratante tenga acceso, en todo momento, a cualquier texto redactado por el contratado, de manera que cada día se cuente con el diferencial de lo hecho el día anterior (la funcionalidad de revisión de MS Word y similares –como la línea base de los ficheros MS Project– es fantástica a este fin); y esto sólo se consigue cuando no se trabaja con un fichero en local que se “sube” a un servidor en un momento dado (o, peor, se envía por correo electrónico): se consigue cuando el fichero está, directamente, en un servidor de ficheros (wiki, MS Sharepoint, MS Groove, etc.). En definitiva, se deben imponer las siguientes normas:
· Una versión de trabajo de un documento es, simplemente, la que supone cualquier modificación respecto del documento previo. Una versión estable es aquella que, de entre todas las de un documento, se ha calificado así en un momento dado y sirve para asegurar emocional y presupuestariamente su uso como referencia temporal de otros documentos y trabajos. Un hito será una versión estable solo-lectura.
· Las versiones de trabajo siempre residirán en el servidor, y se actualizarán directamente allí ante cualquier cambio, por pequeño que sea. Si las versiones se aportan sin que haya control de cambios (bien por el programa en sí, como MS Word, bien por el sistema de soporte –por ejemplo, un wiki), se rechazarán sin más explicaciones (hacen perder el tiempo al revisor).
· Si se aportan versiones cuya diferencia respecto de los ficheros anteriores sea excesiva (muchas páginas), se considerará que el contratado no ha “colaborado ofimáticamente” con el contratante, y se rechazará de plano el documento completo, que deberá ser re-redactado mediante pequeñas adiciones, cada una de ellas sujeta a revisión.
· Las carátulas, hojas de aprobación, dibujitos, etc. no tienen mucho sentido en este esquema, así que, en lo posible, se relegarán a versiones estables e hitos.
· La propiedad de los documentos es siempre del contratante, por lo que, con independencia de su autoría, autoriza su modificación por cualquier integrante del proyecto, sin restricciones (asumiendo que se cuenta con un sistema de versionamiento razonable).
· No se eliminará ningún documento en ningún momento, bajo ninguna circunstancia. Tan sólo se versionarán, incluso mediante un documento intencionadamente en blanco, con la mención “eliminado” y una explicación de la causa de esta acción.
· No se darán aprobaciones expresas sobre versiones de trabajo: tan sólo modificaciones o vetos.
De esta forma se eliminan muchas de las dudas y quejas relacionadas con la elaboración de documentos: las copias desde “trabajos anteriores” (el celebérrimo “copy-n-paste” de las consultoras de prestigio) se tornan más costosas que su elaboración desde cero (es ciertamente difícil simular que se está redactando un documento que ya está redactado; y, además, en cada adición se puede producir un cambio de rumbo, sin lastre moral o presupuestario para el revisor); el ajuste, por otro lado, con la situación concreta a modelar (el objeto de la contratación) podrá ser revisado mejor así; adicionalmente, y sin necesidad de controles presenciales, se podrá controlar mejor la evolución del proyecto, simplemente estimando el diferencial de trabajo realizado de un día a otro, y no respecto del total del proyecto; y, por último, el contratante dispondrá con mayores eficacia y eficiencia de su tiempo, adaptando las revisiones a su agenda de tareas.
La idea es muy simple: ante alguien que te debe un millón de euros y no te paga porque prefiere pagarte de golpe (o en dos o tres golpes), uno confía más en el que te paga 100€ al día, en tanto sobrevienen “los golpes”. Y aquí, como saben contratantes y contratados, también se trata de euros.
. 
