产品经理如何和程序员一起复盘

⑴ 怎样做好产品经理

一个好的产品经理要能规划设计一个产品从出生到成长到成年的整个过程，了解客户需求和使用习惯。简单地说，销售是卖东西，市场是怎么卖，而产品经理的职责是告诉他们卖什么。

⑵ 产品经理怎样更好的和开发人员沟通

诚然，这些挑战可能是由于参与人员的能力问题，这无可避免。但我更愿意相信，沟通不畅、习惯不佳、缺乏换位思考等因素才是最常见的。知乎上的几个问题的讨论，可能会对各不同角色的人之间进行换位起到一定的帮助作用，无疑，这是一件对各方都有积极意义的事情。 产品经理作为贯通各环节的中心节点，避免一些让人讨厌的臭毛病显得尤为重要。从知乎的回答中，我将这些可能成为臭毛病的行为归纳为以下几种情况： 短时间内可以完全避免的：需求不清晰 ，当开发人员问PM需求的时候，发现PM也弄不清楚，这样的问题是一定要杜绝也完全可以杜绝的，如果PM自己都不清楚需求，的考虑这样的工作是否适合自己了。 干预纯技术问题 ，例如：这个code应该这么写。避免之道:对于纯技术的问题不要干预，如果他的技术实现真的有问题，自有相关的人去负责，产品只需关注他最终是否实现了预期的功能。 交付的方案不确定 ，开发人员讨厌其实这样也可以，要不就这样吧的言论，他们需要的是一个明确的方案。在多种方案犹豫不决需要思考的时候，PM最好只是将这样的犹豫不决体现在自己的思考中。除非工程师无力实现你的第一种方案时，再将备选方说出来。 没有必要的预留时间 ,这个我们修改一下，明天提交新的版本，一看，列了一大堆增加的功能，并不是仅仅是修改。coder真的不是神，增加的功能是需要测试的。pm给自己留时间同时，可怜可怜攻城湿，留点时间思考吧。这是一位工程师的原话。Pm要对进度负责，压力很大，但是预留时间是一定要的。 不能完全避免但短期内可以改善的：需求变更 ，这是回答中出现平率最高的一个词汇。但是，要让开发人员失望的是，因为种种原因，这个问题并不能完全避免，PM能做的就是尽量在交付开发之前将尽可能多的问题都考虑到，使可能发生改变的需求讲到最少；另外一个就是要杜绝需求的往复性变更，不要让从方案A改为方案B之后觉得不行，又改回方案B。 口交次数太多 ：要避免口头交代，显然不现实，再完美的文档也无法代替口头上的直接交流。但频繁的口（头）交（流）可能会打断工程师的思路，延缓进度。PM可以做一是尽量完善你的文档，第二个就是尽量在一次口头交流中集中讲完尽可能能多的事情，从而减少次数。 需要长期积累或锻炼才能改善的： 缺乏个人魅力 ：是的，缺乏个人魅力也成为工程师讨厌PM的一个原因了。但是个人魅力这个东西，确实很难在短期内得到改善。甚至，对于个人魅力的判断，不同的工程师会有不同的标准。 经验不足：或者说资历不深，要改变这样的现状，恐怕也非可立竿见影的。 以上 ，以自勉。

⑶ 产品经理该如何跟程序员沟通

产品经理面试的过程中面试官特别喜欢会问一个问题，如果开发人员以无时间为理由拒绝你的需求怎么办？工作中产品经理和技术人员打交道的次数太多了，行业内也流行着一些图片来调侃产品和技术之间的关系，两者的关系可以用相爱相杀来形容。

之所以这么说有两个理由，相爱是因为两者要互利合作，把老板交给的任务完成，而且只有彼此合作才能让工作进展的更顺利。相杀是因为这两个职业又存在着很大的矛盾，产品经理的需求间接决定了技术人员的工作量，有些技术人员确实对产品经理比较反感。

我也看过一些关于产品与技术如何沟通的文章。这篇文章我想结合我自己的亲身经验，分享一些小技巧，可以当做是保持良好关系的润滑剂。

1

首先我们分析一下技术与产品之间产生矛盾的原因。在分析之前，先设一个前提，每个公司在招人的时候都有其标准，寻找价值观相同的人，所以我一直都相信开发人员并不会无故找理由拖延项目周期。反过来，如果开发人员因为品性而偷懒或者说是耍心眼不干活的话，那就没办法了，个人主观因素太大。

