How do programmers "smart fights" product managers and product managers

How do programmers "smart fights" product managers and product managers

RD and PM are well known over the years,

In every project iteration, RD is hoping to get more "free time", which can be used to sharpen energy or learn technology. PM hopes to use RD as efficiently as possible and implement the PRDs piled up by himself as quickly as possible. It is hoped that no matter what the problem occurs, do not extend the performance. This is also the most direct contradiction between the two.

But is there a general solution to the similar problem repeated every day? Adhering to years of experience with PM, we will discuss the following from the eight points below:

• Obtain

• Reasonable human feelings

• How to put pressure on PM

• Never be soft in front of this confrontation

• The villain and the gentleman

• How to cut requests

• The pot should not be backed up

• Role conversion between work colleagues and Life Friends

 

1. Obtain

Some PM is very aggressive, and it seems that I have not discussed it. There are several reasons for this (high level, an important demand for higher-level captioning, or something that I did recently with confidence and confidence, or you may look down on RD and think that you can only work.) This kind of person is very annoying. It seems that only he has his own product thinking, and others are pawns. It must be estimated several times more, the demand for 12 days is estimated to be 18 days, and he will definitely contract the time, because he certainly does not want to suffer, just wants to squeeze you. Sometimes you need to change three requirements. If you think you can only change two, you can change the value at most ~ 2. In this case, everyone has an understanding of it, but we will not go into details here.

 

2. reasonable human feelings

The change of PM posts is more diligent than that of RD posts, and there are often some PM posts that are relatively inactive soon.

Sometimes he knows his own mistakes (where the requirement document is written to produce ambiguity, or which scenario is missing) and wants to ask you to change the requirements. If this place is very easy to change, you have a lock on your brow (difficult to install) and said, "Hey, what was the demand at that time, I will help you change it later in the evening. "or" Hey, well, I have to rewrite some of my previous functions ". In fact, it may be an if branch or a loop algorithm. The PM will immediately say thank you... thank you for understanding... I am in trouble .... you have to work overtime... I tried it once and changed it every second. Then I watched the development documents very late at night. The new PM was so timid that I was too embarrassed to help him change his needs, every time we meet each other, we are very polite.

Iii. How to put pressure on PM

Scenario: PM said in the group: here we changed to this logic... obviously this is not good for us. We need to put pressure on him to give up.

Method 1: All groups (such as Android and iOS) that pull their own groups or other groups reply in the group, "you can't change it !" , "There is no way to change it !", "I have finished writing about the past !" PM looks at the screens in the group and the chrysanthemums are tight...

Method 2 (scare the layman) "The risk is uncontrollable if this is the case !", "This change may be in conflict with our XX component.", "We need to refactor this change !" (PM is afraid of "refactoring".) PM thought I didn't understand it either. It's so serious. forget it...

Method 3 (Major Issues) "This change requires sending an email to both sides and sending a copy to the superiors". PM thought that I would not want to disturb the boss.

 

4. Never be soft in front of the confrontation

Sometimes, the landlord was speechless by PM. At that time, he had no experience and was sulking for a week. This is just like, in college, sometimes it's hard to say who is arguing with you. At that time, maybe you were a hacker, maybe your head was stuck at the time, and you just gave up and thought about it later, I regret how I did it. I think the PM is the same, so it is never soft. I recommend that you do not have to worry about people. As long as you do not lose money, you must strive for the greatest benefit for yourself.

Some people may ask, too, that PM is also a good colleague. I will not see my head in the future. Is it okay to make a noise? Why is RD always so passionate about itself? Most RD is speechless. The PM is slippery, and it is a three-inch tongue. You want to get along with him, so you can be a fool. In fact, we can use the image of our dummies. If we say something too much, we can use "We RD has always been stuck in the Code and won't talk to anyone, don't worry about it. "It's like this strategy to clear your own white and reduce the crime. On the contrary, if you recognize the issue at the time, you can only rely on your own incompetence to change the bug after 12 o'clock overtime.

Aunt and the food-selling barrier said that the food was not fresh, and that the raw material price had increased, and that the food was finally bought after the quarrel, it would be happy to meet later, it's not an enemy. This is also the case for bargaining with PM. The quarrel is not as serious as you think.

5. The villain and the gentleman

