We can define the working boundary of R&D efficiency team as (requirements management+task management+project management) platform +devops+APM+ application operation and maintenance, which is responsible for the whole process from user requirements to online and application operation and maintenance. Its existence is to break the situation that teams are divided into different parts, and at the same time, it can concentrate the needs of each team and make the whole development activity run smoothly and efficiently. Once the R&D efficiency team is with a certain team, there is no higher vision to think about it. If the business direction is well controlled, the business may go astray. A team with similar R&D efficiency will focus on the business of the team, the function of the service team will be well done, and the attention to the whole R&D process will be reduced, thus affecting the positioning and role of the R&D efficiency team.
I have seen the R&D efficiency team and the operation and maintenance team together. At the beginning, Aauto Quicker's operation and maintenance partner was also responsible for the construction of the assembly line. This is understandable, because the operation and maintenance partner is responsible for the company's infrastructure, and if the company's services want to operate and maintain the infrastructure online, it must have an online system. Stealing, operation and maintenance partners also made assembly lines, they only made assembly lines. The parts before the assembly line are not involved, because they have little to do with operation and maintenance, and are limited by manpower and material resources, and the operation and maintenance partners do not involve the parts before the assembly line. Compared with the machine operation and maintenance part, the production and research scene is more advanced, and the part involving product managers, project management, RD and QA students is much more difficult to streamline, standardize and automate. The advantages and disadvantages of this combination are obvious:
The R&D efficiency team is with the QA team, and I have seen this organizational structure. Later, the organizational structure was adjusted, and the R&D efficiency team and QA partners were together. If R&D efficiency and QA team work together, what they do and their influence are absolutely high, which is what I have seen1+1> The organizational structure of 2. It's a pity that the right time and place are occupied, but the effect is not ideal, which is a great pity.
According to my long-term observation, I think it is mainly the problem of employing people and positioning; This paper mainly talks about positioning. The combination of R&D efficiency and QA is actually to exert strength in two professional fields and then jointly produce greater results, instead of growing an R&D efficiency platform on the QA platform. The Aauto faster efficiency project has done a good job in this regard. The R&D efficiency team supports all the platform construction. Through the interface and internal QA automated test platform, their businesses can go at their own pace, and at the same time, they can cooperate, build and support each other at the function point of "combination".
R&D efficiency team and PMO team are together. I have also experienced this kind of organizational structure. PMO promotes the platform to the R&D efficiency team in the business line, bringing users' demands. R&D efficiency supports these users' demands and gives them support and help in their daily work. The key point of this model is that the R&D efficiency team should be directly linked with front-line personnel. Otherwise, the platform will easily become a project management platform in the end, which will meet the management demands of PMO partners to the greatest extent, rather than the demands of the small partners of the first-line Industry-University-Research team. The first-line team's work on that platform is unrealistic, not easy to use, and the experience is poor, all of which are imaginary needs of people who have never been a production and research team; The R&D efficiency team is also very frustrated. I have done everything you asked. In fact, the demands put forward by the platform are all "PMO" demands, and the pain points of "first-line actual users" have not been solved.
The opinions and suggestions of project management experts need to be valued and evaluated, and at the same time, the demands of front-line actual users cannot be ignored. Of course, there are also positive examples of cooperation for reference.
This table is a part of the work related to server R&D efficiency. As can be seen from the above table, each role pays attention to different R&D efficiency domains, and even in the same R&D efficiency domain, different roles pay different attention. Some companies think that the R&D efficiency and operation and maintenance team is both a "cost center" and a support team, so they put the R&D efficiency and operation and maintenance team together to form a huge "infrastructure", "basic platform" or "platform architecture" team. In fact, we should push the R&D efficiency team to its customers from the perspective of users. The operation and maintenance team is not the first user of R&D efficiency service. Our main users are product managers, project managers, RD and QA partners, but the operation and maintenance team supports the R&D efficiency team and has been dealing with each other frequently recently. We are just big customers of operation and maintenance resources.
Therefore, I am inclined to set up an independent R&D efficiency group and exercise its functions. If you have to be with other teams, then being with the R&D team is the second choice; It's just that RD partners are usually closed-loop to an independent team according to business lines/product lines, while the R&D efficiency team, as a public resource, is difficult to divide into a certain business line/product line. The fourth scheme is to form a large team with QA, which is conducive to the construction of quality assurance platform, and ultimately the research and development efficiency and operation and maintenance together.
However, the efficiency project in Aauto faster takes a different path. We divide the production and R&D of all the above-mentioned supporting platforms (including the construction of some operation and maintenance platforms) into one team to support them, which is equivalent to R&D efficiency +QA platform support+infrastructure platform+operation and maintenance platform (part), avoiding repeated construction and maximizing resource utilization. The final result and effect are also very good. Personally, I think that the scale of 1 000 people or less can adopt this organizational structure. /kloc-more than 0/000 people can refer to the content of my next article, mainly about the organizational structure and team building of an R&D efficiency team with about 2,000 people.