PM in my eyes

1 PM in my eyes

1.1 people cloud "one management, half an expert", I said "One management, two experts"

Now, I find that we have to face such a reality: part-time jobs. I used to classify projects into three categories: life-related projects (projects involving personal safety, such as railway projects) and mission-related projects (enterprise-level information projects with clear time nodes ); general Projects (Small and Medium software projects ). I believe that most PM projects, like me, are dedicated to mission-level and General-level projects. Although from a software engineering perspective, we need surgical teams where everyone performs their jobs to focus on different aspects. But the truth is that most of our employers will not hire people who are "superfluous" in their eyes. In this case, PM is required to assume the role. In a broad sense, apart from management, PM often assumes two roles: designers and developers. In many cases, we have to face such an embarrassing situation that we spend a lot of time on design and coding, rather than project management. I often reflect on the structure of my knowledge system as a PM?

I think most developers agree that PM must have certain technical strength. Otherwise, the tragedy of a layman's management experts will occur. From my experience, there are two aspects of knowledge in the technical field that are most important to PM. First, knowledge in the software design field (requirement analysis, architecture design, database design, and uidesign); second, knowledge in the software implementation field (development language, test debugging, and IDE usage ). I think these two points are very important because PM has to take responsibility. Many times, we need to complete the project without the support of the technical director.

1.2 not everyone applies to PM

I think PM needs to have the following inherent qualities:

• SincereNeedless to say, this is what every manager should possess. The most basic capabilities cannot be acquired by the day after tomorrow.
• BackboneAnger of blood gas cannot exist, and anger of righteousness cannot. PM must have the courage to say "no" to unreasonable requirements and dare to safeguard the interests of the team.
• PerseverancePM must be able to resist pressure. Even if the project is sinking, PM should give orders with extraordinary courage and determination.

1.3 Although the theory is very important, more importantly, experience

The things in the book are dead. How to effectively turn theoretical knowledge into productive forces requires long-term experience accumulation. Theory must be related to practice, and there is no strategy for management.

1.4 manage your project first

I don't believe that a person with poor management can manage a team. A person reveals his character characteristics. How can I take responsibility for a team if I am not responsible for myself? Can the project progress be guaranteed for a person who is often late? Can a person with poor life guarantee the quality of the project?

1.5 seek balance rather than optimum

Scope, time, cost, and quality are subject to these four dimensions. In reality, we must realize that the success or failure of our project depends on the balance between the four dimensions. Therefore, it is unrealistic to find the balance between the four dimensions rather than trying to make the best of the four.

1.6 "Four-camera"

"Four-camera" is the most objectionable practice, but it is not uncommon to be around. "One shot of the brain is done; two shots are okay; three shots have an accident in the thigh; four shots have left ." I have heard of many such examples. The lack of the interviewer's ability and the incomplete background investigation contribute to the arrogance of those who are not responsible. It stinks a project, leaves a mess, and keeps switching from one project to another. After changing the resume several times, it looks pretty and the salary rises fast, however, it is difficult to understand that many enterprises are eager for such management capabilities.

2 Open Mind

2.1 Haina baichuan

Whether it is process management or human management, the quarrel between different camps is becoming increasingly fierce. No matter what type of certification exam you take, or you are already in a certain camp, you will often be brainwashed into a certain model or theoretical system better than others. However, there is really no need to divide the project management style into such opposites. Just as the core purpose of software engineering is to reduce the complexity of software development, we constantly explore the project management model to maximize project success. Therefore, I think any good, widely recognized practice that can contribute to the success of the project should be put into practice and promoted if the company permits and risks are controllable. For example, although I manage the process in the project, I am still practicing the "continuous delivery" idea in Agile development. I also benefit from this.

2.2 learn to think

Thinking is mysterious. People do not naturally think about it. We need to avoid some traps.

