Este post viene motivado después de haber escuchado, de nuevo, el Lado Oscuro es fuerte, la frase…
“Documentemos ya [previamente, antes de empezar] la mayoría de las necesidades [huele a requisitos] del cliente, tenerlo documentado no va a estorbar y luego nos puede venir bien”.
Hay variaciones, y derivaciones, de la anterior frase como la de “sin un documento que detalle el alcance no podemos empezar” y similares.
Por otro lado, la anterior frase recuerda a la fase (que no tarea) clásica de requisitos del ciclo de vida en cascada.
Documentar no es gratuito, eso entiendo que es obvio, ya que escribir lleva tiempo, pero lo difícil de hacer ver es que ese tiempo puede ser un puro gasto, que puede no tener retorno ni utilidad en el futuro. Desperdicio.
Desperdicios derivados del tiempo que va entre escribir y ponerse a hacer
Existe un efecto que dice que cuanto más documento, en extensión y detalle, más alcance temporal le doy al documento (más predictivilidad, intento de adivinar el futuro). Y que cuanto mayor es el tiempo desde que se escribe algo en un documento hasta que me pongo a hacer lo que está documentado… mayor es la probabilidad de haber perdido el tiempo escribiendo.
Las principales razones que hacen que algo escrito no valga se ven cuando la teoría (el texto) se pone frente a ponerse a hacer algo. Cuando te pones ves realmente si se podía hacer así, si era viable. Otro efecto es que muchas veces los clientes, usuarios, el mundo, etc., aunque no te lo dijeron, aunque ellos quizá lo intentaron… tenían en mente algo diferente a aquello que acabas de hacer y que previamente escribiste en el documento.
Documentar no deja de ser algo teórico, algo que pensamos que luego haremos y que se podrá hacer y, lo más importante, que en el texto pensamos que tendrá utilidad (valor) a los usuarios… y no siempre es así, y lo descubrimos cuando los usuarios ven en real lo que hemos hecho (y que nos decía el documento que había que hacer).
Recomendación, si vas a documentar, aparte de hacerlo a mínimos, deja también mínimo el tiempo que va desde que escribes hasta que te poner a hacer. Y esto te va a implicar trocear ese «documento» en pequeñas cosas que escribo y enseguida hago (si profundizas en esto acabas en el concepto de Backlog).
Desperdicios derivados de tener mucho texto
Por otro lado, como te contaba en la información irrelevante en una especificación o Product Backlog suele conllevar a mayores estimaciones, tener mucho documentado (más si no es fiable) lleva a…
- Sobre estimaciones por parte de los equipos, existe una teoría (la que te contaba en el anterior post) que dice que psicológicamente si «vemos mucho» por hacer tendemos a estimar más. Si vas a documentar ves a mínimos.
- Costes de actualización de documentos: costes de buscar qué vale y qué no, qué está obsoleto, almacenar, buscar entre muchos documentos almacenados, etc.
- Lo que yo me encuentro es que a más texto… menos se habla. Y como se habla menos hay más malos entendidos, comunicación lenta vía pdf, pero la mejor manera de comunicarse es conversando cara a cara (no por word, ppt, Confluence, mail,etc.)
En la mayoría de los anteriores supuestos es más eficiente no haber documentado, o documentar lo justo, que tener un gran documento que no vale.
.
.
Otros post sobre ¡cuidado! con los documentos…
El coste de la burocracia en una empresa tecnológica
Taller de desintoxicación documental y superación de la abstinencia del word y powerpoint
Previene la Documentitis, elimina las herramientas de “Gestión Documental”
Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.
También soy profe de la Universidad Rey Juan Carlos.
- Las 3 matrices de priorización Ágil - 19 octubre, 2023
- Etapas del Agile Product Management - 12 octubre, 2023
- Agile Product Management: DINÁMICA «Árbol Solución Oportunidad» + «Valores Esperados» - 5 octubre, 2023
Estoy de acuerdo en el grueso de lo escrito, pero me falta el disclaimer que hable de dos puntos.
Esto es para equipos que sean ágiles y que sigan un framework como tal.
Uno de los grandes problemas respecto a lo que comentas es pasar al otro lado, el código autocontenido, donde entender un feature de punta a cabo nos puede hacer pasar por varias capas, tecnologías protocolos y otros, donde el “leer” código no será tan simple para “entender” la solución.
Ahí es donde no he podido encontrar referencias mas a detalle de qué es lo que se debe documentar. Seguramente y la respuesta que siempre se da es “lo que da valor”. Cuando tienes un equipo, es simple, cuando tienes muchos, ése valor se va volviendo subjetivo y es ahí donde los marcos grandes como safe, less o dad no tienen una referencia clara.
Tú has visto algo respecto a esto?
Muchas gracias por tus escritos, son de gran valor para conocer y refrescar muchos temas que son presente pasado y futuro para quienes trabajamos en empresas que quieren cambiar
Hola Javier,
no nos engañemos se documenta para cubrirte las espaldas ante el cliente e incluso ante tu propia empresa. Cuantas veces ha pasado que has hablado con el cliente para hacer una nueva funcionalidad, aceptarla por su parte, desarrollarla y cuando se la enseñas te responde con un…pero este no es lo que yo he pedido. Que hace en estos casos? volver a la casilla de salida? hacerte el tonto?
Ahí es cuando entra en juego la documentación. Aun así, yo también opino que documentar mejor lo mínimo indispensable.
Muy buen post como siempre.
Un saludo,Manu
Hola Javier,
Muy buen post. Más interacción y menos documentación. He sido parte de equipos de desarrollo donde es muy notable aplicar esta práctica.
Tego una incognita en la cual me puedas ayudar a resolver. Si soy un desarrollador independiente que cobra por el alcance de una etapa del proyecto y no por horas trabajadas, siempre les exijo a los dueños del proyecto una documentación detallada del alcance, así evitar aquellos requisitos improvisados o extras que desean incluir durante el proceso de desarrollo y que no estan detallados en el alcance especificado en un inicio y que a su vez significan más tiempo de desarrollo por mi parte y no cubiertos por parte de ellos en el costo mismo.
Cómo considerarías el uso de documentación en estos casos o existe alguna práctica mejor a aplicar que pueda contrarestar el exceso de ambos casos(uso excesivo de documentación y/o requisitos improvisados) ?
Me cuesta encontrar info sobre documentar APIS, supongo que ese tipo de doc no se considera un desperdicio o sí?