Saltar al contenido principal

​
Notificaciones / anuncios

Para que un lanzamiento se desarrolle sin problemas, es útil que todas las partes interesadas estén al tanto del lanzamiento inminente y comprendan el plan de lanzamiento, así como sus funciones y responsabilidades. Además de notificar a los equipos que participarán activamente, también puede ser útil notificar a los equipos que podrían necesitarse si algo sale mal. Tener a alguien de guardia durante un lanzamiento puede ayudar a agilizar la respuesta. Asegúrate de identificar y notificar a cualquier equipo que pueda tener que responder preguntas de los clientes, incluso en las redes sociales.

​
Partes a las que se debe notificar

  • Clientes
  • Socios comerciales, si corresponde
  • Equipos de aplicaciones afectados por el lanzamiento
  • Equipos de soporte
  • Equipos de red (cambios en la red, en espera por si surgen problemas)
  • Equipos de seguridad (en espera por si surgen problemas)
  • Equipos de marketing (listos para hacer anuncios y responder ante problemas)
  • Equipos de redes sociales (listos para supervisar las redes sociales y responder)
  • Equipos de ventas (preparados para responder preguntas de los clientes)
  • Equipos de éxito del cliente (preparados para responder preguntas de los clientes)

​
Plan de notificación

Su plan de notificación debe incluir elementos como la objetivo, los puntos clave para esa audiencia, el contenido del mensaje, el plan de distribución de la notificación y cómo probar los mensajes. La lista de elementos que se deben incluir en el plan es la siguiente:
  • Audiencia objetivo (tenga en cuenta tanto las audiencias internas como las externas)
  • Mensaje
  • Plazos
  • Dependencias
  • Responsables (quién lo enviará)
  • Mecanismo (cómo se comunicará)
  • Mensaje y entrega de prueba (si corresponde; haga pruebas para asegurarse de que se envíen las notificaciones)

​
Distribución de notificaciones

Una táctica habitual es publicar notificaciones por lotes para repartir la carga inicial y reducir el alcance de la confusión si surge algún problema imprevisto. Es más fácil corregir problemas con un grupo pequeño que durante un lanzamiento masivo.
  • Un enfoque consiste en comenzar con un lote de notificaciones relativamente pequeño y, si no se detecta ningún problema, aumentar el tamaño de los lotes con el tiempo.
  • También puede enviar lotes de forma escalonada en todo el mundo para repartir la carga que recibe el sistema al mismo tiempo y hacer que las notificaciones lleguen en el momento óptimo dentro de cada zona horaria, lo que aumenta la probabilidad de que se lean.
  • Puede hacer un lanzamiento gradual para una parte de los usuarios, como clientes individuales, regiones o algún otro tipo de agrupación que tenga sentido para su aplicación.

​
Ventanas de indisponibilidad (si es necesario)

Algunas organizaciones exigen una solicitud formal de una ventana de indisponibilidad si un lanzamiento requiere interrupciones o tiempo de inactividad. Si su organización lo requiere, asegúrese de determinar si será necesario tiempo de inactividad para el cambio de producción o el lanzamiento (u otros sistemas dependientes) y presente con antelación las solicitudes de interrupción o de cambio necesarias para cumplir con los plazos establecidos.

​
Plan de cambio de producción (si es necesario)

Algunos lanzamientos implican pasar de una solución anterior a una nueva. Si su proyecto encaja en este escenario, asegúrese de identificar todo lo que debe hacerse, así como cualquier dependencia, la persona o el equipo responsable de cada tarea y los tiempos necesarios. Puede ser conveniente prever suplentes para todos los roles clave o en cada región, por si alguien se enferma inesperadamente o no está disponible por cualquier otro motivo. A continuación, se incluye una lista de verificación de elementos que deben considerarse para el plan de cambio de producción:
  • ¿Ha documentado el plan de cambio de producción y el plan de reversión, en caso de ser necesario?
  • ¿Es necesario hacer copias de seguridad de algo antes del cambio?
  • ¿Se requieren cambios preparatorios en los datos?
  • ¿Hay registros DNS que deban modificarse?
  • ¿Hay cambios en el firewall?
  • ¿Hay nuevos objetivos de monitoreo?
  • ¿Hay software que deba desplegarse?

​
Criterios de continuar / detener

En el plan general de lanzamiento, es útil contar con criterios de continuar/detener y haber analizado de antemano los tipos de problemas que podrían surgir, cuáles podrían resolverse sobre la marcha y cuáles requerirían una reversión. Un plan de lanzamiento puede especificar intervalos de revisión periódicos, con criterios sobre qué evaluar en cada punto de control y cuánto tiempo dejar que un problema siga sin resolverse. Para cada etapa del lanzamiento, conviene definir criterios de éxito que indiquen que el lanzamiento avanza según lo previsto y puede continuar. Algunos criterios de ejemplo podrían ser:
  • El registro de usuarios aumenta con errores mínimos
  • Los inicios de sesión de los usuarios se producen al ritmo esperado, con errores mínimos
  • Los problemas reportados al soporte se mantienen por debajo de un determinado umbral
  • No se identifican problemas que puedan provocar corrupción de datos
