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”.

Generador de espacios virtuales temporales en entornos colaborativos

Hace algún tiempo tuve la oportunidad de dirigir un proyecto en el sector bancario cuyo objetivo era dotar de un espacio de trabajo temporal a equipos multidisciplinares y geográficamente  dispersos.

No es  extraño que en los  proyectos actuales  sea necesario poner en contacto a personas de distintos lugares o países con diferentes responsabilidades, todo ello  enmarcado  en una actividad temporal. Como indica la propia  definición de  proyecto “un esfuerzo planificado, temporal y único realizado para crear productos o servicios únicos que agreguen valor o provoquen un cambio de  beneficios”.

Además de ser un esfuerzo temporal y único debemos añadir la inmediatez a la hora de organizar un equipo en un breve espacio de tiempo para iniciar los trabajos. De lo contrario no sería competitivo.

¿Cómo podemos poner a trabajar de forma coordinada a un equipo que se encuentra en diversas ubicaciones, con distintas franjas horarias, con diferentes responsabilidades y actividades?

Los espacios de colaboración son áreas virtuales que están dotadas de funcionalidades enfocadas a nuestras actividades y objetivos, que nos permiten registrar actividades, cargar  documentación,  notificar  eventos, calendarios, planificación de hitos, contactos, versionado y trazabilidad del entorno entre muchas otras posibilidades, tantas como sea necesario para realizar nuestro trabajo según su naturaleza.

La filosofía de trabajo de un entorno de este tipo difiere en mucho del que podemos utilizar de forma tradicional, correos electrónicos, carpetas compartidas, etc. Nos permite compartir   de forma centralizada un repositorio de información con todo el conocimiento del proyecto evitando islas. Los integrantes del grupo no tienen información en local (en sus dispositivos) y no se producen pérdidas de información si un miembro abandona el grupo.

Acceder a un espacio de colaboración es acceder al conocimiento del proyecto, a su histórico a tener contacto  a través de este medio con sus integrantes y a asegurar que toda su actividad quede registrada, mediante versionado de la documentación, ciclos de aprobación, auditoría de procesos o notificaciones por eventos a los miembros del equipo.

No es lo mismo preparar una actuación para la  adecuación de una ley o normativa bancaria que  una selección para RRHH o  un proyecto de TI o de relaciones internacionales. Cada uno de los espacios requerirá unos flujos de procesos, un tipo de calendario, documentación específica, auditoria de seguridad, indicadores de actividad, etc.

La operativa a seguir con un “Aprovisionador de Espacios de Colaboración” es la de identificar el tipo de espacio a generar y configurar cada uno de ellos:

• Con una funcionalidad común y/o específica para acometer la actividad o proyecto.

• Con un dimensionamiento, número de integrantes, volumetrías, accesibilidad, etc.

Una vez decidido el espacio que mejor se adapta a nuestras necesidades, y en pocas horas, podemos tener un entorno disponible en cualquier sitio y accesible desde cualquier dispositivo, listo para empezar a colaborar de forma organizada y segura.

Finalizado ese esfuerzo temporal, ese espacio virtual puede desaparecer, disolverse una vez conseguido su objetivo: crear productos o servicios únicos que agreguen valor o provoquen un cambio beneficioso.

Dependiendo del número de espacios a gestionar necesitaremos una herramienta que nos permita gestionar los entornos de trabajo, su seguridad, borrado, notificaciones, dimensionamiento, etc.

Las empresas requieren entornos dinámicos de trabajo, rápidos y flexibles que se creen y se destruyan, como sus productos, alineados con las necesidades de negocio, disponibles en horas para hacer frente a la competencia.

 

La NUBE está en la Tierra

 

Resulta tentador llamar a las cosas por otro nombre si con esto conseguimos atraer público y vender nuestros productos. Algunas veces un ligero cambio, otro enfoque, y una dosis de marketing es suficiente para tener un “Algo 3.0”.

La tecnología se adapta muy bien a estos temas y el consumidor también. Adquirir lo último siempre está de moda.

Para el usuario final el hecho de tener sus datos en “la nube” resulta “cool” aunque no sepamos donde, ni quien los puede ver o utilizar, pero están, o deberían estar, cuando los solicitamos.

El “cloud” es un servicio que se presta desde hace mucho tiempo, si desde hace mucho, pasaron por ser un Host o CPD, donde ya se empezaban a compartir recursos como el almacenamiento, procesamiento la seguridad, a un Grid o Grill a Housing o Virtual Private Server (VPS), Hosting o Clouding ¿os suena? Al final los que están detrás son siempre los mismos, multinacionales del sector o las consultoras boutique, como decía una amigo, que se reinventan para volver a vender lo mismo adaptado a los nuevos avances tecnológicos.

Y no me parece mal, dicho sea de paso, y sin dudarlo es el futuro, pero resulta irónico que te intenten vender de nuevo el mismo concepto (aunque con matices).

