In the second R&D Performance Carnival held on May 29th, Sun Jijun from Zhejiang Future Hotel Network Technology Co., LTD brought “Future hotel — experience sharing of building efficient R&D team”. In this sharing, he introduced the scale of hotel r&d in the future, and explained the three characteristics of an efficient team, the cultivation of four abilities and the four methods in the process of team building. The following practical cases are from the One-stop R&D collaborative platform of Cloud Effect. Register for Cloud Effect immediately, experience the r&d speed and working mode of Alibaba, and Work Like Alibaba together. Please click PPT to download the wonderful video. Please click below to arrange the wonderful content:

Future hotel r&d scale

“Future Hotel” is a joint venture of Feizhu, Shiji and BTG. Our mission is to make it easy for hotels around the world to do business. Our mission is to empower small and medium-sized individual hotels with AI, big data and other technologies, so as to upgrade their check-in experience, hotel service capacity and business capacity. As the future hotel technology team, we did not grow from small to big growth process, faced with the challenge of large-scale development at the beginning, we spent 3 months to form a hundred-person RESEARCH and development team, completed the product technology system and project management system infrastructure. We can build a so fast efficient and mature team, a very important reason is that provide us with solutions based on ali cloud, let us have more focus on industry of SAAS product technology development, that today this would be, and share with you our is how to form a highly efficient research and development team.

At present, we support 18 product lines in total, and at the peak, we can develop more than 50 projects in parallel, and operate and maintain more than 70 applications online at the same time. The current r&d team size is more than 120 people.

Three characteristics

At the beginning of team building, we made some definitions of a team. We believed that an effective team should have three characteristics, and also made a lot of efforts to cultivate four abilities. Let me start with three features:

• Clarity: the team should have clear positioning and objectives. Clarity is the definition of work boundary, system boundary, responsibility and authority of the team. Clarity is also your technical path, your technical battle. It is also important to have clear process and results assessment principles, although not very specific, but we can define some principles and consensus. A team without goals, direction and consensus will not go far. This is also the process of focusing the team and making the team members reach a consensus.
• Unobstructed: is the internal communication of the team unobstructed? In the process of cooperation, is it difficult to know who should do this thing? Is there any kind of discooperation when doing something? Just as many cars want to reach the same place, honking the horn is enough when there are fewer cars, and more traffic signals and signs are needed when there are more cars. If there is not enough single lane, there will be more lanes. How to avoid frequent crashes with different destinations? A leader has the responsibility to build a smooth environment when the team makes many decisions. No matter for top, bottom or level, the most important thing is to feedback to you as soon as there is a problem. At the same time, there is a process of reaching a consensus. When the consensus is reached, can we carry it out in an organized and smooth way?
• Trust: it is very important for a team to build an environment of trust. Trust is different from trust. Trust is trust + dependence. Trust alone is not enough for a team. There must be complementarity between people, between people and teams, and between teams, so that they can work together based on trust. In our industry, there is a problem called “duplicate wheel”. Necessary duplicate wheel we should have, but inefficient duplicate wheel should be absolutely avoided. One is that you do not do well, and the other is that I think I do better, and the reason behind the problem is still mutual distrust. The atmosphere of the team should be simple and direct, without infighting. We must prevent any suspicion and negative things when we find them. Complaining about this stuff is like an infectious disease. If one person gets it, the group gets it, the whole team gets it. On the one hand, we need to find the problems behind the complaints in time and solve them; on the other hand, we need to improve the immunity of the whole team. We need to deal with those who are capable in time.

Four ability

An effective team should have four competencies, and these competencies should be team competencies not just individual competencies

• Quantification ability: Quantification ability is a necessary ability for every member of the team. Quantification ability has always been a topic of discussion in the development team, and it is a common understanding between the business side and the implementation side. Does your team have the situation that when communicating requirements, it can only evaluate the workload by looking at the code? Similarly, the ability to work to quantify, must be the ability to expand, the top architecture design each classmate business knowledge, technical ability, familiar with the system capacity is different, can lead to different results, that we could provide a way to let everybody to quantify the ability to work, let him in the process of the assessment.
• Adaptability: With the continuous development of business, we will always be in a changing environment, business will change, organizational structure will change, but the technical system can not always change. On the one hand, we should let the team know that change is a normal thing to adapt to; on the other hand, we should also let the team know the position of its own technology in the process of change, so as to cope with business changes with the invariable technology.
• Filling capacity: it is not only the filling capacity of the same position, but also the filling capacity of different positions, which can enable one developer to quickly follow up the progress of another. Behind this is whether we have clearly sorted out the structure, and what we need to overcome is the code barrier. Under a development framework, follow the same specification and turn the work of filling into familiarity with the business itself is what we want to do.
• Optimization ability: optimization ability refers to the team’s ability to self-renewal, we need to advocate a culture, the idea of any technology, project management idea and the idea of work there is profit, should be encouraged when we think so, after discussion, it will unswervingly to implement, could start with a small scale test, after mature again in large scale. If a team doesn’t have the ability to self optimization will be a backwater, of course, not all ideas are right, look behind it, or when we deal with the problem of wisdom, we must establish a mechanism to encourage people to participate, puts forward some constructive ideas, at the same time that can reach a consensus on the whole the continuous development of the team have greater benefits.

