“This is the first day of my participation in the First Challenge 2022. For details: First Challenge 2022”

This paper is a text version of the author’s internal presentation on how the front-end team can better support projects and empower. The relevant company information and internal documents have been removed.

preface

The topic of this post is “How the Front End Team can better Support projects and empower”. First, let’s talk about why this post is being done, or where it is targeted.

First, I have been working in the company for two years. Except for the first half year, I participated in the research and development of standard products. Since then, I have mainly worked on projects.

Second, now there is a phenomenon on the retail home decoration BU, that is, when the new project comes, but often can not find the right front person in charge, so how to cultivate the front person in charge? The purpose of this sharing is to comprehensively introduce the main links of a project from the beginning to the end, as well as the focus of front-end work, so as to give some directions to the front-end students who are going to be or want to be front-end leaders.

The content to be shared this time will be broader and not too specific. For example, we can hold a special meeting to discuss our SOP. There are a lot of specific examples in the code specification; These will be shared in more detail later.

However, since the content is basically what we need to do in our daily work, we will not explain a lot of causes and consequences here, and will directly talk about the problem and the matter.

Project delivery methodology framework

When it comes to how to support a good project, we can first refer to our company’s project delivery methodology. Through the whole project cycle and what the whole delivery team needs to do, we can make some positioning for our front-end team and clarify what needs to be done.

Project initiation and blueprint planning

The two project cycles are roughly from project approval to the output of requirements documents. Since these two cycles are executed before the R&D work, they will be classified as the project initiation phase in this sharing. The front end students have three work priorities. The first is to participate in demand research; The second is the front-end man-nature assessment; The third is the construction of the front-end technology architecture.

System implementation and system on-line

Since these two cycles are mainly research and development, they are classified here as project research and development. In this, front-end students need to do a good job in task disassembly and allocation, as well as progress management and development according to the progress management.

The project acceptance

In this cycle, the front-end students will not only cooperate with the acceptance work, but also participate in the project review. Because the project review is very important for the continuous optimization of working methods, this sharing will take the review as a focus and directly summarize it into the project review stage.

Five sub-topics are introduced

Project start-up stage

What should we do at the start of the project to lay the foundation for the rest of the work.

Project DEVELOPMENT Stage

In the research and development stage, what should we do to ensure the smooth development of the project, on time delivery.

Project review stage

Here we talk about the significance of the project review, as well as the specific review method.

Code specification and quality

Focus on the front-end code specification and quality of the solution, as well as the current problems and solutions.

Fu can

Describe empowerment measures and how to organize empowerment to improve the overall capabilities of the front end team.

Project start-up stage

In the start-up stage of the project, there are three main events. The first is to participate in the demand survey. The second is the front-end man-nature assessment; A simple summary is the need to sort out the early needs, and do a good job of cost control; The second is the design and construction of the framework and infrastructure, how to do a good job in the technical architecture of the whole front end.

Needs research and man-nature assessment

Let’s first take a look at the demand survey and man-nature assessment. In fact, this part is mainly what the head of the front end should do, but the front end students can learn about it, because each student may be responsible for a project independently in the future.

Demand survey is the beginning of RESEARCH and development work. Front-end students need to cooperate with customers and product managers to conduct preliminary demand survey/assessment, analyze the feasibility of technical implementation, and lay a solid foundation for subsequent research and development work.

If you go to the customer site, you should know that we need to talk to the customer, talk to the product manager, sort out the needs. After the product manager outputs the corresponding requirements document and prototype, the technical students can be engaged in the development, otherwise there may be some loss of communication efficiency. For example, the product manager himself thinks that there is no problem with the requirements, but after the output of the prototype, the developer came to the developer, and the developer said that it could not be realized, which would waste time and affect the overall development efficiency.

Then, in addition to the needs survey, make a human nature assessment.

Man-day assessment is also a key part of the project, which is directly related to the profitability and delivery cycle of the project. We need to formulate a reasonable man-day assessment and make a reasonable front-end resource investment plan according to the demand, and finally achieve a win-win result for the company and customers.

That is to say, to estimate the front-end students to do these needs, how many people are needed, how many people need to invest, to ensure that our cost is reasonable, resources will not lack, nor waste.

However, everyone’s understanding is not quite the same, the product may be different. Let’s say there’s A requirement, A thinks this should be done, B thinks that should be done; A man-day assessment of A task, A thinks it needs one man-day, but B thinks it needs three man-days. At this time, it is necessary to have a standard workflow to guide and eliminate such differences. At present, SOP of demand research and SOP of man-nature assessment have been gradually improved.

