PM and engineer

Link: http://firecacada.blog.163.com/blog/static/70743762011117114451722/

 

I saw an article before the holiday, saying that the product project should be dominated by engineers. However, it is annoying to let PM drive the project in China, how can we make a good product?

Apparently, this article was written by an angry engineer, angry engineer! I have at least two resonance points with him:

1. PM in China often involves engineers, and there are even some situations where engineers are treated as tools.
2. If engineers have a broad product vision and comprehensive design literacy, it is a perfect choice for engineers to drive the project.

Unfortunately, due to problems in the education environment, there are too few Chinese connections. A good engineer is also an excellent pm. He can only be a long engineer and can do his/her own work. At this time, PM, which is better at requirement analysis and product design, will drive the project.

Sorry. I have done a lot of questions about engineers because of unreliable demands or back-and-forth changes. It was not until more than a year ago that it was a great improvement. I should confess ...... Although there are very few engineers who can do a good job of PM, there are not many reliable PM actually. In the end, everyone has to write weekly reports, right?

At this stage, the product industry is far from mature enough, and it is difficult to avoid a painful round-trip. But at the very least, PM should regard engineers as partners rather than tools, and try to stand in a trench to get their understanding. Therefore, I have accumulated the following experience from the improvement of the collaboration process despite the right and wrong requirements that are difficult to identify.

First, you must get the engineer's approval of the entire project. Every month, there will be an hourly monthly meeting of the Department. For the PPT, I will talk about what our task plan is and what the goal setting is next month or even next stage, explain in detail the reasons for planning and objectives, the close-up and prospective analysis, and design for this purpose. It is hoped that the engineer will recognize the value of what he is about to do, and it is worth the effort. This will pave the way for communication between PM and engineers.

There is another link at the monthly meeting to analyze all the data generated this month, especially the data of the latest new features. This step is also prepared for engineers to understand how much practical work they can produce.

As for the new function gift provided at the monthly meeting (previously mentioned many times), it was originally designed for engineers and then included PM and operation. I have to admit that I am an engineer, because I have the confidence to motivate pm and operation, but out of lack of depth of communication, I need to use more means to motivate engineers to invest in projects.

There are two types of project tasks: large version and small module. For the major version, after the basic framework is finalized, PM will explain it to engineers in advance and listen to suggestions on the design direction from the technical perspective. The whole design process will be discussed three or five times repeatedly to solicit opinions on technical rationality. After the planning case is finalized, the small module will be confirmed together with the engineer, and the visual draft will be reported again. (So it is necessary for PM to sit close to engineers)

I once publicly promised at the monthly department meeting that any requirement can be stopped as long as the engineer thinks it is unreasonable. Until PM can persuade engineers. If the discussion fails, I will coordinate with the technical manager. I don't have the ability to accept strong requirements. It often happens when I was persuaded by engineers. I changed the plan according to the opinions of engineers. I often talk to PM about the differences. You have heard from engineers and you do not have to stick to your opinions. If you make him feel better, the development speed will be faster and everyone will benefit from it. What's worse if you listen to the opinions of technical partners? It helps you change your thinking perspective and find ways to improve development efficiency.

The final plan was finalized. PM said OK, and the engineer thought the direction was roughly correct, and the details were basically reasonable. The engineer evaluated the progress. PM thought it was too long for him to accept it. I went to discuss it with the technical manager to see if it was a step-by-step cut-off or a shift. In addition to a few urgent repair tasks, the PM will not unilaterally determine the development schedule. This includes the priority of a series of tasks. The PM also submits a draft, and the engineer adjusts the order based on the development situation and then confirms it together.

In the entire process of putting forward the requirements of PM, constant negotiation is ongoing to ensure that engineers understand and accept the tasks without resisting or being numb. If a sudden demand change occurs, I will explain it to engineers repeatedly and request an understanding. I am sorry for the waste of their work. For this reason, the time spent is higher than the development efficiency, and the profit is not lost. Although there are still some inplaces in the specific collaboration, the attitude is always good, and the basic effect is also there.

Of course, the implementation of this process requires two prerequisites. The first is to have a stable team. If it becomes a ticket submission collaboration, it will be impossible to share a sense of belonging to the project after the next month's Division from January 1, 1st day of this month. Second, the engineer's personal qualities are basically reliable and the communication is smooth. In particular, the technical manager can serve the public and coordinate the differences without being short. For example, if a function can be implemented, at least how long it will take for me to develop it. PM and I don't have to worry about it, and we rely mainly on the technical manager to make the final judgment. If there is a mistake in the development process, or, if the development fails according to the agreed plan, the technical manager will take the penalty. The core technical partner is responsible for the business management of the development team. He will also be more deeply involved in the product structure design and task planning.

In doing so, the suspicion of treating engineers as tools is also removed. I think it is shameful to treat any colleague as a tool. How can it be considered a partner? For example, you can exchange necessary information and understand the other party. For example, you can change your mind from the other party's standpoint. For example, you can increase your encouragement and help.

From another perspective, I have encountered a situation where the Engineer proposed a rough idea, and PM recognized and took charge of the detailed design, which was then implemented by this engineer. All the results are happy. I have repeatedly asked engineers for ideas at monthly meetings or other occasions. I have to change my perspective and introduce new ideas and inspirations. Even if they do not have the same idea, they will give a very gentle explanation of the reason for rejection and will never reject it. Fear that engineers may not be able to hear the opinions of technical partners.

Today, yunyun is available: "The core of the scientific development concept is harmonious development ."