第一种情况是产品经理的需求与开发人员手头的项目撞期了，解决的办法很简单，就是根据需求的优先级来调整开发排期。碰到这种事，有些领导也总是期望产品经理靠着自己的方法解决。但是除了跟上级领导申请调整优先级，没有别的好办法。一个客观事实，公司在多个项目中确实有优先级之分，虽然你自己的孩子自己最看重但是在别人眼里并不是这样。第二个原因是开发人员是按照公司意愿办事，说严重点你总不希望别人因为你的事情跟领导闹僵，搞砸自己的饭碗吧。

第二种情况技术人员并不认同产品经理的观点，虽然产品经理和技术人员各司其职，但是在工作中会碰到有些技术对产品特别关心，如果产品经理的做法自己不认同的话会提出质疑。如果质疑的人是技术老大，产品经理往往会更被动。遇到这种情况我觉得很正常，想办法说服技术人员。

除了搬出之前做的产品分析和用户调研外，我在工作中总结了一点经验，平时可以多跟技术聊聊天，增进彼此了解，观察他们经常上使用的产品，在沟通说服他们的过程中，可以拿他们经常用的产品举例，这样的话他们本身对那个产品更熟悉，自然也更好理解。另外，在跟技术讲解产品的时候也要适当的画饼，描绘一下产品上线成功后的美好未来，这会带动起他们的积极性。

2

产品经理要做好自己的基础工作，这利于给开发人员留个好印象。做好这方面的工作有两点，一是想好产品规划的原由，避免被技术的同学问住。技术人员也特别讨厌产品经理说“某某产品就是这么做的，我们按照他们的做就行了”这样的话；二是写好产品文档，在产品文档中避免有遗漏的地方，特别是一些比较复杂的功能，一定要解释清楚，因为技术人员会遵照着产品文档进行开发，所以说如果有疏漏的地方会增加沟通成本，如果文档写错了，造成开发出来的产品功能不符合预期就是产品经理的责任了。

为了提高文档的可读性，我们也可以多使用图文、流程图的表现形式，如果只是干巴巴的一个word文档，几千个文字，看起来确实很枯燥。

对于产品经理和开发人员来说信任尤为重要，如果开发对产品经理缺乏了信任，结果就是你的话开发人员不会再听了，每个需求他们需要经过你的领导确认后才会去做。获取对方信任的一个很重要前提就是说话算数，当技术人员询问你某一个问题时如果自己没想清楚，可以先暂时别回答，考虑清楚后再说。要是随口一说，过后又让开发人员修改，不仅会造成开发人员返工，这种行为也是非常不负责任的。

即便文档写的再完善，在产品开发过程中也难免需要当面沟通。项目跟进，需要产品经理极大的责任心和积极性。一个项目立项后，公司通常会把参与人员列为一个小组，产品人员需要根据开发排期跟进开发进展，避免开发出来的产品与预期不符，验收产品功能是否与产品期望一致。这个过程产品人员的工作往往会比较繁琐，也会比较忙，当然也会锻炼产品经理的沟通能力。

3

说一下行业内一直讨论的一个问题，产品经理该不该懂技术？我觉得这个问题并没有什么好讨论的，无论是从个人知识量还是从是否有利工作的角度讲肯定是懂技术要更好，而之所以能吸引那么大的热议，可能是由于很多产品经理不懂技术，但是又没有兴趣学习，所以心底一直会纠结这个问题。

从我个人的经验来看，特别是你做项目比较多的时候，会发现懂点技术跟技术人员沟通起来会顺畅很多，一个重要的体现是技术人员也很愿意跟你交流技术实现的一些想法，而不会说“算了，跟你说了也没用”这样的话。

产品经理懂技术还有一个很重要的益处是当业务部门提出需求时，自己就能评估出技术实现的可行性，对于实现起来比较困难的需求自己就可以跟业务部门商量优化方案。而不必每个功能都去询问技术，无形中也减少了技术的麻烦。

不过我跟很多人的观点也一样，产品经理对技术的了解不需要太精通，说到这我还得庆幸自己大学时候学的是计算机专业，虽然学的不好，但对于现在的工作还是非常有益处的。不过我在工作中也会碰到技术人员偶尔说了一个名词自己不理解的，这时候两种办法，要么主动问一下，要么自己去网上查，明白其中的逻辑关系，知道是怎么一回事就好。

