El Arte de la definición funcional

Dejando de lado las metodologías ágiles donde la interacción es constante (entre desarrollador/cliente)  y donde se ven "in situ" los avances, se hace necesario establecer la forma de comunicar el  qué queremos hacer cuando el alcance es de mayor calado e implica mayor número de interlocutores. 

Aunque el debate sobre el desarrollo incremental versus funcional tradicional es interesante sería mejor tratarlo en otro post. 

Presentar una documentación funcional  que el cliente entienda y que recoja  el alcance y las actividades a desarrollar, que sea claro y suficiente para trabajar por parte del área técnica es, por decirlo de alguna manera, un milagro.  

 

Dos mundos muy diferentes condenados a entenderse si queremos tener éxito en nuestro proyecto. En el centro como interlocutor de ambas partes está la definición.

El documento entregable al cliente podría ser un “Documento de Descripción de Requisitos” (DDR) en el que deberíamos tener en cuenta: 

Qué debe de contener. 

Debe contener una enumeración de todos los requerimientos del proyecto por tipos, con su codificación, versionando y sus dependencias con otros.

Además debe enumerar todos los elementos necesarios para la trazabilidad y versionado del documento (control de cambios). El objetivo es poder seguir históricamente la evolución de cada uno de los requerimientos, número de versiones trabajadas, cambios realizados, participantes o comentarios añadidos. 

El documento debe de adaptarse al “core” de negocio y debe de mantener la esencia de la definición.  

Debemos tener presente siempre el que es lo que queremos hacer, todo lo que se salga de esta línea no debe de describirse y todo lo que no esté en la definición no existe y no se trata en el proyecto.

Qué no debe incluir.

El cómo y el con qué son elementos, en mi opinión, que no deben aparecer ni insinuarse en un documento de definición.

La forma de cómo se va a desarrollar la solución, para abordar el que de la definición funcional, debe de quedar fuera del alcance del DDR.

Por ejemplo, definir un “Proceso de recuento del ranking de popularidad”.

En este caso desarrollamos la definición, el qué, pero no debe trascender el cómo lo vamos a calcular. Esta información aparecerá en otros documentos como DDS, DRT, o en la Micro o Macro de la Arquitectura en el catálogo de software si hablamos de reutilización de código.

Con qué,  No vamos a indicar lenguajes, base de datos, plataformas o tecnologías.

Tampoco debemos utilizar terminología técnica que pueda confundir al cliente.

Hay que evitar en  la medida de lo posible, las listas de valores o los usuarios nominativos dentro de la definición ya que estos pueden cambiar y nos obligaría a cambiar el documento y su versión. Utilicemos otros documentos para estas configuraciones dinámicas.

¿Podemos definir mejor?

Debemos realizar definiciones atómicas de cada requerimiento.

Pocas líneas, párrafos cortos y directos, expresados de forma clara y  sencilla, ajustadas y acotadas al requerimiento que estamos tratando.

Tratar cada requerimiento uno a uno sin mezclar funcionalidades.

El enunciado de cada requerimiento debe de ser claro y único. Es muy importante, “lo que hace es lo que hace y nada más”, si es necesario desglosarlo en varios, hagámoslo. Si intuimos que puede cambiar, mayor motivo para aislarlo y acometer los cambios por separado.

Por ejemplo, un enunciado de un requerimiento no podrá ser “Marcar usuario como más valorado en la comunidad y mostrar el ranking de reputación dentro la comunidad”. Está claro que son dos requerimientos “Marcar” y “Mostrar”. Además no debemos desarrollar parte del requerimiento en el propio texto del enunciado.

Quedaría por ejemplo “Asignar valoración de Usuario” y “Asignar ranking de Usuario”.

En cada uno de ellos se desarrollará las condiciones y tipos de marca y valoración, y sólo en estos requerimientos y en ningún otro se tratarán estos aspectos.

Podremos vincular o asociar funcionalidades dentro de un requerimiento si en el desarrollo del mismo lo consideramos necesario.

Un requerimiento se define una única vez y no puede aparecer en otra parte del documento.

Podemos apoyarnos en maquetas visuales (imitando metodologías ágiles) que podemos mostrar al usuario (interacción visual), sobre todo cuando se trata de una interacción con aplicativos, pantallas o flujos de BPM.

La colaboración del área de “experiencia de usuario” es fundamental para conseguir una buena ergonomía y usabilidad del producto.

Estas maquetas se pueden adjuntar a los requerimientos que se vean afectados pero siempre indicando que es “LowFidelity” y nunca será un compromiso de lo que vamos a desarrollar. Para esto podremos construir una maqueta “HighFidelity” que deberá ser aprobada por el cliente y supervisada por experiencia de usuario para garantizar la calidad de su usabilidad y cumplimiento con las normas de arquitectura funcional.

Firma del cliente

Este esfuerzo de colaboración y de descripción  con sumo cuidado de qué queremos hacer tiene como objetivo la firma del cliente y el compromiso por parte del proveedor.

Este aspecto es,  según mi experiencia, un paso casi tan complicado como la oferta comercial, ya que en este momento se tiene el detalle de lo que vamos a construir y estamos solicitando el compromiso al cliente.

Algunas veces moverse en la indefinición suele “ayudar” más al cliente que al proveedor.

Conclusión

Al final nada de esto sirve si no somos capaces de redactar de forma clara, precisa y ordenada los requerimientos funcionales y el alcance de nuestro proyecto.

El documento funcional es además un documento contractual  con el cliente pero también con las áreas internas o terceras ya que es punto de partida del resto de actividades, planificación, evaluación de riesgos, viabilidad financiera, gestión recursos, arquitectura técnica y un sin fin de documentos que se basan en un DDR.

Dos riesgos latentes en una definición son las “Indefiniciones” y/o las “interpretaciones”.

Si aparecen en el documento es porque no hemos sido capaces de cerrar la funcionalidad (requerimientos) y/o el alcance (objeto del proyecto) y en este caso, todo el esfuerzo en la definición y el valor del documento (DDR) que podamos darle se desvanece y puede generar importantes sobrecoste y fricción entre las partes.

Seamos flexibles, no olvidemos que se trata de “interacciones funcionales” que se revisan constantemente, no se trata de acertar a la primera.

Una vez “cerrada” la definición proseguimos con el procedimiento de desarrollo con sus ciclos de trabajo y certificación y  en paralelo preparemos una nueva versión y recojamos los cambios de los requerimientos. Como comentaba, intentemos ser flexibles sin que sea necesario competir con las metodologías ágiles.  

No es un proceso sencillo requiere mucha práctica, enfoque y capacidad de síntesis. En definitiva no es necesario escribir un “bestseller”.