¡Hola, Habr! Como prometí en la publicación anterior , continúo presentándote a Delivery Club Tech. Hoy hablaremos de transformación de productos.
Casualmente, mi llegada a DC en octubre de 2018 estuvo marcada por una reestructuración total de todos los procesos en el equipo. En ese momento, el departamento de TI, y de hecho toda la empresa, se enfrentaron a nuevos desafíos. Estaba claro que los procesos antiguos no cumplían con los nuevos requisitos. Se referían principalmente a la disminución del tiempo de comercialización.
Se trata de estos cambios, nuevos desafíos, una nueva estructura de equipo, cómo trabajamos sin gerentes de proyectos y analistas técnicos, y los enfoques para el desarrollo de productos que quiero contarles hoy.
En octubre de 2018, asumí el cargo de Jefe de Consumo. Este fue el comienzo de mi viaje hacia Delivery Club. Era necesario armar equipos de producto dentro de la dirección, describir los procesos, formalizarlos y escalarlos a todas las demás áreas. Además, la tarea consistía en derivar métricas de desempeño para los equipos y desarrollar un marco de contratación desde cero.
Características del equipo
El desafío más importante fue lograr la previsibilidad y la transparencia del proceso de desarrollo. La situación se complicó por el hecho de que no había métricas de desempeño en ese momento. Pero lo que era seguro: los lanzamientos no ocurrían periódicamente, y su composición estaba clara solo en el momento del lanzamiento en sí.
Otro problema fue que los equipos no se formaron alrededor del producto. Esta complicada comunicación con el negocio, dado que un mismo desarrollador podía participar en proyectos completamente diferentes, no había un enfoque claro en una tarea específica. Por lo tanto, en un principio se decidió reconstruir la estructura del departamento de TI y pasar de los equipos de plataforma a los equipos de producto.
Con el enfoque de plataforma, las personas del backend se sentaban por separado, los front-end se sentaban por separado y cada equipo tenía un líder de equipo que distribuía las tareas. Los defectos obvios de esta estructura: los desarrolladores no estaban inmersos en el proceso y el producto, no estaban interesados en el objetivo común, los equipos tenían un enfoque diferente y tampoco había recursos dedicados para el producto. Como resultado, el desarrollador estaba desenfocado, los objetivos seguían siendo inalcanzables. Incluso si por algún milagro fue posible lograr el objetivo, debido a la falta de comunicación entre los gerentes de producto y las partes interesadas, a menudo resultó no ser lo que se planeó originalmente.
Lo primero que se decidió hacer: un equipo, un producto. Se asignan recursos, es decir, el equipo realiza tareas solo para este producto y no para otro. Los equipos que trabajan en productos similares forman la dirección del desarrollo. La primera transformación resultó en 4 direcciones:
- Consumidor
- Logística
- Vendedor
- Interno
Lo segundo que se decidió hacer: asignar un product manager a cada equipo. También es uno más del equipo. El gerente de producto desarrolla una estrategia para cambios en el producto, forma métricas de producto en las que se enfoca el equipo y establece las metas para el sprint.
Como resultado, obtuvimos la siguiente celda: "Product Manager - Team Lead - Dev - QA". Incluimos desarrolladores de backend y front-end como desarrolladores, pero también hay equipos sin frentes. Los frontenders son Web Angular y JS, o iOS / Android.
Ahora cada equipo tiene un promedio de 5 ± dos personas. ¿Porqué es eso? No llegamos a esta fórmula de inmediato. Nuestras estadísticas muestran que esta es la composición del equipo que le permite lograr el resultado más predecible. Es decir, el equipo puede incorporar suficientes funciones para realizar cambios significativos en el producto, pero al mismo tiempo, la complejidad de la planificación sigue siendo menor de lo que sería con más personas. Es decir, el error de planificación se vuelve mínimo.
Durante un tiempo experimentamos con roles dentro del equipo, teníamos líderes de equipo de desarrollo móvil (iOS / Android) y un líder de equipo de backend. Pero terminamos con una estructura matricial:
- Un líder de equipo (por regla general, alguien del backend), tiene gerentes de control de calidad, backend y frontend directamente bajo su supervisión.
- product- « — — QA».
- — . . , QA- , CI/CD, QA- .
- - , .
- .
Otra característica nuestra: no tenemos jefes de proyecto ni analistas técnicos. Este fue originalmente el caso en Delivery Club, y decidimos que no lo cambiaríamos. ¿Recuerda que tuvimos un problema con los equipos que se enfocaban en el producto? Entonces, ¿por qué crear intermediarios entre el equipo y el gerente de producto? Para nosotros es importante que los equipos, en primer lugar, se preocupen por cómo sus funciones afectan al usuario final, y no solo por cerrar tickets en Jira. Para hacer esto, las personas necesitan sumergirse en el contexto, el dominio, el negocio e incluso las métricas de productos y las métricas financieras.
Como resultado, el diálogo entre el equipo de desarrollo y el gerente de producto continúa. Los desarrolladores no solo toman una lista de tareas del gerente de producto y se van a desarrollar todo esto, sino que pueden acudir a él en un par de horas y decirle, por ejemplo, "Oye, podemos hacer el botón aquí un poco más simple, pero una semana más rápido", muéstralo en los números y el gerente de producto dirá OK.
Así, el equipo técnico realiza la tarea de análisis técnico, evaluación y descomposición de forma independiente, y luego planifica un sprint con el product manager. Para que esto funcione, comenzamos el sprint, por así decirlo, una semana antes de que comience. Esta es la siguiente sección.
Desarrollo y planificación de Sprint
Pre planeado
Una semana antes del inicio del sprint, el gerente de producto trae los casos y el diseño, responde a la pregunta "¿Qué se debe hacer?" El equipo técnico decide cómo lo hará y cuándo estará listo.
Para hacer esto, el equipo tiene una semana, durante la cual el líder del equipo, los desarrolladores y el control de calidad se reúnen, discuten los detalles técnicos, llevan a cabo la descomposición y reinician planificando el póquer para su evaluación. Durante este período, QA hace una lista de casos de prueba, que luego se probarán.
Planificación
Una vez que el equipo ha realizado la descomposición y la evaluación, comienza la planificación. Todas las tareas se dividen en 8 horas. Para contar la cantidad de tareas en un sprint, multiplicamos la cantidad de empleados por 80 horas de una iteración de dos semanas, y el resultado se multiplica por un factor de enfoque de 0.8.
Otras tareas se superan en cubos, solo hay tres de ellas:
- Producto 60%
- Deuda tecnológica 20%
- Soporte 20%.
Dejame darte un ejemplo. Contamos con un equipo de 3 backenders. Esto es 80 * 3 * 0.8 = 192 horas útiles. Dedicaremos 116 horas (60%) al desarrollo de productos, 38 horas a la deuda tecnológica (20%) y 38 horas al soporte técnico (20%).
Aseo
El lunes programamos tareas, y en medio del sprint, es decir, una semana después, se realiza el aseo. La preparación es el análisis de los resultados de la primera semana y la decisión de si tenemos tiempo para alcanzar la meta del sprint o si algo se debe cortar. Si se logra el objetivo, el gerente de producto presenta planes para el próximo sprint en la misma reunión y se repite todo el ciclo.
Manifestación
La conclusión lógica del sprint es la demostración, donde invitamos a todos los equipos de desarrollo, partes interesadas, colegas de negocios e incluso al director del Delivery Club.
Los compañeros responsables del lanzamiento preparan presentaciones, conversan sobre los logros del sprint y las dificultades que se han superado. Compartimos una historia de producto e información sobre cómo las nuevas funciones beneficiarán al usuario.
¡Este es un día importante para todo el equipo!
Retro
Para nosotros, lo retro es una forma de mejorar la eficiencia. En primer lugar, analizamos las métricas del desempeño del equipo, qué tan exitosamente cerramos el sprint. Verificamos la proporción de tareas en el estado realizado con respecto a las que se tomaron al comienzo de la iteración y arreglamos estos datos por segmento.
Por ejemplo, en Producto, tomamos 20 problemas y terminamos 17. Por lo tanto, la tasa de éxito para este segmento es del 85%. Para nosotros, un buen progreso en el desarrollo de productos es un indicador del 90% o más. Si es menor, discutimos en Retro cómo podemos mejorar esta métrica.
Trabajo de Sprint
A menudo nos preguntan sobre la revisión de código y cómo funcionan las pruebas. Todo es bastante estándar aquí.
El día comienza con un stand-up. Durante 15 minutos, el equipo discute lo que hicieron ayer y lo que harán hoy.
Usamos Jira Flow y Git Flow para trabajar en tareas, tenemos una pila de Atlassian. También hay un tablero Scrum con columnas para hacer - en progreso - listo para revisión de código - listo para QA - listo para la vida - hecho.
Cuando el desarrollador ha preparado el código, crea una rama con el número de problema actual en Jira; esta es una rama de funciones. También lo envía a una solicitud de extracción en Bitbucket. El desarrollador necesita al menos dos aprobaciones. También tenemos integración con Jenkins, si la compilación es verde, entonces puedes fusionar. El líder tecnológico y el líder del equipo tienen derecho a fusionarse. A veces es necesario preparar una prueba unitaria para una solicitud de extracción. Y a veces, deliberadamente, no los escribimos si sabemos que se trata de áreas de negocio no críticas, un dominio no crítico o una característica experimental, y luego podemos eliminarlas.
Cuando todo está bien, lo enviamos para que lo prueben. Un ingeniero de pruebas escribe pruebas automáticas o ejecuta casos de prueba manualmente. Depende nuevamente de cuán crítico sea el dominio. Y luego desplegar.
Podemos decir que este proceso funciona como un reloj. Pero de hecho, en este momento hay una comunicación constante dentro de los equipos. El enfoque principal es el objetivo del sprint y el lanzamiento a tiempo. Para lograr el objetivo, podemos discutir los cambios de producto o revisar la implementación técnica. Todo esto sucede mientras se trabaja en las tareas: siempre es un diálogo entre los desarrolladores, el líder del equipo, el gerente de producto y el control de calidad.
Direcciones de desarrollo y estructura del departamento de TI
En el proceso de transformación, llegamos a una nueva estructura de direcciones de desarrollo. Como recordará, al principio escribimos alrededor de cuatro. Además, quedó claro que para una implementación puntual y de alta calidad de los objetivos, es necesario identificar dos áreas más. Por lo tanto, ahora hay 6 de ellos:
- El consumidor se trata de productos personalizados: sitios web y aplicaciones móviles.
- Logística: sobre logística, mensajería y entrega.
- Proveedor: sobre la integración con nuestros socios (restaurantes / tiendas).
- Interno - call center y soporte.
- I + D: resuelve tareas intensivas en ciencia.
- Plataforma: mejora la arquitectura y la plataforma en su conjunto.
Cada dirección tiene su propia gama de tareas y sus propias dificultades.
Consumidor
La prioridad de esta dirección es la felicidad del usuario. Las principales métricas del producto están aquí: retención, tasa de conversión de pedidos, NPS del consumidor. Desde un punto de vista técnico, es importante para nosotros que todos los datos se envíen rápidamente. En esta dirección, quizás, la mayor carga, ya que trabajamos directamente con el usuario final. Y también hay una gran cantidad de microservicios, la mayoría de ellos aquí.
Los principales productos son un sitio web, incluida una versión móvil, así como aplicaciones para iOS y Android. Las dos corrientes principales son la entrega de comestibles y la entrega de restaurantes. Pila tecnológica más o menos como en cualquier otro lugar: PHP, Go, Postgres, Redis y Memcache para caché, Kafka para comunicación asincrónica.
Logística
La tarea de esta dirección es garantizar la entrega rápida de un pedido a un usuario hambriento. Además, estamos desarrollando una interfaz para despachadores que, si es necesario, ayudan a los mensajeros con el control manual.
Uno de los principales retos de la logística surge cuando crece el número de pedidos y con ello la carga en el sistema. Para hacer frente a las cargas, debe realizar cambios de calidad en la arquitectura. Además, la entrega de alimentos es muy diferente a la entrega de, por ejemplo, suministros de oficina, ropa, libros y más. Allí todo es un poco más sencillo: hicimos una hoja de ruta, la planificamos y salimos.
Con la entrega de alimentos, ese número no funcionará. Todos estamos a pedido, la situación cambia cada 5-15 minutos. Cuando comienza a llover o nevar, la demanda siempre aumenta. Y cuando hace sol afuera y no quiere quedarse en casa, la demanda disminuye. En festivos y fines de semana, el perfil de demanda difiere del de los días laborables. La situación del tráfico y los atascos también hacen sus propios ajustes, especialmente en aquellas áreas donde prevalecen los mensajeros de automóviles / motocicletas. Las horas de mañana, tarde y noche tienen diferentes perfiles de demanda.
Nuestros monitores realizan un seguimiento de esta migración de demanda. Si la demanda ha disminuido, cambiamos los resultados de la búsqueda, damos ofertas más relevantes en la sección "Promociones". Para mejorar la relevancia, conectamos modelos ML que hacen la clasificación personalizada tanto para el usuario como para la zona logística en la que estamos observando un cambio.
Una de las principales aplicaciones en las que se está trabajando en logística es la Rider App. Es una aplicación de Android en la que los mensajeros ven dónde recoger un pedido y dónde se debe entregar.
Vendedor
Esta área trabaja con nuestros socios internos: restaurantes y tiendas. O mejor dicho, con sus gerentes, quienes administran el menú a través de su cuenta personal y reaccionan a las estadísticas en los resultados de búsqueda.
Gracias a los datos recopilados y las estadísticas sobre pedidos, tenemos un buen conocimiento del público objetivo y las características de los restaurantes. Trabajamos con ellos en asociación y les brindamos una herramienta que les ayuda a comprender mejor quiénes son sus clientes y habilitar mecanismos de marketing. También ayudamos a los restaurantes a desarrollar modelos de optimización de precios, a comprender qué platos es mejor mostrar en qué momento y en qué secuencia.
Otro producto en el que se está trabajando en la dirección del proveedor es un tablero, en el que caen los pedidos para la cocina. La cocina acepta el pedido, ve su composición, determina cómo prepararlo y, de hecho, lo prepara. Cuando se prepara el pedido, la cocina lo confirma en la aplicación y transfiere el pedido al mensajero. Y luego el mensajero trabaja con la aplicación Rider.
Interno
Esta área es responsable de las herramientas de nuestro call-center, que brinda soporte al usuario. De hecho, esta es el "área de administración" para todo lo relacionado con los pedidos. El operador puede ayudar al cliente, brindar información adicional sobre el estado actual del pedido, realizar ajustes en el pedido antes de enviarlo al restaurante.
El desafío de esta dirección es hacer un sistema de este tipo, que sea, en primer lugar, conveniente y cubra todas las necesidades del operador y, en segundo lugar, rápido, porque el cliente necesita ser ayudado lo antes posible. Además de la tarea clave, los chicos de Internal están trabajando para reducir el tiempo de procesamiento de un problema por parte del operador y reducir el número de llamadas.
I + D
Cuando necesita cambiar un proceso comercial y al mismo tiempo comprender cómo estos cambios afectarán a toda la plataforma en su conjunto, la investigación y el desarrollo están involucrados. Los chicos realizan experimentos, construyen modelos, cuentan y pesan. También interactúan más estrechamente con el departamento de BI, donde trabajan con big data, modelos ML, diseñan redes neuronales y pronostican la demanda. En este sentido, BI ayuda a la I + D con investigación y herramientas.
La investigación se trata principalmente de trabajar con datos. Por ejemplo, cómo se comportará el sistema si cambia algún factor. La mayoría de las tareas de I + D ahora proceden de la logística, ya que esta área tiene el mayor nivel de incertidumbre.
Plataforma
Esta es una dirección técnica. En primer lugar, los chicos tienen como objetivo mejorar el núcleo del sistema, refactorizar el procesamiento de pedidos y descomponer nuestro monolito. Este no es un desarrollo de producto en el sentido clásico, pero todas las mejoras están de una forma u otra encaminadas a hacer más conveniente y fácil para los usuarios interactuar con la aplicación Delivery Club: reducir el tiempo de respuesta para que las páginas se abran más rápido, aumentar la capacidad de la plataforma para que más usuarios puedan hacer orden y al mismo tiempo la experiencia de uso fue lo más placentera posible para ellos.
Resultados de transformación y nuevos desafíos
Nuestra tarea fue construir un proceso de desarrollo que cumpliera con todos los requisitos de una empresa en crecimiento: los equipos están involucrados en el negocio, se comunican mucho entre sí, son responsables de los plazos establecidos por ellos mismos y comprenden cómo su trabajo afecta al usuario final. El proceso debe ser transparente, medible y, lo más importante, escalable.
Después de realizar una transformación de producto y optimizar el proceso de desarrollo, llegamos a la conclusión de que cada uno de nuestros lanzamientos se volvió predecible. Al principio, sabíamos con una precisión del 80% cuándo y en qué composición se lanzarían los lanzamientos. Ahora, el indicador de desempeño promedio en todos los equipos dentro del departamento ha aumentado al 90%. La implicación de los equipos, es decir, la motivación de los muchachos, ha aumentado muchísimo, entienden lo que están haciendo y por qué, para quién es importante.
El proceso incluye la capacidad de responder a las tareas lo antes posible sin dañar el desarrollo del producto, hay suficientes puntos de comunicación para estimar de manera flexible los costos laborales y responder de manera oportuna a los cambios en los requisitos del gerente de producto. En la práctica, nos aseguramos de que el proceso sea escalable: logramos pasar de 40 personas a 170 con el mismo proceso de desarrollo y sin perder rendimiento.
Al mismo tiempo, no nos detenemos y creemos que la transformación del producto aún está en curso. A fines de 2019, comenzamos a pensar en cómo los equipos podrían influir aún más en los negocios. Los equipos tienen mucha experiencia en el producto, parece que puede usarlo, crear una especie de simbiosis de tecnología y negocios. Además, necesitábamos idear un mecanismo para verificar las hipótesis del producto. Es decir, controlar el valor de las tareas que entran en nuestro desarrollo. Para hacer esto, describimos el proceso GIST, un marco para verificar hipótesis de productos, que discutiremos en uno de los siguientes artículos.
¡Gracias por leer!