viernes, 28 de febrero de 2014

La fase de producción

La fase de producción implica colocar en modo activo
 la nueva solución y detectar y clasificar lo que puede ser mejorado,
distinguiendo entre lo que lleva a cerrar el ciclo de dedsarrollo
y lo que implicaría abrir uno nuevo
Las soluciones se diseñan y se desarrollan para que entren en producción. La fase de producción es así la etapa final en el ciclo de vida de una aplicación de teleinformación . También es donde, con el transcurrir del tiempo, se van detectando aspectos que pueden ser mejorados, con pequeños o con grandes cambios. Adicionalmente, en la fase de producción ocurren los eventos que desencadenan la génesis que promoverá un nuevo ciclo, una nueva iteración de definición, diseño, desarrollo e implementación.

Como hemos visto en otras oportunidades cada una de las fases de ciclo de vida de una aplicación tiene sus particularidades: características y dificultades. En la fase de implementación, es donde la aplicación desarrollada finalmente se coloca en los servidores de producción para comenzar a usar la solución en condiciones reales. Esto paso no significa que no se hayan encontrado algunos problemas, algunas pequeñas fallas, no conformidades con lo esperado o incluso, que a partir de las últimas pruebas y validaciones no hayan surgido algunas ideas nuevas sobre lo que podría hacerse mejor. Lo que significa es que haciendo un balance, encontramos que ya pasamos el punto donde es preferible entrar en producción y corregir detalles durante el camino, estando en activa la nueva solución, que esperar por nuevos cambios y mejoras con la aplicación desarrollada aún sin usar.

En los contratos de desarrollo, en forma realista, siempre hay que considerar un número de horas de soporte técnico que deben reservarse para cambios durante la fase de producción. Siempre es necesario realizar tareas de soporte técnico, incluso algunos ajustes de Arquitectura de información son a veces necesarios, a partir del momento en que se comienza a producir trabajando con la información real, en las condiciones reales, en los procesos oficiales de la institución.

¿Qué tipo de cambios se deben realizar en la fase de producción? Entonaciones técnicas informáticas, pequeñas correcciones de aspectos que actualmente reflejan problemas o que resulta conveniente mejorar, cambios en la estética o en la imagen para un mejor ajuste a la imagen institucional, cambios menores de presentación o de diagramación como el orden o el peso de ciertas opciones en la pantalla, con el objeto de hacer más visibles lo que debe verse en primera instancia o las opciones más frecuentemente requeridas, el agregado o la reestructuración de algunas opciones de navegación que si se cambian se mejora en forma significativa la usabilidad de la aplicación.

En la fase de producción hay que estar atento a todo lo que puede ser mejorado, pero hay que distinguir entre las mejoras que se orientan a cerrar una ciclo completo de desarrollo y las que se orientan a abrir un nuevo proceso de definición, diseño, desarrollo e implementación. Las primeras se pueden atender en lo inmediato, agrupándolas en términos prácticos para facilitar el seguimiento y las segundas simplemente se deben apuntar para su trabajo en un momento posterior, ya que no suele ser conveniente abrir un nuevo ciclo de desarrollo sin cerrar el primero.

También hay que distinguir entre dos tipos de necesidades: las de soporte técnico, que puede ser realizadas por el personal de informática a cago del desarrollo y soporte de la aplicación y que se caracterizan porque sólo implican acciones de tipo tecnológico y las de Arquitectura de información, que involucran el entender los modelos de información con los que se está trabajando para hacer ajustes a nivel de ellos.

viernes, 21 de febrero de 2014

El encuentro de psicologías durante el cierre de la transición

Durante la fase de transición hay un encuentro de equipos de psicologías
diferentes, que requieren destrezas de interacción
de parte de los líderes responsables
La semana pasada vimos que hay un momento en que hay que tomar la decisión de comenzar con la nueva solución implementada. Puede que en ese punto no todo esté completamente listo, pero lo que hay que reconocer es si está lo suficiente como para arrancar ya que si es así, hay que hacerlo con determinación. Queremos unir esa conversación con la de unos días atrás en la que comentamos como en la fase de transición se encuentran dos equipos diferentes en su constitución, origen y perspectiva.  Los desarrolladores y los usuarios. A veces éstos pertenecen a dos organizaciones diferentes, una contratada por la otra, pero, en cualquier caso, siempre son dos culturas, incluso cuando los dos equipos pertenecen a una misma institución, hay un encuentro de psicologías, ¿tiene esto implicaciones?

En nuestra experiencia si las tiene y nos abre la puerta para entender como hay una  necesidad de algunas destrezas adicionales que los líderes de proyectos deben desarrollar. El punto es que para el equipo de desarrollo, el proyecto está cerrando, pero para el que está del lado de los usuarios, el proyecto está abriéndose claramente.