In the early stage of development, there is no convergence between the various rip-offs of PM... add demand will not be changed... the estimated time is many... when details are added, they are all re-estimated... where did the PM miss the branch and immediately proposed to make the PM lose face... in the first version, the PM's hate for you has reached the peak !! Then, after the normal release of the version, you can take the initiative to show it to the PM to appease him. For example, during lunch in the canteen, you can praise him for the demand of this version; what tools are used to draw those flowcharts so well? You need to write them clearly and I can develop them smoothly. For example, at the version summary meeting, everyone was in a relatively relaxed mood. You can say that our version was released on time without delay, and PM was indispensable! Strategizing !...

In such a version, you are neither tired nor wronged. PM is also able to appease the problem. Everyone is a good colleague and the result is very good. Many RD do not say that these round scenes may be introverted or unnecessary. These are immature performances. I want to ask you a question. You have a superior, a leader, and don't talk at ordinary times. Is it necessary to send a group of good Year's greetings?

 

6. How to cut down requirements

Method 1: (Priority Method) after the PM goes out of the demand pool, make sure they list the priority. Directly cut down the lower priority.

Method 2: (scenario weakening method) in some scenarios, which may hardly occur, but most bugs are prone to overlay in extreme scenarios. The demand for such places should be simplified from the very beginning. You can use the tracking tool to check that some of the requirements are useless. In turn, the black PM is used.

Method 3: (do not eat crabs) do not eat crabs means not to step on the first pitfall, when people think that PM's demand is unreasonable, let him find out which other companies in the industry have done this function? You can find an example. This is very useful. Some PM and UI are just like you and he said that I can do what people can do, and I will not do what people can't do. If your attitude is very tough and many unreasonable demands can be filtered out, or you can use common practices in the industry, it is relatively simple. Generally, it is difficult to find Industry examples for unreasonable demands.

Method 4: (Value Method) Is there a lot of demands, but is it worthwhile to do so? I could have used system components. Do you have to write a custom control separately? Some component users are basically useless, and it is unreasonable for you to put so much energy into it.

Method 5: (helpless) estimate the time, and confirm the launch time. I just can't do anything about it. Otherwise, you can go to another group to see if you can borrow someone, otherwise, the launch time will be postponed. This is a big truth.

7. You should not back the pot

The most feared part of the work is to do some laborious and thankless work. After the development, all the requirements that may cause risks in the future must be rejected or declared as risky. Sometimes, when the PM needs to be changed or delayed due to a third party, it must be clearly stated in the extension email, because many higher-level officials are not very clear about what happened below, sometimes you think that everyone else knows that there is no need to declare that. If you ignore this point, it is your own loss. What others saw was that you were still raising PR in the last few days, and thought you hadn't done it yet. I don't know if it was the PM change requirement. Our company has a Task tool, and some bugs are not your pot. You must comment below. I can change it for you, but not my pot or product bug.

Another point that needs to be stated in advance is the time consumption at the engineering level. For example, a low-level product thinks that you can change the logic for 1 minute. In fact, you need to go through: pause the current development branch → switch to the stage branch → pull code → create fix branch → solution → self-test → submit pr → review in the group and merge → deploy to jekins-ci package → download the new package on the Intranet. The Compilation Time is not counted in the middle of so many steps. If it is Android studio, wait for it. iOS xcode compilation is quite fast, but if it involves pod install, it will also have to wait. You don't know what they do, so before they say, "Why are you so slow?", they must give them a popular science.

8. role conversion between work colleagues and Life Friends

Similar to Kobe James in the NBA, he is an opponent on the game and a friend on the game. This is not to say that you should be an opponent with PM at work. The focus is on your own network of contacts, however, to let them know that everyone is spraying each other for their work, it does not affect everyone in life or friends, and their career is also a network of contacts. Some of the previously controversial demands almost joined the PM group and won't directly connect with us. We are still old acquaintances who say hello and sometimes invite games. Sometimes the demand between two men is better solved. After a long time, people gradually know the bottom line of each other. When the supply and demand are not correct, they also know that this is the reason for the superiors on both sides, do not scatter your anger on your friends. In contrast, the relationship between men and women is more complex. Girls are not very rational about the bottom line unless you are handsome.

 

There have been too many business demands recently, so I have not been able to grow any further. I have compiled this article in the hope that it will resonate with you.