The four methods

We have four approaches to the whole team building process:

1. Three big pictures:

Every leader should have three big pictures in mind, namely business big picture, technology big picture and organization big picture. The big business map is to realize what kind of business value, what target, what strategy, what focal point; The big picture of the organization is the guarantee of the organization, talent and talent ability that we need to accomplish these business goals. The technology big map is the way to realize the business big map, including system structure, technology selection, route, boundary, platform and tool definition, etc. The technology big map should be forward-looking beyond the business big map, and can see the technology situation in the next 3 or 5 years. There are big works and small works, but when we grow from small to big, it is a logical extension of verification planning. If it is subversive, it shows that there is something wrong with our technical planning. The technical leader of each company should have these three big pictures, and at the same time, these three big pictures should be printed in the mind of each member of the core team, especially the technical picture, which is best to guide our technical choice when we have resolution conflicts. Is it business system, or business platform, tool building or technology middleware.

2. Define the development framework:

According to different development scenarios, there should be different definition of development framework. If the three big maps are the definition of architecture level, and the technology group is the definition of the relationship between systems, then the development framework is the definition of the relationship between codes in the system, and the relationship between people in the system in the organization of code coordination. You can define a complex relationship, you can define a very technical relationship, but I think you should define a more business relationship, the business logic and the code logic as closely as possible, which is a huge improvement in development efficiency. At the same time, the development framework should be sufficiently low coupling, and the business and code can be clearly mapped, which means that the development students can quickly transform the business logic into code relations, which is convenient for us to evaluate the workload, communicate and track problems. In the practical work, we designed a task responsibility framework, this framework is very simple, is the template pattern and cor pattern, code logic behind directly corresponds to the business system, module, function and the function, module is a directory structure, function is the task, subroutine is a duty, an execution of a function sequence function completes a logic function, Starting from a page or a scheduled task does not affect the business logic behind it.

3. Build a model

Combined with the previous three big pictures and development frameworks, we now have the foundation to build a data model and a process model, on which we can build a communication model. This model can be an Excel sheet or a system, and the functional decomposition sorted out by it is our corresponding system and the code to implement the system. This model is completely described by the business language, but there is a logical relationship with the technical code implementation behind, so that the development students can use the business language to communicate technology. How to build smooth communication is what we are going to discuss. I met a development framework, the description of the business is the business process flow, and development with a state machine, when the two sides of communication if take a state machine to communicate a business demands, the two sides had a deviation, efficiency is very low, because of problems at the same time the state machine implementation, produced a large number of mesh dependence between class and class, The system has developed to the point where it only dares to add code, not to modify it, and any change may affect other dependent code. Therefore, we should establish a communication model relationship between business logic and code logic, and at the same time, it should be implemented in a linear way as far as possible to avoid the dependence between codes. If there is common logic, we can abstract out the tool class, or even rewrite to avoid.

4. Enrich your tools

Tools are not auxiliary systems on the core link. Their purpose is to improve our efficiency. No matter in development, testing, product, operation or operation, tools are required. We should encourage rich tools, make tools systematic, and continue to invest, when the development team is less than 20 people, we should try to make tools, when more than 20 people we can have a platform way to land. Tool building must be considered as a whole, a development team should try to avoid the duplication of inefficient manufacturing tools, but we also encourage thoughtful and orderly tools, through the construction of planning growth to improve the efficiency of the entire development team. Of course, we can also define our tools differently from our roles, development, testing, production, operations, and project management processes.

Some think

A few final thoughts,

The first is: if a team is constantly refactoring the system, then I think there must be an architectural problem. Does your team have the same problem?

The second is: platformization sounds very lofty, but the actual operation must be careful!

The third is: does business complexity determine system complexity and code complexity? As a technical team Leader, we feel it is our responsibility to make our system complexity and code complexity independent of business complexity. That is to say, no matter how deep or complex the business is, the relationship between the code logic behind the business and the system should be relatively clear and linear. The fourth is: how do we balance technical and business goals in the team management process? When business needs are tight, how can we still move toward planning to achieve technical goals and some technical planning?

The original link