关于做web产品某些细节方面的改动，有的时候技术不愿意轻易改动（也包括前端人员），有时候想法会很多，但他们有时候不在乎你所说的。这时我们应该怎么办？

我们来看看知乎网友的回答：

吴伟

以我7年来做pm的经验来看，说服他人，特别是研发、设计、前端这些研发部门的同事，最重要的不是口才、沟通能力和数据，而是专业。专业就是：第一，你要用内行的思维方式、表达方式和处理方式来思考、沟通和执行；第二，你要经常可以做出正确的决定。

一个人要先相信你能说出正确的话，才有可能认真去听你说的内容，进而才有可能认可你的话。通常人们认为只有内行才有可能说出正确的话来，而外行只能瞎指挥。所以pm要时时刻刻表现的很内行，很专业。

有些pm很苦恼：我明明说的是对的，为什么研发人员听不进去？是的，你说的可能是对的，但是由于你平时的表现让研发人员觉得你很外行，他们根本就没有认真听你在说什么。

只有尽量多、尽量深入的了解上下游相关岗位的专业知识，并且有一定的实践经验，才能让我们显得专业。在与相关岗位的沟通中，获得对方的信任感，进而采纳我们的意见。

有几个小技巧可以介绍一下，不过在看这些技巧之前，我必须重申一遍：让自己变得专业的根本办法是自己要尽量多的了解各个岗位的专业知识，小技巧只是一种手段，不要幻想着只凭借技巧就能真正的专业起来。

技巧1：尽量说术语。在我们与研发人员沟通的时候，尽量不要说大白话，而是使用术语。这样会让人家感觉我们很懂技术。例如有一次我和一个客户端工程师说：“我希望弹出的窗口是模态的。”工程师听完后很诧异的说：“你还知道模态？”我说：“当然啦，这对交互设计很重要啊。”于是工程师立刻就把窗口改成模态的了，根本没问我为什么。那么什么叫模态呢？用大白话说就是弹出一个窗口，窗口以外的地方都是黑的，或者不可以操作，只有这个窗口可以操作，类似于win里面经常弹出来的讨厌的错误提示。但是你要是跟工程师这么描述，碰上脾气好的说不准帮你改改，碰上不好的准保反问一句：那多讨厌啊，我就讨厌win弹错误提示。

技巧2：思维要周密，在说话之前要尽量把所有可能的情况及其解决方案想清楚。比如你要修改一个按钮的位置，人家自然要问你，空出来的位置怎么办，改过去之后会不会影响现有的功能，用户能不能习惯等等，如果你能胸有成竹的一一化解，别人自然会听从你的建议。

技巧3：让对方自己得出结论。人都是有自尊心的，都希望自己的决定是正确决定，如果你总是说：“你这样是错的，我是对的”必然引起别人的反感。所以你可以先把遇到的问题摆出来，在提出自己的解决方案后立刻说：这方面你是专家，如果你觉得这个方案能用就用，如果有更好的方案我也没什么意见。

人嘛，通常都是比较懒的，既然你能提出一个还算说得过去的解决方案，而且又让对方觉得是他自己的选择，通常也就不会为难你了。

技巧4：看人下菜碟。不是对每个都用同样的话说服的，人和人都有所不同。以我的经验，对待工程师、设计师、老板是不同的。

对待工程师要有条理，逻辑要清晰，讲究数据。例如：方案1会造成数据服务器负荷过重，并发量在2万/秒以上，并且至少要占用10g的储存空间，最重要的是，我们付出了这么大的代价，其实只满足了20%的用户，而且这部分用基本上都是不付费的用户。这一大套话说完，研发人员会认真想一想：也是啊，万一服务器宕机了责任就大了，还是用方案2吧。

对待设计师要以情动人，因为设计师一般都是学美术出身的，特别感性。例如：大姐，你就给我改改吧，为了画这个原型我昨天都加了一宿班了，你今天不改，明天指不定又插进来什么活儿呢，我这个项目得什么时候上线啊。再说也不是我想改啊，是销售那边儿一会儿说用户喜欢这个，一会儿说用户喜欢那个，我们也拧不过他们啊。设计师一听，都是同事，谁还没个难处啊，得了，加班儿给人做了吧。

