林志霖 Cray 认为产品经理的决策和行为都应该为项目的目标服务，不要热衷于斗争，团队管理值得注意的几点包括：
- 了解美术/前端/后端工作原理。
如果你知道美术设计主菜单悬停二级的不规则投影会浪费前端大把的时间调试，你还能想像前端看到了多难过，你就及时建议改用规则统一透明度的投影。如果你知道后端用 for 循环输出 20 条左右结构的新闻列表，你就应该让前端用 CSS 控制自动左右布局，而不是左右拆成两份。
- 给团队成员足够的信息和空间。
这三个职业都不是工具，尤其后端工程师。再初级的程序员也会向往人月神话，他们能为你提供合理的高效的架构设计。你要给予他们足够多的信息，给他们留出恰当的时间，让他们完成合理的架构。前后端工程师大多对复用和高性能报有成就感，你尽可能提供多的信息，由他们来处理。这也是为他们后期维护和迭代提供便利，你不要有所保留！如果你真的思维不缜密，藏不住的，最后连朋友都交不成。
- 勇于沟通和学习。
工程师跟你说以后用 velocity 来编辑页面，你不理解，那么就问。如果他鄙视你，那么是他的问题，也可能是你的问题。大多数工程师愿意给你讲解的，他们也害怕表达，这是双方的修为。如果工程师说必须从 MySQL 换成 Oracle 了，你问为什么，他说无法承载了，你问要多久，他说要两周，你崩溃了但是问为什么，他说要写数据转换脚本，你问为什么，他说两个数据库之间数据类型不同需要有一些转换，索引规则也不同，你问什么是索引……这都是可以的，你要带着学习的心态而不是问责，否则他越答越反感。最后你若懂了，他会觉得你理解他。
- 小心处理需求变更。
这是个永恒的话题。你可以坦诚表达：需求变更是难免的，是不断探索和调整而来的，作为 PM 我自认无法一次性想到最好，很抱歉。接着就是技巧活了，原则是尽可能避免反复修改。如果有一个页面的数据呈现，你无法想象怎样更好，你可以用 Chrome 开发者工具先去调整查看，别直接让技术修改并当作你的参考。如果你不会用工具可以去学，实在复杂你就恳请技术输出两份效果给你比对，而不是改了说不好再改回去。
第二点就是，如果有的数据呈现模块要裁剪，但有可能日后换个形式换个地方呈现，你就要跟技术说明白，让他只是注释暂时隐藏。你不知道一个简单的数据呈现它用了缓存还是别的什么。
- 成就感是你能给予的共鸣。
你要知道各位同学都在意什么，物质需求可能你无法给予，吃个饭之类的其实是顺理成章，不必刻意。各位同学踏入互联网江湖，大多想在各门各派混出个名堂。如果你有机会，不要吝啬这样的称赞。代码注释，产品主创介绍，向上汇报各同学的技术成果，鼓励同学往各渠道分享技术心得。同时适当认同各位在架构性能上的新想法新思路，包括交互体验上也应该给前端人员发挥空间如果他们愿意。其实最根本的，你要热爱产品并竭尽所能，产品的受众范围和影响力是个天然的成就感。
- 勇于担当。
你多承担一些考核压力和物质压力，同学们才能更有精力投入到工作中。同为打工的你，能做的不过如此了。特别是当项目失败时，怎么可能跟你没关系，该推的不该推的都不该推，早干嘛去了？若出现项目成员能力问题和态度问题，尽早反映，说按此下去结果最好只能如何，把问题丢给你的头。
流浪猫则举了一些亲身经历的反面教材：
- 弹性上班，拍板的事情经常找不到人。
前任上司自己首先实行弹性上班制度，下午才来，技术经理经常都找不到他，我们也不敢去拍板。就算问题是解决了，技术也会觉得你一点都不紧张项目（产品）。连自己的孩子都不紧张，谁替你去紧张。
- 前端做到想吐也要做。
跟前任上司讨论关于项目的问题（我的意见是第一版不用做得太精美，以后可以迭代上线，他的意见是第一版就要做到很出众，以便日后更好地请求资源）。上司跟我谈到他以前的经历：他说在以前公司做，他们策划出的效果有N种情况，由于策划出来的时间点比较靠后，导致前端切图切到想吐，最后还是如期上线，劝我不要太过于考虑实现方面的问题。当时我就想，就为了那些效果而把别的同事搞到想死的感觉，值得么？效益与成本对比如何？你咋知道那些效果就是好的？或者是坏的呢？反正到最后，那期的项目还是有各种效果，同时也让设计加了三周的班，技术到最后上线的时候，连续做到第二天早上（第二天是公司年会）。
- 技术加班，产品跑去吃饭。
在上线 deadline，前任上司跑去跟人吃饭了（交代下背景，在策划期间，他经常都出去吃饭看电影，我跟另外一位策划都只是出去过几次，周六日都在做），而技术兄弟姐妹都在修复 bug。我跟另外一位策划不断在检查，有问题马上反馈修复。某经理晚上十点回来，我立马就训斥他一顿：人家技术都在为我们的项目而加班，晚餐是吃饼干、喝汽水，你还出去吃饭？太说不过去吧？被我训斥了一顿，某经理就马上搞了个麦当劳外卖，还算是将功补过。后来我再提出，要让某经理自己出钱给技术搭的士。
- 项目失败了，没有后续的反馈。
我的个人意见，就算项目失败了，作为项目或产品的发起人，都需要跟大家讲清楚情况（特殊情况除外），在最后总结一下。然后在请大家吃饭啊什么都好，毕竟大家都是为了项目认真努力付出过的，就算失败，也要慰劳一下。
吴伟以其 7 年的 PM 经验来看，说服他人，特别是研发、设计、前端这些研发部门的同事，最重要的不是口才、沟通能力和数据，而是专业。专业就是：第一，你要用内行的思维方式、表达方式和处理方式来思考、沟通和执行；第二，你要经常可以做出正确的决定。 他介绍了几个小技巧：
- 尽量说术语。
在我们与研发人员沟通的时候，尽量不要说大白话，而是使用术语。这样会让人家感觉我们很懂技术。例如有一次我和一个客户端工程师说：“我希望弹出的窗口是模态的。”工程师听完后很诧异的说：“你还知道模态？”我说：“当然啦，这对交互设计很重要啊。”于是工程师立刻就把窗口改成模态的了，根本没问我为什么。那么什么叫模态呢？用大白话说就是弹出一个窗口，窗口以外的地方都是黑的，或者不可以操作，只有这个窗口可以操作，类似于 Windows 里面经常弹出来的讨厌的错误提示。但是你要是跟工程师这么描述，碰上脾气好的说不准帮你改改，碰上不好的准保反问一句：那多讨厌啊，我就讨厌 Windows 弹错误提示。
- 思维要周密，在说话之前要尽量把所有可能的情况及其解决方案想清楚。
比如你要修改一个按钮的位置，人家自然要问你，空出来的位置怎么办，改过去之后会不会影响现有的功能，用户能不能习惯等等，如果你能胸有成竹的一一化解，别人自然会听从你的建议。
- 让对方自己得出结论。
人都是有自尊心的，都希望自己的决定是正确决定，如果你总是说：“你这样是错的，我是对的”必然引起别人的反感。所以你可以先把遇到的问题摆出来，在提出自己的解决方案后立刻说：这方面你是专家，如果你觉得这个方案能用就用，如果有更好的方案我也没什么意见。人嘛，通常都是比较懒的，既然你能提出一个还算说得过去的解决方案，而且又让对方觉得是他自己的选择，通常也就不会为难你了。
- 看人下菜碟。
不是对每个都用同样的话说服的，人和人都有所不同。以我的经验，对待工程师、设计师、老板是不同的。对待工程师要有条理，逻辑要清晰，讲究数据。例如：方案 1 会造成数据服务器负荷过重，并发量在 2 万/秒以上，并且至少要占用 10g 的储存空间，最重要的是，我们付出了这么大的代价，其实只满足了 20% 的用户，而且这部分用基本上都是不付费的用户。这一大套话说完，研发人员会认真想一想：也是啊，万一服务器宕机了责任就大了，还是用方案 2 吧。对待设计师要以情动人，因为设计师一般都是学美术出身的，特别感性。例如：大姐，你就给我改改吧，为了画这个原型我昨天都加了一宿班了，你今天不改，明天指不定又插进来什么活儿呢，我这个项目得什么时候上线啊。再说也不是我想改啊，是销售那边儿一会儿说用户喜欢这个，一会儿说用户喜欢那个，我们也拧不过他们啊。设计师一听，都是同事，谁还没个难处啊，得了，加班儿给人做了吧。对待老板要学会画蓝图，例如：根据竞品研究的结果看，这个产品非常有前景，XX 刚上线 1 个月，就已经有 100 万用户，10万同时在线，收入也差不多有 400 来万。我们在技术上、渠道上、*关系上都比他们强，我觉得只要能够在 2 个月内推出，各项数据肯定比他们强。更何况，我们的产品线目前缺乏的就是用户沉淀，而这个产品正好提供了强大的社交功能，弥补了产品线的空缺。老板一听，小伙子想的挺清楚啊，成，给你两个工程师，一个设计师，1万块项目奖金，1个月给我做出来。业绩好的话再给你发年终奖。
- 人格魅力。
做人要有幽默感，要学会缓和气氛。没必要每次需求讨论的时候都板着脸训人。说说笑话，插科打诨，给设计师倒杯水，给工程锤锤肩，送给运营的小姑娘几块儿巧克力，给运维的同事买几瓶水。你平时这么注重积累，在你需要的时候别人自然不会为难你。能做的就做了，不能做的睁一眼闭一眼也就做了。
Hexybaby 的经验总结包括：
- 尽量在需求确定后再提交开发，需求变更要给出充分的理由。
- 随时准备着，并尽量用最短的时间为技术解决任何非技术问题。例如部门间协调、文档和素材的准备。
- 言之有物，不要说空洞的片儿汤话，一针见血、思路清晰的描述需求。
- 谦虚和威信并存，不懂就问，虚心接受技术提出的产品意见，但原则问题不妥协。
大家对此有什么建议，欢迎发表自己的看法。
本文出自： http://news.cnblogs.com/n/146085/