• PrejudicePeople are facial-loving animals, and they are easily influenced by feelings. When we hear an opposition, most people will instinctively resist, rather than accept opinions and think deeply. There are still many such prejudices. It is difficult for people without training or relevant knowledge to look at the issue in a neutral manner.
• One-sided thinkingOptimistic people only see the good aspects of the problem and tend to ignore the risks. Pessimistic people only see the risks of the problem and ignore the potential value.
• Herd PsychologyPeople are group animals. They are not good at independent thinking. They need society and friends. When thinking, people tend to choose what the public says is acceptable, rather than the viewpoint that the thinker truly agrees. This is the herd mentality of people, but in many cases, truth is only in the hands of a few people.

2.3 psychology is actually very useful

A few years ago, I saw a senior familiar with me reading psychology books. At that time, I was confused. I didn't understand why he spent his spare time on books unrelated to IT. But when I found the shadows of Psychology in some thinking or project management books, I realized that psychology is actually very useful. For example:

When I got into a project, I found a low-level defect that has already spread. This is a strange phenomenon, that is, many of my colleagues found this problem, I think there is a better way of writing, but no one is responding to the design group, and the reason is surprisingly consistent-"This problem is too good, and someone else must have reacted!" In psychology, this is the "bystander effect ". Focusing on some well-known psychology experiments helps us to correctly examine the team and find the essence behind some problems.

2.4 prepare for yourself

In the early stage of the project, we were facing a huge amount of pressure, and employers were urging us to start coding as soon as possible. If we cannot persuade our employers and learn to say no to unreasonable requests, it is likely to be a foreshadowing for later project failures. Software projects reflect such an essence: there is a strong logic between work items, and the lower the cost of solving defects in the early stage of the project, the easier it is for us to focus on projects. Therefore, if the preliminary preparation of the project is insufficient, the code will start. A large number of defects may be exposed in the middle and late stages of the project, and the progress, morale, quality, and cost will be damaged. Therefore, for team consideration and for ourselves, please make preparations before coding.

2.5 quality is very important

Quality, a key core dimension, is often the victim of progress. When the scope, time, and cost can be viewed and traced, someone will sacrifice the most difficult quality to view. From the developer's point of view, we constantly emphasize the quality of code, but in the end, programmers who really dare to face unreasonable design and say "no" and strive to maintain the quality of Code are not paid much attention. Progress is important, but many PM without technical foundation, especially those who do not understand the programmer culture, are sacrificing quality to conceal their incompetence in Project Progress Management.

First-level awareness of quality-we can deliver low-grade software, but not low-quality software.

Second-level understanding of quality-quality is not endless, just meet the needs.

Level 3 awareness of quality-low quality can lead to low mood for excellent developers. (If a good programmer faces bad code for a long time and develops software that is lower than his own quality standards, it will bring down those who really love programming, they even question the technical strength of the team and choose to resign .)

2.6 is the result

Forget your Gantt chart. Before UAT fails, your efforts are just a bunch of code that passes debugging. Do not be fooled by the beautiful progress on the chart, because in many cases, potential defects (especially when preparation is insufficient) will be discovered when you enter UAT ). We tend to neglect risk management if the reconciliation progress is too optimistic. Therefore, to maintain a rational mind, UAT will be implemented.

2.7 code review tested

Do not rely too much on tests. Good code review and quick feedback mechanisms can fix early bugs before they spread, and according to some figures I have learned, the number of defects discovered by code reviews is much higher than that detected by tests.

3. Tools

PM needs to master the use of common tools:

• Development ToolsSuch as VS, Blend, and code generator.
• Management toolsFor example, SVN, TFS, and Project.
• Document toolsSuch as Visio, Rose, and Excel.
• Deployment and release toolsSuch as IIS, SQL Server, and Win Server.

4. Team building

4.1 respect your colleagues

People are equal in life. When you read this text, you may think that you have enough respect for our colleagues. But is it true? Most of the time, when we think we are in a battle and capable of being superior, can we really stick to the principle. The words listed below are extreme and somewhat exaggerated, but I suggest, at the same time, I really hope that the PM will not do the following, because it will really hurt others.