对待老板要学会画蓝图，例如：根据竞品研究的结果看，这个产品非常有前景，XX刚上线1个月，就已经有100万用户，10万同时在线，收入也差不多有400来万。我们在技术上、渠道上、政府关系上都比他们强，我觉得只要能够在2个月内推出，各项数据肯定比他们强。更何况，我们的产品线目前缺乏的就是用户沉淀，而这个产品正好提供了强大的社交功能，弥补了产品线的空缺。老板一听，小伙子想的挺清楚啊，成，给你两个工程师，一个设计师，1万块项目奖金，1个月给我做出来。业绩好的话再给你发年终奖。

当然啦，还有些人江湖气很浓，他只要当你是兄弟，你怎么说他怎么做，没原因，没为什么。对于这种人平时多吃几顿饭，多送点小礼物，到时候自然帮你。

技巧5：人格魅力。做人要有幽默感，要学会缓和气氛。没必要每次需求讨论的时候都板着脸训人。说说笑话，插科打诨，给设计师倒杯水，给工程锤锤肩，送给运营的小姑娘几块儿巧克力，给运维的同事买几瓶水。你平时这么注重积累，在你需要的时候别人自然不会为难你。能做的就做了，不能做的睁一眼闭一眼也就做了。

最后再说一遍，所有的技巧都是一种手段，真才实干才是王道。

孙立伟

这里PM是指Product Manager还是Project Manager?我猜是前者吧。

从用户需求到功能设计到实现，在多人团队中是一个沟通和妥协的过程。简单的说，产品经理提出需求，项目经理主要负责分析论证需求，开发人员主要负责编码以实现需求。但实际情况是，据我粗浅的认识，目前很多小公司做网站，仅仅配一个产品经理，其余都是开发人员，而且常常没有测试。所以产品经理和开发人员的矛盾就更加突出。产品经理不懂技术，或者对技术一知半解，常常觉得“某某功能有什么难的，只需要….”。而从软件开发人员的角度来说，通常的问题是由于网站需要快速开发/快速发布，一开始仅仅为了实现功能而编码，很难去考虑设计问题。代码基础没有打好，尤其不适应改变，导致修改一个功能要涉及太多的方面，因此很容易产生抵触情绪。并且很多开发人员，对产品本身也有很多自己的想法，当产品经理提出的功能需求不能被很好的理解的时候，双方也容易出现矛盾。

私以为，每个人都需要明确自己的主要职责在哪里，这是沟通顺畅的第一步。产品经理提出的功能，需要依赖开发人员的透彻理解和消化，然后才能实现。软件开发人员也必须明确自己的职责，知道自己对产品功能和设计的认识一定不会比产品经理更深，自己的本职应该是尽力去保证软件的质量，做好软件设计。

代码是软件开发人员一行行写出来的，不论好坏，都是他的劳动成果。每个人对自己的劳动成果都有一个下意识的保护心理，我不知道心理学家是如何解释这种现象，但这确确实实是存在的。代码的修改和重写否定在某种程度上都是对其劳动成果的否定，这常常会引起开发人员下意识的抵触。

不论公司/团队大小，不论职位高低，有四个字是必须遵守的，就是“以理服人”。产品经理不要把软件开发人员仅仅看作是一台编程机器，而开发人员也不要觉得产品经理什么也不懂就“指手画脚”。不论是谁，都不要觉得自己的观点是有多么正确，别人就应该接受。坦诚的沟通，才能够达到最好的效果。

有一个比喻，我忘记出处了，说“每个软件开发人员就像一只骄傲的猫”。个人觉得，要管理好软件开发人员，起码需要一个专门的角色，不管是叫Project Manager还是Team Leader，需要他/她懂技术懂管理，让其他开发人员认同。

我个人不认同“什么什么是谁的责任，你不用担心。”这种观点。这种说法虽然在道理上是说得通的，但是在实际工作中不见得奏效。原因有二：

1. 软件产品是整个团队合作的劳动成果，这种观点更多的会容易误导团队，造成”个人自扫门前雪“的氛围，这对团队建设是有害的。我们应该强调产品的质量是每一个人的责任。

2. 如果一旦出了问题，比如是PM的责任，你能怎么样？扣工资？扣奖金？还是公开道歉？自我批评？然后呢？问题最终还是要解决，还是要依赖PM和开发人员一起来解决问题。

因此我觉得，尽管每个人都有自己专长的领域，但是不要过于对自己的观点或者劳动成果过于保护，应该保持一个开放的心态，能够善于倾听别人的观点。有则改之，无则加勉。

延伸阅读：产品经理如何赢得程序员的尊重和支持？

本文系站长之家整理自知乎网，转载请注明出处链接。