The project manager asked: Why is it because I am always working overtime?

Original article, if reproduced, please indicate the source: http://blog.csdn.net/yihui823/article/details/6769887

Symptom

I recently chatted with a project manager. This PM was a technical master before, and he had nothing to worry about. He was also conscientious and desperate to do things. There is no reason for the leader not to promote such a cool man. So, this project makes this buddy PM.

Chatting and chatting, the cool man made a sigh of relief. The current employee is not easy to bring. Every day at, only me and another group leader are left. More than 10 people in the project team are running well.

I'm happy. In fact, I also met this situation. The first project I brought was similar. I did not dare to make an arbitrary decision, so I chatted with him a few more words.

Q: What time do you get off work?

A: Every day after.

Q: Is the task heavy?

A: Actually, it is not heavy.

Q: Do you have not assigned tasks to those who have left?

A: No.

Q: Why can't I schedule tasks for them?

A: They are not sure.

Q: Why?

A: I don't know either. I tried to assign a task to them, but in the end, I and XXX (another group leader) had the problem.

I don't need to ask more questions later, which is probably my estimation.

I call this situation:Baggage mounting.

Analysis

Why is it a burden? We can describe this.

Every project is actually a huge burden. A company has a lot of burdens, big and small. Every burden is properly and completely unlocked, and there is profit in it. However, if the burden is not resolved correctly, it will reduce profits or even damage profits.

Then, each baggage is handed over to a project manager. The Project Manager leads a group of brothers and is responsible for reasonably solving this burden. The burden can be broken down. That is to say, the burden can be divided into large and small sub-packages. How to Solve the sub-burden is also the work of each project team member.

For a project manager, the most important task is how to reasonably break down a large burden into a small burden, and then assign it to the project team members for solutions, in addition, it is necessary to monitor the release of small baggage at any time. Once a small baggage is found to be unfeasible, immediately intervene. If a large baggage is found to be unreasonably decomposed, it must be corrected as soon as possible.

Is the most important task for a project manager, to solve the burden on his/her own sleeves?

The answer is easy to say, of course not. However, it is easy for people who do PM for the first time to enter this trap.

Example

Let's take an example.

Project Manager:

A, you do ### 1 module; B, you do ### 2 module; C, you do ### 3 module. The most difficult ### 4 module and framework I will do. 5 days is required.

Okay, it seems quite reasonable that three ABC engineers went to work.

A is smarter. He finished 50% on the first day and left after work. The next day, I finished my work and left after work. Then I had a three-day tour and waited for the final time to show my performance.

B worked very hard, but the ### 2 module was quite troublesome. B finished 50% on the first day and worked overtime. I encountered a problem the next day and I was not sure about it. So I asked Jia for help. A had no choice but to help B analyze the problem for one afternoon and finally solved the problem. At this time, Jia was delayed for half a day. On the third day, student B encountered another difficult problem. He again consulted party A. After analyzing the problem for a long morning, he decided to leave a sentence: Please wait for me to come and see it. As a result, B worked hard to analyze the problem on the third day and worked overtime until 10 o'clock. On the fourth day, B thought that Jia promised to solve the problem, so he went home after work and did not work overtime.

C is a newcomer and is not familiar with the environment. The first day is familiar with the development environment of the day. The next day I made something rough and felt pretty good. Therefore, things are made on the fourth day of the third day without overtime. On the fifth day, Class C was very happy to report that the work was done.

During the fifth World Class, Jia had already delayed the progress of two days. One day was due to helping B and one day was due to various conferences, reimbursement, and other miscellaneous tasks, busy. A casually asked about the progress of ABC and found that A and C have been completed. B's problem should be solved by.

As a result, Jia worked overtime on weekends. During lunch, I glanced at the C code at random, and it was 108,000 worse than my expectation. So I had to remove C and start from scratch.

So the next week, ABC was waiting for Jia. A is waiting for task a to assign, B is waiting for Party A to help solve the problem, and C is waiting for Party A to rebuild its own program. While Jia has to quickly develop the ### 4 module, and there are a bunch of bugs to change in the framework.

As a result, Jia began to complain to people around him about how his project team did not work hard. Under the intervention of the company's leadership, a published a rule: On July 22, 1234, work must be completed at nine o'clock pm every week.

