Esta entrada forma parte de una serie:
- Identificación de usuarios finales clave.
- Entrevista a dichos usuarios finales.
- Construcción de un prototipo basado en los resultados de las entrevistas. Es importante que el prototipo sea a la vez simple e interactivo.
- Presentación del prototipo a los usuarios finales, solicitando feedback.
- Desarrollar una guía de estilo que refleje el diseño/interfaz del prototipo.
- Completar y extender el prototipo hasta que demuestre funcionalmente todo el software.
- Utilizar el prototipo como la primera línea de base de los requisitos.
- Escribir una documentación de usuario detallada, basada en el prototipo anterior.
- Crear documentación de requisitos no funcionales para algoritmos, procesos, interfaces con otros sistemas hardware y software, etc.
Una vez tenemos cerrado el prototipo, es importante cerrar también, lo antes posible, una documentación de usuario (requisitos, manual de usuario, etc).
Muchos pensaréis: "venga ya. ¿ahora vamos a documentar? ¿No basta con el código?". De esto ya hemos hablado en otros posts: "Nos gusta programar pero no documentar". Hay varios motivos para hacerlo:
- Porque lo pide el cliente (sí, en multitud de pliegos, concursos públicos, etc., se exige documentación).
- Porque lo necesita el cliente (sí, de nuevo, los manuales se necesitan, como se necesita una rueda de repuesto. Y eso es así, aunque la rueda de repuesto, al igual que el manual, quizá no se lleguen a usar).
- Porque el cliente no se va a leer tu código cuando tenga que hacer algo y no sepa cómo, o cuando algo no funcione como el usuario cree que debe hacerlo.
- Porque cada vez que el cliente quiere negociar o revisar el avance del proyecto, no se va a leer tu código para ver cómo va a funcionar todo cuando esté: lo que se revisa son los requisitos o un manual provisional.
Bueno. Sigamos. Aunque normalmente se documenta al final, en nuestra aproximación, lo haremos al principio. ¿Porqué? Pues porque estamos haciendo una toma de requisitos, y la mejor forma de hacerlo es dejando los documentos por adelantado.
Es más fácil para el equipo de desarrollo consultar el manual a la hora de hacer unas pruebas, o de avanzar el desarrollo, que cualquier otra cosa. Quizá el usuario no se lea el manual, pero al menos los programadores y los testers sí deberían estar hartos de leerlo. Probablemente el usuario no se lo lee porque los manuales que solemos hacer son siempre "fuera de hora": los hacemos en ese tiempo que hay al final del proyecto, y porque nos obligan, y siempre es en horas muertas, o cuando ya estamos reventados de intentar sacar adelante una funcionalidad que ya va retrasada. Por cierto, esa funcionalidad tal vez no estaría retrasada si no hubiéramos tenido que rehacer 20 veces el producto...y eso ocurría (tal vez), si nos hubiéramos molestado en hacer un manual de usuario al principio (como aquí planteo).
Otra ventaja de hacer la documentación y manuales al principio, evita tener que hacer una especificación técnica detallada. Ya se indica cómo debe funcionar todo, ya están los requisitos...¡pues a programar!
El cliente y usuarios finales entenderán mucho mejor un manual, y seguro que si es el mismo que usan (y revisan y corrigen) los programadores en el día a día, será un manual útil, y no el típico ladrillo que se suele hacer y que nadie lee.
El tener una documentación completa tan temprano, pule aún más posibles inconsistencias y puntos "oscuros" que pudieran haber quedado en nuestro prototipo. Se evitan muchas veces el tener documentos demasiado técnicos. En su lugar, se está haciendo una documentación basada en el uso, en la funcionalidad, no en la tecnología.
Este tipo de documentación, se va a mantener y a actualizar, mucho mejor que cualquier otro tipo de documento. Puesto que es algo que todo el mundo usa y necesita tenerlo al día: los usuarios finales, los programadores, los analistas, los testers...es como el anillo de la película del señor de los anillos: "un documento para unirlos a todos...".
Este tipo de documento es práctico, sin rollos que pretendan artificialmente hacerlo ameno, o inteligente, o complejo. Dice lo que el usuario necesita que el software haga. Y punto.
En este documento, como hemos dicho, se especifica (como si fuera un documento funcional), el QUE, pero no el COMO.
Pero además, este tipo de documentación da a los programadores libertad y creatividad para resolver técnicamente las cosas como mejor les parezca. Y de esta forma, es mucho más fácil que acabe creando software que cumpla lo QUE necesita el usuario.
Un saludo.
No hay comentarios:
Publicar un comentario