Make This in China
You got to deﬁne, explain, and evolve a product - all with a team in
Good software products are hard to make. Its even harder to produce
good software with a distributed team in China.
Here are some key factors that can position you to greater chance of
Most important word when describing the product:
Assumption: The team will not know unless someone tells them.
You can tell them the program needs to add 2 + 2.
Don’t stop there: tell them what good will this addition do? Spark their
curiosity, bring their heads in the game
A better “WHAT?”
It should result in a better WHAT.
why? Because going from Reqts-> Design will result in a Requirement
explosion of up to 50 times of original requirements.
Who is ﬁlling these requirements gaps?
Two Way Decisions
Localized Decision Making
Derived requirements need localized decision making or else time will
Architecture and Design issues will come up - these need resolution
earlier in the game.
Unidirectional ﬂow of decisions will remove sense of collective
Allow for course correction and mistake forgiveness but dont prevent
local decision making.
Um, looks almost done.....
Clear and present
deﬁnition of done
Expectation setting for DONE.
Corollary is that if its NOT DONE - dont call it DONE.
Extra points for pointing out things that still remain.
Early issue identiﬁcation is rewarded.
DONT HIDE THE REALITY.
Are Unit Tests done
Are Integration Tests done.
Any non-functional testing done?
Any cross browser type testing done?
Less functionality but done functionality.
Impact of Chinese culture on success factors
Factors which contribute to Inter-group success.
1. is there knowledge sharing between the groups?
2. is there open communication between the groups?
3. do groups try to outdo each other or help each other succeed?
4. each group committed to objectives and success?
freedom to question
Chinese cultural factors:
1. centralization of authority
2. Directed style of management
3. Asking subordinates for opinion is uncommon
1. learning from superiors is common
2. questioning superiors is uncommon
how will you overcome this ? in software industry its less of a problem
but still a problem
direct impact on artifact reviews.
The path to clarity
Tolerance for ambiguity - high degrees of this factor may kill your
1. how will you make sure ambiguity is minimized
2. free ﬂow of information to remove ambiguity
3. speciﬁcations that have recurring ambiguity will tend to be ignored
how will you overcome this?
Level of outgroup trust
- treating ingroup/outgroup members dierently.
- knowledge sharing in outgroup less than ingroup
- real issue of trusting outgroup stakeholder commitments
- how will you break the us versus them mentality?
- blurring the boundaries of ingroup and outgroup helps
Concern for face:
Questions = Sign that you are stupid
- Need to reverse this mentality by example. ( i used to ask a lot of questions to outgroups.
gradually team got comfortable following my example).
- Asking for help is a sign of weakness.
- Substitute this fear/anxiety with Reciprocity principle: i will help you if you will help me.
- If you improve my product, I will help you improve yours
- Pronounced when dealing with Outgroup members
Cultural Impact on Intergroup Coordination in
Software Development in China: A Qualitative
Minghui Yuan Doug Vogel
City University of Hong Kong