La filosofía DevOps, que une el desarrollo con el mantenimiento de software, ya no sorprende a nadie. Está surgiendo una nueva tendencia: DevOps 2.0 o BizDevOps. En él se fusionan tres componentes: el negocio, el desarrollo y el soporte. Y así como en DevOps las prácticas de ingeniería fundamentan la conexión entre desarrollo y soporte, en BizDevOps el análisis asume el papel de 'pegamento' que une el desarrollo con el negocio.
Quiero confesar de inmediato: nos dimos cuenta de que realmente tenemos un BizDevOps, solo ahora, al leer libros inteligentes. Se formó de manera orgánica gracias a la iniciativa de los empleados y su inquebrantable pasión por las mejoras. Ahora, el análisis es una parte del proceso de desarrollo, reduciendo significativamente los ciclos de retroalimentación y proporcionándonos regularmente ideas. Contaré en detalle cómo tenemos todo organizado.
Desventajas del DevOps clásico
Cuando se piensan en nuevos productos para clientes, el negocio crea un modelo ideal de comportamiento del cliente y espera una buena conversión, basándose en esto para establecer sus objetivos y resultados comerciales. La equipo de desarrolladores, por su parte, se esfuerza por crear un código de muy buena calidad. El soporte, sin embargo, espera una completa automatización de procesos, así como facilidad y comodidad en el mantenimiento del nuevo producto.
La realidad suele ser que los clientes enfrentan un proceso bastante complejo, el negocio se topa con una baja conversión, los equipos de desarrollo lanzan correcciones tras correcciones, y el soporte se ahoga en la avalancha de solicitudes de los clientes. ¿Te suena familiar?
La raíz del problema radica en un ciclo de retroalimentación largo y de mala calidad, que está incrustado en el proceso. Los negocios y los desarrolladores, al recopilar requisitos y obtener retroalimentación durante los sprints, se comunican con un número limitado de clientes, que influyen en gran medida en el destino del producto. A menudo, lo que es importante para uno no es representativo de toda la audiencia objetivo.
El entendimiento de si el desarrollo del producto avanza en la dirección correcta llega junto con los informes financieros y los resultados de investigaciones de mercado meses después del lanzamiento. Y debido a la limitación de la muestra, no permite la verificación de hipótesis en un gran volumen de clientes. En general, el resultado es un proceso largo, impreciso e ineficaz.
Instrumento trofeo
Hemos encontrado una buena forma de salir de esto. Una herramienta que antes solo ayudaba a los comercializadores, ahora ha llegado a manos de empresas y desarrolladores. Hemos comenzado a utilizar activamente la analítica web para ver el proceso en tiempo real, entendiendo aquí y ahora qué está sucediendo. Basándonos en esto, planificamos el producto y su lanzamiento a un gran número de clientes.
Si se planea alguna mejora del producto, se puede ver de inmediato con qué métricas está relacionada y cómo estas métricas afectan a las ventas y a características importantes para el negocio. Así se pueden descartar de inmediato las hipótesis de bajo impacto. O, por ejemplo, lanzar una nueva función a un número estadísticamente significativo de usuarios y, en tiempo real, seguir las métricas para entender si todo está funcionando como se había planeado. No esperar la retroalimentación a través de solicitudes o reportes, sino monitorear nosotros mismos y corregir de manera ágil el proceso de creación del producto. Podemos lanzar una nueva función, recoger datos estadísticamente válidos en tres días, hacer cambios en otros tres días, y en una semana tener un nuevo producto excelente.
Se puede rastrear todo el embudo, todos los clientes que han tenido contacto con el nuevo producto, descubrir los puntos donde el embudo se estrechó abruptamente y entender las razones. Tanto los desarrolladores como el negocio siguen esto, es parte del trabajo diario. Ven el mismo recorrido del cliente y juntos pueden generar ideas e hipótesis para mejorar.
Tal integración entre el negocio y el desarrollo, junto con la analítica, permite crear productos de manera continua, optimizando constantemente, buscando y visualizando cuellos de botella, todo el proceso en su conjunto.
Todo se trata de complejidad
Cuando creamos un nuevo producto, no comenzamos desde cero, sino que lo integramos en el ya existente entramado de servicios. Al interactuar con el nuevo producto, el cliente a menudo contacta con varias divisiones. Puede comunicarse con los empleados del centro de contacto, con gerentes en la oficina, puede acudir al soporte o a chats en línea. Con la ayuda de métricas, podemos ver, por ejemplo, qué carga tiene el centro de contacto, cómo es mejor manejar las solicitudes entrantes. Podemos entender cuántas personas llegan a la oficina y sugerir cómo continuar asesorando al cliente.
Con los sistemas de información ocurre exactamente lo mismo. Nuestro banco ha estado en funcionamiento durante más de 20 años, y durante este tiempo se ha creado y sigue funcionando un vasto conjunto de sistemas diversos. La interacción entre los sistemas de backend a veces puede ser impredecible. Por ejemplo, en algún sistema antiguo hay restricciones en un campo específico sobre el número de caracteres, y a veces esto provoca fallos en un nuevo servicio. Rastrear errores con métodos estándar es bastante difícil, pero con la web-analítica es elemental.
Hemos llegado al punto de extraer y analizar los textos de los errores que se muestran al cliente de todos los sistemas involucrados. Resultó que muchos de ellos estaban desactualizados, y ni siquiera podíamos imaginar que de alguna manera participaban en nuestro proceso.
Trabajo con analítica
Nuestra web-analítica y los equipos de desarrollo SCRUM están en el mismo espacio. Interactúan constantemente entre sí. Cuando es necesario, los especialistas ayudan a configurar métricas o exportar datos; en su mayoría, los miembros de los equipos trabajan directamente con el servicio de analítica, que no es complicado.
Se requiere ayuda si, por ejemplo, se necesitan algunas dependencias, filtros adicionales por tipo de clientes o fuentes limitadas. Pero en la arquitectura actual, rara vez nos encontramos con esto.
Es interesante que la implementación de la analítica no requería la instalación de un nuevo sistema de TI. Utilizamos el mismo software con el que previamente trabajaban los especialistas en marketing. Solo fue necesario acordar su uso e integrarlo en los negocios y el desarrollo. Claro, no podíamos simplemente tomar lo que tenía marketing; tuvimos que reconfigurarlo todo desde cero y luego dar acceso a marketing en el nuevo entorno, para que estuvieran con nosotros en el mismo campo informático.
En el futuro, planeamos adquirir una versión mejorada del software para web-analítica, que permitirá manejar el aumento de los volúmenes de sesiones procesadas.
Además, estamos en un proceso activo de integración de la web-analítica con bases de datos internas de CRM y sistemas de contabilidad. Al combinar los datos, obtenemos una visión completa del cliente en todas las dimensiones necesarias: por fuentes, tipos de clientes y productos. Los servicios de BI, que ayudan a visualizar datos, estarán pronto disponibles para todos los departamentos.
¿Qué hemos logrado al final? En efecto, hemos convertido el análisis y la toma de decisiones en parte del proceso de producción, lo que dio un efecto visible.
Análisis: no tropieces con la misma piedra
Y por último, quiero compartir algunos consejos que te ayudarán a evitar cometer errores en el proceso de establecer el BizDevOps.
- Si no puedes hacer el análisis rápidamente, entonces no estás haciendo el análisis correcto. Debes seguir el camino simple de un solo producto, y luego escalar.
- Es imprescindible que tengas un equipo o una persona que comprenda bien la futura arquitectura del análisis. También debes decidir desde el principio cómo escalarás el análisis, integrarlo en otros sistemas y reutilizar datos.
- No generes datos innecesarios. La estadística web, además de información útil, es una gran basura llena de datos de baja calidad y superfluos. Y estos residuos interferirán en la toma de decisiones y en la evaluación si no hay objetivos claros.
- No hagas análisis por hacer análisis. Primero los objetivos, la elección de la herramienta, y solo después, análisis donde realmente tenga un impacto.
Este material ha sido preparado junto con Olga Cebotar ().
Fuente: habr.com
