产品与技术人员沟通的技巧

2018-07-23 1

  

产品与技术人员沟通的技巧.png

      产品经理在完成需求以后,需要交予开发团队开发,这时候就涉及到与开发人员的交流,适当的交流方式,可以让你在交流的时候事半功倍。

      第一要旨: 产品人员在提出功能需求时,应明确告诉开发人员,其需求的目标是什么。

      很多产品人员做需求设计,给开发的时候只告诉开发你要做这个这个,那个那个,而并不具体说明为什么要做这些,也许他们认为开发不需要了解这个,也许他们认为开发应该一看就明白这是什么,但实际上,往往这里就产生理解歧义。这是很常见的问题。

      此外,产品人员,特别是没有技术背景或技术背景一般的产品人员,有时候会替开发人员多想,比如会认为这样做简单而那样做复杂,但也许技术实现成本并不是他想象的那样,而对于创业公司,实现成本往往也是特别重要的需要考虑的因素,产品人员往往没有给出实现成本最低的方案,而开发人员则盲目按照定义的需求出发,有时候做出的东西从实现成本来说非常不经济,特别是时间成本,消耗非常巨大。

      在符合第一要旨的前提下,开发人员应能参与需求的讨论,我知道有些大公司或者产品经理不希望这样,我定义好的需求你去实现就好了,你做研发的讨论这个干什么? 但这样其实是有好处的。

      1、研发人员的参与意识强,对产品的热爱度和积极性会提高。

      2、加深对需求目标的理解,减少开发过程中因理解歧义做出无用功或不符合需求的状况。

      3、有可能提供目标一致,而更低实现成本的方案。对创业公司,开发力量不够完善的场景而言,这一点也非常重要。

      当然,强调一点,研发人员可以参与需求设计的讨论,但决策权仍需要明确掌握在产品经理手里,(如果研发人员确实更懂得需求定义,可以兼任产品经理。但只要你赋予了独立的产品经理角色,这个需求的决策权还是必须给予保证的。)

      第二要旨:产品人员应给出所有功能需求的流程和结构图

      在给出具体功能需求设计之前,应给一个总纲,也是为了加深需求理解,形成完整的需求概念的一步重要工作。

      很多时候,产品经理会觉得,我说的都那么清楚了,你怎么不明白呢? 其实主要就是因为在这个环节上产品经理对整个项目的背景,结构,前提,目标早已有了代入感,所以觉得每个细节都理所当然是这样的,但是对研发而言,他们并没有得到完整的背景信息,对细节的理解往往就出现偏差和误判。对彼此功能点的关系,相互的联系了解的支离破碎,那么实现起来这个系统也就难免出现不尽如人意的地方。

      常见的,比如,用户的某个属性,在某个功能中体现出来,而在另一个功能中被赋予或产生变化的,但是因为需求设计的时候,没有给出整体的结构和流程,只是在局部的设计中提供了不精确不严谨的描述(产品经理也许觉得描述的足够清楚了,但是缺乏必备的背景信息铺垫),那么实现的工程师,(甚至可能两个不同功能是不同工程师实现),也许会误判做成两个不同的字段,赋予不同的定义。这样这个属性的实现就彻底错了,而在上线前甚至双方都没意识到存在这样的问题。

      第三要旨:具体视图设计的三要素

      不论是设计网站,还是设计app,基本都是由一个到多个交互视图组成需求设计。

      产品人员在提供这样的应给与研发者如下三要素

      1、界面元素,比如哪里是文字,哪里是下拉框,哪里是按钮,这些属于界面元素,可以用草图,或word简单排版,但要明确界面上的元素是什么,如何展现。是静止?浮动?

      2、数据逻辑,这一点往往也是非常多创业团队和新手产品经理容易忽视的,比如页面这里是最新新闻,那么你要说明,这个最新新闻是基于怎样的数据逻辑获取的,当然这个基本上工程师都知道,按照时间逆序就好,但是如果涉及,比如有一个区块叫做推荐游戏,那么你要告诉开发人员,这个推荐游戏是从什么地方取出来的信息,按照什么逻辑取出来的。有的产品经理说,这不是技术活么?我怎么知道? 哦,要是真不知道,就要跟技术人员沟通这个问题,看看你需要这个地方出现的东西体现出怎样的一种特征,然后问他应该怎么来设计,然后你也要参与思考,这个数据逻辑是否符合用户的预期,以及在运营中是否会出现一些比如说位置会固化,新数据无法体现的问题,这些都是产品经理要思考和确认的,不能说甩手给技术,当然,如果你遇到一个特别有产品经验和理念的工程师,他真能帮你都解决好,但这情况其实非常罕见。

      3、操作逻辑,界面上可以进行操作的有哪些元素,哪个可以点击,可以选择,操作后出现怎样的反馈,比如显示浮层?进入新页面?或怎样怎样? 这也是要在需求设计文档里说清楚的。

      一个视图的设计,说清楚界面元素,数据逻辑,操作逻辑,开发者才能明确这个视图的开发需求。不要让开发的工程师自己去猜,去揣测,如果有些逻辑涉及算法,产品经理不清楚,也要与开发者确认他所采用的逻辑是什么,以及效果是什么,并与自己所预期的效果做比对,而不是说,这个我不清楚,让工程师决定。 操作逻辑可能会指向其他视图,这就是前面说的,结构流程图要说明的地方。

      在百度这样的公司,产品经理要写繁琐冗长的MRD,(其实早期的MRD不繁琐,也不冗长,但后来对需求定义的精确性要求越来越高,内容就越来越繁冗了)。其实我不喜欢这样的风格,沟通成本太高,所以对于创业公司而言,还是尽可能简单直接有效最好。 那么我认为,要做到简单直接有效,做好如上几点,对于大部分场景来说,应该就可以满足。

      重复一下,第一,要让开发工程师明确需求的目的并参与讨论。第二,要给出结构图,流程图,对需求有完整的认识。第三,针对具体的视图,提供元素,数据逻辑,操作逻辑 三要素,其实并不会很复杂,正常一个视图写一页到两页就够了。如果开发工程师配合比较默契,有较多合作基础,中间很多内容可以写个略字。但是这个结构建议还是养成习惯。

      说一个执行中的要点,当产品经理给技术人员展示完文档,表达完需求后,最好的一种确认方式是让技术人员按照自己理解重述一下需求,重述的过程往往容易暴露出理解的歧义。确保你表达的与对方理解重述的一致,这样有可能减少很多后续的麻烦。

image.png


公司简介

   中城投丝路核心团队为打造互联网、数字城市优质平台汇聚全球行业精英,孵化创建了720集团(关注数字城市细分行业应用,如:交通、水利环保等)、181科技公司(关注两岸智慧城市)、180科技(物联网传感平台),为促进数字文化交流还成立了鑫智会联盟中心(在数字六年经验以上的行业先驱组成的智库)。我们为每一位合作伙伴、更为加入团队的每位人才精英提供更为广阔的施展舞台、职业能力锻炼机遇。

查看更多

联系我们

  •  福州市鼓楼区鼓楼科技大厦16层
  •  北京市庙城镇293号院2号(总部)
  •  福清市福建师范大学
  •  联系电话:0591-8786-1210
  •  手机:18050166663
  •  3058661698@qq.com
  •  http://mcms.jmeet.cc