El coste de la burocracia en una empresa tecnológica

Según los estudios realizados por Caper Jones, “documentar” es la segunda “fase” que más tiempo se lleva de media a la hora de desarrollar software. Documentar consume más del 30% del coste de crear un sistema software.
Los datos de Jones son de los 80 y, en mi experiencia, validos a fecha de hoy. Los datos de Jones no dejan de ser una media e, igualmente, hoy nos encontramos proyectos que apenas documentan (problema) y otros que se pasan (problema).
No han sido pocos aquellos que han alertado sobre el impacto negativo (económico, productivo, motivacional, etc.) del exceso de documentación, desde DeMarco en el antiguo Peopleware, el propio Jones, las iniciativas ágiles (que erróneamente algunos han confundido con no documentar, cuando hablan de documentar con sentido), todo el movimiento Lean (que mete a la sobre-documentación en la categoría desperdicio), etc.
Si bien las anteriores no deben haber sido muy escuchadas, o son apenas conocidas, a juzgar de lo extendida que está hoy ésta mala práctica, y de lo que le queda.
Y eso que el exceso de documentación, la creación de documentación no útil, supone una “hemorragia de tiempo” en los equipos, que pierden tiempo (1) documentando y (2) manteniendo la documentación.
Obviamente, si se sobre-documenta… habrá razones, cuestionables, que lleven a ello. En mi experiencia, las principales razones que llevan a la sobre documentación, caen principalmente en alguna de estas tres categorías:
a) Miedo, de no saber lo que se está desarrollando e intentar, por medio de la documentación, evitar depender de desarrollo (del proveedor, de personas, etc.), si bien, como comentamos en ¡Necesito evitar la dependencia de las personas!, la cosa no es tan fácil, y que “esté documentado” no es garantía de evitar la dependencia… puedes tener documentado “software” que ni existe. Más vale preocuparse por tener código de calidad, es decir, mantenible.

b) Desconocimiento, de cómo se construye el software. Ya lo hemos comentado muchas veces. La sobre documentación es otra práctica, dudosamente aplicable, que hemos heredado de reiterativamente, y erróneamente, intentar construir software igual que se construyen coches, presas, puentes, etc.
c) De “cara a la galería”,  para mostrarle papeles a un auditor, obtener un certificado, justificar trabajo, facturar documentos, etc. En parte, esta causa deriva muchas veces de las dos primeras.
Así que, si quieres aumentar tu productividad, la de tu equipo y la de tu empresa, cada vez que te plantees escribir un documento piensa antes: ¿Puedo hacerlo en menos páginas? (a más páginas, más gasto escribiendo y manteniendo documentos) ¿necesito incluso hacerlo? Si voy a describir una parte del software ¿voy a poder mantener el documento? y ¿va a ser útil para alguien?
Después de responder, escribe el documento, salvo que estés en la opción c de antes, entonces, puedes obviar las preguntas.

• Acerca de
• Últimas entradas

Javier Garzás

Javier Garzás es Doctor (Ph.D) en Informática, con un
postdoctorado en la Universidad Carnegie Mellon,
EE.UU. Es pionero en management, planificación,
estimación, product management, Agilidad y en la
aplicación de la inteligencia artificial generativa a la
gestión de la creación de productos y servicios
tecnológicos. Fue el único español en la primera
conferencia Ágil de la historia.

Últimas entradas de Javier Garzás (ver todo)

• OKRs sin Lado Oscuro, IA para OKRs y alternativas para evaluarlos - 25 julio, 2024
• Por qué seguimos usando técnicas ágiles anticuadas: Efecto Einstellung - 18 julio, 2024
• Cómo crear una IA personalizada (me llevó meses, pero te lo enseño en 2 min) - 11 julio, 2024