How to win the respect and support of developers?

For product managers, to win the respect and support of developers, in a sense, is the product to achieve a solid step towards success. Recently, the community of developers and managers in the first and last two posts in the intense discussion, there is no lack of insights.

Lin Zhilin Cray believes that product managers ' decisions and actions should serve the goals of the project, not to fight, and that team management should include:

1. Understand the art/front-end/back-end working principle.

If you know the art design main Menu hover two level of irregular projection will waste the front of a lot of time debugging, you can also imagine the front end to see how sad, you are in time to suggest to use rules to unify the transparency of the projection. If you know that the back end uses a for loop to output 20 or so structure of news listings, you should let the front end with CSS control automatically left and right layout, rather than split into two parts.

2. Give team members enough information and space.

These three occupations are not tools, especially back-end engineers. Second-tier programmers will also aspire to the myth of the moon, they can provide you with a reasonable and efficient architecture design. You have to give them enough information to give them the right time to complete a reasonable structure. Most of the front and rear engineers have a sense of achievement in the reuse and performance report, and you can provide as much information as possible to deal with them. This is also for their later maintenance and iterations to facilitate, you do not have reservations! If you really don't think carefully, can't hide, at last you can't even make friends.

3. Have the courage to communicate and learn.

The engineer told you to use velocity to edit the page, you don't understand, then ask. If he despises you, it's his problem, and it could be your problem. Most engineers would like to explain to you, they are also afraid of expression, this is a fix for both sides. If the engineer says that Oracle must be replaced from MySQL, you ask why, he said can't carry, you ask how long, he said to two weeks, you collapse but ask why, he said to write data conversion script, you ask why, he said that the data types between two databases require some transformations, and the rules of the index are different, You ask what is the index ... This is possible, you have to take a learning mentality rather than accountability, or he will be more disgusted. In the end, if you understand, he will think you understand him.

4. Handle changes in requirements with care.

This is an eternal topic. You can honestly say: the change of requirements is unavoidable, is constantly exploring and adjusting, as a PM I think I can not imagine the best, I am sorry. Then there is the skill to live, the principle is to avoid repeated changes as far as possible. If there is a page of data rendering, you can't imagine how better, you can use the Chrome Developer tool to adjust the view first, do not directly let the technology changes and as your reference. If you do not use tools to learn, it is complex you ask the technology output two effects to you, rather than change the said not to change back.

The 2nd is, if some of the data rendering module to be cropped, but it is possible to change the form of another place in the future, you need to talk with the technology to understand, let him just comment temporarily hidden. You don't know a simple data rendering it uses a cache or something.

5. A sense of accomplishment is the resonance you can give.

You want to know what all the students care about, material needs may you can not give, eat a meal of the fact is natural, do not have to deliberately. Fellow students step into the Internet, most of them want to mix in the door of a famous. If you have a chance, don't skimp on such praise. Code comments, Product introduction, report up the technical achievements of the students, encourage students to share technical experience in various channels. At the same time, appropriately agree with you on the architectural performance of new ideas new ideas, including interactive experience should also give front-end staff to play space if they want. In fact, the most fundamental, you have to love the product and do your best, the product audience scope and influence is a natural sense of achievement.

6. Have the courage to play.

You bear some of the assessment of stress and material pressure, students can be more energy into the work. Working for you, you can do so. Especially when the project fails, how may not have nothing to do with you, should not push the push should not be pushed, why did you go? If the project members ability problem and attitude problem, early reflection, said that the best way to go on the results, the problem to throw to your head.

Stray cats give some examples of personal experience:

1. Flexible to work, the matter of the decision is often not find people.

The former boss himself first to implement flexible work system, the afternoon, the technical manager often can not find him, we dare not go to the decision. Even if the problem is solved, the technology will feel you are not at all nervous. Project (product). Even your own children are not nervous, who for you to nervous.

2. The front-end to do want to vomit.