• "What is this code written !"Do not deny others' labor results. If the developer's Code cannot meet the standards, Please say, "Your code has defects. I have better suggestions ."
• "Design the computation I'm talking about. Shut up your development !"Do not deny the opposition. Developers are the frontline soldiers. No matter how confident we are, we should also listen to the suggestions and make a fair assessment.
• "Will it take you a day to finish writing this ?"Do not embarrass developers in public. Low mood only allows developers to introduce more defects to projects. If the developer fails to complete the process, we should find the cause and solve the problem, instead of blaming it blindly.
• "You cannot do it !"This completely denies the value of the developer. Let's wait for the departure.

4.2 understand your colleagues

Just like sales grouping customers, we should also learn to group stakeholders. Here I don't want to discuss how to manage stakeholders. This topic is too big. I want to talk about how to manage teams. In the final analysis, PM is managing people. We need to understand our colleagues, not only their technical capabilities, but also their personality and psychological needs. People and people are different. Some people map money, some people want to learn technology, some people want to work for stability, and others want to recognize each other. Our colleagues have different psychological needs. When we use management methods, we need to adjust them based on actual conditions, rather than simply following textbooks. In many cases, technical training and authorization are more stable than salary increases.

4.3 always win

"Real teams need to work together ."

Project success cannot be at the expense of developers. We purchase books, participate in training, obtain certification, attend Summits, and spend a lot of time improving and practicing project management methods to control costs without compromising the interests of team members, make sure the project is successful. In many cases, the performance salary of PM is linked to the interests, but we should not sacrifice the interests of quality or team members for personal interests. We do not stand at the center of the company, team, or customer, but at the center of the three to balance conflicts. Adhering to the professional ethics, it is not easy. There will be ridicule from our peers, comments from leaders or complaints from customers. But sincerity and professional ethics are the foundation of our industry, this is enough.

5. Efficiency

5.1 efficient MEETING

"When a large ship is about to sink, what is needed is the captain to issue a command, rather than sitting down for a meeting ."

In reality, we often waste a lot of time on inefficient meetings. Many companies will not hold meetings, nor will they find any cost problems behind inefficient meetings. I have been practicing the efficient meeting method. Here is my personal experience:

• Regular Meeting, small meetingThe meeting mentioned here should be a "quick briefing ". Regular and quick briefings are conducted to detect problems early, handle small problems early, and hold meetings and discussions on large problems. This can reduce the frequency of "heavy" meetings and reduce defect repair cycles and costs.
• Six think hatsAt the meeting, using the "Six Thinking Hats" method can make the meeting more efficient and the conclusion more reliable, which is conducive to solving substantive problems. (The inspiration from my blog post "Six Thinking Hats ")
• Grasp the essenceWe don't have to spend too much effort on modifying the documents used at meetings, especially technical meetings. What we need is accurate graphs and tables, not animations. The document has clear primary and secondary structures and proper font size.

5.2 high-quality documents

• Document sizes are not of the same qualityWith the idea of "no credit and hard work", a large number of low-quality documents have no focus and there is too much nonsense.
• The format is indispensable, but the content is more important.Meeting the template requirements is only the most basic, and the content is the core of the document.
• Beyond the scope of the documentWrite only the content contained in this document.
• The primary and secondary accounts should be distinct, rather than the downstream accountsTaking responsibility for every small thing will only challenge the reader's patience.
• More powerful chartsUse multiple charts and tables.

5.3 fast feedback

The cost of compound defects increases dramatically with the "time from introducing defects to detecting defects. (Just like the deposition of radioactive substances in the food chain)

Similarly, in project management, we need to establish several quick feedback loops, such:

• Between the development team and the test teamTrack, assign, and trace defects to improve the defect repair rate and prevent spread.
• Between testing (deployment) teams and key usersQuickly collect user feedback, provide guidance to users, and notify users of the release time and content updates.
• Between PM and key usersCollect and handle changes in a timely manner, notify users about the handling of changes in a timely manner, and let them know the progress of the project (mainly to let them know what we are doing, so as to be assured ).
• Between PM and Development TeamLearn about the team now, listen to internal voices, communicate and collect opinions in a timely manner, and prevent staff loss.

