以程序员的视角,给产品经理们的一些沟通建议

16 评论 5714 浏览 26 收藏 13 分钟

导读:一边是需求提供方,一边是需求实现方,产品经理和程序员仿佛是「天敌」的关系。有沟通就会有问题,有问题就可能会有矛盾。由于工作方式、工作内容、实际经验、个性等多种因素上都存在差异,每个产品经理的职业生涯中都会遇到与程序员产生沟通上的问题。

一、产品经理和程序员之间到底有什么沟通上的问题?

比如:有些产品经理没有产品的决策权,往往是需求的传话筒,是个需求转达者的角色,开发在质疑需求的合理性时,产品经理直接将锅甩给了需求的来源者,用“这是某某确定要做的需求”这类话去回复开发,由于产品经理没有产品的决策权。这也会需求者的需求多次变更,导致开发硬着头皮反复反工,甚至带着情绪去编码,这无疑会加深两者的矛盾。

比如:有些产品经理没有将自己以为的常识性产品功能细节告诉开发,也没有在产品原型中明确说明。开发以自己的经验去编码,由于两者对同一个功能的认知并不一致,导致开发出来的产品功能与产品经理预期的并不一致,导致双方互相扯皮。

再比如:产品经理往往在开发阶段和程序员去讨论具体方案的实现细节问题,产品经理自己觉得很基础的功能或改动,在开发眼里往往就是系统的大改造。

……

产品经理和程序员在沟通上的问题不胜枚举,但核心冲突是“有限的开发资源”与“无限的产品需求”之间的矛盾。

要解决这个问题,要么提供更多的开发资源,也就是招更多更合格的工程师;要么就让产品经理对自己的行为做更多限制,让产品决策和产品设计方案尽量符合市场和用户需求,尽量合理。

但显然这条路绝大部分企业并不行得通。对于开发者,提供更多的开发资源意味着企业要开发成本;对于产品经理,对其行为的限制有太多不可控因素,一个决策的很可能是涉及多方、多种因素的结果;产品经理的个人经验、认知水平、风格等因素也各不相同。

而且,显然实际工作中,情况还要比这复杂的多。

二、站在程序员的角度,看产品经理应如何和开发沟通

双方的矛盾不可能消除,但站在程序员的角度,产品经理如果能做到以下几点,一定能够减少和程序员之间的沟通问题甚至是矛盾。

(1)产品经理要点到为止,不越俎代庖

产品经理尽量不要与开发讨论具体的实现方案上的细节问题,专业的事情交给专业的人去做,给与充分的信任。

一些技术出身的产品经理经常会与程序员讨论需求的具体实现方式的问题,产品经理认为自己的技术方案更适用,导致讨论结果不欢而散。程序员对技术发展的认知,个人技术经验、技术专业程度等方面大概率比技术出身的产品经理更专业。

要相信,每个程序员都是自己代码的「产品经理」。

(2)产品经理要多了解技术基础知识

对于一些非技术出身或没有技术背景的产品经理而言,由于对技术知识的缺乏,很可能陷入学习技术知识的细节中。产品经理需要了解基础知识,并不需要知道实现细节。产品经理学习技术知识的目的是为了为更合理的设计产品服务,为更好的团队沟通服务。

对于一些非技术出身或者需要学习技术的产品经理,非常推荐唐韧的《产品经理必懂的技术那点事儿》,这本书详细介绍了产品经理工作需要用到的技术知识,非常全面且简单易懂。

(3)没有程序员希望经常被打扰

专注的时候工作效率一般是最高效的。在程序开发阶段,产品经理一定要尽可能少的打扰编码中的程序员。除了一些紧急且重要的需求,需要及时与开发沟通。其他的需求产品经理可以适当划分优先级后,跟开发约定时间后,集中时间去讨论。

(4)多给程序员时间和空间

具体到细节,程序员与产品经理的目标很可能是迥异的,甚至可能是相反的。如产品经理要求先做一个功能,尽快上线,这一需求即使普通人也能理解。

但程序员考虑的不仅仅是需求本身,还要考虑上线后的维护、升级等,而这部分不懂技术的产品经理是难以理解的,即使是懂技术的产品经理,可能也会觉得实现起来是简单的,其中的艰辛和沉重就只有程序员能够体会了。

产品经理要给程序员预留出合理的修整时间。一定不要把研发时间就当作完成时间。研发功能只是一部分,测试、改 BUG 以及处理意外情况的时间都要预留出来。