Talk to the previous boss about the project (my opinion is that the first edition does not have to be too exquisite, can be iterated on the line later, his opinion is that the first edition should be very outstanding, in order to better request resources later). The boss told me about his previous experience: He said in the previous company to do, they planned the effect of N, because the planning out of the time point of comparison, resulting in the front-end Cetucci to vomit, finally or on schedule, advised me not too much to consider the implementation of the problem. At that time I thought, just for those effects and the other colleagues to get the feeling of death, it is worth it? What is the comparison between efficiency and cost? How do you know those effects are good? or bad? Anyway, in the end, the project still has a variety of effects, but also let the design plus three weeks of classes, technology to the last line, Continue to do the next morning (the next day is the company's annual meeting).

3. Technical overtime, the products run to eat.

On the line deadline, the former boss ran to eat with people (account for the background, during the planning, he often went out to eat to see the film, I and another planning are just out a few times, Weeks 6th), and technical brothers and sisters are fixing bugs. I and another planning constantly in check, there are problems immediately feedback repair. A manager came back 10 o'clock night, I immediately scolded him: People's technology is working overtime for our project, dinner is to eat biscuits, drink soda, you also go out to eat? Is that too much to be justified? I was scolded for a meal, a manager immediately made a McDonald's takeout, but also to make amends. Later on, I asked a manager to pay his own money to the technology taxi.

4. The project failed with no follow-up feedback.

My personal opinion, even if the project fails, as a project or product sponsors, all need to tell you the situation (except special circumstances), in the final summary. Then in please everyone eat ah, everything is good, after all, we have to work hard to pay, even if the failure, but also to console.

Wu with its 7 years of PM experience, persuading others, especially those in research and development, design, and front-end research and development departments, is most important not in terms of eloquence, communication skills and data, but professional. The major is: first, you need to think, communicate and execute in an expert way of thinking, expression and handling; second, you can always make the right decisions. He introduced several tips:

1. Try to say the term.

When we communicate with developers, try not to say plain, but to use terminology. It makes people feel like we know the technology. For example, once I and a client engineer said: "I want the pop-up window to be modal." After listening to the engineer, he was surprised to say, "Do you know the mode?" I said, "Of course, it's important for interactive design." So the engineer immediately changed the window to modal and didn't ask me why. So what is modal? With Plain said is a pop-up window, outside the window is black, or can not operate, only this window can operate, similar to Windows inside often pop-up annoying error prompts. But if you describe this with an engineer, you'll get a good temper and you'll have to change it, bump into a bad one-way: that's annoying, I hate windows bombs.

2. Think carefully, and try to make sure all possible situations and solutions are clear before speaking.

For example, you want to modify the location of a button, people naturally want to ask you, empty out the location of how to do, change the past will not affect the existing functions, users can not be accustomed to, and so on, if you can solve the solution, others will naturally follow your advice.

3. Let the other party draw their own conclusions.

People have self-esteem, all hope that their decision is the right decision, if you always say: "You are wrong, I was right" will inevitably cause other people's disgust. So you can first put the problems encountered, in the proposed solution immediately after you said: "You are experts in this area, if you think this program can be used, if there is a better plan I do not have any opinion." People, usually lazy, since you can come up with a reasonable solution, and let the other party feel that it is his choice, usually will not embarrass you.

4. Mas dish.

Not everyone is persuaded by the same words, and people are different. In my experience, treating engineers, designers, bosses is different. The engineer should be organized, the logic should be clear and the data should be fastidious. For example: Scenario 1 will cause the data server overload, concurrent volume of 20,000/sec, and at least 10g of storage space, most importantly, we pay such a large price, in fact, only meet 20% of the users, and this part of the basically is not paid users. This big set of words, developers will seriously think about: Ah, in case the server down the responsibility is big, or with the plan 2. Treat the designer to be feeling moving, because the designer is generally the art origin, the special sensibility. For example: elder sister, you change to me, in order to draw this prototype I have added a class yesterday, you do not change today, tomorrow refers to what kind of work, I have to do this project when online AH. Besides, it's not that I want to change Ah, is the sale over there for a while said users like this, a while said users like that, we also screwed them ah. Designers listen, are colleagues, who has not a difficulty ah, come on, overtime to people to do it. Treat the boss to learn to draw a blueprint, for example: according to the results of competition research, this product is very promising, xx just on the line 1 months, there have been 1 million users, 100,000 at the same time online, income is almost about 4 million. We are better at technical, channel and government relationships than they are, and I think that as long as they can be launched within 2 months, the data will certainly be stronger than theirs. What's more, our product line is currently lack of user precipitation, and this product just provides a powerful social function to make up for the product line vacancy. The boss listens, the young man thinks quite clearly ah, into, give you two engineers, a designer, 10,000 project bonus, 1 months to make out for me. If the results are good, you will be rewarded with an annual bonus.

5. Personality charm.

A person must have a sense of humour, to learn to ease the atmosphere. There is no need to have a straight face every time a need is discussed. The joke, the gag, to the designer poured a cup of water, to the project hammer shoulder, to the operation of the little girl a few pieces of chocolate, to the operations of colleagues to buy a few bottles of water. You usually so pay attention to accumulation, when you need people naturally will not embarrass you. You can do it, you can't do it with a blind eye.

Hexybaby's experience summary includes:

1. As far as possible after the determination of the need to submit development, requirements change to give sufficient reasons.

2. Be ready at all times and try to solve any technical problems with the shortest possible time. such as interdepartmental coordination, documentation and material preparation.

3. Yanzhiyouwu, do not say empty Conreton words, sharp, clear description of the needs of thinking.

4. Modesty and prestige coexist, do not know to ask, humbly accept the technology put forward product advice, but the principle of compromise.

If you have any suggestions, please feel free to express your views.

Trikon Enthusiastic technology Explorer, Senior Software engineer, INFOQ Editor, engaged in enterprise-class Web application related work, focus on performance optimization, Web technology, browser and other fields.