El tipo de documentación que espero como desarrollador

En este pequeño post solo quisiera dar mi perspectiva como desarrollador sobre el tipo de documentación que yo necesito típicamente para poder hacer la implementación de una aplicación con éxito.

Es clásico en muchas empresas de desarrollo el pasar al desarrollador un documento sencillo que apenas si menciona los mismos requerimientos que el usuario ó cliente solicitó. Por ejemplo, supongamos el caso de una característica bastante interesante que tuve que implementar en una aplicación que hice hace algún tiempo. Voy a modificar por supuesto el ejemplo para que muestre un caso mucho más simple que el que me tocó implementar.

Resulta ser que en esta aplicación manejamos gráficos de columnas, como los que hace Excel. Supongamos que este gráfico muestra las ventas de un producto. En el eje X están los distintos meses del año y en el eje Y están las ventas totales para ese mes. Cada producto tiene asociado un tipo de producto. Lo que decía el nuevo requerimiento era algo así:

"Los usuarios necesitan poder mover las ventas de un producto de un mes hacia otro mes, preferiblemente haciendo Drag & Drop en el gráfico".

Y ya. ¡Ese es el requerimiento! ¿Qué se supone que haga yo con eso?

Por supuesto para el que redactó esa línea está muy claro lo que quiere o necesita, pero para mi, que soy el desarrollador y que de hecho no me interesa para nada conocer todo el negocio que está detrás de aquello, pues aquello me deja con una cantidad indefinida de preguntas que simplemente no me permiten para nada empezar mi trabajo:

• ¿Puedo mover las ventas desde cualquier mes hacia cualquier mes?
• ¿Puedo mover las ventas desde cualquier producto hacia cualquier producto?
• ¿Debo validar algo al momento de hacer el Drag & Drop?
• ¿Qué cambios debo hacer en la base de datos para soportar este tipo de funcionalidad?
• ¿Dónde debo guardar los datos?
• ¿En qué momento se guardan los datos?
• ¿Puede quedar un gráfico totalmente vacío después de mútiples Drag & Drop?
• ¿Debe quedar cada Drag & Drop registrado en algún lado? ¿O solo el resultado final?
• ¿Qué pasos específicos lleva a cabo el usuario para hacer esta operación?
• ¿Afecta este Drag & Drop a algún otro proceso del sistema?
• ¿Existe algún máximo o mínimo de Drag & Drop que se deban soportar?
• ¿Qué le digo al usuario si ocurre algún error? ¿O algún fallo en las validaciones?

Bueno, esas entre las pocas preguntas que a mi como desarrollador se me pueden ocurrir, pues no es mi deber el tratar de entender el negocio que está detrás de todo esto, sino simplemente el de implementar, es decir, plasmar en código, lo que me indique el o los documentos técnicos definidos por alguien más.

¿A qué documentos me refiero? Bueno pues, ahí viene el gran debate sobre la documentación que uno debería manejar para plasmar correctamente lo que se debe construir. Como muchos saben, existen cualquier cantidad de metodologías de desarrollo y cada una viene con su propio set de documentos que se supone deben ser llenados. En este post no voy a hablar de ninguna metodología en particular, sino que quiero más bien mencionar las cosas que, desde mi punto de vista, debería contener el documento que yo tome de base para construir una funcionalidad de la aplicación.

Este documento debería, mínimo, tener lo siguiente:

• Descripción de los pasos que realiza el usuario para completar su tarea.
• Un screenshot o bosquejo de la pantalla que se construirá. 
• Descripción de cada una de las entidades y/o atributos que se mostrarán o ingresarán en la interfaz gráfica.
• Descripción de cada uno de las entidades y/o atributos que la aplicación consultará ó modificará.
• Una lista de todas y cada una de las reglas y restricciones que afectan a esta funcionalidad y qué debe hacer la aplicación en el caso de que alguna de ellas no se cumpla.
• Si la secuencia de pasos que realizará el usuario es muy extensa y es importante que se siga esa secuencia específica, un dibujo o bosquejo de los pasos a realizar.
• Una lista de las tablas y campos de la base de datos que deben ser afectados y/o consultados por esta nueva funcionalidad.
• Una lista de las condiciones previas que deben cumplirse antes de que el usuario pueda empezar a utilizar esta funcionalidad.
• Una lista de los requerimientos de calidad de servicio que deben cumplirse, como por ejemplo requerimientos de rendiemiento, seguridad, facilidad de uso, etc.

Solamente con esta información a mano yo puedo sentirme seguro de lo que voy a implementar y no cometeré el error de asumir la respuesta a todas mis preguntas y codificar la aplicación, para al final darme cuenta de que aquello no era lo que quería el cliente.

Y por supuesto no se le debe delegar nunca la creación de esta documentación al mismo desarrollador. ¿Por qué? Pues por varias razones:

• El desarrollador es un experto técnico, mas no funcional. Por lo tanto, él no sabe (ni le interesa saber) nada sobre el negocio que se está tratando de resolver.
• El desarrollador necesita terminar su tarea de implementación con la más alta calidad posible en el tiempo que se le asignó. Si a más de todas las consideraciones de facilidad de uso, rendimiento, legibilidad del código, pruebas unitarias, escalabilidad, portabilidad, etc, que el desarrollador debe considerar, también se le encarga el asegurarse de entender "mágicamente" y plasmar todo lo que el cliente necesita, eso pues es una gran sobrecarga de trabajo para él, que normalmente no resulta en nada bueno.
• El desarrollador, por su naturaleza misma, trata de resolver las cosas con la solución más simple posible, que considere las restricciones que le plantearon por supuesto. El desarrollador, por ende, no va a ponerse a filosofar durante horas sobre lo que le conviene o no al usuario. Así que, si se le encarga a él esa tarea de definición de las especificaciones, pues las mismas resultarán ser lo más simple y fácil de implementar posible.

En conclusión, el jefe de proyecto, jefe de producto o quien sea que se encarge de liderar el proyecto debe de asegurarse de que los desarrolladores reciban la documentación más detallada posible antes de iniciar la implementación de una solución. En la creación de esta documentación entrarán los analistas de negocios, los usuarios finales, tal vez alguna persona de control de calidad, el experto en bases de datos, etc, pero nunca, nunca, el desarrollador.

Mientras más tareas ajenas a la codificación de la aplicación se excluyan del trabajo del desarrollador, mejor será la calidad del producto final y menor será el tiempo requerido para la implementación.

Julio.