6. Communication

6.1 induction seminars are indispensable and resignation seminars are more important

After one week of employment, you need to have a discussion before leaving the company.

When everyone arrives in the new environment, it will be somewhat uncomfortable. In addition, programmers like to work on their own, and new recruits need additional attention. You need to talk to new users about a week to see if they have any problems and ask for suggestions from the project team. In this way, new people can be integrated into the group as soon as possible, reduce the time of team volatility, and improve the process to improve efficiency.

Resignation talk is more important than induction talk. There must be some reason for the abnormal loss of staff. We must find out the crux of the problem through the resignation talk, take the right medicine, and continue to improve the process. In addition, for sales, "Everyone is a potential customer" also applies to us. Maybe the next project is your project stakeholder, and the IT circle is not big, we need friends.

6.2 "Cowboy"

"Cowboy" refers to the dedicated team-owners who are proficient in field technology, have outstanding abilities and enthusiasm for work, and are somewhat difficult to integrate into the group. Although the war between the cowboy and PM often exceeded (mainly in technical debate), I think they are the true treasure of the team. Because they are real senior experts and often have higher quality standards, they often find quality defects that are easily overlooked by others, or have a better way of writing and can put forward pertinent suggestions, provides feasible solutions for technical issues. However, because of my character, most "Cowboy" may have such an idea. Other people's technologies are not as good as me. What I say is correct. I cannot lower my standards. This mentality makes it difficult for them to integrate into the team and often leads to debate. Here is how I interact with "cowboy:

