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