Para unos, las responsabilidades están por terminar, mientras que para otros, si no recién comienzan, es seguro que por lo menos se intensifican debido al cambio de situación que genera la nueva aplicación. Hay implicaciones también jurídicas y financieras: la entrada en producción se concreta en una aceptación que debe firmarse y seguramente unos pagos que deben hacerse.  Hay implicaciones de tiempo, y ese tiempo también se traduce en dinero y nuevas situaciones organizativas. Todo esto expresa las características del momento en que se da ese encuentro de psicologías, de perspectivas contradictorias de las que debemos estar conscientes.

Los líderes de proyecto de ambos lados, de los que están entregando y cerrando y de los que están recibiendo y abriendo, deben ratificar el interés común en que la nueva solución desarrollada entre en producción. Declarárselo explícitamente y estar dispuestos a conciliar intereses particulares.

De lo anterior se desprende como en este punto de la fase de transición se vuelven relevantes lo que la literatura menciona como soft skills, destrezas de interacción reciproca bajo el interés de llegar a acuerdos, a pesar de los obtáculos que vayan apareciendo y en medio del eventual estrés que ciertas dificultades suelen traer consigo. El punto es interesante porque no se trata de un tema de métodos, de criterios objetivos predefinidos al estilo de lo que se expresa en los libros de ingeniería. A lo que nos referimos es a aspectos sutiles necesarios cuando la subjetividad aflora y la objetividad subyace.

Lo que comenzó debe concluirse para beneficio de la institución para la que se desarrolla el proyecto. Todos deben entender que la fase de implementación debe finalizar. Con la conclusión de la fase de transición y el arranque de la nueva aplicación no termina el ciclo de vida de la solución, sino que arranca la quinta fase: la producción, la razón de ser que debe ser el norte de todos los participantes del proyecto.

viernes, 14 de febrero de 2014

Arrancar la nueva solución

A veces hay que tomar una determinación:
Hacer explícito entre los involucrados en el proyecto
el interés institucional de entrar en producción
La conversación de las últimas semanas  ha girado en todo a la entrada la producción. Esa fase de transición a través de la que transformamos una aplicación desarrollada en una aplicación en uso. Hemos visto que se dice rápido pero que tiene sus complicaciones específicas, muy diferente a las de las dificultades de las otras fases del ciclo de vida de una solución: la definición, el diseño, el desarrollo. Hay un aspecto interesante que queremos conversar hoy: la decisión de arrancar, de decir ya, comenzamos a operar con el nuevo sistema. ¿En qué momento y bajo qué condiciones debemos tomarla?

El razonamiento simple y lo que muchos, en forma inexperta se imaginan, es que la entrada en producción es un punto, un instante, una decisión bien concreta producto de una situación bien definida: todo está absolutamente terminado. En realidad, salvo casos muy sencillos, el problema no es así de simple.  Es muy típico que si estamos en un proyecto para el cual definimos una Arquitectura de Información es porque estamos trabajando una solución de alguna complejidad, que tiene unos cuantos casos de uso (ver Conceptualización de la solución y casos de uso) y por tanto es una solución para la que las puras pruebas constituyen un proceso que requiere de múltiples tareas.

Puede notarse que si hay varios tipos de usuarios involucrados, que normalmente los hay, que si hay varios procesos y varios estados posibles para la información (Ver Estados de la información), que es natural que los haya, la cantidad de situaciones posibles que deben ser probadas (verificadas y validadas) pueden fácilmente ser más de un centenar y a veces varios (Ver Verificar y validar). Afortunadamente si se han hecho bien las cosas, siguiendo las recomendaciones que hemos dado para el desarrollo de la aplicación y para la fase de transición (Ver Recomendaciones para la implementación de una solución),  seguramente estamos realmente cerrando con todas o la mayoría de las precondiciones en estado de conformidad a lo definido y esperado.

Pero es muy usual que cuando todo está a punto, o casi a punto, se aprecien nuevos detalles, de distinta naturaleza. Desde criterios  estéticos hasta puntos ligados a la usabilidad donde alguna indefinición existía, zonas grises para las cuales todo no estaba completamente especificado o donde, a pesar de los esfuerzos de descripción sencilla y objetiva, quedó un espacio para la opinión y la subjetividad. La inminencia y la tensión de las implicaciones de la entrada en producción agudiza los sentidos, el hecho de que ganamos experiencia con los casos probados y eso nos permite imaginarnos eventuales situaciones de borde que podrían traer algunas complicaciones o, simplemente, que  algunas de las personas pueden, casi literalmente, ver más en la condición de estrés de la transición. ¿Qué hacer entonces?