• Recognize the capabilities of "Cowboy" and respect their suggestionsMost cowboy pursues a sense of team identity, rather than salary. recognizing them is the greatest respect for them.
• Independent completion of some complex core functionsThey like to challenge complex tasks, and the C \ V (copy, paste) work makes them feel like they are wasting their lives.
• Use as needed.In some fields, they can often reach a certain degree. Based on their capabilities, they can authorize them to take charge of some code quality or design work. This not only makes them feel their abilities recognized by the team, they can also use their "High Quality Standards" mentality to Improve the Quality of code (pay attention to everything, so that the "Cowboy" needs to communicate with them in advance for code review, because they may not take into account others' faces, take very direct communication methods, such as irritating older developers, so they are more suitable for "Technical Training" and "Design Review" than "code review ".)

6.3 how to interview

First, we are only responsible for technical interviews and do not communicate with candidates about salary issues. Second, if any of the following steps fail, there will be no further steps.

　　Step 1: Ice BreakingEliminate the tension of the interviewee, which is generally introduced by the interviewee.

　　Step 2: Test whether your resume is fakeMethod 1: a person's memory of numbers is vague. If his or her resume is fake, the applicant will blur the fictitious number on his or her resume. Method 2, inquire about the project experience on your resume to see if it complies with industry practices.

　　Step 3: Capability EvaluationIt is generally a purely technical discussion to assess whether the applicant is competent for the current position based on the written test content and job requirements.

　　Step 4: answer questionsDescribe your position or job description and answer your questions.

6.4 excluding "Resources" is the worst practice

When our developers are not qualified for their roles, I prefer to arrange training instead of recruiting new people. To be honest, you cannot understand the current market. A large number of developers flood into the society, and they talk about the new technology, but do not understand what the code they write is doing. I am also responsible for interviews. Among the young programmers, there are fewer and fewer basic skills. Therefore, we do not want to solve the problem of insufficient technical resources through downsizing and recruitment. Everyone who has read the Mythical man-month should know that injecting resources into a project that is lagging behind will only lead to lagging behind. Therefore, if you find that "Resources" are insufficient, you should give priority to training. The cost and cycle of training for old employees are much lower than that for new employees. If the training is unqualified, you should consider recruitment.

Author:MeteorSeed

Thank you for reading this article. If you find some gains, please click "recommendation" on the right. Your support is my greatest encouragement...

Indicate the source for reprinting.

From: http://www.cnblogs.com/MeteorSeed/archive/2013/04/15/2880961.html

1 PM in my eyes

1.1 people cloud "one management, half an expert", I said "One management, two experts"

Now, I find that we have to face such a reality: part-time jobs. I used to classify projects into three categories: life-related projects (projects involving personal safety, such as railway projects) and mission-related projects (enterprise-level information projects with clear time nodes ); general Projects (Small and Medium software projects ). I believe that most PM projects, like me, are dedicated to mission-level and General-level projects. Although from a software engineering perspective, we need surgical teams where everyone performs their jobs to focus on different aspects. But the truth is that most of our employers will not hire people who are "superfluous" in their eyes. In this case, PM is required to assume the role. In a broad sense, apart from management, PM often assumes two roles: designers and developers. In many cases, we have to face such an embarrassing situation that we spend a lot of time on design and coding, rather than project management. I often reflect on the structure of my knowledge system as a PM?

I think most developers agree that PM must have certain technical strength. Otherwise, the tragedy of a layman's management experts will occur. From my experience, there are two aspects of knowledge in the technical field that are most important to PM. First, knowledge in the software design field (requirement analysis, architecture design, database design, and uidesign); second, knowledge in the software implementation field (development language, test debugging, and IDE usage ). I think these two points are very important because PM has to take responsibility. Many times, we need to complete the project without the support of the technical director.

1.2 not everyone applies to PM

I think PM needs to have the following inherent qualities:

• SincereNeedless to say, this is what every manager should possess. The most basic capabilities cannot be acquired by the day after tomorrow.
• BackboneAnger of blood gas cannot exist, and anger of righteousness cannot. PM must have the courage to say "no" to unreasonable requirements and dare to safeguard the interests of the team.
• PerseverancePM must be able to resist pressure. Even if the project is sinking, PM should give orders with extraordinary courage and determination.

1.3 Although the theory is very important, more importantly, experience

The things in the book are dead. How to effectively turn theoretical knowledge into productive forces requires long-term experience accumulation. Theory must be related to practice, and there is no strategy for management.

1.4 manage your project first

I don't believe that a person with poor management can manage a team. A person reveals his character characteristics. How can I take responsibility for a team if I am not responsible for myself? Can the project progress be guaranteed for a person who is often late? Can a person with poor life guarantee the quality of the project?

1.5 seek balance rather than optimum

Scope, time, cost, and quality are subject to these four dimensions. In reality, we must realize that the success or failure of our project depends on the balance between the four dimensions. Therefore, it is unrealistic to find the balance between the four dimensions rather than trying to make the best of the four.

1.6 "Four-camera"

"Four-camera" is the most objectionable practice, but it is not uncommon to be around. "One shot of the brain is done; two shots are okay; three shots have an accident in the thigh; four shots have left ." I have heard of many such examples. The lack of the interviewer's ability and the incomplete background investigation contribute to the arrogance of those who are not responsible. It stinks a project, leaves a mess, and keeps switching from one project to another. After changing the resume several times, it looks pretty and the salary rises fast, however, it is difficult to understand that many enterprises are eager for such management capabilities.

2 Open Mind

2.1 Haina baichuan

Whether it is process management or human management, the quarrel between different camps is becoming increasingly fierce. No matter what type of certification exam you take, or you are already in a certain camp, you will often be brainwashed into a certain model or theoretical system better than others. However, there is really no need to divide the project management style into such opposites. Just as the core purpose of software engineering is to reduce the complexity of software development, we constantly explore the project management model to maximize project success. Therefore, I think any good, widely recognized practice that can contribute to the success of the project should be put into practice and promoted if the company permits and risks are controllable. For example, although I manage the process in the project, I am still practicing the "continuous delivery" idea in Agile development. I also benefit from this.

2.2 learn to think

Thinking is mysterious. People do not naturally think about it. We need to avoid some traps.

• PrejudicePeople are facial-loving animals, and they are easily influenced by feelings. When we hear an opposition, most people will instinctively resist, rather than accept opinions and think deeply. There are still many such prejudices. It is difficult for people without training or relevant knowledge to look at the issue in a neutral manner.
• One-sided thinkingOptimistic people only see the good aspects of the problem and tend to ignore the risks. Pessimistic people only see the risks of the problem and ignore the potential value.
• Herd PsychologyPeople are group animals. They are not good at independent thinking. They need society and friends. When thinking, people tend to choose what the public says is acceptable, rather than the viewpoint that the thinker truly agrees. This is the herd mentality of people, but in many cases, truth is only in the hands of a few people.

2.3 psychology is actually very useful

A few years ago, I saw a senior familiar with me reading psychology books. At that time, I was confused. I didn't understand why he spent his spare time on books unrelated to IT. But when I found the shadows of Psychology in some thinking or project management books, I realized that psychology is actually very useful. For example:

When I got into a project, I found a low-level defect that has already spread. This is a strange phenomenon, that is, many of my colleagues found this problem, I think there is a better way of writing, but no one is responding to the design group, and the reason is surprisingly consistent-"This problem is too good, and someone else must have reacted!" In psychology, this is the "bystander effect ". Focusing on some well-known psychology experiments helps us to correctly examine the team and find the essence behind some problems.

2.4 prepare for yourself

In the early stage of the project, we were facing a huge amount of pressure, and employers were urging us to start coding as soon as possible. If we cannot persuade our employers and learn to say no to unreasonable requests, it is likely to be a foreshadowing for later project failures. Software projects reflect such an essence: there is a strong logic between work items, and the lower the cost of solving defects in the early stage of the project, the easier it is for us to focus on projects. Therefore, if the preliminary preparation of the project is insufficient, the code will start. A large number of defects may be exposed in the middle and late stages of the project, and the progress, morale, quality, and cost will be damaged. Therefore, for team consideration and for ourselves, please make preparations before coding.

2.5 quality is very important

Quality, a key core dimension, is often the victim of progress. When the scope, time, and cost can be viewed and traced, someone will sacrifice the most difficult quality to view. From the developer's point of view, we constantly emphasize the quality of code, but in the end, programmers who really dare to face unreasonable design and say "no" and strive to maintain the quality of Code are not paid much attention. Progress is important, but many PM without technical foundation, especially those who do not understand the programmer culture, are sacrificing quality to conceal their incompetence in Project Progress Management.

First-level awareness of quality-we can deliver low-grade software, but not low-quality software.

Second-level understanding of quality-quality is not endless, just meet the needs.

Level 3 awareness of quality-low quality can lead to low mood for excellent developers. (If a good programmer faces bad code for a long time and develops software that is lower than his own quality standards, it will bring down those who really love programming, they even question the technical strength of the team and choose to resign .)

2.6 is the result

Forget your Gantt chart. Before UAT fails, your efforts are just a bunch of code that passes debugging. Do not be fooled by the beautiful progress on the chart, because in many cases, potential defects (especially when preparation is insufficient) will be discovered when you enter UAT ). We tend to neglect risk management if the reconciliation progress is too optimistic. Therefore, to maintain a rational mind, UAT will be implemented.

