Hiiiiiii!!!!!! I’m @kakeyang.
I feel that weather in Hanoi is getting like summer, however, it’s chilly today. What on earth is it??

This photo shows landscape from our office. We can see horizon because few tall buildings are around here.
And there are lots of developing area in Hanoi.

In this article, I will list up anti-practices of offshore development project.
I think they are all obvious ones 😀

I listed up some anti-practices but these mean totally that we have to estimate load in Japanese side.

Entrust progress management completely

We never do it. We can’t do it even if offshore development team assigns project leader.
This is because awareness of schedule is quite different between Vietnam and Japan.

Assumed results

• Schedule can be delayed before you notice.
• We can find several problems if we ask deeply despite that they said ‘no problem’.

Solutions

• All of outputs (such as documents and source code) should be ‘monitored’ from fixed view point everyday with setting the date of review and delivery. You can manage by tickets.

Start coding before document review

We must not neglect to confirm whether we could share recognition through document review even if we’re in the situation that we want to start coding due to not enough date.

Assumed results

• Things that are totally different from requirements are implemented.

Solutions

• We should fix design documents after review and confirmation that we don’t have any recognition differences. Test cases too.
• We should start coding after fixing design documents.
• If there may be affect to schedule, we should reconsider of scopes and assignee or adjust deadline.

Make developer team to collateralize quality of all outputs

About design of software and DB, documents and source code. It’s hard to make foreign people to understand the level of quality. Check them all.

Assumed results

• They will design that is not considered of maintainability and scalability although it works following specification.
• We may have to discuss the case that we re-develop in Japan because of terrible maintainability.

Solutions

• We must review all outputs. We must check all ‘characters’ of documents. Because recognition differences can occur unexpectedly.
• Source code too. We must review all source code files. I recommend you review source code with GitHub when pull request.
• We must explain intent of specification.

Define outputs and goal loosely

We have to assume that events we didn’t expect at all can happen. Define goal clearly and complete project up to goal.

Assumed results

• Source code that all bugs have NOT been fixed is delivered.

Solutions

• You should throw off the Japanese “common sense”.

Don’t be careless that outputs quality should be so so because we’ve reviewed all documents and source code. Put “common sense” in Japan that source code should be tested totally and bugs through testing should be fixed perfectly. This example can happen.

What we have to know if you choose offshore development

• That the Japanese believe that they are “common sense” is not always a “common sense” for them too.
• Only the things written in documents can be implemented. We have to make documents without leakage and consistent by writing all of things we can define in that time without leakage and review them deeply. (If we don’t do that, things with misunderstanding can be implemented.)
• We have to understand that our instruction was not optimum in case that efficiency of members doesn’t improve or things that we don’t assume at all are output.

… so it’s very hard to advance offshore development 😀

日本語の記事はセプテーニエンジニアブログを御覧ください。

I plan to write an article next about continuous integration (CI) with precondition of TDD in order to improve quality in offshore development.