On Friday of the second week, Jia dragged his tired body and announced to everyone that the project was not progressing well and he worked overtime on Saturday. In the complaint, ABC had to work overtime on weekends instead of working with Jia to solve the problem.

The above is a simplified description, but it is similar to the phenomenon that most early PM people encounter.

For project manager A, his workload is too random and he does not track the progress of the team member's workload. This directly leads to the final result: All the workload is on his own. This is what I am talking about.

Many technical experts are not convinced by the project manager. They think that this person is only assigning tasks and chasing us all day long to keep us working. If they don't do things themselves, they will throw them to me if they encounter problems. However, once he achieves the position of the project manager, he should know that assigning tasks and chasing the progress. This is the focus of the project manager!

I just said that the focus is not all work. I wouldn't say that the project manager doesn't need to write code. The Project Manager can properly write some code to help control the project. We will discuss this later. Let's take a look at how the project manager can avoid the problem of "hanging baggage", so that the project team members can complete the project together?

Improvement 1. First, do not think the team members are so bad.

Many project managers, once they see that the team members abandon themselves and leave office, they will be furious and define the group members as bad children. Then, I did not dare to assign tasks to the team members. It is better to do anything by myself. I often hear complaints from PM. Now it is difficult to manage and have no sense of responsibility. In fact, although I have a strong personality after the 80 s, my sense of responsibility is not as bad as I think. Although you have a weak sense of responsibility, it is not as bad as a project team. If something goes wrong, find the cause from yourself.

If the Task Arrangement is reasonable and clear, I think most engineers will take responsibility for the task. Pay attention to the following points:

A) define the task clearly and clearly.

B) The task is assigned and cannot be checked at the end.

C) Adjust the subsequent work at any time based on the task completion status.

D) Do not undo the task at will.

2. Second, do not think the team members are so stupid.

Many technical experts cannot believe the capabilities of their subordinates. Once they see that the subordinate code is not well written, the structure is not good, the API used is not correct, and the comments are not clear enough, they will put a cross fork in their technical capabilities. In subsequent work, I did not dare to give anything to my subordinates. Once the subordinates make some mistakes, they will be furious.

Remember, even if you are indeed the best technically in this project team, you should not do the same. Why?

A) the company cannot give you ten project managers who are as good as you are.

B) if ten people are asked to contact you, you may not care about them.

C) if you are too good, where can your subordinates make mistakes. No chance to make mistakes, how to grow

 

3. In the end, do not consider yourself as a god.

This sentence seems similar to the previous two sentences, but it is actually quite different. The biggest significance is: do not do anything yourself. Remember, the goal of PM is to do a good job in the project, not just by yourself. You can't do ten projects by yourself. Even if you have done it, it is also the credit of 10 people, not you alone. Therefore, you must give it to your subordinates.

Example of Improvement

If I am a project manager, I will arrange it in the above example.

A is the most difficult to do ### 4 module and framework. B: ### 2 module, C: ### 3 module. I will do it myself ## 1 module.

On the first day, I will not start to do the ### 1 module immediately. First look at the work of each person. If the code of C is not good, arrange B for counseling.

The next day, B told me that the ### 2 module is not correct. I asked him to solve it by himself. I started my ### 1 module.

On the third day, B is still uncertain. I helped him solve the problem one morning. I found the problem and told him how to solve it. Let B spend the afternoon solving it.

On the fourth day, B still needs to help C, so it is not enough time. I told B that you should stop helping C. Complete the ### 2 module with your attention. I am here to help C. A complained to me about too much work. I said it was time to show your technical strength.

On the fifth day, B encountered another problem. I asked him to solve the problem first. C has already completed ### 3. I asked c To Help Me With ### 4. I also checked the problem of B.

The sixth day, if the project is tight, you can work overtime for one day. If it is within the buff control range, it can be completed by next Monday. A finished ### 4 and framework, and B's problem was finally solved by myself. Although I also solved it, I didn't tell him, but I just praised him for doing great work. C has completed ### 4, although I have to improve ### 4.

I think, although the work is very tight, it is basically done if everyone adds a one-day shift (or the project milestone is extended for one day. Everyone has the opportunity to contribute. Although busy, the atmosphere of the project team is still good.

I have extracted the burdens and hoped to help people who are doing pm and those who wish to develop in the future.