How can product managers and programmers avoid conflicts?

First, three sentences that product managers and programmers hate most

Product managers and programmers are like a pair of lovers, who are at arm's length and sometimes tear their faces. Everything is fine when you make peace, but you lose when you tear it.

Do you know what are the three most annoying sentences for programmers?

1, this requirement is very simple, just change it.

2, you probably get one first, let me have a look.

3. I got off work first. Let's go

I think any programmer will be furious when he hears such words. It's weird not to tear it. As a programmer, how would you answer these three sentences?

1, this requirement is simple? You can do it. Come on!

2. Maybe buy one first? Excuse me, sir (madam), how much is it?

3, your uncle's

Do you know what product managers hate most?

1, this requirement cannot be met.

This demand is too heavy, it is estimated that it will take three months.

I don't have time to make this change. We'll arrange it later.

The product manager is at the front end, with users, bosses and sales, and the release pressure is great. I guess I'm not much better when I hear this.

1, this requirement can't be met? I didn't mention it, and neither did the 2B user.

2. Will it take so long? What's the use of raising you? I might as well do it myself.

3. No time to make changes? Who cares? Wait for the boss to film you.

2. What is the essential difference between a product manager and a programmer?

Dad worked as a programmer and a product manager, and he knew the difference between the two jobs, each with its own difficulties.

Generally speaking, making products pays more attention to creativity and scheme ability, and does not need accurate logic, so the cost of trial and error is relatively low, and it is also affordable to change the prototype and scheme.

The programmer's job is very precise logic. A seemingly small change may have a great impact on the code, so the cost of trial and error is high. If it is not done well, the system may be reconfigured because of the change of requirements. At this time, the frustration of programmers can be imagined.

Third, a list of friendly relations between product managers and programmers

1. After collecting the requirements, the product manager should try to get rid of some unreasonable requirements and communicate with users during the requirements analysis stage to avoid the delay of product release and unnecessary cost waste caused by unreasonable requirements. Of course, this requires the product manager to convince users, not just to be the mouthpiece of users.

2. When analyzing the requirements, the product manager should, according to his own experience, keenly find some technical requirements that are difficult to achieve, let R&D intervene in time, evaluate the technical feasibility, and avoid the situation that the requirements are fixed and R&D says it can't be done.

Of course, this requires our product manager to have a certain understanding and predictive ability of software technology architecture. You can't let R&D participate in all requirements at the stage of requirements analysis, and the cost is extremely high, so grasping this degree is also an ability.

3. Prototype is the best way to communicate requirements, and it is the best way to avoid the differences in requirements understanding between products and R&D. It is difficult to achieve good results just by writing some written requirements specifications.

However, it should be noted that the prototypes drawn by product managers are generally non-high-fidelity prototypes in order to better communicate the requirements, so they cannot be completely done according to the prototypes and need to be customized based on our own front-end architecture.

4. During the requirement review, R&D may have some different opinions. After years of development, they will have a lot of good experience. Good experience should be accepted with an open mind. You can't think that you are the boss of the product, just do as I say. This will easily lead to contradictions, seek common ground while reserving differences, and achieve the same goal by different routes. This is the best result.

5. When R&D says that this requirement cannot be realized, there are two situations. One is that it is more troublesome to realize this demand and deliberately lie to you; Another situation is his blind spot of knowledge, and he may really not know if he can do it.

The product manager needs to be able to negotiate with R&D, such as adopting analogy (we have done similar requirements on other projects), such as going to the architect to discuss the technical feasibility.

6.R&D sometimes involves a lot of work, and the whole online planning takes a long time. The product manager can ask for a detailed list of resource allocation, so that we can clearly see how many R&D tasks a requirement is broken down into and who is responsible for the start and end time of each task. In this way, the product manager can probably see whether the context of the task is reasonable. Whether the workload is reasonable, etc.

The product manager must never say that it will take so long to make it so simple. If such a thing happens, it will definitely anger the other party, or we should negotiate on the basis of reason.

If it is really impossible to reduce the workload, if increasing manpower can solve the problem, you can consider applying for resources from the leader. If it still doesn't work, it is necessary to cut demand or change plans.

7. When the version plan is determined, try not to add requirements, which will easily disrupt the pace of development. If you must add it, you must make it clear to R&D. This is a mandatory requirement for user leaders or bosses to transfer contradictions. If possible, increase the demand and postpone the online plan as much as possible.

8. If the requirements change during the development process, it is necessary to update the requirements document in time and send it to our R&D classmates. Otherwise, R&D colleagues probably won't do this, so they must write it down on paper.

9. Insist on working overtime with R&D colleagues when going online, so that everyone is a team, winning together and losing together.

10, the last point is to communicate more. There is no problem that a hot pot can't solve. Everyone has a good relationship. Many things will naturally be easy to communicate, and they will trust each other more, so everything will be fine.