Cómo superamos la incertidumbre en Delivery Club

Amigos, hola a todos! Mi nombre es Kolya Arkhipov, soy responsable de Investigación y Desarrollo en Delivery Club.



Nuestro equipo resuelve tareas intensivas en ciencia dentro de la plataforma FoodTech: desarrollamos componentes basados ​​en algoritmos y datos, de los cuales hay muchos en la plataforma DC. En el proceso de resolución, nos enfrentamos a muchas incertidumbres tanto del lado empresarial como del desarrollo.



El material resultó ser voluminoso y, espero, útil para usted. Por lo tanto, recomiendo poner en una tetera y preparar un delicioso café, lo hice yo mismo mientras trabajaba en este artículo.



Hoy os contaré la carrera que ha pasado nuestro equipo durante el pasado año. La analogía surgió por sí sola: trabajamos en una empresa muy dinámica, el líder del mercado FoodTech en Rusia. Estamos desarrollando rápidamente diferentes áreas de negocio, ¡y realmente nos impulsa! No solo llegamos a la línea de meta con éxito, sino que también obtuvimos muchas ideas durante la carrera. Esto es lo que quiero compartir contigo.

El artículo apareció después del informe en la conferencia RIT ++ 2020 . Para aquellos que aman los videos, búsquenlo al final del artículo.

¿La tetera ya está hirviendo? ¡Súper! Entonces, lo que se discutirá hoy:

1. I + D e incertidumbre. Lo que enfrentamos.
2. Experimentos. Cómo y por qué los llevamos a cabo en batalla.
3. Mensurabilidad. Analicemos la elección de métricas y trabajemos con riesgos.
4. Autonomía. Cómo en DC Tech adaptamos el marco GIST y el enfoque de la fuente interna.

Luz verde, embrague, primero, vamos.

I + D e incertidumbre

En algunas empresas, el equipo de I + D se dedica a la investigación fundamental de nuevas tecnologías. El propósito de dicha investigación puede ser tanto el desarrollo de procesos actuales como verticales completamente nuevos en los negocios. Por ejemplo, blockchain era una tecnología de este tipo hace unos años.



Inmediatamente, estamos hablando de otra cosa. La I + D en Delivery Club se trata de resolver problemas aplicados. Nuestro negocio está creciendo rápidamente, la cantidad de pedidos está creciendo y la mayoría de nuestros procesos internos se basan en datos y algoritmos. Con un aumento en la cantidad de datos de entrada, algunos algoritmos dejan de ser efectivos, y aquellos componentes que ayer nos convenían completamente, hoy a menudo los encontramos inoperantes.



Como habrás adivinado, estos problemas suelen ser débilmente deterministas y, como resultado, están acompañados de muchas incertidumbres de todos lados. Resaltemos las claves:





Echemos un vistazo más de cerca a lo que nos enfrentamos y si realmente son dificultades.



Cómo lograr el objetivo



Siempre entendemos claramente el objetivo comercial: en qué dirección planeamos movernos, hacia dónde debemos ir. Pero está lejos de ser siempre claro cómo abordar este objetivo cuando se trata de tareas de investigación. ¿Qué estrategia adoptar: mediante experimentos o una gran implementación de la función de inmediato? ¿Construir entornos con simulación o experimentar en combate? La elección es grande: los ojos se elevan.



¿Qué vale la pena hacer exactamente?



De acuerdo, entendemos el objetivo comercial y acordamos qué estrategia seguiremos. Es hora de decidir sobre un conjunto específico de características que llevaremos a cabo. Cómo elegirlos, qué incluir en la cartera de pedidos, en qué secuencia: debe determinar no solo "qué es exactamente lo que vale la pena hacer", sino también quién tendrá la máxima experiencia en nuestra área.



Cuándo podemos alcanzar nuestra meta Sin