The DEMAND survey SOP mainly includes the following contents:

  1. Types of demand research;
  2. Project background investigation;
  3. Preparation of presentation materials;
  4. Question preparation;
  5. What are the methods of demand research?
  6. Research to collect content;
  7. Skills of demand research;
  8. Frequently asked questions on demand research;
  9. The cause of the problem.

In addition, there are auxiliary forms containing some research plans and interview notes.

In fact, it will look more like the operation manual of the product manager, but the front end students will be more or less involved, so in order to ensure the overall delivery quality of the project, the standard process still needs to be emphasized.

The MAN-day assessment SOP mainly includes the following contents:

  1. The background, significance, methodology, applicable scenes and stages of man-nature assessment;
  2. Specific evaluation procedures and supporting forms.

Design and build of framework and infrastructure – front-end r&d process

Here to share a closed loop diagram of front-end R&D process, we can first look at each link of front-end R&D, what can be done, what should be done.

Such as:

  1. In the development preparation stage – are relevant specifications and technical documents prepared?
  2. Coding & joint investigation stage – whether the framework is set up; Whether the material library is complete, CLI, continuous integration, continuous delivery tools are complete; There are data Mock documents, Mock services, and so on;
  3. Debugging and optimization stage – including data burial point, performance testing, compliance testing and automated testing;
  4. Build deployment phase – includes build deployment, quick page setup capabilities;
  5. Finally, the stage of data collection and analysis after going online includes abnormal data monitoring, behavior data monitoring, performance analysis, data calculation and data visualization.

This flow chart may not be perfect, but in general, it gives us a good idea of how we can make better changes in the R&D process when we are benchmarking our daily work to a standard process.

Design and construction of framework and infrastructure – Implementation direction

A good front-end architecture is very important for the project, which is conducive to improving the scalability, maintainability, performance and development efficiency of front-end applications.

In our previous projects, we basically copied the standard project and changed it. In most cases, there was no problem, but sometimes the difference of project environment and products would be relatively large, so it could not be completely applicable.

At this time, the above closed-loop diagram of R&D process can be combined to consider whether the framework is reasonable and the infrastructure is perfect. For example, in a Great Wall Motor project I once participated in, Jenkins was not available to do the Web side release, so we wrote a set of scripting tools to optimize the release process. In addition, we added Taro UI to the material library to improve the development efficiency of small programs; Then, some attempts were made on data Mock to improve the efficiency of the front and back end. In fact, there are many points that can be thought of.

Summary of preliminary work

I have mentioned several key points of work in the start-up stage of the project. Here I summarize some abilities needed in the preliminary work, which require the combination of soft and hard skills to make the subsequent work smoother and easier to receive good results.

Soft skills include:

  • Teamwork ability – Whether within the team or with customers, smooth collaboration is conducive to work;
  • Empathy and perspective-taking ability – In the technical field, we tend to look at problems from the perspective of technology, while customers tend to look at problems from the perspective of business scenarios. If there is no perspective-taking, our communication with customers will be inefficient and even lead to some differences.
  • Forward-looking thinking – There are two problems in our project. One is that the requirements are frequently modified or even torn down and started from scratch. Another is that technology cannot adapt to the development of business, resulting in subsequent rework. This requires us to view demand and technology more from the perspective of development, take into account the possibilities and changes in the future, and make things more stable.

Hard skills include:

  • Solid professional skills on the job – ability to establish professionalism in front of customers, of course, this is a basic requirement for programmers.
  • Standardize workflows – If workflows are not standardized and uniform, there can be a lot of variance. There is an obvious example, we used to joke that the human nature of the project contract is very different from the human nature of our R & D evaluation, so can we do some actions of qi? Workflow standardization is one solution, and SOP of many processes are being improved gradually.
  • Iteration of working methods, upgrading of R&D capabilities – this is something we continue to do, and we will also talk about how to optimize working methods through review later; Research and development capabilities, such as front-end multi-terminal technology, back-end DDD, this road is also continuing to go.

Project DEVELOPMENT Stage

After the preliminary work is finished, we will enter the R&D stage. Next, we will talk about the main things to be done in the r&d stage of the project.

The first is task breakdown and assignment; The second is schedule management.

Task breakdown and assignment

Referring to the diagram above, after the requirements are prototyped, each function point needs to be broken down into front-end subtasks. The basic principle of splitting is divided into two types of page writing, interface or logic processing, and to maintain a certain degree of granularity, if the page is more complex, you can further split the popover, sub-module. We need to keep each task as single as possible, which will help us track the progress of the task later.

