Product Refactoring: Remember an “amazing” international team trip

2022-05-07 0 By

I believe that many students have faced the situation of taking over the “mess” project, the style of strange UI interface, 18 twists and turns of processing logic and countless hidden extremely deep pit.Some projects are so complex that every small change we make requires days or even weeks of research, and we still have online bugs.What I want to share with you today is another scene in this process — a multinational team working together on refactoring.There were both sadness and joy, but the most important thing was that I gained valuable experience of cross-team, cross-country and cross-culture project cooperation.Hope to give you some enlightenment.The project product of the author is a merchant app, which provides offline transactions, merchant/store self-service, sales and commission report and other services for large, medium and small merchants cooperating with the company.The backend mainly connects to the company’s core data system.The original version of the App was made by a Czech outsourcing company and had only a few simple features.After the launch, the number of merchant users was relatively low (average DAU was about 1500), and there were a large number of complaints every day, so the company decided to entrust the local real estate research group for follow-up research and development.After I took over the project, THROUGH communication with the Czech development team and reading relevant documents, I found the following problems:The function is too single, and there is almost no connection with the outside. The pain point of merchants is not grasped to solve the data confusion, the iteration cycle is too slow, and the agile development is not reflected. Aiming at the above problems, we quickly developed a series of solutions after many discussions within the group:Through telephone communication with some merchants in the early stage, we realized a very serious problem in the product design before: it was divorced from the actual needs of users.Perhaps because the designers and the development team are all foreigners, they skipped the very important part of the process from the beginning: user interviews.Just based on my business experience in this field, I designed an APP according to the usage habits of foreign users.Therefore, another colleague in charge of the APP and I applied for half a month to conduct field research in merchants and stores of different types and regions.Through in-depth communication with merchants and observation of various details in their daily app use scenarios, we successfully collected potential user needs.At the same time, we also set up a user wechat group to facilitate the feedback of merchants.Later, it has been proved that the establishment of wechat group not only facilitates businesses, but also plays a great role in user research before we launch new and important functions each time.Relying on this close user relationship, we also held several user conferences, which successfully established the brand image of the company.Ii. Integration of internal requirements After field investigation, we went back to the company and discussed with all relevant business departments, divided all requirements into several modules and developed them according to their priorities:O2O related (scan code shopping, product maintenance, marketing promotion, store reservation) data report (sales, commission) merchant College III. Czech Trip After more than a month of sorting out the needs,Finally came the most critical, complex and interesting part of this refactoring: the collaborative development of multinational teams.One of the problems mentioned above is “data clutter”.Why does this happen?In fact, this is related to the background fetch logic of app.Originally, the APP should have directly obtained merchant information from the master data system, but in the preliminary design, the master system worked in 8*5 mode (8 hours a day, 5 days a week). In order to meet the needs of the APP, a system was added in the middle of the two, which can support 7*24 work.But that poses a problem: the data are inconsistent.The data on the App side was previously fetched from two sources: the intermediate system of the source system.Also, data is transferred asynchronously, via RabbitMQ or Kafka, so there can be some data loss in the case of large amounts of data.Both the main system and the intermediate system were developed in the Czech Republic, so I was officially on a foreign trip.Europeans attach great importance to sports and love to be close to nature, which is directly reflected in their working time arrangement: many people arrive at the company more than 7 am, or at the latest 8 am, because they can leave as long as they stay at the company for eight hours (including lunch break), and almost never work overtime.So most people get off work by mid-afternoon or mid-afternoon, and you can see the streets full of people running, cycling and playing sports.Other men choose to sunbathe on the lawn with their children (yes, yes, this is common in Europe).Some leaders go to bars in small groups for drinks, watch football games, and then go home to enjoy family time.But this is at odds with the hectic pace of work at home.Originally, there was a time difference of six or seven hours between China and Europe. The Chinese development team of app had been waiting all morning to have a meeting and discussion with The European side in the afternoon. However, they usually drink coffee after work to adjust their mood before starting the work schedule of the day.This brings great inconvenience to docking.To make matters worse, the Czech team takes planning very seriously, which means that any development is limited to the scope of the requirements document. At most, it is considered to be beyond the scope of the requirements document and needs to go through the process again.This is a serious departure from the Agile model of development, and while major changes are not recommended at the beginning of development, I think there is flexibility in dealing with small, easily changed points that are critical to the user experience.In this reconstruction, the data modeling of the master system and the optimization of the data transmission mode between systems are extremely important, even the core.If the upstream system is still a mess, then the downstream app does not matter how fancy.This is the key reason why I have come to the Czech Republic.In the face of this situation, the most important thing is to maintain good communication with the core people in each link.First of all, I and two major team’s project manager to do a few in-depth exchanges, and hopes the two sides in order to product smoothly launched on time the work of their team to make some adjustments, such as: China team to work some time late, and the Czech republic team to be more earlier, so make sure that the two teams overlap can be a little more time.Secondly, in view of the Czech team’s attitude towards documents, I organized tests and held test case analysis meetings after each requirement review meeting and before formal development. The testers often considered more carefully, and various extreme and boundary conditions could be supplemented in place.In this way, there are basically no loopholes in each document. As for some text and color adjustments, I will bypass the Czech project manager and directly find corresponding development colleagues to make modifications based on personal relationships.In addition, it is important to establish close personal relationships with key people in this project.After all, people are emotional creatures, and this works even in countries like Europe and America, where the rules are strictly enforced.For example, I would pay special attention to some local news and accompany them to the bar after work to have a drink and watch football matches, so as to actively integrate into the local life.As time goes by, the relationship between us becomes more harmonious, and there will always be someone to help you solve key problems.Subsequently, we also optimized the main system, such as replacing manual audit with intelligent audit and customizing the approval flow.These were complex features for the Czechs, but they were able to get them online on time, thanks to the seemingly unrelated efforts made on the above project.Because of the smooth communication, when faced with problems, we can work together to solve them, instead of repeatedly passing the buck to each other.One might ask, shouldn’t this be the scope of the project manager?In some companies or projects, this may be true, but in the author’s project, each project manager is only responsible for his or her own APP or system, and such cross-system communication and coordination is best accomplished by the product manager.In fact, project management has always been a qualified product manager should have an ability, because we are the ones who are ultimately responsible for the product, so any link in the product launch a hole, people should be duty-bound to fill up our products, and even development (some companies do have this kind of situation).The development of cross-country teams not only tests the language ability of a product manager, but more importantly, the understanding of different cultures, so as to find the most suitable way for team cooperation in the process of project coordination.I hope the above experience can give you some inspiration on how to cooperate with multinational teams.This article was originally published by @Dave. Everyone is a product manager, without permission