How technicians participate in product design discussions: activating the backwater

Intermediary transaction http://www.aliyun.com/zixun/aggregation/6858.html ">seo diagnose Taobao guest stationmaster buy cloud host technology Hall

Most of the time, programmers and product managers in a project sense is completely different, like two elephant, a hope to touch the cow, a hope to touch the bread, obviously both are not rational.

CTO Club Member, General manager, chief architect, Wang Zhaofa, Shanghai Software Technology Co., Ltd.

So in project management, we're going to introduce iterations and increments. Iterations allow the software to continuously refine an attribute, incrementally supporting the gradual delivery of all features. The combination of the two can be constantly trimmed to approximate real needs, early exposure and risk avoidance. In the project exchange, there are three misunderstandings that are often encountered.

Myth One: Technical staff constantly overturn the needs of product managers

In some traditional enterprises, technical personnel are often authoritative, and product managers are often new or promoted senior executives, whether product managers or technical backbone, are subject to their career planning and vision of the impact of the entire company or the entire project to the visionary planning, and enterprise policy makers are free from the technical backbone and product managers, Often results in the collapse of the entire project's needs and objectives.

In the end, this phenomenon is often characterized by: products through the implementation has been done, and finally in the technical staff that became a "server does not support Deployment", the final outcome; or performance as: Product manager finally made a demand, and can implement, after the lecture, the technical backbone said "sales department has tried this technology, Now the client does not support, training salespeople to use the software for at least three months ", so that the entire demand collapse.

Misunderstanding two: technical personnel too much or too much to read the needs of product managers

Too much interpretation of demand is in fact a disregard for demand.

What we often encounter is that when the project cycle is over, the whole project is not half done, and the idea gathered during the discussion is "does the product manager say that the UI interface is important?" We have designed 8 sets of interfaces, as for the software core we have not started "," the product we have planned the mobile phone, PC and tablet three media, so we tested on three platforms, and the software code hasn't started yet.

Misunderstanding three: technical staff indifferent to demand

The phenomenon of the technical staff indifferent to the demand is often expressed as: do you want me to do mobile projects? But my PC client is still developing it? You want to write code, but we are still doing the training of the last project.

For the above three kinds of misunderstanding, demand and development asymmetry, the key lies in responsibility, goal and performance. It is easy to understand that if a new project is suddenly implemented by an old-fashioned team, and if the implementation is not agreed to be punished, or if the implementation of success will no longer use the old standards to maintain the software, imagine the whole team members of the resistance is how strong.

To solve the communication error, and create a happy communication atmosphere, the implementation of outstanding works, is not without the solution. I have been engaged in web development and team management for many years, sharing four experiences here.

Experience one: Full-time to do special things-do not have a complex business requirements or excessive luxury

The mistake that people tend to make is that they have too much demand for others. We certainly hope that the cleaning staff aunt can write excellent code, on the hall, got the kitchen, but this is the phenomenon of great perfection, often finally do nothing.

So in the management team process, tell the team: you do not need to have too much implementation, you only need to concentrate on doing one thing, and after work will be happy to go home, the next morning there will be an incremental demand list and so you implement, will not let a programmer to do "demand collection", also won't let an art to "by the way write CSS" such a demand.

The idea seems conservative, but the facts are effective and safe. It is impossible to ask all members to be compound talents, what employees can do and what to do, long to be their own boss.

Experience II: No matter what the outcome, you give me first, the responsibility I will bear

The project manager or Product manager is the first to assume responsibility, as a manager to instill in the team the idea is: you just according to my needs to do a good job, all the responsibilities I will take. Only in this way can we build a team that dares to retreat, rather than simply blaming the members for their responsibilities.

The premise of taking responsibility is not only courage or boldness, but also wisdom. Often the manager can see the level that no other member can see. It is conceivable that when the iphone was developed, it was invested in technologies such as screens, sensors, and mobile Internet, while members of the Macintosh team who were originally involved in PC development were not able to understand it, but the technology was well integrated into the product.

In our project management also needs the "black box promotion, after the series" ability. For example, the prospective arrangement of members in the UI, hardware, software, requirements and other aspects of parallel development, and afterwards can be good to these technologies "dry" integration, even if the team members have discrete, will not affect the entire project.

Experience three: With the same robe, together

What is more important than equality? Working with team members, getting off work, eating fast food, and finding solutions together are far more effective than a paper document or a high horse. Do not expect through teleconferencing, QQ, Mail can solve all communication problems, face-to-face communication, is always the most important sensor channels.

Experience Four: Can not speak, but there are tools to get you involved

Some people say: there is a difference in demand, the implementation of a soft rib, then the meeting to solve Bai. "Program apes" are often verbally expressive of the weak, or ignore verbal communication (in fact they are not incapable of communicating, and tend to be silent at the meeting, complaining about the myriad and active on social networks), for the simple reason that "writing code is already very tired, why communicate so much", "I am not a manager, Why to participate in the Exchange "," I only earn code programming money, and no one pays me to participate in the exchange of payment.

In response to this phenomenon, the manager should allow and give full respect, we have to do is: Allow dumb members, but I will have other tools to get you involved. Including online surveys, monthly reports, team development, logging, Report collection, and even birthday party, on the basis of the same robe with staff, fully let the staff to communicate, so as to resolve the gap between communication.