In terms of task allocation, the priority should be assigned according to ability, so that each person can do the task that ADAPTS to his ability, or the task will not be too difficult or easy for him to achieve.

Schedule management

In terms of progress management, a major action is to go through the above schedule every day to Review the start time, end time, progress, test progress and so on of each task, whether it is expected.

There are also some basic principles:

  • Follow up progress every day, today’s things tomorrow;
  • Do not strongly rely on upstream and downstream, the design draft is not out, can first write pages and interaction according to the prototype; Before the interface is out, you can Mock data by yourself;
  • Feedback when tasks are blocked.

Because tasks are scheduled according to the delivery schedule, try to ensure that each task can be completed on time, and if there is a blockage, it needs to be handled and supported in time.

On the other hand, if the schedule is not reasonable and the progress is not followed up, it may lead to delivery delay or even failure, so we need to strengthen the progress management.

Project review stage

When we deliver the project according to the plan and then the project is over, does it mean that the previous planning and execution are in the past and not helpful for the future work?

The answer is no.

We need to examine what we are doing well and what we are not doing well. Such as code specification and quality, whether there are many bugs, or even customer complaints; There are also things like how well you manage your progress, whether your assigned tasks are blocked, etc.

It also needs to be dealt with. The good aspects should be strengthened and commended, while the bad aspects should be improved and the working methods should be optimized iteratively.

For the project review process, the corresponding SOP has also been sorted out.

The basic contents of the project review SOP are as follows:

  1. The first is the significance of the review summary, that is why to do the review;
  2. The second is the method of the summary of the review, is the review of the time to follow the ideas, methods;
  3. The third is the organization of the conference;
  4. The fourth is the preparation of the summary of the review meeting.

Code specification and quality

Specification and quality of the code is also in the project has often talked about things, step back, if we didn’t do, like many defects, performance also not line, to cause a decline in the quality of the whole project, even will let customers for our professional, lose faith in our company, so want to focus on the code standard and quality.

Here are two sections, the first is some ideas for solving the problem; The second is the current problems and solutions.

Ideas for solving problems

Ancillary tools such as some lint tools configured on the project; Jenkins helped us standardize the deployment process, and lint double-checked; Jest, some testing tools, etc.

Specification documents are available on the company wiki and microdisk for our daily study and development constraints.

Code paradigms we emphasize what standard code looks like and use tools to generate standard and generic code; There are also some standard components and tool methods that can be deposited, which can be reused to further improve the code specification.

Code Review is a manual way to find problems. From my entry, Code Review was basically non-existent in the past, and now it has been done well.

From the priority of these methods, auxiliary tools will be given priority, because automatic or semi-automatic processing of tools will be easier and less effort, but tools are not omnipotent, so specification documents and code paradigms should also be strengthened.

The last level is Code Review. It is relatively laborious to find problems manually, so we hope that problems will not flow to Code Review as far as possible.

Current problems and solutions

Low awareness of Code Review

In fact, this is understandable. The awareness of code review has gone through a process. The solution is to cultivate the awareness of code review, make some emphasis, strengthen process management, for example, review permission is strictly limited, prohibit special ways to bypass.

Some projects may be 996 when they are busy, and the schedule is also very busy, so they may feel powerless to review the code. Therefore, we will implement 2+1 audit system, in which multiple people share the audit task, with an extra pair of eyes to find problems, and consider organizing code review afterwards.

Problems occur repeatedly and are difficult to eliminate. For example, the pursuit of frequent visual restoration without 0px error; Same method copy and paste everywhere…

This is also real, the same problem, the same person, changed again and again, so how do we deal with it? First of all, we should make good use of tools. Tools are more reliable than people for some common problems.

The second is to strengthen the standard publicity, that is, through some channels to repeatedly emphasize.

If there are still some relatively poor situation, it may be related to personal performance, but also affect the amount of project bonus.

The existing specifications are scattered and incomplete, which mainly means that our specification documents and auxiliary tools are not complete. The solution is to establish a perfect specification system, which will be discussed in detail in the enabling chapter later.

Continue to carry out

Without proper compliance, bugs can be like whac-a-Mole, where one Bug disappears and another pops up.

In fact, it is also a little like the bear above, tired of dealing with water leakage in various places, can not stop, so in the specification we need more emphasis, more implementation.

Fu can

Empowerment is often mentioned in team management, which is also applicable in technical management. In order to better improve team capabilities, we also need to take empowerment measures. This is mainly about organizational empowerment, but what is organizational empowerment? My understanding is to empower the team by decentralization to flatness.