duda, el tiempo es muy importante para los negocios. La investigación es interesante y entretenida, puede buscar nuevas funciones en los datos, algoritmos de investigación, leer notas interesantes de nuestros colegas en otros países. Pero es importante que las empresas comprendan cuándo se logrará el objetivo, porque una función lanzada en el momento equivocado a menudo simplemente no es necesaria: el mercado de FoodTech es muy dinámico ahora.



¿Por qué alguien necesita mi código?



La incertidumbre final, aunque lejos de ser significativa, es una cuestión de motivación para los desarrolladores. La I + D es en gran medida un desarrollo experimental, como resultado, nuestro código no siempre se arraiga en la producción. Al principio, estábamos muy molestos porque no entendíamos por qué hicimos la función, y con todo nuestro corazón, y la empresa decide que no funciona y debe ser cortada. Preguntas: ¿por qué estoy haciendo esto? ¿Por qué alguien necesitaría mi código? - apareció con nosotros con bastante frecuencia. En el proceso, nos dimos cuenta de cómo podemos y debemos trabajar con esto, y ahora estamos seguros de que esta es una de las incertidumbres más críticas que debe superarse en primer lugar.



Y así, habiendo llenado un montón de baches tan decentes, reunimos todos nuestros problemas en un solo lugar y nos dimos cuenta de que para la felicidad nos faltan tres procesos en la intersección de estas incertidumbres.

1. , , .
2. . , , . , - , , .
3. , , - . . IT- ( ), , , , 2-3 . — , .

Esquemáticamente en la imagen de abajo.



Los experimentos responderán a las preguntas de cómo alcanzar las metas y qué hacer exactamente. Las métricas permitirán responder de manera muy clara y transparente a la pregunta de si este código realmente debería permanecer en producción. La plena autonomía ayudará a evaluar y cumplir los plazos.



No paramos. Embrague, segunda marcha, estamos ganando impulso rápidamente.

Experimentos

Considere una plataforma de asignación automática de mensajería personalizada. Tiene una tarea bastante sencilla: reunir a tres participantes del mercado: nuestros socios, los encargados de la logística (es decir, sus mensajeros) y los clientes, para que todos los participantes estén satisfechos. Es decir, cuando llega un pedido, debemos elegir un mensajero que vendrá al restaurante exactamente en el momento en que el restaurante termine de preparar el plato, lo recoja rápidamente y lo entregue al cliente caliente y sabroso a la hora prometida.



Parece bastante sencillo, y aquí se podría decir: ¡suficiente teoría! Es hora de pasar a lanzamientos reales.



Estoy de acuerdo con usted, pero aún así, detengámonos un poco en el proceso de los experimentos. Veamos el panorama completo.

1. - — . — , , .
2. — . . — , .
3. — Just In Time. , : , , . , , , . , FoodTech- : , . , .

Echemos un vistazo más de cerca a qué proceso se encuentra bajo el capó del incremento de producto.







3.1 Hipótesis. Puede formularse en palabras o mostrarse esquemáticamente. Lo principal es justificar claramente por qué debería funcionar. Es decir, el experimento debe tener formación teórica.



3.14 Desarrollo. No me detendré aquí, en este artículo se describen más detalles sobre nuestro desarrollo . Usamos Scrum, iteraciones de dos semanas con todas las actividades requeridas.



3.2 Preparación. A continuación, debe preparar un experimento. Es decir, debemos decidir con qué segmento geográfico o audiencia queremos comunicarnos durante este experimento. Y también seleccionar el segmento con el que compararemos los resultados.



3.3 Experimento. A continuación, comenzamos el experimento en sí. Un punto importante: incluso antes del comienzo, acordamos las métricas comerciales que monitorearemos. Dejemos hoy la discusión de métricas técnicas, las cuales nos dicen que el experimento está lanzado y técnicamente estable, hablaremos más de indicadores comerciales. Definitivamente arreglaremos las banderas rojas: estos son algunos valores de umbral que no debemos cruzar durante nuestro experimento.



