Making Software in China
•Download as KEY, PDF•
1 like•226 views
Key points to consider when creating software in China with cross cultural teams.
Recommended
Recommended
More Related Content
Recently uploaded
Recently uploaded (20)
Featured
Featured (20)
Making Software in China
- 1. Make This in China Thursday, March 26, 2009
- 2. Make This in China Thursday, March 26, 2009
- 3. Make This in China Thursday, March 26, 2009
- 4. Make This in China Thursday, March 26, 2009
- 5. Most important word when describing the product: WHY? Thursday, March 26, 2009
- 6. Expected Result: A better “WHAT?” Thursday, March 26, 2009
- 7. Two Way Decisions Global Vision but Localized Decision Making Thursday, March 26, 2009
- 8. Um, looks almost done..... Clear and present definition of done Thursday, March 26, 2009
- 9. Impact of Chinese culture on success factors Knowledge sharing Communication Mutual support Stakeholder commitment Thursday, March 26, 2009
- 10. Power Distance: The perceived freedom to question superiors Thursday, March 26, 2009
- 11. Uncer tainty Avoidance: The path to clarity Thursday, March 26, 2009
- 12. Individualism/Collectivism: Level of outgroup trust Thursday, March 26, 2009
- 13. Concern for face: Reviews Clarifications Thursday, March 26, 2009
- 14. Reference Cultural Impact on Intergroup Coordination in Software Development in China: A Qualitative Analysis by Minghui Yuan & Doug Vogel City University of Hong Kong 2006 Thursday, March 26, 2009
Editor's Notes
- You got to define, explain, and evolve a product - all with a team in China. 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 success.
- You got to define, explain, and evolve a product - all with a team in China. 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 success.
- You got to define, explain, and evolve a product - all with a team in China. 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 success.
- 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
- 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 filling these requirements gaps?
- Derived requirements need localized decision making or else time will be lost. Architecture and Design issues will come up - these need resolution earlier in the game. Unidirectional flow of decisions will remove sense of collective ownership. Allow for course correction and mistake forgiveness but dont prevent local decision making.
- 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 identification 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.
- 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?
- Chinese cultural factors: 1. centralization of authority 2. Directed style of management 3. Asking subordinates for opinion is uncommon ---> impact 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.
- Tolerance for ambiguity - high degrees of this factor may kill your product. 1. how will you make sure ambiguity is minimized 2. free flow of information to remove ambiguity 3. specifications that have recurring ambiguity will tend to be ignored how will you overcome this?
- - treating ingroup/outgroup members differently. - 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
- 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