Mejor hágalo usted mismo: cómo creamos la aplicación móvil interna Perekrestok.ru

¡Hola! Mi nombre es Maria Timofeeva, soy la directora de producto del supermercado en línea Perekrestok.ru. Con el lanzamiento de nuestra nueva aplicación móvil, decidimos contar cómo hicimos la versión actual, cuántos errores recolectamos y cómo llegamos a la conclusión de que, en nuestro caso, el desarrollo interno es más útil para el producto.

En esta publicación, describiremos las características del outsourcing y el desarrollo de aplicaciones internas, así como también hablaremos sobre los detalles de la plataforma. Luego intentaremos volver en nuevos artículos y contarle sobre nuestro diseño, dispositivo de back-end y desarrollo de versiones para iOS y Android.

Por donde empezamos

Qué había dentro y cómo funcionaba // Semyon Matsepura, jefe del grupo de desarrollo móvil del supermercado en línea Perekrestok.ru

Desde el lanzamiento de Perekrestok.ru, los pedidos se han procesado a través de la aplicación My Crossroads, combina la gama y los servicios de la red minorista y supermercado en línea Desde enero de 2020, comenzamos a desarrollar una nueva aplicación llamada "Online. Crossroads", mientras admitíamos la actual. En primer lugar, se seleccionaron equipos internos y se desarrollaron conceptos: desde la idea hasta las características aprobadas.



Varios meses de trabajo se dedicaron a un estudio más detallado de la cocina interior (especialmente minorista, logística, todo tipo de promociones y programas de bonificación), tratamos de tener en cuenta y optimizar todo lo que alcanzamos antes. Se escribieron nuevas API móviles teniendo en cuenta el funcionamiento de las aplicaciones (porque desde el exterior parece que tanto el sitio como la aplicación se crearon para seleccionar bienes y compras, lo que significa que funcionan casi de la misma manera, pero esto no es del todo cierto).

Si inicialmente pasa tiempo y desarrolla la API correcta al principio, puede acelerar significativamente el proceso de desarrollo. Y también hemos configurado el trabajo de las solicitudes, la API móvil es un trabajo por contrato, es muy importante cómo se enviarán las solicitudes y se recibirán las respuestas. Se pasaron muchos días eligiendo la mejor solución. Sí, por supuesto, el equipo de back - end.va activamente hacia el uso de microservicios.

Dio la casualidad de que abordamos la creación de una nueva aplicación desde varios lados al mismo tiempo y comenzamos a remodelar aplicaciones de respaldo y móviles (iOS y Android) en paralelo. Mientras los backenders están rehaciendo todo lo que hay dentro, el equipo de desarrollo móvil trabajó en la arquitectura, los diseñadores continuaron creando el sistema de diseño y los especialistas en marketing evaluaron a los competidores y sacaron conclusiones sobre la funcionalidad de nuestra aplicación.

Al crear una nueva aplicación, tratamos de desarrollar su arquitectura lo más detallada posible, para tener en cuenta incluso los detalles más pequeños con el fin de proporcionar su soporte más simple en el futuro y obtener un producto de alta calidad en la salida.

Inhouse vs Outsource

Cómo reunimos equipos para el producto // Elena Tikhonova, Jefa de Aplicaciones Móviles

Las empresas a menudo tienen una opción: usar sus propios recursos al desarrollar algunas aplicaciones y servicios, o escribir una especificación técnica clara y externalizar todo de forma segura. En principio, esto a menudo depende de la tarea específica. De una vez por todas, decir que la casa es más fresca que la subcontratación (o viceversa) es imposible. Después de todo, hay situaciones en las que es más rápido, fácil y económico conectar rápidamente un equipo de terceros para crear un producto que separar a especialistas de TI a tiempo completo, cuyo tiempo ahora es más importante para la empresa y cuesta más. Por lo general, esta es la creación de algunos recursos promocionales únicos. Te tomó un aterrizaje solo por ciertas vacaciones: lo subcontrataron, hicieron todo por ti, las vacaciones pasaron, pusieron el aterrizaje sobre la mesa. Todas. Las excepciones son raras, pero hay, por ejemplo, que realmente nos gustó el estilo de trabajo de una persona en particular de la subcontratación,y seguimos trabajando con él ahora, encajó bien con el proyecto.

Pero si se trata de algo más complejo (y de larga duración), que requiere nuevas integraciones, soporte constante, entonces aquí la casa se vuelve más rápida, más barata y más segura. Es mejor hacer algo una vez y mantenerlo, que rehacer los servicios desde cero de vez en cuando. Sin embargo, si tuvo otros ejemplos en la práctica cuando la tercerización es realmente mejor, escriba los comentarios.

