Nihon (as the Japanese call their country) still remains mysterious and unusual in the eyes of foreigners. Outside its borders, many national stereotypes are widespread, including, for example, the famous Japanese quality and efficiency of labor. We also know that the Japanese are very responsible and sometimes die from overwork. Against this background (as well as the endless comparisons of "ours with yours"), one might get the impression that Japan is the abode of productivity and someone, and these guys know a lot about development processes. Is it so? Let's look at the example of our project, where the customer was a traditional large Japanese company.
Introduction
Our team faced the difficult task of adapting the existing PoS solution for the Japanese market and making it cross-platform, while minimizing deviations from the existing solution. We can say that on the one hand we got carte blanche to change the product, but at the same time we were seriously limited by the existing code base. We were entrusted with changing the core functions, and the development was carried out according to a waterfall model. Work on the project took 3 years, during which we dealt with gigabytes of lines of code, made dozens of business trips from Tokyo to Kazan and back, and managed to work with three hundred participants from both the customer and related contractors from Japan, Russia and the Philippines.
Of course, in order to fully judge the specifics of working with the Japanese, one project is not enough - after all, a lot depends on its specifics and the type of company. But, taking into account my impressions and accumulated experience - both my own and my fellow Japanese scholars, today I will try to tell you point by point about the very features that we encountered when working with our Japanese colleagues, and what lessons we learned and what have learned.
Working in Excel
The very thing that caused the pain. Microsoft Excel in Japanese companies is used for everything: documentation of very different details (even if there are only UML diagrams), a collection of screenshots with bugs, and, of course, endless report fields, from the cells of which megapixel matrices could be added. For our managers, Excel simply could not stand such suffering and refused to work. By the way, sometimes this obsession takes on bizarre forms . If for reports this format is even more or less familiar, then for development documentation it is exotic, to put it mildly.
Too long rallies
Basically, our Japanese colleagues are very responsible: they understand all the consequences of their decisions, and therefore cannot make these decisions for a long time. They also love rallies. And if for a Western person a rally is a way to solve problems and report back, for the Japanese it is also an opportunity to agree on their decision with colleagues, reducing their own burden of responsibility.
And even if it ended in nothing, its duration was usually directly proportional to the volume of tickets that were on our board. And since testing was on the Japanese side, there were enough tickets. Imagine how much we programmers love to go into details, and multiply that by the Japanese factor. You will receive hours of detailed technical issues accompanied by an interpreter. And adding to this the translation from Japanese into English, and sometimes comments in Japanese and Russian, when the opposing side is waiting for their turn, we get a record of 8 hours .
When I became a team lead, this did not suit me - and I tried to reduce the percentage of translations that often confused the focus in the direction of communication in English, and also tried not to succumb to the temptation to go into details. In general, this helped to cut the average meeting time by about half - as well as the number of bugs and the amount of work.
The language barrier
Japan is a self-sufficient country, and the level of emigration there is relatively low. Therefore, the very English language that we hoped for is not very popular there: an interlocutor with an A2 level is the maximum we could count on. Remember, if you are starting a project with Japanese, then you cannot do without a translator ! From the very beginning of the project, we had a person without whom our interaction with the Japanese would have been simply impossible - a Japanese-speaking project coordinator, who was responsible for conducting negotiations and key correspondence. In addition to him, several translators participated in the translation of documents, letters, and tickets and in the negotiations.
The difficulties associated with the language barrier remained until the end of the project - but in such situations, a lot of confidence and perseverance on our part helped. We understood that despite the different languages, we had a single goal.
Reports anytime, anywhere
Our project was carried out on a waterfall development model, and the abundance of reporting and constant updating of schedules was partly due to this. This is not to say that the abundance of reporting is a purely Japanese feature. But if we compare a similar project in Russia and the CIS with Japan, then the Far Eastern flavor is manifested in all its glory. As a team lead, I had to fully deal with all types of reporting documents both as a reader and an author - with the exception, perhaps, of financial ones: in terms of quality with an analysis of the causes of bugs, in terms of progress, extraordinary technical, and, of course, traditional for waterfall schedules. Each of these reports was a weighty Excel file lined with tables in the best traditions of nursing home scanwords .
In the course of continuous communication at the long winter rallies, understanding began to spread first to the management, and then to the team. We came to understand the main differences from this kind of reporting in a similar Russian project - they were not made for show, but contained relevant indicators of the project's status and were the object of close attention and analysis (and often corrections) of our Japanese colleagues.
Japanese Style Schedule
Nevertheless, they had both meaning and even a good purpose: for example, a quality report shows problem areas, when compiling it, you can get to the bottom of the problem, and a progress report helped track the amount of work completed to date. By the way, the second one over time acquired more and more new columns, and it could take up to three hours for the manager to fill it out 2 times a week, and sometimes more often. With the schedules, it turned out even more difficult: initially I tried to programmatically take tickets from the task tracker along with estimates and put them on the schedule in MS Project, but it turned out to be very capricious, and the schedules constantly flew and changed. Desperate, I quickly threw in the construction of schedules - in Excel, of course.
Difference in time
We work according to Moscow time, and the difference with Japan is 6 o'clock. When I was on a business trip, such a time difference was a little depressing: you are used to the fact that during the working day, someone close to you will write to you in messengers, then when I started work, it was still 3 a.m. in Russia ... But the biggest inconvenience was during communication with the customer.
Working with Western colleagues, you seem to be playing ahead of the curve all the time: you start working before them and you can calmly tune in to a working mood, clean up yesterday's mail and prepare for rallies. But no - imagine yourself in the place of the Japanese. You find a critical bug that needs to be fixed urgently, while the developers are still sleeping. Even if you understand that they will try and continue to fix the bug after the end of your working day, but the feeling of eternal lateness will increase in proportion to the urgency of the bug. Fortunately, our coordinator works in Vladivostok, which is 1 hour ahead of Japan. This was very helpful, since he heroically took the brunt of his indignation upon himself and damped the feelings of the Japanese a little.
Nevertheless, recalling the very propensity of the Japanese to overwork, for us, as developers, acceptance testing periods were usually a source of constant stress for the whole working day: you come to work guilty for bugs and "late" and leave, too, partly guilty for not you manage to fix it "today". However, over time, we got used to this mode, and at the same time, for more effective communication and localization of bugs, our teams of Japanese testers and our developers moved their work schedules closer to each other.
Focus on quality
The methodology we have worked with involves multi-layered testing phases. First, testing at the development level, and then a few more phases on the customer's side. Perfectionism is a double-edged thing: such conditions often eat up all the time set in the phase according to the first Parkinson's law, but at the same time, their meticulousness and scrupulousness were aimed at the little that united us - the quality of the final product.
If many processes and redundant routines seemed meaningless to us, then caring about the quality of the code and, as a result, the product is what we found a common language in. At different times, the entire code was run against two static analyzers. The client allocated time to fix the problems found, which is not such a common practice in agile / western projects. In addition, we covered all new and changed code with tests. It did not always work out completely, therefore, in order to save time and efficiency, the main emphasis in the active phase of the project bugfix was on integration tests. By the way, one of our deliverables was the test run and code coverage report - such concern for quality resonated in our hearts, and we most often found compromises in this area.
Also, as an improvement in the quality of the code, we offered the Japanese the practice of conducting up to 4 reviews from different people, including the team lead, depending on the complexity of the ticket. As a result, this prompted me to explore the possibilities of automatic code pre-review in GitLab. I could not apply all this on the project, but I wrote a small template for future projects. In addition to strengthening the review, we have achieved success in improving automated testing (unit, integration, smoke).
Performance metrics (KS)
Metrics were introduced on the project, including the number of lines (KS) of the written code. This has been the subject of intense controversy and discussion throughout development. This metric was used to track progress, estimate bug density, and serve as the basis for the expected number of tests, documentation pages, and review times.
The number of lines of code was also used to calculate programmer productivity.
A lot of problems with this method immediately come to mind: the UI code is much more voluminous, but contains less complexity, and the other 10 lines of code can be obtained at the cost of persistent brain activity for several days. We tried to start evaluating the work in the number of use cases, but there were no dedicated analysts, and the competencies of the developers were not enough. Towards the middle of the project, a previous team lead suggested using the number of methods as a metric for volume. As a result, we began to count both KS and the number of methods.
As time went on, the confusion became even greater: I decided to use historical data on actual time spent and actual volume produced to find coefficients that would translate labor hours into volume estimates. Since, in addition to writing, we were accompanied by a huge number of process tasks, testing phases, reviews and documentation, such a calculator was very useful to us.
Estimates and deadlines
In Japan, there is a practice of pushing the developer to lower estimates and, accordingly, deadlines, and then pushing on the feeling of guilt (“ you yourself said so ”) so that the “culprit” would rework, trying to meet the deadlines. In our situation, it sometimes resembled bargaining for deadlines. We made sure that 2-3 additional developers would not speed up the work on the problem - but on the other side, the wires stood their ground. With varying degrees of success, we heroically defended the deadlines, and on the eve of especially critical deadlines we made a compromise, which usually consisted of overhauls and, less often, attracting additional resources. However, we have often successfully failed these deadlines.
Over time, it was decided to automate this phenomenon as well. I took tickets as a basis, added the necessary reviews, possible bugs and ... I tried to pull this in MS Project. Unfortunately, from time to time he showed a different order of tasks and in an unknown way set constraints. There was not much time, so I decided to quickly make the construction of Gantt charts in Excel - since it turned out to be more predictable and obedient. Thus, we could easily change estimates - along with them, the completion dates also changed. It became much easier to rebuild the schedules, the customer liked them. Although this did not solve the problem of failing deadlines, we could warn the customer in advance about the time shift.
Traditions
When I went on a business trip to Japan with seven people, we were ordered to observe the dress code traditional for Japanese offices: a business suit, a light shirt and a tie. Of course, for programmers who are used to wearing hoodies in everyday life, this was a real challenge. Nevertheless, time played a role, and there was a sense of belonging (you can call it herd instinct ), which added energy and even made in some way "ours". The picture was entertaining: at Shinagawa Station in Tokyo, there are a large number of offices of large traditional Japanese companies, where every morning thousands of white collars flocked from all over the capital and the suburbs. The spectacle is fantastic!
Photo source
Usually our working day began at 9 o'clock, although some Japanese colleagues came up later. For lunch, we lined up with the same office workers in line at our favorite ramen shop not far from the place of work. I can't get around the topic of queues in Japan - it's just complete relaxation, because no one will ever climb ahead of the queue without a vital necessity. And in the metro there are special places for queues, and no one ever breaks the rules for building queues, and this is great.
By the evening, the work in our office was just accelerating. In our office, the working day ended at 18:00, but almost none of the Japanese were going to leave. But at the same time, they also love to relieve stress with sake and more.after work - and they do it quite often. And even though we had some contradictions at work, outside of working hours in an informal setting, our colleagues turned out to be sincere interlocutors.
In traditional Japanese companies, the Japanese maintain a strict chain of command in their relationship with their superiors. It seems to me that this is one of the current key differences between the developers of Japan and Russia. When problems arise, the Japanese almost never blame the direct performers, but are more inclined to blame the management, and on both sides. The higher the rank, the greater the responsibility and the higher the cost of failure. Everything is according to the rules: the greater the strength, the greater the responsibility .
Client is god
Japan is distinguished by its special attitude towards the client. And our Japanese customer probably expected the same attitude from us.
There is indeed a saying in Japanese: "O-kyaku-sama-wa kamisama des" (The client is a god) - and it really hits the mark. If we look at the relationship between the customer and the contractor in Russia, then the contrast with Japan will be very noticeable. Throughout my life in Russia, polite communication with the performers did not promise anything good to the customer - on the contrary, the more scandal and rudeness with those who provide you with service (couriers, waiters, repairmen, etc.), the more the best result is guaranteed. In Japan, according to my observations, you can be calm. Yes, the service is expensive, but it is guaranteed to satisfy the customer. It's a matter of taste, but I like this way - to remain polite and not worry about quality.
Conclusion
Despite the disagreements and difficulties, we coped with the work with the Japanese customer and his technical team. Some features turned out to be difficult and unpleasant for us, while others deserved respect and brought us closer together. We had to come to terms with something or even wait until the time and teamwork did their thing, somewhere it turned out to find a compromise, and somewhere - a workaround.
Is it fair to say that most of the stereotypes about Japanese people at work are correct? Everything is not so simple.
The subordination between superiors and subordinates is indeed felt more strongly in Japan, but recently, young people are increasingly breaking the system. Recycling is common, but there are more holidays in Japan than in Russia. There are hyperresponsible people who are inclined to meet the deadline at all costs, always and everywhere - and this does not depend on the country or mentality at all. The longer we worked with our colleagues from Japan, the less the differences were noticeable and the more similarities were found. The unique history and culture cannot but reflect on the national character and traditions, but nevertheless, there was much more in common. And I am grateful for this experience!