2.7 code review tested

Do not rely too much on tests. Good code review and quick feedback mechanisms can fix early bugs before they spread, and according to some figures I have learned, the number of defects discovered by code reviews is much higher than that detected by tests.

3. Tools

PM needs to master the use of common tools:

• Development ToolsSuch as VS, Blend, and code generator.
• Management toolsFor example, SVN, TFS, and Project.
• Document toolsSuch as Visio, Rose, and Excel.
• Deployment and release toolsSuch as IIS, SQL Server, and Win Server.

4. Team building

4.1 respect your colleagues

People are equal in life. When you read this text, you may think that you have enough respect for our colleagues. But is it true? Most of the time, when we think we are in a battle and capable of being superior, can we really stick to the principle. The words listed below are extreme and somewhat exaggerated, but I suggest, at the same time, I really hope that the PM will not do the following, because it will really hurt others.

• "What is this code written !"Do not deny others' labor results. If the developer's Code cannot meet the standards, Please say, "Your code has defects. I have better suggestions ."
• "Design the computation I'm talking about. Shut up your development !"Do not deny the opposition. Developers are the frontline soldiers. No matter how confident we are, we should also listen to the suggestions and make a fair assessment.
• "Will it take you a day to finish writing this ?"Do not embarrass developers in public. Low mood only allows developers to introduce more defects to projects. If the developer fails to complete the process, we should find the cause and solve the problem, instead of blaming it blindly.
• "You cannot do it !"This completely denies the value of the developer. Let's wait for the departure.