有两种情况要多预留出修整的时间。

一种是研发团队自己对功能没有把握,可能是全新的功能,可能是比较难做的功能,可能出现许多 BUG 和功能实现糟糕的情况,那就要多预留出时间。

另一种是产品团队表示对功能也有疑虑,比如在提供需求时表示这个功能很有可能要调整,或者对功能本身信心不足,那也要多留时间做调整。

(5)注意沟通的问题方式和方法

程序员喜欢按照既定的需求优先级和产品方案有序的工作。产品经理给到开发的需求一定要是合理划分优先级的,版本需求的提供与团队的开发节奏尽量保持一致;遇到问题先分析、定位问题,而不是遇到问题先把问题直接退给开发,然后催着开发短期内加急处理。

(6)产品需求变动及时告知,最好给与变更的背景说明

我见过太多的产品需求文档更改之后没有及时告知开发,导致测试验收阶段的需求与产品预期需求不一致的情况。产品经理不要想当然的以为改动的需求开发一定会看,产品经理的需求变动一定要及时告知相关开发相应的改动,有时候需求的变动可能就是简单的一句话,及时的沟通可以避免后期的大改动和双方推诿扯皮。

(7)对问题要有自己的判断

产品经理接收到的需求一定要有自己的清晰判断,哪怕是很小的需求,到产品经理这里必须经过理性分析后,再安排开发进行处理。

以bug为例,很多时候一线或者客户反馈的“bug”极有可能是对系统的不熟悉,对系统的配置性错误导致的问题,并非是系统bug。产品经理作为需求处理的最后一道防线,提交给开发要做的一定是确定的事实,提交一个非bug需求给到开发去处理,不仅会浪费开发时间,还有质疑产品经理对业务的熟悉度和专业性。

产品方案提交给开发前,产品经理至少应该明确的问题:

  1. 你提这个需求是要为谁解决什么问题?
  2. 这个问题是否客观存在?
  3. (退一步讲,如果客观存在)你为什么觉得你的解决方案可以解决这个问题?
  4. 除此之外你想过其他解决方案吗?你为什么觉得这个方案是最优的?

如果你连这些基本问题都没有想过或是想清楚,被动等着开发去问的时候才去思考,结果可想而知。

(8)沟通需求、需求文档要尽量详细明确

这个是产品经理基本功,也是经常容易被忽视的一点。

沟通需求一定要有目的,要具体,否则多半是浪费开发的时间;需求文档一定要详细并且明确无歧义,具体文档详细到什么程度,可根据每个团队的风格、默契程度确定。如果没法确定,那就说明的越细越好。开发在编码的过程其实就是细节的实现过程,产品经理在细节上深入思考后和程序员沟通会更加顺畅。

(9)平等、尊重与理解

从归属部门来看,产品经理一般属于产品部,程序员属于研发部,归属部门上不同,但都处同一个工作流上。

从工作流程来说,产品经理处于需求的上游,程序员处于需求的下游,双方对于用户、需求、业务的理解程度有很大的不同,程序员在理解需求时有问题太正常不过,有问题时产品经理应该及时给与耐心的回答。

尊重程序员的工作成果,涉及需求改动甚至需要砍掉的需求,尽可能跟开发说明白为什么。毕竟谁也不想自己费了很长时间、花了很大气力做的东西,因为产品经理一个未经思考的决定改动。

要让程序员从心理上认同做这件事的价值,程序员没有理由拒绝一个合理的需求,如果需求能给用户或者企业带来价值,或是体验上的提升,即使开发量很大或是难度很大,程序员也会激情满满。

有许多经验帖都谈到产品经理与程序员的矛盾症结在于改需求,其实改需求只是表象,互联网本来就是一个快速变化的行业,改需求不可避免,根源在于产品经理是否有独立思考的能力和意识。

改需求是人云亦云,是老板Push,还是实践过后从观察数据洞悉人性得来的深刻启发,这里大不相同。

因此产品经理除了要当团队的连接器之外,还得锻炼自己成为团队的大脑,只有你把需求想踏实了,想细致了,想全面了,才有足够的底气去应对各方各面的挑战,在程序员面前更具信服力。

我自认为优秀的产品经理都是相对清闲的,因为前期的需求文档和原型图都写得非常细致了,预知研发人员会问什么问题,都在原型图上醒目的标识,让研发人员很少甚至是无需过问产品经理,从此产品经理可以在于研发的纠缠中解放出来,真正去想长远的规划。