También es útil haber identificado criterios que podrían desencadenar una decisión de “detener” para interrumpir el lanzamiento. La tolerancia al riesgo varía según el entorno, pero algunos criterios de ejemplo podrían incluir:
  • Un porcentaje alto de registros o inicios de sesión de usuarios da lugar a errores que no pueden resolverse rápidamente
  • Un número elevado de problemas de soporte que no pueden resolverse rápidamente
  • Se identifica una condición que podría provocar corrupción de datos
  • Se descubre un problema de seguridad de alta gravedad

​
Reversión

Siempre es aconsejable contar con un plan para revertir o deshacer un lanzamiento, por si ocurre algo imprevisto que no pueda resolverse. Revisar el plan de lanzamiento en cada paso que implique un cambio puede ayudar a identificar las tareas o modificaciones necesarias para revertir un lanzamiento o un cambio de producción. El plan de reversión debe incluir los pasos que se deben seguir, la secuencia, cuánto tiempo probablemente llevará cada uno y la parte responsable. Comprender el tiempo total necesario para revertir los cambios puede ayudar a determinar el momento de la decisión final de seguir adelante o no, de modo que se ajuste a cualquier ventana de indisponibilidad requerida. Si se migran o modifican datos para el lanzamiento, el plan debe incluir cómo revertirlos, si fuera necesario. La reversión puede requerir ejecutar scripts para deshacer cambios operativos o restaurar un almacén de datos a partir de una copia de seguridad tomada antes de que comenzara el proceso de lanzamiento. También es necesario planificar el caso en que se introduzcan algunos datos en un sistema nuevo antes de que sea necesario revertirlo. ¿Será necesario abandonar esos datos / transacciones con la reversión, o tendrá alguna forma de capturarlos y aplicarlos en otro lugar para que no se pierdan? Si la resolución de los problemas o el proceso de reversión pudiera tardar más de un turno, conviene asegurarse de contar con una persona principal y quizá otra de respaldo disponibles y preparadas para hacerse cargo durante cada turno de trabajo. Si un problema exige una respuesta prolongada, muy superior a un solo turno, hay límites en cuanto al tiempo que las personas pueden seguir rindiendo de forma realista sin descanso. Puede ser útil contar con recursos preparados para una respuesta a incidentes continua entre zonas horarias, si fuera necesario.

​
Contactos de guardia

A medida que se acerca el día del lanzamiento, conviene identificar a todos los contactos que puedan ser necesarios para solucionar problemas o resolver incidencias, y pedirles que estén de guardia y preparados para ayudar si hace falta. La persona responsable del lanzamiento debe disponer de la información de contacto de cada persona de la lista de guardia para agilizar las comunicaciones. Si hay una “sala de lanzamiento” física o virtual, las personas de guardia deben saber dónde está y estar preparadas para unirse si hace falta. Tener preparada una sala central o una videoconferencia puede agilizar las comunicaciones y la resolución de problemas entre todas las partes si se produce alguna incidencia.

​
Criterios de éxito

Se necesita mucha planificación para que un lanzamiento tenga éxito, pero ¿sabrá cómo evaluarlo? Si define criterios de éxito antes del lanzamiento, podrá determinar qué debe monitorizar y si es necesario implementar monitorización o comprobaciones adicionales para evaluarlo. Por ejemplo, si uno de los elementos de los criterios de éxito es la cantidad de registros o inicios de sesión, ¿tiene alguna forma de monitorizarlo y se ha probado para garantizar que sea precisa? Le convendrá contar con estadísticas para poder destacar el éxito de su lanzamiento. No querrá descubrir después del lanzamiento que no recopiló datos para cuantificar todo el arduo trabajo que su equipo dedicó al lanzamiento.

​
Plan de riesgos y mitigación

No es agradable pensar en las cosas que podrían salir mal, pero si ocurre algo, te alegrarás de haberlo hecho, ya que contar con un plan puede acelerar la respuesta. Algunos ejemplos para los que conviene planificar incluyen:
  • Error de software en la aplicación
  • Incompatibilidad de la aplicación con la configuración del navegador del usuario
  • Fallo o interrupción de la red
  • Ataque DoS
  • Fallo del entorno de alojamiento
  • Problemas de carga o capacidad
  • Problemas de datos o corrupción de datos
  • Vulnerabilidad de seguridad detectada
Si tuviste un período beta, puede ser útil revisar sus resultados para identificar otros posibles escenarios de fallo.

​
Guía de planificación del proyecto

Ofrecemos una guía de planificación en formato PDF que puede descargar y consultar para obtener más información sobre las estrategias que recomendamos. Guía de planificación del proyecto de IAM B2C