Rompiendo cambios: creando grandes cambios.

May 10 2022
Para garantizar el éxito de la nueva versión del producto, debe planificar con anticipación y pensar en cómo la entregará a sus usuarios. Aquí hay algunos consejos que aprendí. Agradecimientos Este artículo solo fue posible gracias al apoyo y las reseñas de mis maravillosos amigos André Cavalcanti y Lucas Schlee.
Emiliano Arano — Ola

Para garantizar el éxito de la nueva versión del producto, debe planificar con anticipación y pensar en cómo la entregará a sus usuarios. Aquí hay algunos consejos que aprendí.

Expresiones de gratitud

Este artículo solo fue posible gracias al apoyo y las reseñas de mis maravillosos amigos André Cavalcanti y Lucas Schlee. Gracias ❤️

He trabajado como desarrollador de pila completa en una plataforma de comercio electrónico empresarial durante casi cuatro años y, como desarrollador de plataforma, debe tener mucho cuidado cuando implementa porque otros confían en su solución para crear sus productos, lo que significa que necesita mantener una API sólida, que puedan integrar mientras la evolucionan para adaptarse a las necesidades comerciales en constante evolución. Ese es el contexto que te hace muy consciente de los cambios y quiero compartir algunos aprendizajes que tuve en el camino.

Los cambios son el corazón del desarrollo de software, estamos: codificando nuevos, revisando los de otra persona o teniendo una reunión para discutir qué/cómo y cuándo. Incluso si piensa en términos de herramientas y procesos, por ejemplo, sistemas de control de versiones, solicitudes de incorporación de cambios, SEMVER, canalizaciones de CI/CD, etc. Están dedicados a hacer factible la entrega de estos cambios a nuestros usuarios finales y para que tengamos algo de sueño de calidad.

Todo eso para evitar romper las expectativas, pero desafortunadamente, a veces tenemos que hacerlo, ya sea porque los requisitos cambiaron, se encontró una mejor solución o nos equivocamos durante la implementación inicial, eso es lo que llamamos romper el cambio y pueden hacer su vida como mantenedor. de dos soluciones miserables. Imagina que tienes que corregir el mismo error dos veces, estar allí y puedo decirte que no es divertido.

Y por API me refiero no solo a los puntos finales REST y firmas de funciones, sino también a toda la experiencia del usuario de su página. Si mueve un botón/formulario de una página a otra, está creando un cambio importante, porque su usuario ya no sabe cómo ubicar esta función, como si fuera un caso de prueba de Cypress y ahora está fallando, por eso tienes que tratar este cambio como tal.

He decidido escribir mi experiencia con los cambios de división en dos artículos, el primero estará enfocado en la parte de desarrollo y el otro en la migración de los usuarios.

La idea no es darte una receta de cómo hacerlo, sino mostrarte algunas herramientas que pueden ser útiles.

Por lo tanto, mi enfoque para implementar y desplegar grandes cambios está realmente conectado con el ciclo de vida del producto en sí mismo, como si estuviera creando un producto completamente nuevo.

Ciclo de vida del producto

Introducción

1. Por qué / Razón de ser

Al igual que un producto nuevo, necesita una buena razón para justificar el tiempo invertido por sus usuarios para adaptarse a esta nueva versión. Imagina que eres un vendedor y tu trabajo es vender una nueva versión de un producto existente a un cliente que ya lo tiene, ¿cuáles serían tus argumentos?

Los seres humanos están programados para resistir el cambio

por lo tanto, si desea obtener cierta adopción de esta nueva versión, debe brindarles a sus usuarios una buena razón para hacerlo, esto es fundamental para las próximas etapas; de lo contrario, estará construyendo una bicicleta para un pez, lo que significa un producto totalmente funcional que no uno querrá usar. Puede ser una característica nueva o mejoras en la velocidad, de cualquier manera, corregir errores tipográficos o actualizar marcos no es lo suficientemente bueno por una razón. Si está creando una plataforma, piense que su usuario es otro desarrollador y que también deberá vendérselo a su PM y EM. Punto de bonificación, si pudiera obtener alguna métrica relacionada con el dinero para respaldar su propuesta, por ejemplo, reducir los costos de alojamiento o mejorar las tasas de conversión, esto hará que su argumento se venda como pan fresco.

2. Planificación de la implementación