产品经理最主要的能力之一就是共情能力,遇到沟通问题或是矛盾、冲突时,站在程序员的角度思考下自身可能存在的问题,相信你会和程序员的沟通会更加顺畅。

 

本文由 @PM肖邦 原创发布于人人都是产品经理,未经作者许可,禁止转载。

题图来自Unsplash,基于CC0协议。

给作者打赏,鼓励TA抓紧创作!
更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 学到了

    来自湖南 回复
  2. 确实,觉得产品经理如果是学过相关技术的知识,可以更高效的沟通

    来自安徽 回复
  3. 作为一个小白还没有遇到过特别难沟通的开发

    来自浙江 回复
    1. 我一直把程序员分成三种:
      第一种是:老老实实打工,产品经理叫我做什么我就做什么,我按照需求文档做,我按照领导的要求完成任务,我没有过多的想法,我只是需求的执行者。这种一般是经验在0-2年的程序员居多。
      第二种是:我觉得我不应该老老实实做需求执行者,我还需要给产品提我自己的想法,我也是团队的一份子,我该为团队献计献策,甚至有时候我还要提出一些合理的改进意见。这种程序员的经验和项目经历一般很丰富,要不就是自身学习能力强,有责任心。
      还有一种就是:对需求改动或者是遇到没有做过的功能本能的抗拒态度,不想学习也不愿学习,往大了说,甚至是没有责任心的佛系程序员。当然,这种程序员很少。

      来自上海 回复
  4. 我也是产品经理,非常感同身受,一般有些需求提过去,如果研发说做不到,我都会问无法实现的具体原因,然后再帮着一起想办法,看看能不能找到折中的方案。但在公司里,确实也有些研发就不愿意动脑筋,内心对要做的需求没有信心,或者感觉做起来很麻烦,本着多一事不如少一事的心态来拒绝,这种研发有时候也是拿他没办法。

    来自广东 回复
    1. 我一直把程序员分成三种:

      第一种是:老老实实打工,产品经理叫我做什么我就做什么,我按照需求文档做,我按照领导的要求完成任务,我没有过多的想法,我只是需求的执行者。这种一般是经验在0-2年的程序员居多。

      第二种是:我觉得我不应该老老实实做需求执行者,我还需要给产品提我自己的想法,我也是团队的一份子,我该为团队献计献策,甚至有时候我还要提出一些合理的改进意见。这种程序员的经验和项目经历一般很丰富,要不就是自身学习能力强,有责任心。

      还有一种就是:对需求改动或者是遇到没有做过的功能本能的抗拒态度,不想学习也不愿学习,往大了说,甚至是没有责任心的佛系程序员。当然,这种程序员很少。

      来自上海 回复
  5. 对产品狗的9点控诉(手动狗头)

    回复
    1. 也可以理解为:对产品狗的9点提升建议~

      来自上海 回复
  6. 写的很在理,也非常有针对性~
    研发各端该怎么与产品沟通也写一写呗?
    怎么体现研发团队接受需求的有效性,不同语言在对需求实现的过程中需要如何响应、如何交付高质量代码~
    另外测试从需求评审到用例产出以及对最终结果的保障~
    期待看到不同角度的内容,产品经理是团队的连接器,但同为工作流上的伙伴,”上”善至”下”之余,也望”下”善承”上”~

    来自北京 回复
  7. 评论都是说产品经理,虽然但是,其实程序员也有问题。最好的办法就是两者相互沟通,程序员了解产品经理,产品经理了解程序员,补一些对应的基础知识,都不会有这么大的矛盾。

    来自四川 回复
  8. 咱就是说,产品经里需要一些编程思维和编程能力,这样也不至于答应太过离谱的需求,

    来自四川 回复
  9. 大部分产品经理都是:这个简单,好说好说;
    而程序员:这么难的需求你也会答应?我写不出来,有本事你自己上。

    来自四川 回复
    1. 这个需求很简单?怎么实现我不管?明天马上上线?…

      来自上海 回复
    2. 其实如果是小公司,就是程序员根本不愿意动脑去做新东西,你不找技术文档给他找好,他就不做,幸好我自己会做。

      来自广东 回复
  10. 写的太好了 都是干货 句句在理

    来自辽宁 回复
    1. 都是实际工作中和开发沟通的总结。要相信,每个程序员都是自己代码的「产品经理」。

      来自上海 回复