Por buscar una definición de “nube” sirva esta del NIST:

• “The National Institute of Standards and Technology (NIST) is an agency of the U.S. Department of Commerce that defines and sets standards for any emerging technology. NIST defines cloud computing as a model for enabling convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction. Cloud computing refers to both the applications delivered as services over the Internet and the hardware and systems software in the data centers that provide those services. According to NIST, this cloud model promotes availability and is comprised of five essential characteristics, three service models, and four deployment models.”

Para una empresa las dudas sobre la seguridad, disponibilidad, accesibilidad, etc resultan inquietantes y es lógico empezar a hacerse preguntas sobre este tipo de servicio. Y en cuantas más preguntas se hacen, más se parecen las respuestas a lo que ya sabemos o a lo que tenemos.

En época de crisis tenemos que ser imaginativos y si además nuestro producto ayuda a abaratar costes, porque es cierto que esta tecnología ayuda, aprovechemos el tirón y coloquemos nuestro nuevo concepto. Este parece ser el discurso.

¿Qué aporta la nube fuera de los avances técnicos de los últimos tiempos?

¿Hablamos de escalabilidad? Compartir recursos, administración de volumetrías y accesos, balanceo de carga, sistema híbridos, virtualizaciones dinámicas de recursos y espacio. No es nuevo aunque quieran cambiar la siglas, SaaS, PaaS , IaaS o algunas características: On-demand self-service, Broad network access, Resource pooling, rapid elasticity, measured service, ya presentes desde hace tiempo en otras soluciones.

¿Y por qué en este momento?

Está claro que en los últimos años se han abaratado los costes de almacenamiento, de las líneas de datos, de la electrónica de red, hasta el coste de los técnicos.Todo esto junto con nuevas aplicaciones de seguridad y la creciente necesidad de movilidad hace que este tipo de producto sea más apetecible y necesario.

Que podamos gestionar de forma más independiente nuestras infraestructuras y las adaptemos dinámicamente a la demanda de nuestro negocio es fundamental para ser competitivos. Podemos conseguirlo con la externalización de estructuras de TI. Esta es una solución, pero no perdamos de vista que “la nube” se encuentra en la Tierra junto con nuestro proveedor de siempre, busquemos primeras marcas y proveedores de referencia. (Azure puede ser una buena solución, por su diversidad en la oferta y recorrido hasta la fecha, aunque tenemos otras también interesantes).

Quizás pueda adelantar, sino lo está ya, que en un futuro inmediato nuestros datos (fotos, documentos, el vídeo de la boda, etc) se almacenarán en el espacio profundo tipo “DEEP DATA NETWORK 3.0”, en un servidor que nos circunvale en la estratosfera o en un clúster en Marte :)

 

Sensibilidad al cambio de alcance en ingeniería de software.

Gestionar un cambio de alcance en un proyecto suele ser, en algunos casos, más o mucho más complejo de lo que el cliente podría imaginar. 

Si hablamos de ingeniera de software parece que la sensibilidad por parte del cliente respecto al cambio  en el alcance del proyecto suele ser escasa o incluso nula. ¿Por qué? 

Sin embargo, si observamos otros ámbitos de la ingeniería, parece que este tema está superado. Por ejemplo, en una obra civil, si estamos construyendo un puente entre dos montañas y  ya tenemos los cimientos asentados,  es difícil que nos pidan mover el puente  400 metros a la derecha.  Parece existir una conciencia general sobre la dimensión del nuevo trabajo a realizar y del sobrecoste que supondrá.  Será porque se ve el hormigón, el perímetro de la obra delimitado, el despliegue de accesos a la zona de trabajo, las medidas de seguridad implantadas.

Sin llegar a este extremo, en otros proyectos como en la construcción de una casa, si ya estamos levantando los tabiques ¿sería lógico que nos pidieran reorientar la entrada principal? ¿Accedería el propietario a abrir una nueva fachada y a reorganiza la distribución de su casa?

Sin demasiados conocimientos sobre arquitectura el cliente es perfectamente consciente de lo que está pidiendo y de sus consecuencias. Puede “verlo”. 

En ocasiones,  en el desarrollo de software, nos solicitan  cambios que afectan a la arquitectura del proyecto (sus cimientos), hasta el punto de necesitar rediseñar los “from” (fachadas), la seguridad, los accesos, los modelos de datos o incluso la tecnología a utilizar.  

Sin embargo el cliente no siempre percibe la dimensión del cambio. No sólo piensa  que se puede hacer de forma rápida sino que el coste o es bajo o no tiene mayor  impacto. ¿Qué es lo que no ven?

Pasar de una arquitectura centralizada a distribuida, modular la funcionalidad, migrar a otro lenguaje o adaptarse a nuevas normativas bancarias en tiempo récord no parece un problema si se trata de algo “abstracto”, de código, de elementos  que residen  en nuestro “Cloud” tan de actualidad  en estos momentos. 