3.4 Análisis. Hemos acumulado una gran cantidad de datos interesantes y únicos que solo nosotros tenemos. Sería extraño no extraer información útil de ellos, es decir, sacar conclusiones razonables sobre la validez de la hipótesis que se está probando, así como enfatizar cosas nuevas sobre la audiencia de nuestro servicio.



3.5 Conclusión.Probablemente el punto más importante de este proceso. En nuestro caso, la salida siempre está presionando tres botones:

• extender el experimento aún más, a la siguiente geografía o al siguiente segmento de la audiencia;
• retroceder si algo salió mal;
• Seguir. Hay casos en los que vemos la influencia de factores de terceros, que no tomamos en cuenta, y como resultado, no podemos sacar una conclusión inequívoca. En estos casos, decidimos continuar.

Experimento real

Finalmente es hora de ver cómo funciona esto con un ejemplo del mundo real. ¿Estás cansado todavía? Empieza la diversión.



Volver a la plataforma de asignación automática. Antes de eso, sugerimos que el enfoque Just In Time sería muy bueno para nosotros para reducir el tiempo de entrega. Lo compararemos con la estrategia de asignación actual, que denotamos como un algoritmo codicioso.



Primero, justifiquemos la hipótesis.

Algoritmo codicioso

Su característica clave es prescribir de inmediato. Tan pronto como el pedido llega a la plataforma, buscamos el mensajero de nuestro socio más adecuado para este pedido, designamos sin demora e informamos al mensajero sobre este pedido. Como resultado, optimizaremos el tiempo dedicado a buscar un mensajero. Pero este enfoque no siempre es efectivo, porque en un minuto la situación puede cambiar: llega un nuevo pedido o se libera otro mensajero. El algoritmo ya no reacciona a esto. A continuación se muestra una ilustración.





En este ejemplo, tenemos un total de 45 minutos para elegir dos pedidos. Parece que podemos hacerlo mejor.

Justo a tiempo

La tarea de este algoritmo es elegir exactamente el mensajero que llegará al restaurante exactamente en el momento en que el pedido esté listo. ¿Qué nos dará? En última instancia, reducirá el tiempo de entrega debido a que:

• el mensajero pasará menos tiempo en el restaurante;
• Elegiremos el mensajero de manera más óptima.

Técnicamente, esto es bastante fácil de implementar. Cuando se recibe un pedido, elegimos un mensajero de inmediato, pero no le informamos sobre el pedido, por lo que hacemos una "cita virtual" y nos da tiempo para cambiar nuestra elección. Y finalmente decidiremos (si transferir el pedido al mensajero) solo cuando el camino al restaurante sea igual al tiempo restante para preparar el pedido. Esquemáticamente, en la siguiente ilustración.







Como resultado, seleccionamos pedidos en solo 30 minutos, que es un tercio menos que en el caso anterior.



En mi opinión, la hipótesis está justificada, la estamos llevando a cabo. Según lo acordado, no consideraremos el proceso de desarrollo en detalle.

Pasemos a preparar el experimento.

¿Qué hay que preparar en nuestro caso? No tanto: el período de la prueba A / B, la geografía del experimento y la que compararemos. Nos detuvimos en una ciudad determinada, seleccionamos las condiciones para minimizar el impacto de una estrategia de cita en la segunda.



Definitivamente negociaremos con la empresa sobre las señales de alerta y las reacciones a ellas. Las banderas rojas son umbrales de métricas comerciales que no queremos cruzar durante el experimento. Si se cruza, entonces en la abrumadora cantidad de experimentos esto es retroceso. Pero hay excepciones cuando sabemos con certeza que la intersección no ocurrió por nuestra culpa, sino que fue el resultado de otros factores. En este caso, a veces podemos decidir continuar con el experimento.