4.2 understand your colleagues

Just like sales grouping customers, we should also learn to group stakeholders. Here I don't want to discuss how to manage stakeholders. This topic is too big. I want to talk about how to manage teams. In the final analysis, PM is managing people. We need to understand our colleagues, not only their technical capabilities, but also their personality and psychological needs. People and people are different. Some people map money, some people want to learn technology, some people want to work for stability, and others want to recognize each other. Our colleagues have different psychological needs. When we use management methods, we need to adjust them based on actual conditions, rather than simply following textbooks. In many cases, technical training and authorization are more stable than salary increases.

4.3 always win

"Real teams need to work together ."

Project success cannot be at the expense of developers. We purchase books, participate in training, obtain certification, attend Summits, and spend a lot of time improving and practicing project management methods to control costs without compromising the interests of team members, make sure the project is successful. In many cases, the performance salary of PM is linked to the interests, but we should not sacrifice the interests of quality or team members for personal interests. We do not stand at the center of the company, team, or customer, but at the center of the three to balance conflicts. Adhering to the professional ethics, it is not easy. There will be ridicule from our peers, comments from leaders or complaints from customers. But sincerity and professional ethics are the foundation of our industry, this is enough.

5. Efficiency

5.1 efficient MEETING

"When a large ship is about to sink, what is needed is the captain to issue a command, rather than sitting down for a meeting ."

In reality, we often waste a lot of time on inefficient meetings. Many companies will not hold meetings, nor will they find any cost problems behind inefficient meetings. I have been practicing the efficient meeting method. Here is my personal experience:

• Regular Meeting, small meetingThe meeting mentioned here should be a "quick briefing ". Regular and quick briefings are conducted to detect problems early, handle small problems early, and hold meetings and discussions on large problems. This can reduce the frequency of "heavy" meetings and reduce defect repair cycles and costs.
• Six think hatsAt the meeting, using the "Six Thinking Hats" method can make the meeting more efficient and the conclusion more reliable, which is conducive to solving substantive problems. (The inspiration from my blog post "Six Thinking Hats ")
• Grasp the essenceWe don't have to spend too much effort on modifying the documents used at meetings, especially technical meetings. What we need is accurate graphs and tables, not animations. The document has clear primary and secondary structures and proper font size.

5.2 high-quality documents

• Document sizes are not of the same qualityWith the idea of "no credit and hard work", a large number of low-quality documents have no focus and there is too much nonsense.
• The format is indispensable, but the content is more important.Meeting the template requirements is only the most basic, and the content is the core of the document.
• Beyond the scope of the documentWrite only the content contained in this document.
• The primary and secondary accounts should be distinct, rather than the downstream accountsTaking responsibility for every small thing will only challenge the reader's patience.
• More powerful chartsUse multiple charts and tables.

5.3 fast feedback

The cost of compound defects increases dramatically with the "time from introducing defects to detecting defects. (Just like the deposition of radioactive substances in the food chain)

Similarly, in project management, we need to establish several quick feedback loops, such:

• Between the development team and the test teamTrack, assign, and trace defects to improve the defect repair rate and prevent spread.
• Between testing (deployment) teams and key usersQuickly collect user feedback, provide guidance to users, and notify users of the release time and content updates.
• Between PM and key usersCollect and handle changes in a timely manner, notify users about the handling of changes in a timely manner, and let them know the progress of the project (mainly to let them know what we are doing, so as to be assured ).
• Between PM and Development TeamLearn about the team now, listen to internal voices, communicate and collect opinions in a timely manner, and prevent staff loss.