Al igual que en otras ingenierías es necesario levantar nuevos planos (volver a definir),  someterlos a aprobación, presentar un calendario, desarrollar (construir), realizar pruebas técnicas y funcionales, certificar, buscar nuevos perfiles si procede, etc.  

En definitiva volver a pasar por un procedimiento exigente y exhaustivo que garantiza que se entiende el nuevo alcance y la calidad de la entrega. 

Hace años se hablaba de líneas de código para valorar un cambio. Podíamos medir si el impacto era de veinte o treinta mil líneas, por utilizar un tangible, pero aun así era discutible.

De igual forma  ocurre con las  horas de esfuerzo. ¿Podemos explicar al cliente el impacto de una modificación en un modelo de datos, en una API o una DDL?  Sin cierto nivel de conocimiento previo  sobre la materia es difícil valorar el alcance de la propuesta. 

Es más fácil medir el cambio cuando se ve afectada el área de hardware, la que se puede ver, como ocurre si ampliamos nuestros entornos Host, Clúster, TELCO, etc.

En definitiva,  gestionar un cambio de alcance en una aplicación de software requerirá de un esfuerzo extra por parte de sus responsables que deberán transmitir de forma clara y sencilla, sin tecnicismos, lo que supone los cambios y de un ejercicio de imaginación  por parte del cliente, para entender lo que está  al otro lado de su pantalla.

Recuperar la confianza en un Proyecto

Si tenemos la suerte de participar con el cliente en un proyecto desde la fase de definición, las posibilidades de llegar a buen puerto y cumplir con todos nuestros compromisos en fecha, calidad y coste aumentan de forma significativa.

Pero no siempre tenemos esa suerte.

En  muchos casos los proyectos nos llegan ya iniciados. Heredamos  compromisos  difíciles de defender con  desvíos en costes y alcance. En  ocasiones contamos con un equipo desmotivado o reducido, con baja calidad de los trabajos y  en consecuencia, con  un cliente que  ha perdido la confianza en el proveedor.

Cuando se trata de proyectos no siempre tenemos un único responsable. Las indefiniciones, reiterados cambios de alcance o circunstancias con terceros hacen que en algunos casos se diluya la responsabilidad. Y en estos casos ¿Quién lo paga?

Con este panorama conseguir reconducir nuestro proyecto se puede convertir en un verdadero reto.

Dar un primer paso, en un ejercicio de trasparencia, es poner sobre la mesa el estado real en el que se encuentra el proyecto con total claridad, afrontando la realidad y sin minimizar ningún riesgo. Este ejercicio es el más complicado y delicado de un proceso de recuperación de un desastre ya que exige a todas las partes una prueba de voluntad y en algunos casos reconocer donde hemos fallado. Y en esta línea, es importante no buscar culpables.

Si conseguimos una “Foto real” y consensuada, donde podemos identificar cada una de las situaciones y estadios del proyecto,  podemos elaborar un plan de trabajo, donde tengamos bien descritos los pasos a ejecutar.

Tan importante es conocer el estado y la propuesta de replanificación, como lo es sentirse cómodo con las nuevas responsabilidades adquiridas entre el proveedor y cliente.

Contar con el apoyo y la implicación de la Dirección de la compañía o “Stakeholder” es fundamental, no sólo en el fondo sino en la forma, que en muchos casos supone un sobrecoste  que puede llegar a la reducción de beneficios o incluso a pérdidas en aras de una estrategia de empresa.

Un proyecto está compuesto por distintos estratos de los que se derivan diferentes responsabilidades. Si bien es cierto que es necesario un acuerdo a nivel de dirección que impulse el cambio, saber transmitir esta necesidad  al área  operativa puede ser muy  complejo   ya que en muchos casos es la que sufre mayor desgaste  debido a la fricción del día a día.

Llegar a este punto de entendimiento es el principio para reconducir el proyecto.

Sólo podemos generar confianza cuando realmente damos seguridad en lo que hacemos, es decir, cuando el cliente constata que la solución o parte de la misma es sólida y de adapta a los requerimientos solicitados.

Dividir o “fasear” la funcionalidad/entregas, si podemos, en busca de la recuperación de la credibilidad a corto plazo y avanzar con pequeños pasos hace que podamos medir mejor los entregables y cumplamos con las fechas de compromiso, otro punto que nos otorgará seguridad con el cliente.

En definitiva, saquemos la “Foto” real del estado del proyecto, replanifiquemos y aprendamos de los errores. Identifiquemos riesgos y acciones correctoras, busquemos compromisos de alto nivel entre las partes y avancemos con paso firme y seguro con compromisos a corto plazo para recuperar la confianza.

                                                                                                  Javier Ferrari Arroyo