Table of Contents
Hitoshi Goto
Ukihiko Takagi
In the previous article, we covered how to work effectively with overseas vendors. This time, we will look at key points when ordering from overseas vendors.
Some Overseas Vendors Are Reluctant to Acknowledge Bugs
In Japan, fewer companies seem to conduct source code reviews (walkthroughs), but conducting these early in the development process helps identify programmer habits and compliance with standards, so source code reviews remain valuable for improving program quality.
However, it is worth knowing that overseas, this culture may not exist, and some vendors do not acknowledge bugs identified during source code reviews.
Here is a story from when we asked an overseas company to do customization development for a project. When we conducted a source code review and pointed out an obvious bug, they would not acknowledge it and demanded we provide evidence.
With no other choice, we created test data that would trigger the bug and submitted a test report, and they finally accepted it.
I have heard that similar vendors exist beyond just this company.
It is best to clearly specify at the contract stage what reviews will be conducted and who will respond to defects found in those reviews and how (in Japan, even after the contract, specifying this in the project plan and adjusting would be fine).
However, even at the same company, when the bridge SE (an engineer who coordinates between you and the overseas vendor) is competent, they addressed bugs found in source code reviews, so ultimately building a solid structure is important.
Simplifying Screen Design to Prevent Misunderstandings
Looking at overseas applications including Oracle EBS (e-Business Suite, a general-purpose integrated package for core business operations by Oracle Corporation), screen designs make good use of tab-based screen switching, with processing content on each screen organized simply.
This is partly to ensure maintainability, but there is also the thinking that designing complex screens from the start leads to rework when specifications are miscommunicated. There may also be the idea that spending time building difficult things results in opportunity cost.
*Oracle EBS is a registered trademark of Oracle Corporation and its subsidiaries and affiliates in the United States and other countries.
The same is true for business applications we support in development – overseas development vendors tend to request simple screens. This is likely because they can build them without mistakes and with less rework.
In fact, if you design screens with the craftsman-like operability common in Japanese business applications, overseas vendor developers will say they cannot understand the specifications themselves.
In summary, when ordering development from overseas vendors, the secret to success is to aim for simple screen designs that are self-explanatory and leave no room for specification miscommunication.
Not only should the screens themselves be simple, but the content to be implemented should also be communicated simply without misunderstanding.
In that case, Japanese tends to become ambiguous or abstract. Even when we Japanese think we are writing logically, from a foreigner’s perspective it apparently looks like an emotional way of specifying that leaves things to the implementer’s discretion.
Therefore, the trick is to write in English from the start, and moreover, to write concisely in bullet points.
<< Read Part 16 of the Series | Read Part 18 of the Series >>
