How do product managers get programmers to put down their knives?

Abstract: Friendly cooperation is an art.

• How do you get programmers to put down their knives?
• Author: Vicky

Fundebug is reproduced with authorization. All rights reserved.

Product managers and programmers seem to be natural enemies, and how do you subtly prevent even the most well-tempered programmers from getting emotional when faced with the product manager’s ever-changing needs?

Belongs to the enemy positions, as is known to all, a product manager with programmer programmers with product manager to fight because demand of news is more common, and even violence seen programmer cut men’s event, so does the product even joked that products belong to high risk industry, the industry faces be cut at any time, quilt sack, beaten and so on all sorts of problems.

It’s not as scary as it sounds, but it’s really important to get them to put down their knives in the face of constantly updated programs that are about to explode.

The main field of analysis here is how to appease the programmer in the face of frequent changes in requirements, which are already on the edge of runaway.

There are many reasons for changing requirements:

1. The client’s sudden change of heart and request must be fulfilled.
2. The leader suddenly sees an app and asks for changes based on that app.
3. The pit had to be filled in later due to careless consideration.
4. The technology didn’t understand the requirements before, and something went wrong and needed to be changed.
5. …

In the face of changing requirements, even the good-tempered programmers will turn into bad-tempered dragons. As product dogs, it is very important for us to stabilize development in order to meet the requirements as soon as possible.

Steady development is key

Be prepared

Both stood in their area, is justified, but put together, the product development process will be difficult, to the product function implementation, tomorrow technology considering this feature at least a week even said that the demand can’t realize, either cut demand or change requirements, products also can’t promise, you come to me to, both sides have a quarrel.

Here are a few things product managers can do in the early stage to reduce a lot of unnecessary arguments.

1. Clear requirements, clear logic, careful thinking, do not let the program guess.

We are making product prototype, and write the PRD document, must be clear and accurate description of requirements, all of the requirements from the perspective of reasonable, justified, reduce with individual subjective language description (such as I feel, I think), such a description of the development will have a product not from set out actually, all functions are taken head of, There will be distrust and an impression of incompetence on the part of the team, which will make it harder to implement later requirements.

In the description of the function, as detailed as possible to consider a variety of scenarios, reduce the program imagination space, the more we think, the more fully considered, the program in the process of development can be closer to our original needs.

Such as an input box to do that, we need to consider first the character length of the border, to support the input character types (such as mobile phone number input is digital type, but note there is no limit to the input is), if required, if there is a default value, whether to have the clues, state of input error prompt routine description. However, there are also some special scenarios, such as the need to automatically bring out the previously entered characters when typing text, support for direct quick selection and quick typing, whether to support pasting, etc. These also need to be taken into account. In short, the more fully the product is considered in the early stage, the program development will be easier, and the later stage will not produce unwanted changes because the product missed some scenes.

2. Respect and understand technical personnel.

I surveyed the programmers around me, and the most annoying thing I heard from the product was: “This requirement is simple…” On reflection, it is mainly because some products do not know technology and decide the length of development cycle by subjective judgment.

For example: the need is to go to the supermarket to buy a bottle of water; Technology may be to consider how far it is, whether it is appropriate to walk or take a car; How many ways are there to get to the supermarket? Is there only one kind of water or many kinds of water? If there are a lot of people buying water together, do you need to queue or can you multithread… .

So after we give the requirements, we can listen to the program’s opinion, and don’t say “this requirement is easy…” through subjective ideas. . At the same time, we also need to learn a little more technology, don’t know to ask, usually can go to some technical forums, but also to avoid a requirement review, technical report for 3 days, the result of two hours to complete this situation.

3. Communicate online for minor matters and in person for major matters, and keep written records of all adjustments.

A lot of thinking is needed in the process of program development, so if the program is interrupted in the middle of the process, the previous preparation may be wasted, so when there is no particularly important notice, you can communicate through online, and I will naturally go to see it when the technical work is finished.

For important matters, always communicate in person and don’t send email notifications out of fear of conflict. Written content is likely to cause errors in everyone’s understanding and ultimately cause bigger problems. Being proactive, coupled with a genuine, friendly attitude, is a good place to start to avoid conflict.

Most important, after all adjustments in the notification and determined the scheme must be written records, procedures to receive many messages a day, a lot of demand they need not be in time to deal with you after we communicate, even a little bit small changes may be missed, so after the communication clear, be sure to record in position for easy application view, also convenient behind test can understand.

Generally, we can add a page in front of the prototype to document the requirements for adjustments, and put a quick jump link after each adjustment to facilitate the application to locate quickly. The diagram below: