Lanzar un producto es la parte más importante del trabajo de cualquier compañía de software. Pero si tienes miedo de hacer un lanzamiento, entonces tal vez estás haciendo algo mal. Te diré cómo suelo organizar el lanzamiento. Este artículo no pretende ser una guía exhaustiva porque todo es individual en la industria del desarrollo de software.
¿Cómo prepararse para el lanzamiento?
Elige una persona responsable
Puedes tomar turnos de servicio, tirar dados o tirar fósforos, de cualquier manera es bueno. Es importante la rotación de personas y la capacitación de aquellos que no saben cómo liberar. Por ejemplo, al tirar dados, puede ingresar las reglas que el que estaba de servicio la última vez tiene derecho a transferir, y si estuvo de servicio dos veces seguidas, automáticamente no está de servicio. El deber no debe tomarse como castigo o reclutamiento, y debe haber personas que puedan asegurarlo.
Calendario personalizado
Establezca una fecha en el calendario corporativo y asegúrese de que todos los interesados estén informados.
Hacer tabla en wiki
Indique la versión de la tabla, la fecha y la persona responsable del lanzamiento. Esto es más necesario para mantener datos históricos. Puede y debe observar de inmediato si el lanzamiento fue exitoso y qué se incluyó exactamente en el lanzamiento.
Notas de lanzamiento
Este es exactamente "lo que se incluyó exactamente en el lanzamiento". En primer lugar, estos datos deben compartirse con los analistas: pueden comparar cualquier cambio en el KPI con lo que se incluye en el lanzamiento. Con base en estos datos, pueden sacar conclusiones sobre qué funcionalidad necesitan los usuarios, qué ideas son buenas y cuáles no, y qué pasará en la próxima iteración.
Anuncio interno
Es importante que otros departamentos sepan cuándo se realizó el lanzamiento, por ejemplo, para hacer publicaciones en los servicios sociales. redes sobre una nueva versión de un producto (crear una guía de información), monitorear KPI (las métricas pueden aumentar o disminuir), etc.
Durante el lanzamiento
Crear lanzamiento de brunch
El código que se publicará no debe modificarse, excepto para corregir errores críticos. Y en el caso ideal, cualquier solución debe pasar por una solicitud de grupo. Además, todas las pruebas deben ser verdes.
Enviar notificación
Debe notificar a todos por correo o en el messenger que se ha creado un brunch de lanzamiento y que se están preparando para el lanzamiento.
Hacer etiqueta
Asegúrese de hacer una etiqueta cuando finalice el lanzamiento y apriete las correcciones en la rama de desarrollo.
Hacer la liberación en sí
Idealmente, debe tener mecanismos que controlen la liberación: por ejemplo, liberar solo el 10% de los usuarios o solo los no pagadores. Esto es necesario para eso. para reducir el daño de los errores que ocurrieron durante el proceso de desarrollo y que no se encontraron durante las pruebas.
Liberación de un botón
Mítico Por supuesto, cuanto menos factor humano participe en el lanzamiento, mejor. Pero esto es normal, si no todo se puede automatizar.
Si todo salió mal según lo planeado
Por supuesto, en caso de cualquier error, no se pueden culpar entre sí, pero deben resolver el problema juntos y elaborar un plan para prevenir tales incidentes en el futuro.
Después del lanzamiento
Para monitorear
No olvide monitorear los errores, la carga del servidor. También vale la pena prestar atención al KPI: si realizó un lanzamiento y su DAU se cayó, entonces tal vez algo no funciona tan bien como debería, o las herramientas de monitoreo en sí están rotas. Vale la pena comprobar cualquier actividad sospechosa.
Informe de éxito y fracaso
Es mucho mejor si aprenden sobre el problema de los desarrolladores, no de los usuarios. Y, por supuesto, si ha resuelto algún problema, puede jactarse de ello con seguridad.
Retrospectiva
Esto, por supuesto, depende en parte de la metodología de desarrollo, pero si algo salió mal durante el proceso de lanzamiento, vale la pena discutirlo. Si algo estuvo bien, entonces también vale la pena discutirlo. Idealmente, en el tablero para cada punto de falla debería ser un punto de éxito o gratitud para un colega. Esto ayudará a no convertir una retrospectiva en molesta y negativa.
Pide pizza y celebra
Durante tales reuniones, solo los colegas se convierten en amigos y camaradas. Y esto significa que en la próxima batalla, los amigos no te decepcionarán.
Comience a prepararse para el próximo lanzamiento
Realmente me gusta la idea del tren de lanzamiento, cuando cada lanzamiento se lleva a cabo regularmente en fechas claramente definidas. Gracias a esto, el equipo depura el mecanismo de liberación. Como escribí anteriormente, no es necesario lanzarlo al 100% de los usuarios: se puede implementar a un pequeño grupo de personas.
¿Cómo se lanzan otras compañías?
Spotify
Spotify se lanzará a menudo en función de la práctica del tren Release. Como el nombre de esta práctica sugiere, el lanzamiento es muy similar a un tren: aquellos que no han tenido tiempo de terminar su trabajo están esperando el próximo lanzamiento. Las ventajas de este enfoque son que un equipo fallido no retrasa la entrega del producto y no trata de impulsar tareas inacabadas. Y como resultado, los devops no tienen sus teléfonos rotos por la noche, y el equipo de guardia no aparece en el trabajo con bolsas debajo de los ojos por la mañana. Por supuesto, este enfoque no funcionará para una empresa de outsourcing: el cliente no pagará por el trabajo inacabado. Francamente: Me gusta la cultura de la empresa, le aconsejo que vea un video (https://labs.spotify.com/2014/03/27/spotify-engineering-culture-part-1/) sobre cómo funciona.
Reserva
Estos chicos también son muy geniales. Sus lanzamientos se basan en pruebas A / B. Supongamos que hay una versión estable actual - versión A, y hay una versión que el desarrollador acaba de terminar - versión B. Si KPI es mejor en la versión B, entonces vale la pena aumentar el porcentaje de usuarios para esta versión. Si la versión B es peor, entonces hay dos opciones: la versión B simplemente no es estable o es una característica que nadie necesita. Este enfoque es adecuado para una empresa que se ocupa de su producto en funcionamiento, pero lo más probable es que no haga una revolución. Si está interesado en aprender más sobre la fabricación ajustada, lea el libro Lean Startup (http://theleanstartup.com/).