Pocas personas saben que Sportmaster une a todo un grupo de empresas, que incluye a Ostin, FunDay y otras. La división SMLab, que emplea a casi 1.500 personas, es responsable de mantener el funcionamiento de toda esta máquina. De estos, alrededor de 400 son desarrolladores y entre 25 y 30 desarrolladores front-end. Todos los demás están involucrados en el soporte de TI para fabricación, logística, finanzas, y esto también incluye desarrollo web, control de calidad y muchos otros.
Todos nuestros desarrolladores están haciendo aproximadamente lo mismo que sus colegas de otras grandes empresas: desarrollar nuevos sistemas y mantener los antiguos. Tenemos una pila de tecnología muy grande, así como una gran variedad de aplicaciones que apoyamos y desarrollamos. Sobre nuestros hombros recae el desarrollo y el apoyo de dichos sitios: Sportmaster, Ostin, FunDay, Columbia, Fila, Demix, UrbanVibes. Además de todo esto, tenemos una gran presencia en la automatización interna. En general, para los desarrolladores hay un lugar donde implementar, para bombear sus habilidades.
Cocina interna
Como ya les dije a los desarrolladores de nuestra división de unas 400 personas, para gestionar eficazmente una división tan grande, la empresa inició un proceso de transformación hace dos años. Ahora estamos trabajando en Agile, actualmente tenemos alrededor de 30 equipos de producto y se espera que hasta 100 desarrollen y mantengan sus proyectos. Cada equipo tiene una variedad de competencias: negocios, analistas, desarrolladores, probadores, ingenieros de automatización, metodólogos. Creamos un portal especial donde rastreamos las métricas del equipo y, a su vez, los metodólogos ayudan a los equipos a configurar los flujos. Tan pronto como el equipo se vuelve lo suficientemente independiente, los metodólogos pasan a ayudar a otros equipos.
Frontend en su buen entendimiento nació en SMLab hace dos o tres años. Antes de eso, había un zoológico de marcos, una gran cantidad de bibliotecas diferentes como knockout, jquery. Todo esto impuso muchas restricciones al desarrollo, búsqueda de nuevos empleados y rotación entre proyectos.
Lo primero que hicimos fue desmontar todo el software de la empresa, en qué consisten y en qué están escritos, e hicimos un radar tecnológico, gracias al cual actualmente controlamos la lista de tecnologías disponibles en la empresa. Tenemos reglas claras para agregar nueva tecnología a la lista de disponibles. Si es necesario introducir nueva tecnología en el radar, se forma un RND, se contrata un equipo de especialistas para realizar este estudio. Con base en los resultados, el equipo crea una presentación de la tecnología y forma la documentación RND y luego la defiende en el comité técnico. Si el comité decide que una tecnología es importante para un mayor desarrollo, amplía el alcance de las tecnologías disponibles en toda la empresa.
También investigamos mucho sobre la elección del marco para toda la empresa, lo que resultó en la elección de Vue. Ahora se escribe nuevo software en él y todo el antiguo se reescribe gradualmente.
Para todo el Sportmaster en su conjunto, utilizamos más de 200 sistemas que automatizan todas las actividades internas de la empresa. Por ejemplo, hemos automatizado todo el proceso comercial de merchandising: el proceso de exhibición de mercancías en la tienda, verificación, etc. Ahora estamos trabajando en la automatización de estudios fotográficos y un centro de llamadas, mucha gente está involucrada en esta área.
Todo el comercio electrónico en Sportmaster se divide en dos grandes grupos:
el primer grupo son los sitios gigantes: como Sportmaster y Austin, y el segundo es un grupo de sitios igualmente importantes, pero con cargas mucho menores, como FunDay y el grupo de sitios monomarca.
Ostin se convirtió en el primer gigante en estar escrito completamente en nuevas tecnologías como NodeJS, Vue, SSR, Kotlin, etc. y entró en producción. La versión actual del sitio web de Sportmaster se escribió hace aproximadamente 4 años. Ahora está en marcha el desarrollo de una nueva versión 3.0 sobre nuevas tecnologías con un nuevo diseño, y pronto reemplazará a la anterior. La situación es similar con el sitio de Funday del segundo grupo, el sitio se está desarrollando activamente utilizando una nueva pila, pronto veremos un nuevo sitio.
El grupo de sitios de marca única fue la segunda iteración del desarrollo de sitios en la nueva pila. Me presentaron temporalmente al equipo en la etapa de su formación y ocupé el cargo de líder de equipo, actualmente dejé el equipo y continúo trabajando con el equipo desde el puesto de curador.
Sitios web monobrand
Un poco de historia. Antes de pasar a TI, trabajé en el negocio durante unos 5 años. Más de una vez me encontré con software recién creado, por lo que tenía la sensación de que los programadores lo escribían exclusivamente para ellos mismos. Y luego llegué a la conclusión de que el producto debería ser conveniente para todos: para los usuarios externos y para todos los participantes en el proceso de desarrollo desde adentro.
Cuando llegó el turno de los sitios monomarca. De hecho, un mes antes del inicio del desarrollo, mi equipo y yo fuimos a estudiar sitios que ya habían sido creados por otras empresas, y sacamos dos problemas principales.
Primero, las empresas descuidan las métricas de usuario: notamos que, por ejemplo, una tarjeta de producto se abre durante 20 segundos, cualquier filtro se aplica durante 10-15 segundos. Es decir, no resulta una compra, sino una especie de lucha con el sitio.
En segundo lugar, existen problemas con la visualización del sitio en dispositivos móviles. Todos están torcidos.
Por lo tanto, cuando llegó nuestro turno, primero comenzamos a crear un diagrama de componentes, dibujamos todos los bloques y conexiones que deberían haber sido, y luego comenzamos a trabajar en la optimización de cada bloque por separado y sus conexiones con otros bloques. Estuvimos de acuerdo con el backend en que toda la lógica, trabajar con microservicios, cálculos, agregaciones necesarias, etc. recae sobre sus hombros, y el frontal está involucrado en la visualización y lógica de interacción con los usuarios.
Gracias a esto, hemos minimizado el tamaño de la respuesta y estandarizado significativamente la API, lo que facilita que el equipo navegue en el proceso y en la cuerda del trabajo en la nueva funcionalidad, acordamos muy rápidamente un contrato.
En el segundo negocio global, discutimos y acordamos en el equipo cómo trabajamos con las estadísticas de aplicaciones. La estática nos ha causado problemas en otros proyectos más de una vez, cuando de repente se volvió inmanejable y su tamaño se calculó en gigabytes. En general, acordamos abandonar esta carpeta: será automáticamente generada y recopilada por nuestra aplicación. El proyecto ya tiene aproximadamente un año y todo el contenido estático no pesa más de 30 MB.
Cuando llegamos al diseño, decidimos llevar a cabo el desarrollo para que no hubiera duplicación de código, hicimos el diseño para poder adaptarnos a diferentes dispositivos. Los especialistas en SEO han hecho un gran trabajo en este tema, informando qué bloques son dependientes de SEO y cuáles no. Hemos resaltado el CSS crítico. Todas estas acciones mínimas llevaron al hecho de que la página en el sitio web de una sola marca pesa en promedio no más de 20Kb y se abre casi instantáneamente.
También hubo resultados inesperados. Al inicio del proyecto, comenzamos a compilar la documentación no en la forma en que todos la escriben habitualmente, con una lista de componentes y una lista de sus funciones. Documentamos todo en general: comandos de inicio, dependencias, entornos, estilos de código, etc. E hicieron todo esto, en general, solo para ellos mismos. Pero cuando todo estaba comenzando, había cinco personas en el proyecto, y ahora hay 20.
Y ahora es mucho más fácil para nosotros poner al día a los nuevos empleados: simplemente les permitimos estudiar la documentación durante un par de días, después de lo cual están listos para comenzar y participar en misiones de combate por su cuenta.