6. Communication

6.1 induction seminars are indispensable and resignation seminars are more important

After one week of employment, you need to have a discussion before leaving the company.

When everyone arrives in the new environment, it will be somewhat uncomfortable. In addition, programmers like to work on their own, and new recruits need additional attention. You need to talk to new users about a week to see if they have any problems and ask for suggestions from the project team. In this way, new people can be integrated into the group as soon as possible, reduce the time of team volatility, and improve the process to improve efficiency.

Resignation talk is more important than induction talk. There must be some reason for the abnormal loss of staff. We must find out the crux of the problem through the resignation talk, take the right medicine, and continue to improve the process. In addition, for sales, "Everyone is a potential customer" also applies to us. Maybe the next project is your project stakeholder, and the IT circle is not big, we need friends.

6.2 "Cowboy"

"Cowboy" refers to the dedicated team-owners who are proficient in field technology, have outstanding abilities and enthusiasm for work, and are somewhat difficult to integrate into the group. Although the war between the cowboy and PM often exceeded (mainly in technical debate), I think they are the true treasure of the team. Because they are real senior experts and often have higher quality standards, they often find quality defects that are easily overlooked by others, or have a better way of writing and can put forward pertinent suggestions, provides feasible solutions for technical issues. However, because of my character, most "Cowboy" may have such an idea. Other people's technologies are not as good as me. What I say is correct. I cannot lower my standards. This mentality makes it difficult for them to integrate into the team and often leads to debate. Here is how I interact with "cowboy:

• Recognize the capabilities of "Cowboy" and respect their suggestionsMost cowboy pursues a sense of team identity, rather than salary. recognizing them is the greatest respect for them.
• Independent completion of some complex core functionsThey like to challenge complex tasks, and the C \ V (copy, paste) work makes them feel like they are wasting their lives.
• Use as needed.In some fields, they can often reach a certain degree. Based on their capabilities, they can authorize them to take charge of some code quality or design work. This not only makes them feel their abilities recognized by the team, they can also use their "High Quality Standards" mentality to Improve the Quality of code (pay attention to everything, so that the "Cowboy" needs to communicate with them in advance for code review, because they may not take into account others' faces, take very direct communication methods, such as irritating older developers, so they are more suitable for "Technical Training" and "Design Review" than "code review ".)

6.3 how to interview

First, we are only responsible for technical interviews and do not communicate with candidates about salary issues. Second, if any of the following steps fail, there will be no further steps.

　　Step 1: Ice BreakingEliminate the tension of the interviewee, which is generally introduced by the interviewee.

　　Step 2: Test whether your resume is fakeMethod 1: a person's memory of numbers is vague. If his or her resume is fake, the applicant will blur the fictitious number on his or her resume. Method 2, inquire about the project experience on your resume to see if it complies with industry practices.

　　Step 3: Capability EvaluationIt is generally a purely technical discussion to assess whether the applicant is competent for the current position based on the written test content and job requirements.

　　Step 4: answer questionsDescribe your position or job description and answer your questions.

6.4 excluding "Resources" is the worst practice

When our developers are not qualified for their roles, I prefer to arrange training instead of recruiting new people. To be honest, you cannot understand the current market. A large number of developers flood into the society, and they talk about the new technology, but do not understand what the code they write is doing. I am also responsible for interviews. Among the young programmers, there are fewer and fewer basic skills. Therefore, we do not want to solve the problem of insufficient technical resources through downsizing and recruitment. Everyone who has read the Mythical man-month should know that injecting resources into a project that is lagging behind will only lead to lagging behind. Therefore, if you find that "Resources" are insufficient, you should give priority to training. The cost and cycle of training for old employees are much lower than that for new employees. If the training is unqualified, you should consider recruitment.