Your SlideShare is downloading. ×
Make This in China
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Make This in China

256
views

Published on

Making good software with great offshore teams in China. Some key points to consider.

Making good software with great offshore teams in China. Some key points to consider.

Published in: Travel, Business

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
256
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
9
Comments
0
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • 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



  • Transcript

    • 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

    ×