Hay que tomar una decisión en algún  momento, pero hay una determinación previa que a veces hace falta ratificar entre los involucrados: debemos hacer explícito el interés en finalizar, lo bueno que es entrar en producción. Parecerá  una tontería, o una obviedad, pero la verdad es que muchas veces se cae en situaciones de  difícil cierre, de no convergencia, porque cada proceso de validación trae más puntos a la mesa, porque se agregan nuevas condiciones, o se exagera el peso de algunas no conformidades, particularmente si hay zonas grises.

Es trabajo de los líderes en estas situaciones es analizar si se está convergiendo a un punto de cierre de proyecto o si, por el contrario, el proyecto está entrando peligrosamente en un estado de no cierre crónico. Se deben pesar las no disconformidades contra las ventajas institucionales de iniciar las operaciones. Lo que sigue a la transición no es el fin del ciclo de vida, sino la entrada en producción, una nueva fase que también tiene sus dinámicas. Si hay dificultades que se detectan en los intentos de cierre, es importante tomar una determinación: revisar si algunos de los puntos pendientes pueden ser corregidos en producción. Si es así, no hay que dudarlo, hay que decir: ¡seguimos hacia delante!

viernes, 7 de febrero de 2014

La entrada en producción

Entrar en producción no es instalar y arrancar y sino un proceso
que tiene pasos que deben ser planificados para asegurar el éxito
Las soluciones de teleinformación se desarrollan en un sitio y se implementan en otro. Es la mejor práctica, ya que se evita que la construcción de una aplicación interfiera con la producción. La transición desde la red de desarrollo, donde se construyó la solución, a la red destinataria, donde la solución se colocará en producción, es un proceso que debe realizarse, en forma ideal, en dos pasos: preproducción y producción. Estos dos pasos son diferentes en sus objetivos, sus aspectos críticos, sus validaciones y sus logros. La semana pasada explicamos las características del paso de preproducción, por lo que esta semana nos concentraremos en los detalles del proceso de entrada en producción.

En la preproducción sólo migramos del servidor de desarrollo a la red destinataria y aprovechamos el hecho de que no estamos en producción para validar concienzudamente, en forma sistemática, todas las condiciones, incluso las contingencias más eventuales (Ver  La Validación de una solución). Es una actividad crítica que debe ser exhaustiva en sus condiciones de prueba, pero al menos tiene la ventaja de que se trabaja en forma paralela, con todos los sistemas actuales manteniéndose en producción y sin afectar ni a la institución ni a sus usuarios (Ver Una implementación bien hecha se hace en dos etapas). Cuando este paso se aprueba se está en condiciones de colocar la nueva solución en producción.

Para la entrada en producción hay que instalar la solución en el servidor definitivo, pero el problema no es tan simple como suena. Hay que planificar y desarrollar previamente las pruebas de aceptación que nos ayudan a desarrollar la confianza en que todo está bien o que nos dan las alertas sobre no conformidades que hay que atender antes de seguir adelante.

Un aspecto muy importante que se requiere para colocar la aplicación en producción tiene que ver con la data de trabajo. Es muy probable que debe migrarse desde la aplicación actual a la nueva lo cual es un proceso que podría ser complejo y consumir tiempo y recursos en forma significativa, por lo que debe prepararse a través de mediciones previas que nos ayuden a saber en cuánto tiempo puede realizarse la tarea.

Es muy común que la instalación de la nueva solución requiera detener las operaciones regulares  en el sistema actualmente en uso, ya que hay un momento en que las nuevas transacciones deben recibirse y realizarse en el nuevo sistema. Esto significa que después de instalar la solución desarrollada debe escogerse el momento propicio para activarla. En muchos casos puede ser los viernes al final las operaciones regulares, pero en soluciones que son mayormente usadas los fines de semana puede ser en otro momento.

En cualquier caso antes de iniciar las operaciones con el nuevo sistema hay que asegurarse de que los test de certificación no hayan dejado data o estados indeseados.  En el paso de preproducción no hay problema con ello, pero en el caso de la entrada en producción sí. Antes de iniciar deben cargarse los datos requeridos y si éstos provienen desde una migración ésta debe realizarse en un proceso medido ya que el tiempo disponible puede ser una variable crítica.

Los pasos naturales son así pues, la instalación, la certificación de la operación, el asegurarse del estado inicial, la migración, validación e instalación de la data y el seguimiento de las operaciones en estado de alerta después del encendido.

El paso de preproducción permite desarrollar el conocimiento necesario para el paso de producción, la confianza  requerida en los equipos de trabajo y el entrenamiento del personal operativo y de soporte y por eso es la mejor práctica. Intentar en forma directa hacer la entrada en producción sin un paso de preproducción puede ser muy duro y en vez de acortar puede alargar el tiempo empleado en las tareas de implementación.