1. Introduction

With the steady increase of the number of the team and members of the technical level enhances unceasingly, at the same time, the development of the business also puts forward higher requirements on team/individual, so also is trying to explore constantly in the direction of technology, “to move as a” is that we always adhere to the team concept, personal ability and weak and cannot decide the r&d efficiency level of the team, Only when everyone has the ability to think systematically can the team form an upward driving force of technology atmosphere and promote each member to have a higher pursuit of development technology. At present, our background team adopts Java technology stack. Although the technology is stable, the middleware tools used are always updated and iterated, with more and more new features and new use gestures. The background team needs to make a complete plan to adapt and dig.

To sum up, providing better and faster development support for the business, promoting the formation of a good team technical atmosphere, and the trend of technical development are all important reasons for driving us to do a good job in technology planning.

2. What is technology planning?

First of all, what is planning?

Planning, that meanspersonalororganizationA comprehensive and long-term development plan is designed to reflect on the overall, long-term and fundamental problems of the future and to design a complete set of future actionsplan.

Based on the three characteristics of programming that we can relate to technology, what aspects do we need to consider?

** Integrity: Technology planning must be a systematic thinking of the existing system, to get a comprehensive and overall improvement plan, not stay on some specific optimization points; ** For example, our background services are mainly domain services, and each domain service needs to be independently controlled for traffic/authorization. We are wondering whether we can access the unified gateway to control traffic and authorization, which requires overall consideration among architecture, domain, and system.

** Long-term: The general cycle of technical planning is in the quarter, half year or even year, which means that this thing is relatively long-term and stable and needs to be promoted continuously. ** When certain directions or solutions are determined, they need to be “operational” for a long time, such as the introduction of a new middleware tool, which follows the concept of feasibility -> use -> optimization, such as “version iteration”.

** Directionality: Technology planning needs to propose a long-term goal for a certain direction, and design a comprehensive development plan and action plan; ** Technical directions are often diverse, such as R&D efficiency, background architecture performance and other directions. Here, we need to prioritize. For example, if we need to carry a large amount of traffic in the next stage, we should increase the priority of architecture performance.

3. How to make a technical plan?

3.1 Preparations

There are new and old members of the team, with varying levels of development, and a different understanding of the overall architecture and process of r&d. Therefore, before making technical planning, we need to let everyone have a good understanding of the current background R&D architecture and system specifications. Taking the background business structure of our team as an example, the main application scenarios of the current business are quality education, organization and publicity, family sharing, etc., on campus/enterprises. The specific business structure is shown in the figure below.

At present according to the technology research and development of the three stages of development, the compilation & deployment, “line”, we combed the each stage involves the technical components/tools, during the development phase is divided into components/tools/middleware/business code & document specification/collaboration technology points, forming technology of panorama, facilitate everybody technology stack has a clear understanding of the background.

3.2 Technical Direction

According to our existing supporting business, department responsibilities, department resources and other actual conditions, it can be divided into six technical directions: business support/system architecture performance/technical atmosphere construction/RESEARCH and development quality/technical specification/RESEARCH and development efficiency. Each of these technical directions should consider the following:

Support direction: business support is always in the planning of the weight of technology, all are to provide business with better, faster, more efficient back-end services, need to take into account the direction of product planning support (new business/new product need technical requirements), third party project docking (data docking/project management), the whole development process optimization;

System architecture performance: service availability (SLA indicator) Service concurrency performance (QPS/TPS) Scalability (considering capacity expansion solution) Security (security architecture/data protection/audit) openness (interface/domain capability) operation and maintenance (troubleshooting /FAQ support);

Research and development efficiency direction: here is mainly to write less repetitive code, can share the part extracted, will repeat the coding time on the framework understanding; Focus on business tool optimization, CBB common component building, new tools/frameworks/languages, etc.

Quality direction: Quality is the life of a product, mainly considering unit test coverage, automated test tools, how to improve test efficiency, pressure testing, etc.

