Mensaje de Navidad 2013

Nos vemos de nuevo en enero 2014, después de la llegada de los reyes.

Recomendaciones para la implementación de una solución

La fase de implementación o de transicición puede ser más complicada de lo que
aparenta en la planificación. Pero hay recomedaciones que pueden ayudar y que
los gerentes deben tomar en cuenta

Durante todo el año hemos descrito el ciclo de vida de las aplicaciones desarrolladas con buenas prácticas de calidad y  una correcta Arquitectura de información como un espiral que transita cinco fases: Definición, Diseño, Desarrollo, Implementación y Producción. La semana pasada entramos en los problemas que se originan al intentar implementar una solución previamente desarrollada y vimos que, con independencia de la completitud, lo ingenioso y lo bien realizado que estén el trabajo de diseño y la labor de desarrollo de una solución, siempre habrá posibilidades de que se presenten problemas en la implementación porque los ambientes de desarrollo y producción son diferentes, incluso cuando aparentan no serlos en sus indicadores nominales y en las planificaciones.

Siendo así de incierta, la fase de implementación tiene una particular relevancia de la que es conveniente estar conscientes: hasta que no logre su cometido los usuarios no sentirán (y con razón desde su perspectiva) que el trabajo de desarrollo fue realizado, porque, para todo efecto práctico, una solución que no está operativa es una solución que no existe.

Ante esta complejidad podemos preguntarnos si se puede hacer algo para disminuir los riesgos de tener sorpresas durante la fase de transición. La respuesta es que si, que si bien nunca se pueden eliminar totalmente los riesgos, si se pueden minimizar si se realizan cinco cosas que un gerente debe recordar siempre al momento de planificar la implementación dentro de un proyecto.

Se trata de cinco recomendaciones básicas que podemos hacer para la fase de transición. En esta oportunidad las enumeraremos e introduciremos muy brevemente y dejaremos para siguientes ocasiones la ampliación con más detalles. Las recomendaciones son:

1. Establecer explicitamente los criterios de validación
2. Validar la aplicación en el servidor de desarrollo
3. Comenzar la transición en forma temprana, antes de concluir la construcción.
4. Hacer la transición en dos etapas: primero a un servidor de preproducción y luego al servidor de producción
5. Considerar que algunos ajustes pueden ser hechos durante la etapa de producción

Establecer explicitamente los criterios de validación
Tener claro los criterios que debe cumplir la solución construida para poder considerar la tarea realizada elimina subjetividad en las decisiones y una peligrosa fuente de malos entendidos entre las personas involucradas.

Validar la aplicación en el servidor de desarrollo:
Cada cambio de ambiente operativo introduce nuevos posibles puntos de falla e involucra otras personas por lo que es importante tener los criterios de aceptación bien definidos antes de pasar de un ambiente de trabajo a otros.

Comenzar la transición en forma temprana, antes de concluir la construcción:
Hay tareas de transición que pueden hacerse cuando aún se está construyendo y resulta recomendable realizarlas así, cada vez que sea posible.

Hacer la transición en dos etapas: primero a un servidor de preproducción y luego al servidor de producción:
Cuando no hay ambientes de preproducción en las instituciones hay más riesgos. Cuando los hay, se debe usarlos sistemáticamente.

Considerar que algunos ajustes pueden ser hechos durante la etapa de producción:
No se debe jugar al todo o nada. Es importante siempre un poco de flexibilidad en el camino que conduce a una transición plena al ambiente de operaciones final.

Estas cuatro recomendaciones básicas merecen comentarios adicionales. En siguientes oportunidades ampliaremos los detalles…

La implementación de una solución

Llevar una aplicación desarrollada al ambiente de producción
es una tarea que luce simple pero que puede ser bastante compleja

Con alguna frecuencia los desarrolladores jóvenes piensan que la construcción de la aplicación es el final de la complejidad, casi el último recodo del difícil camino de crear una nueva solución y, por tanto, el fin de los problemas técnicos de envergadura. Ojalá fuera así, pero muchas veces no lo es. No es lo mismo una solución construida que una solución en producción. Entre la aplicación desarrollada y la solución habilitada en condiciones  reales, útil a los usuarios y a la institución para los cuales fue desarrollada media un trabajo, el de la fase de implementación o de transición. Cuando no se ha hecho la tarea luce como sencilla, pero el trabajo no siempre es tan simple como aparenta y el camino de la transición suele estar lleno de sorpresas. Aunque en algunos casos la transición al ambiente de producción puede hacerse en un tiempo relativamente corto, a menudo surgen inconvenientes e imprevistos por lo que la fase de implementación requiere el concurso de competencias técnicas y gerenciales.

