Saltar al contenido principal

​
Notificaciones / anuncios

Para que un lanzamiento se desarrolle sin contratiempos, conviene que todas las partes interesadas estén al tanto del lanzamiento inminente y comprendan el plan de lanzamiento, así como su función y responsabilidades. Además de notificar a los equipos que participarán activamente, también puede ser útil avisar a los equipos que podrían necesitarse si algo sale mal. Contar con alguien de guardia durante un lanzamiento puede ayudar a agilizar la respuesta. Asegúrese 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, en caso de problemas)
  • Equipos de seguridad (en espera, en caso de problemas)
  • Equipos de marketing (listos para los anuncios y para responder a 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

Tu 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. Los elementos que se deben incluir en el plan son:
  • Audiencia objetivo (considera tanto audiencias internas como externas)
  • Mensaje
  • Plazos
  • Dependencias
  • Responsables (quién lo enviará)
  • Mecanismo (cómo se comunicará)
  • Mensaje de prueba y entrega (si corresponde, haz pruebas para confirmar que las notificaciones se envían)

​
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 a gran escala.
  • Un enfoque consiste en empezar con un lote relativamente pequeño de notificaciones y, si no se detectan problemas, aumentar el tamaño de los lotes con el tiempo.
  • También puede enviar lotes siguiendo una programación escalonada en todo el mundo para distribuir 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 los mensajes.
  • Puede hacer un lanzamiento gradual para una parte de los usuarios, como clientes individuales, regiones u otro tipo de agrupación que tenga sentido para su aplicación.

​
Ventanas de indisponibilidad (si son necesarias)

Algunas organizaciones requieren una solicitud formal para una ventana de indisponibilidad si el lanzamiento exige alguna interrupción del servicio o tiempo de inactividad. Si su organización lo requiere, asegúrese de identificar si será necesario tiempo de inactividad para la transición o el lanzamiento (o para otros sistemas dependientes) y de presentar con antelación las solicitudes de indisponibilidad o de cambio necesarias, de acuerdo con los plazos requeridos.

​
Plan de transición (si es necesario)

Algunos lanzamientos implican pasar de una solución anterior a una nueva. Si su proyecto se ajusta a este escenario, asegúrese de identificar todo lo que debe ocurrir, así como las dependencias, la persona responsable de cada tarea y los tiempos necesarios. También puede ser conveniente prever suplencias para todos los roles importantes o en cada región, por si alguien se enferma de forma inesperada o no está disponible por cualquier otro motivo. A continuación se incluye una lista de verificación de aspectos que conviene considerar para el plan de transición:
  • ¿Ha documentado el plan de transición y, si fuera necesario, el plan de reversión?
  • ¿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 avanzar/no avanzar

En su plan general de lanzamiento, es útil contar con criterios de avanzar/no avanzar 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 periódicos de revisión, con criterios sobre qué evaluar en cada punto de control y cuánto tiempo permitir que un problema permanezca 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 un número mínimo de errores
  • Los inicios de sesión de los usuarios se producen al ritmo esperado, con errores mínimos
  • Los problemas de soporte reportados se mantienen por debajo de un determinado umbral
  • No se identifican problemas que puedan provocar corrupción de datos
También es útil haber definido criterios que podrían activar una decisión de “no avanzar” para detener el lanzamiento. La tolerancia al riesgo varía según el entorno, pero algunos criterios de ejemplo podrían incluir:
  • Un alto porcentaje 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 detecta un problema de seguridad de alta gravedad

​
Reversión

Siempre es recomendable contar con un plan para revertir o deshacer un lanzamiento, por si ocurre algún 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 una transición. El plan de reversión debe incluir los pasos a seguir, la secuencia, cuánto tiempo probablemente llevará cada uno y quién será la parte responsable. Comprender el tiempo total necesario para revertir puede ayudar a determinar el momento de la decisión final de seguir o no seguir, de modo que encaje dentro de 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 la ejecución de 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 datos en un sistema nuevo antes de que haya que revertirlo. ¿Será necesario abandonar esos datos / transacciones con la reversión o tendrán alguna forma de capturarlos y aplicarlos en otro lugar para que no se pierdan? Si la resolución de problemas o el proceso de reversión pueden tardar más de un turno, conviene asegurarse de contar con una persona principal y quizá otra de respaldo, disponibles y preparadas para ocuparse de la situación durante cada turno de trabajo. Si un problema exige una respuesta prolongada, mucho más allá de un solo turno, hay límites en cuanto al tiempo que las personas pueden rendir de forma realista sin descanso. Puede ser útil contar con recursos preparados para una respuesta a incidentes de tipo follow-the-sun, si fuera necesario.

​
Contactos de apoyo

A medida que se acerca el día del lanzamiento, conviene identificar a todas las personas de contacto que podrían necesitarse para solucionar problemas o resolver incidencias y pedirles que estén disponibles y listas para ayudar si hace falta. La persona responsable del lanzamiento debe tener la información de contacto de cada persona de la lista de apoyo para agilizar las comunicaciones. Si hay una “sala de lanzamiento” física o virtual, las personas de apoyo deben saber dónde está y estar listas 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 una incidencia.

​
Criterios de éxito

Planificar un lanzamiento exitoso requiere mucho trabajo, pero ¿sabrá cómo evaluar sus resultados? Si define criterios de éxito antes del lanzamiento, podrá determinar qué debe supervisar y si hace falta implementar supervisión o comprobaciones adicionales para evaluarlo. Por ejemplo, si uno de los elementos de los criterios de éxito es el número de registros o inicios de sesión, ¿dispone de alguna forma de supervisarlo y se ha comprobado 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ó ningún dato para cuantificar todo el arduo trabajo que su equipo invirtió en él.

​
Plan de riesgos y mitigación

No es agradable pensar en las cosas que podrían salir mal, pero, si ocurre algo, agradecerás haberlo hecho, ya que contar con un plan puede acelerar la respuesta. Algunos ejemplos para los que conviene prepararse incluyen:
  • Error en la aplicación de software
  • 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 hubo 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 B2B IAM