Cuando tiene plazos ajustados, necesita personas motivadas por el producto en sí y que no serán rociadas sobre otra cosa, ya sea por cuenta propia o por un plazo adicional de otros clientes de la empresa de outsourcing. Sí, con una instalación interna es importante ganar una masa crítica de desarrolladores. Porque cuando (te gusta) tienes un departamento que tiene casi casi personal, pero aún tienes que subcontratar a alguien para las tareas, es difícil considerar una casa pura. Para nosotros, ese mínimo necesario cabe en 5 personas para cada plataforma + 2 analistas de sistemas + 3 gerentes + 2 diseñadores + 2 probadores + 4 personas del equipo de back-end. Total 23 personas.

Reunimos a nuestros equipos con énfasis en las habilidades profesionales de los muchachos y en hacerlos realmente cómodos trabajando juntos. Las habilidades blandas prestan aún más atención a veces. Ahora el equipo solo está aumentando y su composición anterior no cambia.

Si también haces una aplicación minorista

Con todas las características // Maria Timofeeva, directora de producto del supermercado en línea Perekrestok.ru

Tenemos un par de consejos para usted. En primer lugar, como se mencionó anteriormente, trate de asegurarse de que la arquitectura y toda la estructura interna de su aplicación sean establecidas por el equipo interno. Si conecta la subcontratación al principio, tendrá que correr vigorosamente por el rastrillo, y luego, con un alto grado de probabilidad, volverá a hacer todo de nuevo. O no lo rehacerá, pero gastará muchos recursos en soporte completo.

En segundo lugar, en aras de la velocidad de los lanzamientos, puede omitir algunos pasos secundarios de los scripts de usuario. Para ahorrar tiempo, tiene sentido lanzar una función en una forma ligeramente más simple de lo que pretendía. Y luego atornille a la implementación completa. Durante 4.5 meses lanzamos una aplicación que incluía toda la funcionalidad de la versión web. Deje en la forma básica, pero - todo.

Mira el ejemplo de nuestra aplicación. En nuestro caso, la ruta del usuario es una compra. El flujo asociado con esto debe elaborarse lo más detallado posible: seleccionar productos, agregarlos a la cesta y realizar un pedido. Pero todo tipo de cosas, incluso importantes para el servicio, como una escala conveniente para evaluar pedidos, también son necesarias, pero su estudio puede minimizarse. Regrese a esto más tarde, cuando todo lo principal esté hecho.

Es precisamente por esto que a menudo se nos reprocha el hecho de que hay tarjetas en la interfaz en las que hay muy poca información sobre el producto: precio, foto y nombre. Al igual, algunas otras aplicaciones de entrega de alimentos tienen enormes tarjetas donde puede ver el producto con todo detalle, incluido el grado de transparencia de la escala de pescado y el clima como el día de la vendimia para el vino.

Entonces, de manera similar, puede abordar el diseño en caso de que tenga pocos encabezados. Menos puestos: más espacio para su visualización e información sobre cada uno. Pero, francamente, tenemos suficientes puestos. Por lo tanto, la interfaz tiene pantallas con las cuales el usuario ordena los productos más familiares y a menudo comprados. En este caso, generalmente es importante para él simplemente comprender que el producto está en stock y comprarlo rápidamente. Por lo tanto, una tarjeta minimalista que realiza completamente su función.

En tercer lugar, y esto, lo más probable, se aplica a cualquier aplicación con pago por pedidos, y no solo al comercio minorista como tal. Agregue soporte para Apple Pay / Google Pay y más. Esto es más importante de lo que parece. Su aplicación debe tener una buena página de pago, que le permite una vez más verificar discretamente y corregir errores si es necesario, y agregar rápidamente el producto correcto. Aquí es importante tener en cuenta que el número de cargadores es mínimo. ¿A quién le gusta cuando la pantalla se congela al agregar un nuevo producto a la cesta y no puede desplazarse más?

Cuarto, diseño. Estudie la ruta del usuario y haga que sea conveniente para él en primer lugar en esta ruta. Convocamos a varios consultores de diseño, y comenzaron a aconsejarnos alegremente según fuera necesario. Aconsejaron, en general, cosas interesantes: soluciones increíblemente hermosas, en la pila más moderna, utilizando todos los enfoques visuales nuevos.

El problema era que al final habría resultado una aplicación con un montón de hermosas piezas, tal vez habría tomado incluso un par de premios de diseño y, en general. Pero el usuario simplemente se sentiría incómodo al usarlo. También llega a la aplicación de entrega de alimentos para pedir comida, y no dejarse inspirar por excelentes gráficos y aprender nuevas tecnologías para la vida móvil. En cuanto a mí, una historia en la que el diseño se pone por encima de la funcionalidad en aras del diseño es una mala historia.

Y para hacer una buena funcionalidad = conozca bien su producto. Reunimos el sitio CJM, la versión móvil y la versión anterior de la aplicación, tomamos todas las revisiones negativas con detalles, vimos lo que a la gente no le gustó, dónde estaban las dificultades e intentamos tener esto en cuenta.

Intentaremos escribir un artículo separado sobre diseño de aplicaciones.

Nueva aplicación

Esto es lo que obtuvimos como resultado: puede descargar la aplicación aquí .



Agradecemos sus comentarios, críticas y comentarios.