Con toda una fauna diversa de variables de hardware y de software, de capas y de interdependencias, el hacer que una aplicación de mediana complejidad trabaje en un segundo servidor, en el ambiente de producción de la institución de destino, es un trabajo en el cual pueden surgir imponderables que en ocasiones pueden hacer que una tarea supuesta a realizarse en horas se tenga que realizar en días, incluso en semanas, y luego de vencer toda una serie de dificultades.

El origen de los problemas tiene que ver con que el ambiente de desarrollo, en el cual trabajan los constructores nunca es exactamente igual al ambiente final en el que la solución desarrollada debe operar. La implementación no es copiar archivos, generar las condiciones iniciales en las bases de datos y configuraciones de la aplicación y pulsar un icono de invocación. Muchas veces es así la teoría, pero la práctica puede ser distante de ese desiderátum.

Todos los sistemas tienen versiones y subversiones, las condiciones de uso de una plataforma operativa cambian después que se han instalado y desinstalado capas de software, los discos se llenan, las plataformas de producción pueden implicar múltiples servidores con necesidades adicionales de establecimiento de permisos en ellos, hay cortafuegos y antivirus que pueden están presentes en producción y no haber sido considerados durante el desarrollo, los estándares de la industria al final dependen de sus implementaciones y esto hace que no todos los supuestos estándares siempre se comporten consistentemente, algunos servidores pueden requerir de pasos de configuración que los implementadores no tienen registrados en sus procedimientos, el ambiente de producción tiene una historia previa que es muy diferente de la de los ambientes de producción, la ingenuidad de algunos técnicos los lleva a veces a pensar que un cambio en la subversión de un paquete es algo trivial que debe resultar irrelevante, la burocracia administrativa de la red de destino puede marcar pautas que generan retrasos, en fin, cualquier variable ignorada o de apariencia intrascendente en una planificación puede saltar al momento de implementar lo que ya está desarrollado.

Lo triste del caso es que para los usuarios finales y las contrapartes de los desarrolladores la solución no existe si no está implementada, por muy grande que haya sido el trabajo de los constructores y por muy completa y eficiente que haya sido la fase de desarrollo.

Los componentes básicos de una aplicación moderna incluyen interacciones con el sistema operativo, el sistema de archivos, el sistema de gestión de bases de datos, el servidor de Web, el o los servicios de páginas Web dinámicas, el o los sistemas de mensajería y el uso de determinados clientes Web. Todo ello son posibles puntos que podrían generar  dificultades al momento de hacer la transición de una aplicación desarrollada al ambiente de producción. Debido a lo señalado el trabajo de hacer una transición desde el ambiente de desarrollo al de producción es una fase delicada, compleja y llena de posibles puntos de fallas, por lo que tendremos que hablar más sobre ella…

La inteligencia de las personas no garantiza los resultados

Mejor equipos geniales que personas geniales.
Los mejores resultados no los producen las personas inteligentes,
sino los equipos de alto desempeño.

La semana pasada estuvimos hablando de las buenas prácticas de trabajo durante el desarrollo de soluciones de gestión de información producidas con tecnologías de la información y conceptos de Arquitectura de información. La conclusión incluyó el énfasis necesario que hay que hacer en los métodos, en los procedimientos definidos y gestionados, en la mejora continua de procesos, realimentado la organización que desarrolla con el análisis permanente de los resultados, buenos o mejorables, de cada tarea. Quedó la pregunta planteada de si, como muchas veces se cree, lo que se necesita es contar con las personas particularmente inteligentes, al punto de hacer ésto el centro casi exclusivo de la atención, dado que hay una cierta consciencia de que los resultados que se obtienen desde una persona u otra son muy variables. La respuesta que dábamos es que no es así y que la garantía final de buenos resultados estaba en métodos y procesos. Es el punto donde continuamos hoy.

Aclaremos de entrada que no queremos decir que cuando hay métodos y procedimientos los resultados sean siempre buenos o que las personas no se equivocarán. Los errores y los problemas son siempre inevitables. Lo que afirmamos es que cuando se hace el trabajo bien, dentro de procedimientos maduros, métodos definidos y mejora continua de procedimientos a partir del análisis permanente de lo que puede ser mejorado, los resultados satisfactorios tienden a ser la norma y, si los métodos y procedimientos se mejoran constantemente, los buenos resultados será cada vez más repetibles, gestionados y el desarrollo será así optimizado.

A veces se cree que las personas brillantes es lo que hay que buscar en los equipos. Esta creencia es un error que tiene sus fundamentos. Es cierto que una persona genial puede hacer veinte veces más que una promedio (No hay error ni exageración en la afirmación. Una persona bien competente puede hacer el doble o el triple de una promedio. Pero una muy competente puede producir diez o veinte veces más). Pero hay dos elementos que hay que tomar en cuenta. Uno que las virtudes de un equipo son siempre mayores a las de las personas, por lo que es mejor contar con gente que sabe trabajar con otros en equipos de alto desempeño, que descansar sobre resultados impredecibles productos de las mentes geniales.