¿Qué más hay que preparar? De acuerdo con nuestros compañeros de la sala de control, quienes observan en tiempo real que todo va bien con los pedidos. Para ellos, nuestro cambio será visible, porque antes asignábamos un pedido para el mensajero de inmediato, pero ahora no hacemos esto, nos damos un tiempo para cambiar de opinión. Es por eso que se debe advertir a los colegas sobre los experimentos planeados.



Bien, sigamos adelante. Se preparó un experimento, se lo llevó a cabo y se obtuvieron los resultados. Y aquí viene la parte divertida: el análisis.

Análisis de experimentos

Acordamos mejorar el tiempo total de entrega y de repente hubo cuatro horarios. Vale la pena explicarlo aquí. Al lanzar un experimento, es importante observar no una métrica clave, sino varios indicadores comerciales que son críticos para el negocio; en este caso, podemos reducir significativamente los riesgos de una hipótesis fallida que influya en los procesos reales en la plataforma. Seamos honestos, cometimos tales errores al comienzo de nuestros experimentos y, a veces, tuvieron consecuencias realmente desagradables. Pero los errores son buenos, aprendemos de ellos.



Echemos un vistazo a los resultados. Mostraremos las gráficas sin valores específicos, porque el propósito del artículo no es un análisis detallado de la eficiencia del algoritmo Just In Time. Queremos centrarnos más en nuestro enfoque al realizar experimentos. Por la misma razón, no nos detendremos en la teoría de realizar pruebas A / B y determinar la significancia estadística de los resultados, este es un tema enorme para la próxima publicación, y quizás incluso para todo el ciclo.

• « ». , , . , . , — , . , . , , . , . , , (/), — , , . -, .
• « ». . , , , . , . , .
• « » « ». : . .

Como resultado, tenemos una disminución en la métrica clave (1), una disminución en una métrica muy importante (2), valores estables de las otras dos métricas clave (3, 4), las banderas rojas no se encienden. Esto nos permite concluir sobre el éxito del experimento y la validez de la hipótesis que se está probando.



¡Clase! ¿Pasaste a la siguiente hipótesis? ¡Es fantásticamente entretenido y diseñado para mejorar la vida de todos! Pero no, eso no es todo. Queda, quizás, uno de los pasos más importantes, que no debemos olvidar. Esto es para presionar uno de los tres botones:

1. Desenrollar
2. Retroceder
3. Seguir

En el proceso de experimentos, el equipo debe tener un colega cuya función sea ser responsable por completo de la función, que presionará uno de estos tres botones. Al principio, tuvimos casos en los que nos olvidamos de este paso, como resultado, recibimos varias docenas de experimentos lanzados simultáneamente sin un estado comprensible para cada uno de ellos. Dieron resultados positivos, pero no se implementaron por completo, lo que es ineficaz para los negocios. Además, tuvimos que gastar importantes recursos solo para recordar los detalles y poner las cosas en orden. Pero, nuevamente, aprendemos de los errores.

Experimentos del mundo real

Detengámonos brevemente en por qué experimentamos inmediatamente en la batalla. Este enfoque generalmente se opone a los entornos de simulación analítica, que, basados ​​en datos históricos, pueden, con cierta precisión, responder qué “sería” si implementamos tal característica.



¿Por qué elegimos el primer enfoque por nosotros mismos? Dos razones.

• -, .
  
  , , . , - , , . — .
  
  
  
  . .
  
  
  
  ? , , , — . , , , , , . , .
  
  
  
  Vale la pena ser honesto aquí en que este es un enfoque bastante arriesgado. El riesgo de decepcionar a la audiencia, clientes, empresas. Este artículo está dedicado principalmente a cómo reducir dichos riesgos: seleccione con cuidado y precisión métricas (varias) y monitoree en tiempo real. En caso de que algo salga mal, simplemente apagamos el experimento de inmediato.

• El segundo es, por supuesto, la velocidad. Los experimentos en condiciones de combate mostrarán resultados de manera mucho más precisa y rápida.

