If you immerse yourself in work and don’t know how to report, let alone 996, even 007 will be useless!

The word is like the face, I am Brother Jun!

A survey found that 80% of programmers think that work reports are formalistic and boring, but I want to tell you that it is very important to do a good job report, which is directly related to whether you can grow quickly, get promoted and get a salary increase in this company. And I want to tell you something disturbing. Even if you work hard, the results will be very good, but if you can't report your performance, it won't be very good.

Thinking that as long as you work hard, get 996, 007, impress yourself, and get results, your boss will take the initiative to give you a salary increase and promotion. This is all wishful thinking.

why?

Because there are N people under your leadership, he may not know you very well, and there will always be information gaps~

Therefore, learning to report and taking the initiative to report is particularly important at work.

1. Three types of reports

a. Planning reports

It means you tell your leader what you are going to do, how long you will do it, to what extent you can do it, etc.

b. Progress report

In the process of work, if the progress falls behind, if there are delays or quality problems, timely reporting and timely resolution will make the leaders feel at ease and worry-free.

c. Results report

This is the most difficult thing and what leaders value most is that after completing an iteration or project, you have to summarize how much value your work has brought to the business and try to quantify it, how much your personal technical breadth and depth have improved, and how much your personal technical breadth and depth have improved. How much personal soft skills such as communication, collaboration and review and summary skills have been improved.

Therefore, there are at least these three types of reporting. Reporting itself is a science that must be paid attention to and learned.

2. The correct posture for the most difficult "results report"

In fact, it is not difficult to learn the method. Let’s talk about the results report in depth. We can think about it from the following four dimensions:

The first dimension is outcomes.

For example, if you are engaged in business development, you can summarize it from two perspectives: business development and technical optimization. For business development projects, it is natural to summarize them from the business dimension, such as the daily activity of a certain business user. For technical optimization solutions, it mainly depends on the value that the technical solution brings to the business. For example, the high availability solution reduces the number of business P1 failures from 3 to 0 times.

For another example, if you are an infrastructure development team, it is recommended to summarize the results from aspects such as system performance, availability, and cost; if the middleware system has been commercialized, it can also be summarized from aspects such as sales volume or traffic.

For departments such as operation and maintenance and testing, the results are recommended to be summarized in terms of quality, efficiency and cost.

The second dimension is data.

A relatively vague description such as "improved development efficiency" should be changed to a description using specific data such as "developing a function increased from 10 man-days to 2 man-days".

Many people will encounter a question when they first try. It seems that this matter cannot be described using data? What should we do at this time? In fact, in most situations, it's not that you really can't use data to describe it, but that you haven't collected data and haven't developed the habit of using data to explain it.

The third dimension is the technology itself.

For programmers, after completing a project, what technical improvements have been made, what new technologies have been learned, which technologies have a deeper or more comprehensive understanding, etc., can all be sorted out systematically in the summary.

The fourth dimension is self-growth and reflection.

In addition to focusing on technical improvement, you also need to focus on the growth of personal comprehensive capabilities, that is, the improvement of soft power, such as business understanding, project organization, communication, and work methods.

Finally, taking business understanding ability as an example, after completing a project, you can summarize it from the following perspective: What are the business adaptation scenarios? Who are the target users? What are the characteristics of the target users? What problem does the target user solve? What is the actual effect?

If you usually work with your head down and walk, then reporting means looking up at the sky. This is an important scene for communicating directly with the leader to get immediate feedback, clarifying and correcting goals, and quickly correcting/improving yourself. You should pay more attention to it.

The above is for your reference~

Finally, a special announcement. I recently had dinner and chatted with architects and technical directors of several medium-sized companies, and I summarized some of their underlying thinking and work methodologies that enabled them to grow so fast . I shared this topic once before, and the effect was very good. I'm going to start a live broadcast at 21 o'clock this Saturday night to have an in-depth chat with you.

I believe it will definitely broaden your horizons. You can take pictures of your colleagues on the beach without using so much. Please click "below" to make an appointment . You are also welcome to come to the live broadcast room with other questions. See you there~

Recommended popular articles from the past:

I have been working part-time for 15 years and working on my own for 3 years. I would like to share with you 8 top insights!
happy! Two readers come to report the good news!


For more exciting news, follow my official account and learn and grow together.

aea4de293d2fc373d6052e749b8bf91d.png

Guess you like

Origin blog.csdn.net/chengjun_java/article/details/132750094