Product managers and developers: to avoid some nasty smelly problems

Article Description: Do not do product managers who are annoying to developers.

First of all, no one will hate a person for no reason, unless you have a nasty smelly problem. And some smelly problems, oneself is may not think very serious. This is due to human self-awareness of the obstacles caused by the inevitable. Without a product manager who hates developers, you need to first figure out what the developer really hates. So I asked a question: What bugs do developers hate about product managers?

Surprisingly, this issue has aroused a lot of understanding in the industry discussion and attention, and follow suit to create what the designer hates the product manager of what the smelly problems? What are the bugs that the product manager hates about developers? , the product manager hates the designer's smelly problems? And so on. It's not hard to speculate that in an internet company, it's always challenging for people of different roles to achieve seamless cooperation in the process of accomplishing projects together.

Admittedly, these challenges may be due to the capacity of the participants, which is unavoidable. But I am more willing to believe that communication is not smooth, poor habits, lack of transposition thinking and other factors are the most common. The discussion of several issues in the knowledge of the various roles may play a role in exchanging places between different players, and undoubtedly, this is a matter of positive significance to all parties.

Product Manager as a link between the central node, to avoid some annoying smelly problems appear particularly important. From the answers I have made, I have categorized these possible behaviors into the following situations:

Can be avoided in a short period of time:

The demand is not clear , when the developer asked the PM needs, and found that PM also do not know, such a problem is must be eliminated also completely can be eliminated, if the PM themselves are not clear demand, the consideration of such a job is suitable for their own.

intervene in purely technical issues , such as: This code should be written like this. avoid the way : for pure technical problems do not intervene, if his technology implementation is really a problem, the relevant person to be responsible for the product only to pay attention to whether he finally achieved the expected function.

The delivery of the solution is uncertain, developers hate "in fact this can also", "otherwise it is", they need a clear solution. When a variety of options are hesitant to think, PM it's best to just put such indecision into your own thinking. Unless the engineer is unable to implement your first plan, then say the alternative.

There is no need to reserve the time, " This we modify, tomorrow to submit a new version, a look, listed a lot of added functionality, not just modify." Coder is really not God, the added function is to be tested. PM give yourself time to stay at the same time, poor poor siege of the wet, save some time to think about it. "This is the exact words of an engineer. PM to be responsible for the progress, the pressure is very large, but set aside time is a must.

Not entirely avoidable but can be improved in the short term:

requirements Change, which is the highest rate of the answer in a vocabulary. However, for developers to be disappointed, for a variety of reasons, this problem can not be completely avoided, PM can do is to try to make as many problems as possible before the delivery of development, so as to minimize the need for possible change, the other is to eliminate the need for reciprocating changes, Do not feel that it is not possible to change from programme A to programme B and change back to programme a.

Oral sex Too many times : To avoid verbal confession, obviously unrealistic, and then the perfect document can not replace the head of the direct flow. But frequent mouth (head) (flow) may interrupt the engineer's train of thought and delay the progress. PM can do one is to try to improve your document, the second is to try to focus on a verbal communication as much as possible, so as to reduce the number of times.

To be improved by long-term accumulation or exercise:

lack of charisma: Yes, the lack of personal charisma has also become a reason engineers hate PM. But the personal charm of this thing, it is really difficult to improve in the short term. Even, different engineers will have different standards for the judgment of personal attractiveness.

Lack of experience: or qualifications are not deep, to change the status quo, I am afraid it will not be immediate.

Above, to pasted.