Antes de seguir adelante, arreglemos algunas pequeñas victorias.





Un proceso de experimentación transparente nos da la respuesta a la pregunta de cómo lograr un objetivo. Y al realizar pruebas inmediatamente en condiciones reales, comenzamos a comprender mejor a nuestra audiencia. Como resultado, el equipo de desarrollo tiene la experiencia suficiente para proponer características específicas que resuelven un problema comercial.



No está mal, pero eso no es todo. Ahora es el momento de hablar más sobre mensurabilidad. Y mientras tanto encendemos el tercero, gas al suelo, el viento silba.

Mensurabilidad

¿Por qué necesitamos métricas? Principalmente para confirmar una hipótesis o reducir el impacto de una suposición fallida. Las hipótesis, incluso fundamentadas en teoría, no siempre disparan. Y cuando disparan, a veces en la rodilla.

• -, FoodTech, : , , , .
• -, , , . , , , . ! , , , . , , -.

Nuestra experiencia demuestra que una buena receta es cuando hay varias métricas. Una métrica objetivo: mejorarla; y algunas claves más, no debemos dejarlas caer.



Introduzca un espacio de supervisión unificado en el que miran tanto las empresas como el desarrollo. No tiene que ser una herramienta, usamos dos: Metabase y Grafana, pero en el futuro planeamos elegir una de ellas. Lo más importante es que debe haber un único espacio donde mirarán los colegas de negocios y desarrollo. Y asegúrese de identificar las señales de alerta.

banderas rojas

Sí, estos son algunos valores de umbral de métricas que no debemos cruzar durante el experimento. Vale la pena ponerse de acuerdo con la empresa sobre las reacciones, si se han cruzado, y publicar alertas sobre ellas.



Y una pequeña victoria más: respondimos a la pregunta "¿Por qué alguien necesita mi código?". ¡No nos olvidemos de ella!





Permítanme recordarles que esta incertidumbre por parte del desarrollo es que no siempre entendimos por qué nuestro código no permanecía en producción y, francamente, estábamos tristes por esto. Al adoptar un enfoque de inmersión de igual a igual desde el desarrollo hasta las métricas comerciales, no solo mejoramos nuestra comprensión de las soluciones del cliente, sino que también nos dimos una dosis de impulso para resolver problemas comerciales al enfocarnos en el resultado final.



Bien, descubrimos experimentos y procesos transparentes, métricas y mensurabilidad. Delante está la línea de meta, giramos en la cuarta, y a máxima velocidad hasta la victoria.

Autonomía

Todo lo anterior funciona de la mejor manera posible solo cuando nos volvemos autónomos tanto del lado comercial como del desarrollo.

ESENCIA

Aquí, por autonomía, entendemos la mínima dependencia a la hora de tomar una decisión. ¿Qué hemos hecho en el lado comercial para tomar decisiones rápidamente y no ahogarnos en procesos de aprobación? Hemos implementado el marco GIST.





Este enfoque es Metas, Ideas, Proyectos escalonados, Tareas. La empresa tiene objetivos comerciales claros que la gerencia comunica de manera transparente a todos los empleados. Para lograr estos objetivos, los empleados arrojan ideas. Puede haber una docena o una idea. Es importante que una idea aún no sea un proyecto. Estos son algunos de los enfoques que me gustaría implementar. Step-project: estos ya son proyectos: características bastante grandes que implementan estas ideas. En nuestro ejemplo Just In Time, el destino es exactamente el proyecto Step. En el último nivel están las tareas a las que estamos acostumbrados, este ya es un proyecto Step descompuesto, estimado en costos laborales.



Entonces, ¿cómo le ayuda el enfoque a lograr la autonomía? Cuando proponemos hacer esta función (Just In Time), la empresa ve de forma transparente:

1. El tamaño y el costo de implementar la función.
2. ¿Qué idea está implementando?
3. Cuál es el objetivo específico de la empresa (impacto).

