In e-commerce come from a variety of areas: fintech, software development, telecom. And they quickly find out that here, too, is pretty boring. We spoke with representatives of various areas of the IT department about unexpected professional challenges, work tasks and growth points.

Drive, buzz and quick feedback

My name is Alexander Afenov, I’m the head of development for the commercial department, I call myself Timlid Timlid. Prior to joining Lamoda, he was involved in outsourcing development for mobile operators. For 4.5 years at Lamoda I have gone from a middle-developer to the head of the department.

How was this growth arranged?

The onboarding process is designed so that during the trial period developers roll out new features (and sometimes even entire projects) to production. Tasks and goals for the test are selected depending on the grade and characteristics of the new employee, and even after the first three months they continue to teach him and immerse him in the business and specifics of IT systems: through self-tests, they show the course of business processes, on code review they share the basics of the internal development culture , explain which parts of the projects can be refactored, and what will soon be brought to new services. However, a truly deep understanding of the operation of the system does not appear immediately. For this, in my opinion, we need to work out about a year.

In order to get used to it faster and feel everything with your hands, and also for the rotation of knowledge within teams, there is a support service on duty (here about it was my big report on Teamleadconf ). Within a week, one of the engineers solves the issues that fly around the system, when priority tasks end, he takes them from the technical backlog.

For the brave and desperate, and those who want to maintain the system, there are night shifts. This is an interesting challenge for those who want to quickly pump. At night, you can truly enter into a close relationship with the system, because part of the business processes occur during strictly non-working hours.

For example, I sit during the day and program something, releases roll and everything is fine, and then I go on duty and late in the evening I see that goods are being received at one of the transit warehouses, and because of an error in the IT system, something tearing apart a business process. In practice, it turns out this way: several sales representatives are sitting in a warehouse, cannot finish the working day and go home. At this moment, you can and should feel your hands on the business process, repair, help and understand how everything works. And at other times you don’t encounter this, and you don’t have to face it for years. Combined with financial motivation and drive - it’s very cool.

What now?

