Few people know that Sportmaster unites a whole group of companies, which includes Ostin, FunDay and others. The SMLab division, which employs almost 1,500 people, is responsible for maintaining the operation of this entire machine. Of these, about 400 are developers and 25-30 front-end developers. All the rest are involved in IT support for manufacturing, logistics, finance, and this also includes the departments of web development, quality assurance and many others.
All of our developers are doing roughly the same thing as colleagues in other large companies: developing new systems and maintaining old ones. We have a very large technology stack, as well as a large scope of applications that we support and develop. On our shoulders lies the development and support of such sites: Sportmaster, Ostin, FunDay, Columbia, Fila, Demix, UrbanVibes. In addition to all this, we have a large springboard for internal automation. In general, for developers there is where to deploy, to pump their skills.
Internal kitchen
As I already told the developers in our division of about 400 people, in order to effectively manage such a large division, the company launched a transformation process two years ago. Now we are working on Agile, we currently have about 30 product teams, and up to 100 are expected to develop and maintain their projects. Each team has a variety of competencies: business, analysts, developers, testers, automation engineers, methodologists. We created a special portal where we track team metrics, and methodologists, in turn, help teams set up flows. As soon as the team becomes independent enough, the methodologists switch to helping other teams.
Frontend in its good understanding was born in SMLab two or three years ago. Before that, there was a zoo of frameworks, a large number of various libraries such as knockout, jquery. All this imposed many restrictions on development, search for new employees and rotation between projects.
The first thing we did was dismantle all the company's software, what they consist of and what they are written on, and made a technological radar, thanks to which we currently control the list of available technologies in the company. We have clear rules for adding new technology to the list of available ones. If it is necessary to introduce new technology into the radar, an RND is formed, a team of specialists is recruited to conduct this study. Based on the results, the team creates a presentation of the technology and forms the RND documentation and then defends it at the technical committee. If the committee decides that a technology is important for further development, then it expands the scope of available technologies across the company.
We also did a lot of research on the choice of framework for the entire company, which resulted in the choice of Vue. Now new software is written on it, and all the old is gradually rewritten.
For the entire Sportmaster as a whole, we use more than 200 systems that automate all internal activities of the company. For example, we have automated the entire merchandising business process: the process of displaying goods in the store, checking, etc. Now we are working on the automation of photo studios and a call center, a lot of people are involved in this area.
All e-commerce in Sportmaster is divided into two large groups:
The first group is the giant sites: such as Sportmaster and Austin, and the second is a group of equally important sites, but with much lower loads, such as FunDay and a group of mono-brand sites.
Ostin became the very first giant to be written entirely on new technologies like NodeJS, Vue, SSR, Kotlin, etc. and went into production. The current version of the Sportmaster website was written approximately 4 years ago. Now the development of a new version 3.0 is underway on new technologies with a new design, and soon it will replace the old one. The situation is similar with the Funday site from the second group, the site is currently being actively developed using a new stack, we will soon see a new site.
The mono-brand site group was the second iteration of site development on the new stack. I was temporarily introduced to the team at the stage of its formation and held the position of a team lead, currently I left the team and continue to work with the team from the position of a curator.
Monobrand websites
A little background. Before moving to IT, I worked in business for about 5 years. More than once I came across newly created software, from which there was a feeling that programmers were writing it exclusively for themselves. And then I came to the conclusion that the product should be convenient for everyone: for users outside, and for all participants in the development process from within.
When it was the turn of mono-brand sites. A month before, in fact, the start of development, my team and I went to study sites that have already been created by other companies, and brought out two main problems.
First, companies neglect user metrics: we noticed that, for example, a product card is opened for 20 seconds, any filter is applied for 10-15 seconds. That is, it turns out not a purchase, but some kind of struggle with the site.
Secondly, there are problems with the display of the site on mobile devices. They are all crooked.
Therefore, when our turn came, first of all we started creating a component diagram, drew all the blocks and connections that should have been, and then began to work on optimizing each block separately and its connections with other blocks. We agreed with the backend that all the logic, working with microservices, calculations, necessary aggregations and so on falls on their shoulders, and the front is engaged in the display and logic of interaction with users.
Thanks to this, we have minimized the size of the response and significantly standardized the API, which makes it easier for the team to navigate in the process and in the chord of work on new functionality, we very quickly agree on a contract.
In the second global business, we discussed and agreed in the team how we work with application statics. Static caused us problems on other projects more than once, when it suddenly became unmanageable and its size was calculated in gigabytes. In general, we agreed to abandon this folder: it will be automatically generated and collected by our application. The project is already about a year old, and all static content weighs no more than 30 MB.
When we got to the layout, we decided to conduct the development so that there was no duplication of code - we did the layout so that we could adapt it to different devices. Seo specialists have done a great job on this issue, told which blocks are seo-dependent and which are not. We've highlighted the critical CSS. All these minimal actions led to the fact that the page on the mono-brand website weighs on average no more than 20Kb and opens almost instantly.
There were also unexpected results. At the start of the project, we began to compile the documentation not in the form that everyone usually writes it, with a list of components and a list of their functions. We documented everything in general: startup commands, dependencies, environments, code styles, etc. And they did all this, by and large, only for themselves. But when everything was just beginning, there were five people in the project, and now there are 20 of them.
And now it is much easier for us to bring new employees up to date - we just let them study the documentation for a couple of days, after which they are quite ready to go and engage in combat missions on their own.