Specification: mainly in order to improve the whole team, from the development, documentation, operations and so on in the process of extracting a set of standard of conduct, similar to the manual of ali development, this is very important in our team, avoids repeatedly hit the pit, and the team’s technology accumulation, and best practices and standards;

Technical atmosphere construction: it is mainly to let everyone build a learning and growing technical atmosphere, so that members have a higher pursuit of technology, efficiency and quality.

3.3 the target

3.2.1 Target Source

Technical planning targets are mainly derived from product planning and industry benchmarks. for example, in the second half of the product planning, 50W should be added, daily activity should be 100W +, QPS should be 3000+, equipment daily activity should be 6W +, instantaneous peak should be 10W +QPS and other performance indicators should be supported, as well as new business scenarios. If expanding business scenarios in other industries, consider whether the organization needs to build basic information in the middle office. At present, it is difficult to do industry benchmarking, especially for our 2B business, mainly considering that the product and business form is very different, and it is not meaningful to compare the indicators simply.

3.2.2 Goal setting

Technical goals should be set according to SMART principle (i.e., Specific, Measurable and Attainable) and must be Relevant to other goals with time-based deadlines. For example, if we set a goal of “improving system availability”, which is obviously not in line with the standard, we can change it to “H2(second half)-Q3(third quarter)- July (month) equipment area service XXXX interface availability to be more than 99.9% (currently 99.5%)”.

3.4 Objective Decomposition

Breaking each big goal into smaller ones helps analyze the rationality of the goal. The more specific the goal decomposition is, the higher the achievable rate of the goal is. Goals can be decomposed into monthly technical planning goals and put into individual/team goal management. Where there is a goal, there is an output. The minimum output granularity should be a working system or a structured document.

3.5 Key Actions

This is goal-related, and each of the key actions is geared around achieving the technical goals, and the key actions are related to the individual’s weekly/daily work plan. Key actions also emphasize output summary, should grasp the rhythm.

3.6 Technical Planning and Management Document Template

We use simple documents for management around objectives/objectives breakdown/key actions/responsible persons, as shown in the table below, where the items are taken as an example of the direction of improving the performance of the system architecture.

Planning direction

The target

Target decomposition

The key action


Those responsible

System Architecture Performance

H2-q3 (second half Q3 target): Improve the QPS of xx services to XXX +

Q3-M7(Target in July): THE QPS of interface A of XXX field service reaches XXX +

Q3-m8: The QPS of interface B of XXX domain service reaches XXX +

Q3-M7-W1(first week in July): Build the pressure testing environment and conduct the pressure testing;

Q3-m7-w2: Optimize the QPS of interface A to XXX according to the pressure test results


4. Precautions

4.1 Team Consensus

In order to act in concert and landing forcefully, it is very important to reach a consensus of all members. It will take at least two weeks from the first version of the technical plan to the final action, during which we will hold many discussions or meetings, and consider each goal in each direction repeatedly in combination with the suggestions and ideas of different collaborators such as business, product, project management, front end and hardware. At the end, there is a “closing” ceremony, like the start of the project, to let everyone understand the importance of the project.

4.2 Check Mechanism

Our background has been established for almost three years, and the technical planning has been done for two years, but the actual landing effect is quite good. It is concluded that a strong inspection mechanism is needed. Usually, we will appoint two team members as “supervisors” of the technical planning landing.

1. On Every Saturday, the supervisor will send screenshots and links of progress in the group and @ them to everyone.

2. On the 14th and 29th of each month, the supervisor will send screenshots and links of progress in the group and @ each person.

3. On 15th and 30th of each month, the supervisor will hold an appointment meeting room to make a summary and invite everyone to attend.

5. Summary

This paper is mainly about recent summary in the team to do technical planning process, this paper expounds the importance of the team’s technical planning, in view of the technical planning of the key action, direction, target, the target decomposition, as well as the matters needing attention in the process of planning to the ground, check mechanism and other issues, to show you some of our practical experience, hope everybody can bring certain inspiration in the technology plan.