Quienes han trabajado en proyectos conocen de primera mano esa sensación de felicidad indescriptible de sacar un proyecto en vivo. La comunicación por parte del líder confirmando que el proyecto ha entrado en operación, genera una gran satisfacción y a la vez un gran temor, dado que detrás de esas tres líneas del correo, existió una programación, diseño, expectativa, conocimiento del equipo de trabajo, imprevistos, planes de acción para solucionar problemas, cambios de recursos, discusiones, nuevos interlocutores, trasnochos, toma de decisiones, en fin, la lista es interminable.

Los proyectos de tecnología en particular tienen ciertos componentes adicionales que le agregan mucha más “emoción” a poder tener un proyecto no solo en vivo, sino estabilizado.

Etapas de una salida en vivo

Etapa preliminar

El primer ingrediente es que cuando se plantea la necesidad de iniciar un proyecto, el promotor supone mapas mentales donde toda la necesidad está clara y la fase de diseño la da por finalizada sin dar inicio. La mayoría de las veces parten de esquemas o bocetos que carecen de todo nivel de detalle.

La mayoría de las veces el inicio del proyecto de tecnología no tiene nada que ver con tecnología y surgen diferentes necesidades en cuanto a reformar los procesos y evaluar la idoneidad de las personas del equipo que ejecutan las acciones que se van a ver impactadas con la implementación de la herramienta tecnológica.

En esta etapa preliminar aparecen las primeras fricciones dado que los tiempos de la necesidad ya inician atrasados  pues no se había logrado convencer a los patrocinadores de invertir en una solución de tecnología (aquí algunos consejos para vender un proyecto de tecnología al interior de las compañías de forma exitosa). El compromiso de los tiempos es un tema extremadamente delicado que genera bastantes frustraciones ya que lo normal es suponer tiempos sin tener clara ni la necesidad ni el nivel de esfuerzo y se basan en prácticas de proyectos diferentes a tecnología que no son comparables.

Etapa de diseño

Suponiendo que esta etapa preliminar fue superada y se tomó la decisión de disponer recursos para la ejecución del proyecto, inicia en forma la etapa de diseño funcional. En esta fase se deben plasmar todas esas ideas de gran nivel en un documento de detalle que, posteriormente, será el insumo para que un equipo de desarrollo tecnológico pueda materializar la necesidad.

Ese documento resulta ser un dolor de cabeza para los responsables funcionales ya que al unir al equipo que todos los días ejecuta la tarea que será digitalizada o automatizada, se tienen muchas aristas y se ejecutan diferentes criterios ya que depende finalmente de personas.

Adicional, existen casuísticas que a pesar de ser la excepción son tratadas como una necesidad primaria a implementar que llevan a desarrollar lógicas de alta complejidad sin el cálculo de una medida de costo beneficio. Este proceso lleva bastantes iteraciones, es muy desgastante y suele ser la primera decepción del proyecto que debe ser controlada dado que los tiempos originales estimados ya fueron superados  atendiendo una etapa de diseño que desde la aprobación debía estar completada al 100%.

Etapa de revisión técnica

Posterior a esto viene una etapa de revisión técnica para aterrizar la necesidad funcional a lógicas que se pueden lograr, la mayoría de las veces las necesidades funcionales son “una carta al niño Dios” en las cuales la materialización resulta bastante compleja y requiere recursos muy superiores a los estimados inicialmente debido a un bosquejo de gran nivel que no tenía el detalle necesario.

Un componente adicional que le agrega complejidad a los proyectos tecnológicos es que se imaginan funcionalmente la integración de diferentes herramientas tecnológicas, esto a pesar de ser realizable, la mayoría de las veces supone una coordinación de diferentes interlocutores, proveedores tecnológicos con diferentes ANS, metodologías de trabajo,prioridades, es una “torre de babel” que requiere del mejor de los controles y rigurosidad por parte del responsable del proyecto como un todo.

El problema de esta etapa no es solo poner de acuerdo a los equipos técnicos, sino poder transmitir al equipo funcional las restricciones de tecnología o los impactos del proyecto para ejecutar determinada funcionalidad. Al equipo funcional le genera bastante frustración esta etapa dado que la premisa del proyecto original era cumplir una necesidad funcional y no cumplir la necesidad teniendo en cuentas las restricciones técnicas que no deberían de existir.

Etapa de ejecución de desarrollos

Superadas todas las etapas, viene un aterrizaje de los tiempos y un cronograma de detalle para iniciar la ejecución de los desarrollos; un tema relevante es que las etapas anteriores ya tuvieron un atraso con respecto a lo planeado originalmente y la disponibilidad de recursos puede haber cambiado de forma abrupta y lo primero ante esa liberación es una fase de programación de recursos y liberación pertinente para atender el proyecto que, normalmente, no es considerado en el panorama de trabajo original.

Normalmente, los entregables de los proyectos de tecnología son binarios, no hay cómo mostrar avances por la cantidad de componentes tecnológicos dependientes, enlazados e impactados, no es posible mostrar parte del flujo o la herramienta sin una integración. Esta restricción es bastante difícil de explicar y transmitir al equipo funcional, ya que los proyectos en otros ámbitos pueden verse el paso a paso e inclusive realizar correcciones a lo que se va viendo construido.

En tecnología se desarrolla lo diseñado, se prueba lo diseñado y se entrega al cliente lo diseñado, el cliente normalmente en esa entrega intenta involucrar nuevos actores que serán impactados con la salida del proyecto con el fin de realizar un manejo del cambio adecuado. Acá surgen nuevas necesidades, diferentes perspectivas, otras casuísticas que al no ser consideradas en el diseño original impactan nuevamente el cronograma definido, la opción de cerrarse a cambios en esta etapa de primer contacto con los usuarios que van a operar la herramienta puede generar incomodidades y fricciones que perjudican en gran medida la aceptación del proyecto.

Una buena acción para controlar este tema es realizar un levantamiento de nuevos requerimientos en dos frentes: los que son totalmente necesarios para dar inicio al proyecto, “stopper”, y los que son deseables, pero no son necesarios y su implementación mejoraría la experiencia, “nice to have”. Un tema relevante en este punto es ser bastante claros con el alcance definido y una expectativa en tiempo y recursos de poder abordar el 100% de las necesidades.

Etapa de pruebas

Una de las etapas más importantes de todo el proyecto es ejecutar pruebas de usuario funcional y dar una aprobación formal de que lo desarrollado corresponde a lo pactado en las necesidades. Aquí surgen impedimentos ya que el equipo dispuesto para esto no lo tiene como prioridad, dado que deben seguir atendiendo la operación con las herramientas actuales. Es bastante importante, aunque se dificulta la mayoría de las veces, destinar tiempo de calidad para la ejecución de pruebas a cabalidad para controlar al máximo los incidentes que puedan surgir en la operación del proyecto.

Etapa de salida en vivo

Todo lo anterior se materializa con el despliegue de las funcionalidades y salir a productivo para esto hay que tener mucho orden y disciplina para poder recopilar absolutamente toda la historia del recorrido del proyecto hasta este punto, cualquier olvido puede generar grandes insatisfacciones o se debe controlar con velocidad y proactividad. Posterior a eso viene toda una etapa de estabilización que debe tener atención de primera línea y poder generar el menor ruido posible ya que paralelo a la operación del proyecto se están generando acciones de gestión de cambio para la recepción positiva y superar las barreras de entrada.

Como puede verse, detrás de las sacar proyectos de tecnología en vivo, ¡hay un mundo entero tras bambalinas!