Entonces solo necesitamos compararlo con el proyecto Step vecino de acuerdo con los mismos criterios: costo, impacto. Celebramos una reunión (son habituales con nosotros), discutimos, priorizamos y tomamos una decisión.



Parece muy simple y directo. En nuestro caso, lo es, y funciona: la empresa toma decisiones rápidamente, estamos contentos. Pero este es solo el primer paso hacia la autonomía, porque desde el lado del desarrollo tampoco deberíamos estar bloqueados.

Fuente interna

Es como código abierto, solo dentro de la empresa. La arquitectura del Delivery Club son microservicios, ahora hay más de un centenar de ellos. A menudo, para realizar una característica, es necesario modificar no solo los componentes de los que nuestro equipo es responsable, sino también los servicios vecinos. Y aquí tenemos dos formas:

1. Ponga mejoras en el backlog de otros equipos, acuerde que los chicos las harán.
2. Hazlo tu mismo.

En nuestra adaptación, el proceso funciona de la siguiente manera. Hay una gran función Just In Time que afecta a tres grupos de servicios:

• una plataforma de autoasignación de la que I + D es responsable,
• plataforma logística,
• componentes de interacción con socios (restaurantes y tiendas).

Nosotros hacemos esto:

1. recopilar todas las tareas en la cartera de pedidos del equipo de I + D;
2. priorizamos y distribuimos dentro del equipo cuál de los muchachos perfeccionará cuál de los componentes;
3. coincidimos con los líderes técnicos de los equipos de logística y áreas de socios sobre los matices de implementación;
4. nos desarrollamos, los colegas realizamos una revisión;
5. luego nos probamos a nosotros mismos;
6. Ya estamos dando a los propietarios de servicios para que entren en producción.

Después de entrar en producción, estas mejoras quedan en el área de responsabilidad de los equipos propietarios de estos servicios.



Para ser absolutamente honesto, el enfoque no es perfecto y tiene riesgos. El principal es el tiempo. La mayoría de las veces modificamos los componentes entre 2 y 2,5 veces más de lo que hubieran hecho los propietarios del servicio.



Pero el beneficio también es obvio, supera con creces el pequeño retraso en la implementación: es previsibilidad. Es importante señalar aquí que otros equipos tienen su propio trabajo atrasado, sus propias prioridades y, en la mayoría de los casos, no pueden tomar nuestras tareas "urgentemente". Por lo tanto, nuestro plazo para negocios es realista, no se verá afectado por posibles cambios de prioridades en otros equipos.



Entonces, felicitaciones - ¡final, victoria!





Hemos implementado el marco GIST para una toma de decisiones rápida y transparente, y el enfoque de fuente interna para la autonomía en el desarrollo, y ahora todas las piezas del rompecabezas están ensambladas. Es hora de terminar, fue una carrera interesante, ¡gracias por tu participación! Resumamos.

conclusiones

• Un experimento es una herramienta transparente y eficaz para lograr un objetivo.
• Llevándolo a cabo en un entorno real, estudiamos a nuestra audiencia, lo que nos permite hacer cambios cada vez más útiles, así como entender por qué no todas las funcionalidades deben permanecer en producción.
• Pero para evitar el caos, se necesita un proceso claro, la distribución de roles y el nombramiento de una persona responsable.
• En la fase activa del experimento y durante el análisis, vale la pena monitorear varias métricas clave a la vez y no olvide sacar una conclusión (en nuestro caso, presione uno de los tres botones).
• Tomar decisiones rápidas y autonomía en el desarrollo ayuda a lograr resultados y a mantener motivado al equipo.

Grabación en video del informe de la conferencia RIT ++ 2020 .





Eso es todo, gracias por estar conmigo en esta carrera. Estoy seguro de que estamos en el principio y que aún quedan grandes desafíos por delante. Con mucho gusto los compartiré, ¡hasta pronto!