Management and Improvement of Domain Knowledge
If we lack of domain knowledge, there will be greater risks that the functions we deliver will not meet user requirements. Many people overlook the effect of understanding customer business in doing a good project. These activities include research on user behavior in the field of this project, define typical user portraits and conduct user behavioral analysis, and then feedback on business analysis and testing to guide their work.
Build a knowledge-sharing system to bring out the power of collective wisdom. Because of a knowledge-sharing system, all knowledge such as the domain knowledge of the team can be opened to everyone, so that the knowledge level of the team can be maintained at a very high level. It is better to let users find what they want on their own. We can set up mail groups and concentrate important and intellectual mails in public places. Members who join later can easily find them on their own.
Continue to grow and establish a knowledge framework to achieve the goals of reducing delivery risks and costs. For key areas such as continuous integration, automated test methods/framework, and agile requirements management, standards should be established first. These are the core of team knowledge. We can effectively reuse the previously accumulated knowledge framework and form an effective teamwork, rather than relying on a limited number of top experts. I believe that it can also bring value to our customers while forming large-scale development and reducing inner team cost.
INTEGRATION OF DEVELOPMENT TEAM
The development plan designed for a customer is like this, 5-8 development teams will be arranged to work in parallel. Each of them is responsible for their own module development, and they need to frequently perform system integration and joint debugging. They hope to follow the operation idea of product integration. Each module forms its own functional team and implements the product manager responsibility system. Each product team is equipped with product manager, business analysts, test engineers, designers, and developers. Every member needs to be responsible for the overall success of the product. Each product team shall be highly cohesive and low-coupling at the organizational level. When considering the overall integration of the system, the independence of each team shall be ensured to avoid unnecessary horizontal communication.
Pay attention to observe customers’ safety regulations, many customers will ask everyone on offshore teams to sign a confidentiality agreement. We can’t disclose customer requirements in external forums and other places, nor can we post the code for discussion. The tools we use are also specified. In many cases, data cannot be stored on servers on the external network.
Effectiveness of Offshore Teams
When the size of the team develops to a certain extent, how to improve the effectiveness of the team will become increasingly important. We can consider from experience learning and from standardized work practice to ensure that mature results could be applied, and there will be no repeated invention of wheels.
Learn to expose problems, successful projects are the same, but failed projects are in different forms. The failure of one team guarantees that other teams will not follow the same path.
Use technical means to solve problems, for example, use virtualization tools, so that developers can get an environment anytime and anywhere, and then start working quickly.
Even in small teams, communication and getting along with team members is often difficult. However, in the world we live in, the communication of details within the team is an increasingly indispensable factor towards success. And those tools that can reduce the complexity of communication and assist in the development of more robust software are undoubtedly a huge boost for distributed teams. This is why technologies such as Docker deserve our in-depth understanding.
Learning from History and Facing the Future
Looking back at the processing enterprises which were characterized as “processing with materials, assembly with supplied parts, processing with supplied samples, and compensation trade" in the 1980s and 1990s, then we can foresee the future of outsourcing industry. Processing companies that had been settled in the status quo have already declined and vanished. Outsourcers will continually look for lower-cost contractors, some labor-intensive enterprises (such as Nike) have set their sights on Southeast Asia. Outsourcing must embark on the road to innovation, attempt process innovation, or find the soil to breed products. Of course, some OEMs now have their own brands.
Outsourcing companies are similar to the OEMs of that age. If you want to win the future, you also need to form your own core competitiveness. You must either nurture your own products or cultivate your unique ability.