Now I have a global management task - to bring together and unify all teams working with commercial functions. We will solve this in two ways: through the rotation of tasks among teams, and through the involvement of our “wolf wolves” - system architects, who will also monitor horizontal connections within and between teams. In order for each team to become independent, sometimes you need to develop the guys and give them different tasks and the opportunity to learn new technologies: sometimes PHP developers connect to projects in Java and Go. Since 2018, everyone in my area has been working with Kafka, which has become an important part of our infrastructure, generally accepted technology and one of the most popular ways of exchanging data between systems. (Here 's a report on how we do it)

All developers and other team members should not only cut something in the corner, but also understand what the neighbors are doing. We want them to touch other people's systems with their own hands: in the future, this makes the teams more independent and allows them to run into the systems necessary for solving the business problem.

What surprised you when you came to e-com?

In Lamoda, communication with a client and how IT actions affect people's lives and their real experience have come to the fore. Here, they are not interested in the benefit of the moment, but rather in the long-term loyalty. We want our product to be used on a regular basis. The main specificity for development is the need to respond quickly to problems. For example, something has broken in us, and at the point of delivery of goods there is a living person and cannot pay for his coat.

We see when, due to our mistakes, people in the warehouse and in delivery suffer. And we rejoice with our customers, for example, when we completely redesigned the payment processing process and launched Gift Cards, which everyone was waiting for.

Redo everything from scratch

I am Alexandra Kamzeeva - I used to work in system integration, three and a half years ago I started working as a system analyst at Lamoda.

Why do I need an analyst in development?

This is the first question of many developers. But then, when they work with a good systems analyst, they get a taste and are asked to call analysts for each project. Developers are not dedicated to the intricacies of business processes, and without this knowledge it is difficult to make a solution that is ideal for business. An analyst is needed to do a detailed study before the start of development, ask questions, get answers and take everything into account in the compiled specification. This minimizes the number of iterations and errors and saves developers time and nerves.

What was your first major e-commerce challenge?

My most global and interesting challenge so far is a new system for automating the process of returning money to a client’s card. This was one of the weaknesses of our system, it was written back when Lamoda was a startup. There were a lot of manual operations that increased the risk of errors. We began to think about approaches to changing this system, and then there was a “magic kick” from the state: Federal Law No. 54 was adopted. Under this law, all companies offering goods and services to individuals must transfer sales data to the tax office through the OFD (fiscal data operator), indicating what they sold, when and through which intermediaries. All this is printed on the check. It works in the opposite direction: in addition to information about what is sold, you need to transfer, for which the money is returned, and print the check.

We divided the project into 7 phases, this allowed us to focus on a specific feature in each phase and release them into the product one after another. As a result, we automatically automated everything we could to return the correct data to the tax without unnecessary manual corrections.

Not only a performer, but also a co-author

My name is Igor Grammatchikov, and I joined the online store development team a year and a half ago from a large business process automation company. Now I am a frontend developer, I make a Lamoda website. Before that, I developed interfaces for internal automation systems in large network stores, where it was just a development for some kind of abstract client. Now I feel that this is my product, and I want to be liked not only by users, but also by myself. I myself regularly buy on Lamoda, all my colleagues and friends use it, and sometimes we ourselves see jambs that we can fix.

The tasks are different. For example, I had the task of making a drop-down basket on the site so that it worked on all pages that were already rewritten to the new vue.js framework and those that remained on the old backbone.js, jquery code. For more than a month I was piling over this task and ran into many problems. But in the end, after much joint deliberation, we developed a method, honed it, and now everyone can use it easily and simply.

We are not only dealing with mass issues. Recently, we struggled with a specific bug that occurred only for one user. In my past works, everyone would have simply come up with a polite explanation and scored, but here we repair everything that does not work as it should.

This is the first time I really work on agile: we have daily stand-ups, many meetings with the manager and the designer. And the developer is not only a performer, he is also a co-author. At all meetings, they really listen to my opinion, and not just - wrote it down and went to saw. You say that it will not work, let's redo it? And the team begins to think the best.

User feedback and code review as development drivers

I am Viktor Barsukov - the developer of one of the warehouse automation teams. I have been working in the team for six months, and before that I worked in fintech and in the fiscal data operator. We constantly communicate with warehouse employees - users of our systems that give us quality feedback. In fintech this was not - we wrote and forgot. And then it is tested by someone, deployed by someone. The fact that we communicate with our direct users every day, and the hard code review motivates me very much for further development. We have a direct slogan: guys do a code review of each other! In order for the task to move further, two engineers and one of the team leaders must look at it. This is a very cool practice: in addition to stand-ups, reviews, and flashbacks, you can see a live code change. So the general picture of development appears.

What business processes do you automate?

There are many tasks in working on warehouse automation: working with the supply of goods, placing goods on shelves, managing sorting, packaging, and collecting orders. There is also interaction with warehouse employees: from counting KPIs to choosing the optimal route for moving between shelves.

We have small tasks, and there are similar to a detective story, when you look at the logs, where and when things went wrong. This is exciting. Now we are solving a global problem - switching from Java to Kotlin in an Android application, this will give more opportunities from a development point of view.

What is the largest business challenge you are solving now?

Now the warehouse development team is implementing another major project - Warehouse-2. Previously, we worked with one physical warehouse, and connecting the second will require major changes in all business processes, and therefore in systems that automate them. The second unit at the start will be similar to the first (about the first we wrote a separate article ). But in the future, the second warehouse will be larger, and the level of automation of business processes is higher and more modern.

One of the tasks is to synchronize data between future systems so that the data between them is not duplicated and does not conflict.

I set up the communication bus based on the Camel framework. Actually, this was my first experience with Camel, so the task was not only to refine the routes taking into account the second warehouse, but also to deal with the framework itself.

Axapta for three months

I’m Elizaveta Naumenko, and for a year I have been working in the support and development team of the ERP (Enterprise Resource Planning) department as a support consultant. Our department is engaged in the automation of all financial reporting, accounting and distribution.

The system is built mainly on Axapta and a little 1C. Axapta interacts with dozens of our internal systems, as it is the source of master data on procurement and finance. Axapta is constantly accessed by our other platforms, so there is a lot of integration and support.

The main challenge for me was a quick immersion in the process, I had to learn and develop very quickly. In the three months of the trial period, I learned how our processes work on Axapta. I felt like I was getting another higher education (more about how we share knowledge within the team here ).

What is the hardest part of your job?

The hardest part is urgent support tasks. According to SLA, there are literally a few hours to resolve critical errors. There are also complex tasks that can be stretched out because a deeper analysis is needed. If you can’t cope on your own, then I can go to my supervisor and ask for help. Even approach the head of ERP development and say that I do not know what to do and how to solve the problem. And this is rather encouraged, because we all understand that if the error is not corrected in time, then a stop-situation for the business is possible, and this is critical for the team, since this is the company's money. If this happened, then there will certainly be a retrospective analysis of the incident: what to do and how to prevent errors next time.

Technological diversity: Zoo, but contact

I am Timur Nurutdinov, I am responsible for the entire development at Lamoda. From my point of view, we have a large e-com with a huge number of processes, in which many people work, and even more people use our services. For all this to work, we use almost all modern technologies, since we have to solve almost all possible IT problems. Our technical radar has a real zoo, but it’s a contact, you can try everything. Of course, we have less in-house development than IT giants, but tasks and projects are not easier than theirs.

And what do you personally like about your work?

The Lamoda IT department has many users: customers, business customers, company employees. And for me it is a special pleasure to see the result of our work - when we quickly solve their problems. I made a whole report about this at HL ++ 2019, where I told in detail what other challenges the e-commerce industry poses to an engineer, and why we enjoy it.

Challenge accepted or what tasks do Lamoda engineers solve