标签：算法 投票 约束 控制力 中心 ref 自己的 开发 请求
PM在YY...作为强势的技术来回答一下吧。说明白WHY，HOW，WHAT就好了。
我想点两个赞，u can u up，no can no bb 什么的。
微软的win8之父年轻时候也是一个PM应该是微软最伟大的pm之一了吧。他有一天和程序员起了冲突，程序员说必须有两周才能干完，他说项目等不及了。就这样冲突一直没有一方让步，直至一周后，这个PM带着自己写的code给程序员看，他只用一周就可以这些功能。所以产品经理还是要懂一些技术才能和程序员更好交流
我觉得碰到强势的工程师是一件好事。同时，别人拒绝你的需求未必是一件坏事。
作为产品经理，你的任务是：
1、想清楚需求，并且让合作者认同你的需求（觉得这个需求应该满足，有一定的重要性）；
2、想清楚解决方案，并让合作者认同你的解决方案
如果对方完全不认同你的需求，请考虑你的需求是否合理；
如果双方共同认可需求，只是你的解决方案被吐槽说无法实现。
此时问自己两个问题：
1、这个需求紧急么？
2、这个解决方案是唯一可行的么？
如果不紧急，那么慢慢的多次商量。我周围的人们就总说 念念不忘 必有回响。
通常情况下，请相信你的工程师，想另一个解决方案吧——车到山前必有路，一定会有其他解决方案。
首先，要让技术积极面对本产品，如果你的技术团队对本产品都抱怀疑态度或者根本没信心，他们是不会有主动高效地去完成产品开发的。
其次，又要讲人格魅力了。其实这东西很虚，所谓能依靠人格魅力来影响弟兄干活的人，我想也没有几个。不过我觉得，一般产品能做的，有这么几方面：不要把自己处于高点，你和做技术的弟兄是平等的，不要总是以责难、指导、下命令的形式来待人；要理解技术的苦处，要懂得体谅他们通宵加班的痛苦，有条件的情况下，和他们一起加班；适时请大家吃顿饭（反正公司报销，算借花献佛）；偶尔也要告知弟兄们，自己也受到上层的很大压力，适当地装一下可怜。
最后，要懂得一些技术（我说的是了解，不是精通）。一些逻辑性的东西，必须要懂得。如果技术说无法做，要和他坐下来沟通，看卡在哪一个具体的点上。譬如某一个功能做不了，不是简单地就做不了这个功能，要找到具体原因。这些技能，其实并不需要懂得如何开发，只要有基本逻辑能力其实还是能够做到的。如果确实是技术问题，可以向公司的技术中心求助（神马？你们公司没有技术中心？那找高手求助吧，武林高手在华山）
What‘s more？首先，要让技术积极面对本产品，如果你的技术团队对本产品都抱怀疑态度或者根本没信心，他们是不会有主动高效地去完成产品开发的。
其次，又要讲人格魅力了。其实这东西很虚，所谓能依靠人格魅力来影响弟兄干活的人，我想也没有几个。不过我觉得，一般产品能做的，有这么几方面：不要把自己处于高点，你和做技术的弟兄是平等的，不要总是以责难、指导、下命令的形式来待人；要理解技术的苦处，要懂得体谅他们通宵加班的痛苦，有条件的情况下，和他们一起加班；适时请大家吃顿饭（反正公司报销，算借花献佛）；偶尔也要告知弟兄们，自己也受到上层的很大压力，适当地装一下可怜。
最后，要懂得一些技术（我说的是了解，不是精通）。一些逻辑性的东西，必须要懂得。如果技术说无法做，要和他坐下来沟通，看卡在哪一个具体的点上。譬如某一个功能做不了，不是简单地就做不了这个功能，要找到具体原因。这些技能，其实并不需要懂得如何开发，只要有基本逻辑能力其实还是能够做到的。如果确实是技术问题，可以向公司的技术中心求助（神马？你们公司没有技术中心？那找高手求助吧，武林高手在华山）
What‘s more？
90后上司强势，其实是利用强势的外表掩盖经验与知识面的不足。但是经验不足的上司或许也有优点，例如人际关系可能相对简单，暂时不能纯熟地耍手段，和在你背后捅刀子，除非他性格特别黑暗，从小就腹黑。
作为程序员，架构师，但是同时自己兼任产品经理职位，并且经常和客户沟通的我来说一下我对于这个问题的体会：
1. “技术上实现不了”的技术潜台词：“技术上性价比不高”
技术上确实有性价比不高的东西。可能是和当前能力不匹配，可能是和技术选型冲突很大，也有可能是某需求的背后是众多大牛日思夜想要解决的终极难题。
“性价比不高”的意思是这条路可以走，但是走这条路会花费过多的资源：时间，人力，技术能力，业界对于某问题的一般解决水准，学术界对于某问题的前沿解决水准，相应的工具和技术堆栈。如果你的公司，团队，个人的目前的资源和水准并不足以挑战某些问题，则不应该给予此类问题过高的优先级。又或者要解决某些问题确实可以解决，但是解决所花的时间或成本会大大干扰主线任务，并且很可能导致工程超期，则不应优先解决。
2. “技术上实现不了”的针对PM的心态的潜台词：“你丫是傻叉”
你丫净扯些没有用的！不会写程序的PM不是好的需求方！懒得理你但是又不想直接说你是傻叉就用技术上实现不了这样的话！整天看些PM修炼集锦写些天花乱坠的文档搞些什么人性的设计真的大丈夫？你思想有多远我们就能跑多远么？你知不知道写程序也是一个工作，也是有轻重缓急和工作速率之说么？还有，写程序并不是从零开始的一个过程，每一段程序都有它的前后积累以及上下文支持的，并不是你一句话就说出来那么简单的。
导致这个问题的最主要的原因是：
PM方处理问题domain和程序员方处理问题domain本身的巨大认知鸿沟。
这个里面细讲出去就无穷无尽了，基本上要向程序员把全人类的所有方面都讲个遍，再让PM自己达到程序员的程序能力和经验，才能认识到上述鸿沟的巨大。这还不算解决鸿沟。
这个问题，和所谓的“我准备创业，万事俱备，就差一个程序员了”的问题是同一个问题，只不过后者表现地更加极端一些。
3. 如何（部分地）解决这个问题
广义的PM方，其实就是CEO，创业者，需求方，甲方，客户，以及市场。
广义的程序员方，其实就是架构师，CEO，创业者，以及自己所创造的技术/产品的需求方，第一个客户，和市场。
在大公司里面，这个问题基本是无法得到满意的解决的：
因为每个人的JD都限制了他的视角的扩大化。每个人都是他所在的局部信息孤岛的受益者和受害者。大家忙着满足KPI之类的东西，大目标是什么，也成了一个文档中写的东西。
而在小公司里面，或者创业团队里面，这个问题更加无法得到令人满意的解决：
看起来小团队会更容易形成共识，但是这个并非尽然。另一方面因为每个人的视角的扩大相应地要求他的认知水准和对于事，物，人，时，以及自己心态的把握能力要成倍地提高。而且一个人的视角和见识能扩张，但是他的技术能力的匹配度则很难以一个非常快的速度扩张，小团队会经常面临能力匹配不足够的问题。
4. 唯一的解决办法：强
解决办法就是变强：某人很强，你很强，你所在的团队很强，你的团队所能够匹配和动用的内部资源和外部支持很强。
怎么才能强？一个简单的办法是prioritize，做事有先后与轻重缓急，想问题也得区分重要度，要走的路径规划好了，又要能够坚持又要能够变通。不浪费资源，少浪费时间，战略和细节都不能差。全局想的清楚，局部看得明白，细部做得踏实，时间把握地恰当。能避难，也能迎难。真的要变强，需要错误试错和时间，也需要机会经验和视野。简单来说就是一个字，强人所难。
5. 小更新一下，“强人所难”的意思有两方面：
1. “强自己/别人所难”，就是勉为其难，把难以解决的部分，用耗时，毅力，其他方面的资源，其他方面的人员等办法，乃至于“拖字诀”（拖也是需要能力的，就是面对压力的能力），把这个很难的问题绕过去，或者变相地部分解决了，或者延后解决。强自己所难。如果push了别人，或者fail了别人，则是让别人为难，当然最后还是你自己为难。
2. “在大家都很难办的地方拥有超出寻常的强大能力”，就是说大家都趟不过去的河，你不知道怎么地就很轻松地过去了。比如说你是技术某方面技术超强，或者你是PM说服力超强，或者你是萌妹子让技术拿你没办法。在别人弱的地方你很强。
第一个强，强的是综合素质和心理素质，第二个强，强的是专业素质和专业能力。
这样你就能（部分地）解决（大部分的）问题了。
无法在技术上说服工程师，至少你们得在「目标」上达成一致或把技术说服。
大家都是平级，凭啥让工程师听你「发号施令」？
改需求只要说1句话10秒钟，人家要搞半天呢！
所以，让技术对要做的方案有认同，为什么这样做，为什么不那样做，目的是什么都讲明白。
甚至是，把备选方案也说出来，大家讨论。
只要目标达成一致，后面就好办了。
很重要的一点是意识到，公司雇佣你当产品经理的目的，就是为了让你带领一帮最优秀的技术人才， 设计人才， 数据科学家，律师等等做出好的产品。产品经理的作用， 不是让你做设计，搞技术，挖数据，因为你不是这些方面的专家。而是能够有效地利用好这样一帮人，让搞技术的人闪耀发光， 让设计师巧思灵动，让数据科学家柳暗花明，你就赢了。
所以，我的建议是，首先，要相信你们团队搞技术的人都比你懂技术并且承认这一点。我一般都会先说，你在技术上是权威，所以特别想请教你，从你的角度看怎么实现xxxxx。相信我，技术大牛最厌恶的就是产品经理自己屁也不懂却指手画脚，胡乱要求。要肯定他们的能力，问问他们想，好好讲讲你自己对这个产品的vision，问问他们如何实现。
第二点，如果技术不同意你的意见，研究清楚是为什么。是因为你们在乎的东西不一样（技术常常会在乎“这是一个碉堡了的算法”，而你在乎的可能是“到底大家会不会点这个按钮”。）还是因为你们对这个产品真正解决的问题没有达成共识。我的原则是，公司来的都是聪明人，聪明人之间意见不一致，估计是本身掌握的信息不一样，或者认定的目标不一样， 如果本身掌握的信息一样，认定的目标一样， 在乎的东西一样， 那你们估计多半会达成共识。
其实，很多产品不尊重技术，也不尊重人。
1，不尊重技术人员的成长；认为技术跟说话一样简单，一学就应该会，一点就应该通；
2，不尊重技术人员的时间；认为技术人员就应该去加班，认为技术人员的时间，就是应该由他们去支配；
3，不尊重技术人员的自我；认为技术人员满地都是，随便招一个就能把不听话的技术替代掉；
研发拒绝产品的需求，通常出于以下几方面的原因:
1. 欠缺尊重感: 作为产品经理的你，在心里是否真正尊重你们的研发人员？如果你并不认可研发人员，对方是能够感知的，继而产生本能的排斥，趋向于拒绝你的需求。
2.没有把需求赋予意义: 当你提出这个需求的时候，有没有同时告诉研发人员这样做的目的是什么？为了达成什么产品目标？人们总是对被赋予意义的事情更加上心。
3.需求逻辑不清晰: 排除了上面两个因素，那么最有可能导致需求被拒绝的原因就是你的逻辑不够清晰，或者逻辑上存在一些明显的的问题，这种就被称为不靠谱的需求。研发人员常常说，技术上无法实现可能是因为他们想不清楚你的逻辑要怎样被实现，也就是说你的逻辑是不清晰的。在这一点上，如果你有计算机的专业背景，一定会有帮助的，因为你会本能的去考虑如何用代码逻辑来实现人脑逻辑。你可以学习简单的编程，例如，把电影院订座系统的这个程序写出来，好好理解一下。
4.并非真是拒绝: 我发现有的研发人员是以拒绝需求作为一个讨论的开始的，他们只是说这个需求难以实现，其实是留了一个空间，让你跟他继续深入的讨论。这种情况通常是他们手上的事情非常多，已经产生本能拒绝的心态了，所以你就需要去论述你的需求具备更高的优先级。
1.产品经理懂技术是不是必须？
不是。每个职业角色都会碰到很多不同的对接角色，这些技能可没办法全学过来。
而且对技术难点的预判(不一定对)也会影响对产品的设计。
个人认为应该是产品大胆提需求，和技术沟通再减掉现阶段实现有困难的部分。
懂一些更好，可以提前筛去不靠谱的设计部分
2.关于关系远近
好沟通但能力不行，强势但能力一级棒，你选哪个，为了最后出好活，肯定要技术好的。
对方是否强势，个人觉得并不是问题，关键是作为提需求的你来说，心里是不是有谱，也就是你的能力行不行。
经济社会，大家都做好自己的事，关系好人家也不能陪你玩，满足你的烂需求，浪费自己的职业生命。一次两次成，多了则没戏。
所以多关注自己，你有理，你怕谁
3.过往经历
从自己经历来看，好的技术不仅coding技术好，而且思维缜密，能帮你过滤和改进，所以，沟通过程也是产品优化过程。
他们甚至能在业务层面给出好的建议，所以也要善待技术
前提就是找共同点，争取站在一条船上
产品经理和研发方一开始就是在两条船上。产品经理希望产品的功能越多越丰富越好，提倡做加法；研发方关注产品的稳定性和兼容性，提倡做减法。从某种程度上，他们天然是对立的。
当一个强势的技术在以“这个功能实现技术上无法实现”为理由来拒绝时，不管是因为资源不充分或者技术上有难度，其实质就是，坚持做会影响到稳定性。
产品经理不一定要很懂技术，但一定要从技术的角度出发来考虑问题。
这个需求是不是可以分解的？如果需求能够分解的话，那么就一定要分解，而让技术能够一步步实现。产品的质量和稳定压倒一切，需求盲目而快速的堆叠也许能够占一时的先机，但对不稳定的产品，用户一定会用脚投票，而一旦用户形成了某个产品不稳定有质量问题时的观念时，基本你就永远失去了这个用户和受他影响的一批潜在用户。
这个需求在同类竞争对手的产品中有没有实现？如果同类产品已经实现了，那么产品经理应该有8成的把握可以坚持自己的主张了。因为这意味着这不是一个不可能完成的任务，而研发方用技术上无法实现来抵制就基本站不住脚，至少，大可以一试。
实现这个需求从技术的层面看有什么好处？实现新的需求就意味者改动，意味着投入资源，意味者带来不稳定。从技术的层面看，这就是代价和成本，那么产品经理如何引导研发经理看到回报。这个需求能不能开辟一个新的市场和吸引新的用户，能不能为公司带来收入，能不能提高公司的竞争力进而激励公司的股价。最直接的，研发方能不能学到新的东西从而提高技术水平和进行技术的积累。如果产品经理能帮助厘清成本和回报之间关系，相信研发方也会试着考虑考虑。
最后还要看公司的架构了，那个能够拍板的人一定要是能把投资和回报算得很清楚的。Ta最好是一个既懂产品又懂技术的。
以技术无法实现或过分困难为由推脱开发责任并不应该视为影响产品的进度。
因为已经连开始都被开发人员拒绝了，还怎么开始呢？
这个时候的PM的最大问题还是在于沟通。
技术实现力度大，好，在资源紧迫的情况下，这是主要需求，我们就将需求中一些次要的部分降低难度，最次的办法是降低质量，保证功能上线。
没有所谓的不能做的事，只有不能做事的人。
如果产品不会技术，千万不要被技术人员所谓的不能做而难住。你要认真的问他具体哪里不能做，一定要让他一五一十的说出来，首先他就要理清自己不能做的理由。然后你再问他有没有更好的解决方案，因为这个时候的技术人员必须提供解决方案，然后你与其他干系人进行决策。
除了投资方是获得解决方案的，我们每一个人的存在就是为了解决一个又一个的问题，制造问题并不能有效促进项目的进度，要达到共识需要不断的沟通。作为技术人员，遇到较难实现的需求时，我一般这样做：
1、问清楚从产品角度为什么提这个（这些）需求。
2、觉得能力有限无从下手，那就直接说先研究再说，一定时间（1-2个工作日？）后给答复。
3、觉得有困难，告诉他困难是在哪里，需求所需要的成本。
4、如果在产品上有自己的考虑，就直接表达自己的想法。我想不会有产品人员在拒绝跟技术人员讨论对产品的看法。
沟通这些后，尤其是第四条，基本上就不会以“技术无法实现”的借口推脱。当然这是以“双方同一个团队目标一致”为前提。如果以上下级的身份来沟通，那就只好以“拿人工资，做好本职工作就行了”的态度做事。
一句话总结：与其命令技术人员去被动实现，不如让技术人员明白为什么这么做并主动去解决问题。从技术人员的角度来说，如果拒绝了产品的某些功能或改动,主要有这么几种情况:
1. 能实现，但是不能在时间点实现
2. 觉得这个功能不需要，甚至觉得提出这个建议是很可笑的事情
3. 看你不顺眼或者看老板不顺眼
根据情况去处理.
但是记住:如果你达到了让技术人员让步的目标,那么很可能与"做出好产品"这个目标越来越远.面对强势的技术人员，我觉得最重要的就是让他们从心里认同你的需求，自愿地去帮你实现，否则就算你只是在口头上说服了他们，最终的结果也未必能达到你的期望。当然在这个过程中，争吵是不可少的，但是双方都应该站在对方的角度作沟通。
所以说产品人员需要魄力与魅力，让自己带领的虚拟团队一致认同自己要做的事。
如果我搞不定会告诉你为什么:
1. 逻辑前后矛盾
2. 很多设计师的通病: 只有 UI 完全没考虑 UX, 或者设计师给的东西根本不符合你给的需求
3. 表述不清楚, 不如直接告诉我想抄什么好了
4. 想法过于迂回曲折却不知道到底是为了啥, 说说目的或许我会告诉你更直接的做法
5. 法律或者用户条款不允许这么做
...
我是PM，目前所属在电商部门，我们电商负责人特别想找自己的技术，这样一个是沟通方便，还有就是我作为PM，可以从一次次的配合中，学到基本的技术常识，虽然我学过数据库和C，但早忘光了，我可以补回来，但需要时间，所以有个自己人在技术团队里，会非常方便。
我目前的最大阻碍就是，技术部负责人看不上其他人，产品评估会上已经说可以做了，中途又在开发的时候，让执行的技术偷偷做了修改，而且不经过产品经理的同意，上线了才知道是改了的。这点我觉得很过分，我等于被架空了，而且没有被尊重的感觉。主要是！这个产品出问题，用不了，运营的需求满足不了，是我来担责任，不是技术。这个我觉得就是人品有点问题了，估计给我穿小鞋。在规划时就拉技术一块来，哪怕是旁听，发现问题他会及时提出的。
等你定案了，技术告诉你无法实现，他说服你很累，你改需求也累。
最重要一点，技术不是你的下属，也不是你家孩子，高高在上的命令，只能让他反感，消极抵抗。你可以告状吵了他，但换一拨也一样。本问题我比较有发言权，因为和我直接接触的技术就是一个比较难缠的家伙，呵呵，说正题：
1. 沟通：首先要和技术成为朋友（方法及尺度自己掌握），在中国很难分清工作与私人关系的，当你和他成为朋友（都是人，相信你能做到），一个好的开始
2.合作：前提要把自己的工作做好（不怕狼一样的敌人，就怕zhu一样的队友，你懂的），其它按照正常流程去操作首先个人感觉追求和技术人员说行话的这种想法和做法是错误的，而且很有可能会招来技术人员的反感（他们会说你是技术还是我是技术啊，你懂什么），如果能顺利沟通，那么很容易被技术人员带到技术实现细节，而不能从宏观上去看待整个产品的发展目标和轨迹。
——————————————————————————————————————
so，如何能说服技术总监和开发人员，个人认为功夫全在日常的积累了。
这种积累包括对行业的发展前景的认识；
包括对行业中的强劲对手动向和产品的理解；
包括对自家产品发展目标、定位、当前业务情况的理解；
如果这些自己能拍着胸脯的娓娓道来，那肯定不惧怕和技术大牛的对决了 强势体现在哪里？我看到的情况有2种：
1 不同意在规定的时间内完成规定的东西。
2 不同意产品设计，认为应该遵照他的想法。
针对1：往细了问，不能完成的原因是什么？时间太短，还是资源有限，还是实现难度大，还是风险较高。问到细节后，你才可以有针对性地说服他，或解决问题。
针对2：要么武断，你就听我的。但一般这样会引起更大反感和抵触不合作的情绪。另一种，就是鼓励对方说出自己的想法，再通过事实去说服。这部分工作很大程度上靠说话方式、逻辑能力。能让对方真的接受你的想法，或暂时同意按你的想法做。当这样也无效，并且你认为严重损害工作效率时，找上级是必须的。标签：算法 投票 约束 控制力 中心 ref 自己的 开发 请求
原文地址：http://www.cnblogs.com/stevendes1/p/7222187.html