Por otro lado, la manera de prevenir los problemas ligados a los errores humanos no es trabajando con personas que no se equivocan, sino con procedimientos a pruebas de errores que hacen evidentes las fallas y disparan las actividades que generan correctivos.

Los métodos y los procedimientos realizados por equipos integrados y bien coordinados son los que conducen las buenas experiencias. A su vez, las experiencias (buenas y malas) deben usarse para refinar los métodos. Es decir, si hay algo que falló, los constructores deben preguntarse cómo pueden evitar esa falla en el futuro. De qué manera pueden mejorarse los métodos de trabajo y los procedimientos para que los problemas analizados no se presenten o, al menos, los resultados indeseados se detecten con poco esfuerzo en forma temprana.

Cuando nos damos el tiempo para hacer este tipo de reflexión, y analizamos, concluimos y producimos mejoras a los métodos y procesos como una práctica recurrente, los buenos resultados se repiten sistemáticamente.

Los métodos para construir

La construccíón de muros de piedra y de soluciones de tecnologías
de la información se realiza mejor y produce buenos resultados
si se trabaja con métodos y se siguen procedimientos
que son analizados y revisados
(Fotografía tomada de http://www.themarthablog.com)

Para construir buenas soluciones de gestión de información es importante, crucial en nuestra opinión, tener un método. Probablemente un conjunto de métodos enmarcados dentro de una metodología consistente. Esto es tan importante que decirlo debería resultar una trivialidad. Sin embargo, en la práctica, son muchos los casos en que el uso de metodologías no es lo que priva. La presión que ejerce la necesidad urgente de resultados, descontextualizada de qué es lo que asegura los buenos logros y evita el retrabajo, el deslumbramiento que producen ciertas herramientas, el desconocimiento de las prácticas elementales de gestión de la calidad de algunos desarrolladores y organizaciones, la ausencia de cultura de procesos, son algunos de los elementos que inciden en que se no sean pocos los casos en que se trabaje sin métodos ni metodologías.

La verdad es que los hechos están allí y las buenas prácticas internacionales muestran que si se desea garantizar buenos resultados, productos del trabajo satisfactorios y conforme a especificaciones y un cumplimiento razonable de los calendarios, es importante trabajar con métodos y diseñar, mejorar y seguir procesos.

Toda buena solución desarrollada con herramientas de tecnologías de la información es siempre el producto de una serie de interacciones e iteraciones. Interacciones entre todas las personas involucradas que hacen sus aportes respectivos en cada una de las fases de proyecto e iteraciones dentro del equipo de desarrollo refinando por aproximaciones sucesivas un resultado que por definición nunca está acabado, dado que siempre es perfectible y se tiene conciencia de que puede mejorarse, en su presentación, en su facilidad de uso, en su funcionalidad, en su flexibilidad, en su adaptación al usuario, etc. Todo esto dando por descontando el cumplimiento de los requisitos que fueron planteados en las fases tempranas del proyecto.

Si las cosas son así, tiene que haber un criterio para decidir cuando la construcción está lista para ser entregada y que debe pasarse a la etapa de transición con el objeto de que, finalizada ésta, la solución construida pueda entrar en producción. Este criterio es la validación final, donde los constructores, sus contrapartes y los usuarios certifican que la solución construida está lista para transferirse al ambiente de preproducción.

Pero ocurre en el camino, que mientras se construye, e incluso durante la transición, las iteraciones continúan. Es por ello que el uso de métodos y procesos es fundamental. Métodos y procesos es la única garantía de mejoras continuas en el refinamiento sucesivo que mencionamos. Si no hay métodos, en cualquier momento, en cualquier iteración, alguno de los desarrolladores hará algo mal con consecuencias negativas ya que puede que los malos resultados no sean detectados hasta muy tarde en el tiempo y en los cronogramas.

Es por ello que los métodos y los procesos hacen diferencias, especialmente cuando la organización que los usa los revisa y mejora constantemente. Muchos constructores, inadecuadamente, se confían y se dejan llevar por la apreciación de que se tiene en un instante un buen resultado. Lamentablemente estos buenos resultados son seguidos estadísticamente, en las próximas iteraciones, por los malos, ya que la concentración en los productos y no en los métodos y procesos hace que los problemas, inconsistencias y errores, inevitables en el tiempo, no sean detectados y corregidos.

Tener personas competentes ayuda a la producción de buenos resultados, pero no sustituye la necesidad de colocar el acento en los métodos y la mejora continua basada en procedimientos y procesos como lo expondremos con más detalles en una próxima oportunidad.