There are two sections here. The first section is about enabling measures. The second is to introduce the biweekly technology sharing program.

Fu can measure

Establishment of normative system

The above “code specification and quality” also introduced about this thing, is our current specification document some scattered, no system, micro plate, put some also put some on the wiki, the author, nor is a unified, and many are aimed at a certain point to some set of rules, which is similar to a call “island effect”.

So what’s the problem? Development students may not find the direction in some places, how to write standard code. Even the Review students do not know whether a certain code is standard or not, which leads to our overall standard level cannot be improved.

Therefore, it is necessary to build a standard system from point, line, surface to body. If you pick up watermelon, you will not miss sesame seeds. In fact, the company is already doing this, and it is expected to be completed in the first half of this year.

Talent echelon construction

Here is mainly to the front – end person in charge, or technical backbone to do some requirements. In terms of projects, many things cannot be completed by one or two people. For example, Code Review cannot be done well by only one person. More capable and willing students are needed to get involved and have more eyes to find problems. For example, core module research and development also needs more technical backbone, so we need to grasp this training plan, ideally, when things come, there are competent people to do it well.

This will be gradually implemented in work. For example, some front-end students with excellent performance may be assigned to take charge of core modules, or they may be put in charge of the front-end of a project.

Encourage knowledge creation and open source technology

This is something that we do all the time, and I’ll emphasize it again here, or we’ll explore incentives and norms later. For example, we have been encouraging some precipitation and sharing in micro-disk or wiki, and the technology of open source may not go much further, but it will go further in the future. What are the benefits? Can precipitate technology, enhance internal and external influence, and is conducive to maintaining technological innovation.

Work efficiency improvement

This has a lot to do with our daily work. Now we mainly focus on improving the front-end infrastructure. For example, the low-code platform the company is promoting can save more time and effort for the front-end students’ development work. In addition, I have seen in several projects that front-end projects lack the ability of automatic construction and deployment. Every time we send a version, we have to type a package under each project and then drop it to the server one by one. Later, we made a script tool for package deployment and optimized the process.

There are plenty of examples. For example, it is possible to generate generic pages with simple configuration. Can you even be more intelligent, output design draft from the designer, on the key to generate the relevant code, currently speaking, the industry also has some practice and results.

Front-end work is from 0 to 1, and then to tool, engineering, and finally intelligent a development process, there are many points to improve efficiency, here is not a list, we will go to do more to identify, further improve the efficiency of the front-end.

Technology sharing, training

First, let’s talk about the current situation. At present, we still lack formal technology sharing and training at the front end. Maybe in a few months or half a year, the alumni of the production and research side will do sharing or training once. Starting from this year, we plan to do more technology sharing and training. At present, we have made a major plan, hoping to develop the habit of technology sharing in BU first, which will be introduced in detail in the next section.

In general, I hope we can keep the habit of learning upward and from each other, and have an atmosphere of being willing to learn and good at learning, so as to better enhance our technical ability and improve the team atmosphere.

Bi-weekly technology sharing program

Introduce the biweekly technology sharing plan and why it is necessary to do technology sharing. It has been mentioned in the last section. In this section, I will introduce the rough plan and its specific significance and make the plan more perfect later.

First of all, the sharing scope is for the front end students of retail and home decoration BU. The plan is to share once every two weeks. We will also check the enthusiasm of the front end students, so it may be more frequent.

Then what is the specific purpose and meaning of sharing?

For individuals, it will be conducive to the growth of technical ability. For example, if you have a technology and I have a technology, then there are two technologies after sharing, or the technology has been iterated and become better. There is also the ability to improve communication and expression, writing ability, confidence, after all, we programmers are a lot of time with the machine dialogue, but also need some interpersonal communication, public expression, writing ability is also helpful, so as to further enhance our confidence.

For the team, the collision of technologies can enrich the technical stack of the team, improve the research and development ability of the team, and then strengthen the communication within the team, which is conducive to the formation of a learning atmosphere, precipitation of team culture.

If you have any better suggestions can be put forward, we will consider adding them to the specific plan later.

Share a Sentence

And one last word,“We must both walk with our heads down and look up at the stars.”.

Sometimes we work very hard on projects. We keep our heads down, work overtime, and constantly move from one project to another. The technology seems to be the same.

At this point, we have a question, will the technology continue to make better progress? In fact, I used to have this question, so we need to look at the road, to know and follow the industry’s development direction, and strive to walk in the forefront.

The enabling measures mentioned above will gradually solve this problem, so that we can go more steadily and further on the road of technological growth, and I hope to witness these better changes with you.