毕竟术业有专攻，虽然我们希望知识越多越好，但也别给自己太大压力。况且技术知识也在更新迭代，他们使用的框架也会变化，技术的语言也有很多，如HTML、Java、PHP等，你不可能全都精通。

4

最后说点工作中会遇到的个人主观因素。

当产品经理跟其他部门提需求或是沟通确认的时候也不排除其他同事有未及时回复的情况，为了确保项目上线也为了争取资源，这个时候就需要产品人员更加主动一些，所以产品经理有时候还需要脸皮厚一点。

当提交一个需求给开发部门制定排期，你会发现他们都会把时间定的很充足。也许你会因此对其他同事有看法，但其实在工作中都是这样子，大家都不会把自己的时间安排的太紧张，而且还要考虑过程中可能会出现的风险因素，例如请假的情况。当然也不能把时间定的太长，那样老板该不开心了，所以最好是产品经理根据上线时间与开发人员定一个时间结点，让开发人员在这个时间点前完成即可。

⑷ 产品经理和程序员,如何避免矛盾

产品汪和程序猿

一、产品经理和程序员最讨厌的三句话

产品经理和程序员,就像一对情人，若即若离，有时还会撕逼，和谐的时候一切都好，撕逼的时候两败俱伤。

你知道程序员最讨厌的三句话是什么吗？

1、这个需求很简单，改一下就好了

2、你先大概弄一个，我看看再说

3、我先下班了，加油啊

我想任何一个程序员听到这样的话都会气炸了，不撕逼才怪，你作为程序员会如何回答这三句话？

1、这个需求很简单？你行你来啊！

2、大概先弄一个？请问先生（女士），什么叫大概？

3、你大爷的

你知道产品经理最讨厌的三句话是什么吗？

1、这个需求做不了

2、这个需求工作量太大了，估计要搞3个月

3、这个变更没时间做，往后排吧

产品经理在前端，有用户、有老板、有销售，版本发布的压力很大，听到这样的话估计心情也好不了哪去？

1、这个需求做不了？又不是我提的，还不是那个2B用户提的

2、要做这么长时间？养你们有什么用，还不如我自己来

3、变更没时间搞？随便，等老板来拍你吧。

二、产品经理和程序员本质上的差异是什么

奶爸干过程序员，也干过项产品经理，深知这两类工作的差异，各有各的不易。

总体上来看，做产品更侧重于创造和方案能力，不需要精密的逻辑，所以试错成本相对比较低，大不了改改原型，改改方案，这个成本是可承受的。

程序员的工作是非常精密的逻辑，一个看似很小的变更有可能对代码产生很大的影响，所以试错成本非常高，弄不好可能会因为需求的变化导致系统的重构，这时候程序员的挫败感是可想而知的。

三、产品经理和程序员友好相处的清单

1、产品经理收集需求后，在需求分析阶段，需要把一些不合理的需求尽量和用户沟通去掉，避免不合理需求造成产品发布时间延迟和没有必要的成本浪费，当然这需要产品经理去说服用户，不能只做用户的传声筒。

2、需求分析时，产品经理应该根据经验，敏锐的发现一些在技术层面实现有困难的需求，及时让研发介入，评估技术可行性，避免后续出现需求定下来，研发说做不了的情况。

当然这需要我们的产品经理对软件技术架构有一定了解和预判能力，你不能所有的需求都要在需求分析阶段让研发介入，这个成本也是极高的，所以要把握好这个度也是一项能力。

3、原型还是需求沟通的最好方式，这样是避免产品和研发在需求理解上有差异的最好手段，只靠写一些文字的需求说明书很难达到好的效果。

但这里面要注意一点，产品经理绘制出来的原型一般是非高保真原型，是为了更好的沟通需要，所以不能完全按照原型做，需要基于我们自己的前台架构进行定制。

4、需求评审的时候，研发可能会有一些不一样的意见，他们做了很多年的开发，会有很多好的经验，好的经验要虚心接受，不能觉得自己是产品就是老大，就是要按我说的做，这样很容易造成矛盾，求同存异，目标一致，这个是最好的结果。