Antes de comenzar a desarrollar, piense en cómo planea poner esto en producción. Para mí, la forma ideal es que pueda hacer una implementación progresiva utilizando alguna estrategia como alternar funciones y con una reversión fácil . Quizás, si su cambio es demasiado grande, puede dividirlo en diferentes fases e implementar estas fases progresivamente. Una vez que estaba trabajando en una aplicación que tenía básicamente cuatro páginas diferentes y mi estrategia era implementar una página por vez en lugar de la aplicación migrada completa a la vez, si su página es demasiado compleja, incluso puede dividirla en secciones. Lo importante aquí es hacer pequeñas iteraciones en las que te sientas cómodo implementando cada fase y aun así evolucionar hacia tu objetivo.

3. Observabilidad

el ojo de sauron

Mejore sus herramientas de observación, asegúrese de tenerlas configuradas en la versión anterior y también en la nueva. Por observabilidad, me refiero a registros de errores y métricas que puede usar para evaluar el comportamiento de su entorno en tiempo de ejecución. Si aún no lo tiene, es bueno invertir algo de tiempo en agregarlo a la versión anterior, incluso si tiene la intención de eliminarlo inmediatamente, porque de lo contrario, terminará sin una línea de base para comparar lo que se espera. Y qué no. Los ejemplos podrían ser quizás algunos tiempos de espera que solo ocurren en producción o errores en dispositivos específicos, es posible que ya estén ocurriendo, pero si no lo sabe, lo harán retroceder incluso si no tiene nada que ver con su cambio. Además, es importante tener un tablero que muestre la tasa de adopción de esta nueva solución y, si prometió alguna métrica, es Es mejor hacer un seguimiento de eso también. El Net Promoter Score (NPS) es muy común cuando se piensa en evaluar productos y puede valer la pena hacer un seguimiento para comparar un antes y un después, aunque personalmente prefiero la escala de Likert, ambas son muy buenas para evaluar cambios. Mostrar tu progreso es importante para tus stakeholders como lo es para tu moral, esto te animará en el futuro

Algunas herramientas que he usado antes para este asunto:

  • Logrocket : registros de errores
  • Splunk : registros de errores, alertas y paneles
  • Grafana : métricas, alertas y paneles
  • Honeycomb : métricas, alertas y paneles
  • Google Analytics : métricas, paneles
  • Amplitud : métricas y paneles
Codificando con amor

Algunos estándares/conceptos de la industria que vale la pena conocer en este contexto son:

  • Registro de cambios → Un archivo de descuento que contiene una lista ordenada cronológicamente de cambios notables para cada versión de un proyecto. Véase
  • Versionado Semántico (SEMVER) → Estrategia de versionado de su producto donde cada incremento de versión tendrá un significado específico. Véase
  • Desaprobación → Desalentación del uso de alguna característica. Cuando marca algo como obsoleto , les está diciendo a sus usuarios que esta función no debe usarse y que podría eliminarse en las próximas versiones.
  • No abra demasiadas ramas → Trate de mantener el nuevo código lo más cerca posible del código en la rama maestra, intente separarlo en diferentes carpetas, tal vez incluso un enfoque monorepo. Si abre una rama diferente y sigue trabajando en la versión anterior, con el tiempo las ramas divergirán hasta el punto de que será muy doloroso fusionarlas.
  • Haga pequeñas solicitudes de extracción → A nadie le gusta revisar grandes solicitudes de extracción (+1000 líneas), toman demasiado tiempo y hacen que los errores sean más fáciles de pasar por alto. Fusionar los cambios directamente en la rama maestra también ayudará con esto.
  • Pruebas de caja negra → Para validar la precisión de la nueva versión, puede capturar algunas entradas/resultados del entorno de producción y ejecutarlas en la nueva versión para evaluar sus cambios, haciendo las adaptaciones necesarias en consecuencia.
  • Obsoleto → Marcar características como obsoletas es una buena práctica para preparar a sus usuarios para una versión futura y también le servirá como una lista de TODO mientras desarrolla la nueva especialización.

En este artículo, traté de generar conciencia sobre el desafío de implementar una nueva versión del software existente y algunas estrategias que puede usar para reducir esta carga. Asegúrese de dar a sus usuarios buenas razones para migrar y también una forma de que esta migración se produzca de la mejor manera posible. En el próximo, articularé más sobre cómo obtener algo de tracción y migrar su base de usuarios a esta nueva pieza de software, para que pueda seguir adelante sin ataduras al pasado.

Chao

Algunos artículos interesantes:

https://www.emersonhc.com/change-management/people-hard-wired-resist-change

© Copyright 2021 - 2022 | unogogo.com | All Rights Reserved