Since last week, the company has transferred me from the position of full-stack engineer to the position of project manager, and started to try to manage the position. I feel that changing a position is like changing a job, and I am full of energy again. Starting a new project, recruiting new project members, although they are all doing software development, but the perspective of viewing is completely different from before, and the things they see are different. A week passed quickly.
After contacting the team members for a period of time, what I see is that the team members have their own strengths and characteristics. One member may be completely opposite to the other, but they all have their own strengths. This may be the case Differences make a whole team. Learning to see the strengths in everyone is an essential skill for transitioning to a management position.
There are very good teammates in the team, and I learned some good methods and experiences from them when communicating with each other. For example, to build a team resource library, when we finish writing our respective module codes, we organize a code sharing meeting, along the way, how do I realize this function, what ideas and methods are used in the code. In this way, even if some colleagues did not write this piece, but after hearing someone share it, they can immediately find out how to write it. It is equivalent to opening up the respective resource pools among the members and exerting the strength of the team. Personally, I feel that this method is a good way for team members to grow. In the later process, it can be organized every two weeks.
There is also the importance of the review process in the entire software development cycle. It feels good to hear my colleagues say that he has experienced the entire project development process, and it is worth learning from. Especially the requirement review link before development and implementation. I didn't seem to have encountered this in my previous company. The process is roughly: before the demand comes out, everyone checks whether the demand can be met by all parties, whether the developed architecture can be realized, how does the product manager feel, how does the test feel, etc., write a confirmation document, and all parties confirm Only after that start coding. This avoids a large number of code refactorings caused by requirements changes in the later stage.
Of course, there are still some deficiencies in this process, that is, points that can be improved next time, such as organizing meetings:
1. When the weekly meeting is held, collect and sort out the problems encountered by the members in advance, and at the same time find a teacher who can solve the problems to solve them together.
2. Try to shorten the meeting time as much as possible, no longer than 1 hour.
3. Use a mind map to list the meeting nodes and core content in advance.
I asked myself this question the other day:
What are the constant qualities or abilities in being a project manager? In other words, no matter how you change projects, what is the most important ability?
A few things that come to mind right now are:
0. Communication skills
Communication ability is indeed an important part, no matter how you change the project communication is very important.
1. Bring growth to team members
I think it is important to bring growth to team members, because the growth of team members will improve the quality and progress of the project, and at the same time, it is beneficial to the company and members.
2. Ability to finish ahead of time
This ability is the key to creating profits for the company.
I also asked a senior, and she gave me the answer:
Communication skills, risk management and control.
Human risk, customer risk, capital risk.
At the same time, I also asked a layman:
What he mentioned is that the management system and system will not change because of changing projects. At the same time, one thing is the ability to complete ahead of schedule.
He talked about the importance of finishing ahead of schedule. In a management position, more is to create value for the company and save costs. What was originally completed in two months was completed in one month, saving half of the cost for the company. Created additional value.
The following is a reference for the capabilities of an excellent project manager provided by other netizens:
1. Initiative
You can't expect colleagues at the same level to put aside their own affairs and come to help you solve the problem. At this time, the project manager plays a coordinating role. You should always ask the programmers about the situation, what kind of help you need for any difficulties, and do your best. Efforts to use their power to help programmers.
2. Bug fixes in time
The project manager must be able to grasp the priorities of the bugs, especially the parts that are not related to the business and the program. In extremely difficult situations, they must work out a compromise with the programmer to solve the problem as soon as possible.
3. Complete tasks on time
He should have a more detailed understanding of the level of the programmers under him, who is more proficient in which direction, where is the interest, what is the current level, what level can be improved, and what is the reason for not being able to complete the task on time before. Failure to complete tasks on time is due to
1. The level of programmers is not good. If this is the reason, the project manager does not have a good understanding of programmers. Of course, the programmers cannot be blamed for the plans formulated in this way.
2. The programmer's understanding is wrong. This is because the project manager did not communicate well with the programmer and did not reach a consensus. Of course, this is the responsibility of the project manager.
3. If the project manager has a wrong understanding, then there is nothing to say.
4. Innovation
There should be no innovation in the normal process, not that there is no need for innovation. New methods and ideas should be accurately certified before being used in work. Blind innovation will only lead to unfinished projects, and good ideas will not be certified. , If there is a problem in the mix, it is not clear whether it is an innovation problem or an original problem. Even if there is no problem, it cannot be proved that it is because of the benefits brought by innovation.
5. Responsibility
A programmer does not need a sense of responsibility, which is stipulated by the system. He only needs to complete the task according to the plan. He does not need to bear such a big responsibility. The burden of responsibility should fall on the project manager. Good-looking code appears only in the format specified by the project manager. The so-called good-looking is clear naming rules, the same style of indentation, and the same style of comments. Programmers are not brothers, so how can they know other people's styles and habits? Well, if the project manager does not specify, there will be a variety of styles. The format that is good enough does not need to be advanced. It is just to let everyone unify. The unified style can play a very good role in finding bugs and modifying the program. Also saves time.
Finally, the same sentence, learn by doing, experience the process, the meaning of life lies in experience, feel the collision of thinking among team members, accept the differences of each person, cherish the time everyone spends together, whether it is success or failure , it eventually formed part of my life.
references:
0. Ability of software project manager
1、https://blog.csdn.net/xal0610/article/details/113933348
2、https://copyfuture.com/blogs-details/202003042152545652nixd8ulaszvbn5