5、研发说这个需求做不了的时候，有两种情况，一个是觉得这个需求实现起来比较麻烦，故意骗你；另外一种情况就是他的知识盲区，他可能确实不知道这个事能做。

产品经理需要有能力和研发进行谈判，比如采用类比法（类似的需求在其它项目上咱们就做过），比如去找架构师探讨技术可行性。

6、研发有时候评估的工作量会比较大，整个上线计划拉的比较长，产品经理可以要求研发出详细的资源配置清单，这样能清楚的看到一个需求被分解成了多少个研发任务，每个任务的起止时间，由谁负责完成。这样产品经理大概能看出任务的前后置关系是否合理？工作量是否合理等。

产品经理绝不能说，这么简单怎么要搞这么长时间，类似的话一出，绝对会激怒对方，还是要有理有据进行谈判。

如果实在无法压缩工作量，如果增加人力能解决问题的话，可以考虑找领导申请资源。如果还是不行就要砍需求或者改方案了。

7、在版本计划定好的情况，尽量不加需求，这样很容易打乱开发的节奏，如果一定要加进来，一定要和研发说清楚，这个是用户领导或者老板的强制要求，转移矛盾。如果可以的话，增加了需求尽量推迟上线计划。

8、开发过程中如果需求有改动，需要及时更新需求文档，同时发给我们的研发同学，否则只是靠嘴说一下，很可能研发的同事就不做了，所以一定要落到纸面上。

9、上线的时候要坚持和研发同事一起加班，这样大家才是一个团队，赢了一起狂，输了一起扛。

10、最后一点，就是要多交流，没有什么问题是一顿火锅解决不了的，大家关系好了，很多事情沟通起来自然容易，而且也会更信任对方，这样就万事OK了。

⑸ 项目负责人如何和程序员沟通

做一名程序员，虽然好的口才不是必要条件， 但不善于表达自己想法以及与上司同事沟通，吃亏的是自己；

最近做一个项目，与项目的负责人出现一些不愉快的事情,出现这种情况虽然与其它杂七杂八的事情有点关联， 但最重要的原因还是在工作上缺乏沟通； 例如， 上周他给我们C#组的人员分配工作， 每人负责一个小模块， 数据库和需求文档已经提供有，但数据库的表字段有可能根据实现开发情况做少许改动，而且也给我们一个例子看， 可能参考该例子来做； 在统一讲需求时虽然听起来明白了，但做起来会发现很多关节的细节没考虑进去，而这些细节往往会影响到开发的速度， 甚至看骈符合了文档的需求，但却不符合负责人或者说是客户的实际需求;因为文字类型的需求是比较抽象，特别是要做用户界面， 虽然有例子，但也只能参考，不能照搬也做，这样做出来的程序很多情况下只符合程序员自己的需求； 已经花了很多时间去做一个可能不需要的功能，如我当时做一个日历控件来显示排班信息，且也接近交货日期了，到时交到负责人手里时才发现，这个日历控件不是必要的，选择的时间范围是在弹出窗口里，且不保存到数据...， 这时发现做了很多无用功，又要加班加点去赶进度了。虽然这只是一个小例子，但相似的例子在前几个月里已经发生过几次，为什么呢，因为表达能力差，也不善于与人沟通。可以利用日事清管理工具来沟通，把想法写出来。然后@给项目负责人。不用直接面对，效果不错。

⑹ 在职场上，产品如何与其他同事顺利沟通

有人的地方就有江湖，职场也是个小社会，如何与其他同事相处，也是一门艺术。尤其是产品人，相处融洽，则事半功倍，还会加速你的成长，相反，则会处处碰壁，事倍功半。

1.多沟通，多主动；

新人要多发挥自己的主观能动性，主动出击，不能坐以待毙。老同志不一定都那么热心肠或者八卦，每人都有自己的一某三分地需要耕耘，所以主动和老同志交流沟通，多主动帮助他人，跨出第一步，你会发现，越来越自然，关系自然变得融洽了。

4. 想他人所想，急他所急，同理心；

做事情，多从他人的立场点考虑，更能赢得他人倾心，久而久之，你的个人风格会让大家喜欢并互传，口碑也就形成了了，这样大家会更乐意和你处事。

总得来说，用心做事，用情做人，好好工作，好好学习。

我是生涯规划师Cally,欢迎关注，一起聊聊生涯那些事。