Para qué sirven los documentos de requisitos funcionales
El sello que certifica que se está siguiendo el modelo en cascada es el documento de requisitos funcionales. El documento funcional especifica, antes que se empiece a programar, como debe ser el software y qué es lo que debe hacer. En teoría, el desarrollador puede consultarlo para aclarar cualquier duda que tenga sobre cómo funciona el software.
Digo en teoría, porque en la práctica esto no suele suceder. Yo mismo he tenido mi buena ración de documentos funcionales, me ha tocado escribirlos y corregirlos, pero nunca los he utilizado para lo que se supone que están hechos: para aclarar mis dudas sobre como debe funcionar un programa.
Los documentos funcionales no parecen muy útiles. Algunos expertos en hacer buen software, como la gente de 37 Signals, incluso piensan que no sirven de nada. Pero, entonces, ¿por qué seguimos haciendo documentos funcionales?
La respuesta, como casi siempre que se reincide en un error claro, no es tanto técnica como psicológica.
A muchos desarrolladores o responsables de proyectos les gustan los documentos de requisitos funcionales porque limitan su responsabilidad. Hacer buen software que contente al cliente es algo complicado; cumplir un documento de requisitos funcionales es algo mucho más sencillo. El documento funcional es una especie de contrato de lo que el desarrollador se compromete a hacer: en vez de comprometerse a hacer un software de calidad que resuelva problemas reales, el desarrollador se compromete sólo a implementar lo que está escrito en el funcional.
Si el producto no funciona bien, o no resuelve los problemas del cliente, el desarrollador se siente eximido de responsabilidad: “Mi programa cumple el funcional -dice-, si querían otra cosa, tenían que haberlo dicho en el documento funcional“. La culpa no es mía, sino del cliente, que no ha sabido escribir un buen documento funcional.
Los documentos funcionales son la excusa perfecta para hacer software chapucero y luego echarle la culpa al cliente.
El problema es siempre el mismo, los documentos funcionales lo hacen personas del rubro IT mientras que los clientes pocas veces entienden que es lo que realmente uno le esta preguntando, pero nadie se pone a pensar en que se siente que te hablen en chino. Culpar al usuario final es la forma de quitarnos la responsabilidad de que los documentos funcionales están mal hechos. A diferencia de lo dicen los de 37 signal, yo creo que los documentos funcionales sirven de mucho, los buenos documentos funcionales sirven de mucho. Si hacemos documentos chapuceros y luego un software que cumpla con estos no es culpa del cliente, aunque siempre es más facil echarle la culpa a otros.
Hola Tekno Duke, supongo que es una cuestión de gustos pero mi experiencia personal es que existen alternativas ligeras a los documentos de requisitos funcionales, como las tarjetas con historias de usuario que se usan en Extremme Programming, y que funcionan mucho mejor. Esta práctica consiste, simplemente, en escribir las historias de usuario en tarjetas; son historias sencillas y concisas, quizá de una línea, no un documento exhaustivo. No especifican al pie de la letra como tiene que funcionar la aplicación, sino que sólo sirven para que el cliente sepa en qué estás trabajando, y tu puedas centrarte en implementar funcionalidades concretas, y, por supuesto, para planificar el proyecto.
Al finalizar una iteración, se puede replanificar el proyecto. Quizá priorizar más unas historias, o añadir algunas nuevas. Es un proceso mucho más ágil.
Yo, personalmente, me siento más productivo trabajando de ese modo y no echo en falta ningún documento funcional.
Saludos
Hola,
Ante todo enhorabuena por el blog, merece la pena pararse a leerlo. Respecto a los funcionales, efectivamente, he hecho cosas que no quiero recordar gracias a ellos… Engendros que duraron 3 dias en producción pero que firmaron los clientes, es más insistierón. Creo que las metodologias dependen más del cliente que del desarrollador. Para esos clientes tocahuevos que pasan de tu opinión, son cerrados de mollera, ratas para aburrir y creen que tu trabajo lo podria hacer un mono bien enseñado, aunque un buen trabajo me llena de paz, un funcional bien cerrado sin ambiguedades aunque sepas que lo que estas haciendo no tiene sentido, me da una tranquilidad que no tiene precio.
Un saludo.