caoz的心得与分享,只此一家,别无分号.

关于产品与技术沟通的一些建议

发布日期:2015-09-15 11:55:52 +0000

有一个新创业的项目,我个人有一点点投资参与的,最近开发进度一直不如预期,因为开发的负责人也是我认识很久的一个朋友,所以有点奇怪,就去聊了聊。(说来惭愧,主要我也有责任,本来答应一开始研发就介入做一些技术沟通的工作,结果自己太懒,一直没太多过问) 然后发现,问题主要还是出现在沟通环节。这个创业团队的负责人,业务运营能力应该还是有的,但是他们之前没有技术产品开发的经验,简单说就是,团队里缺乏一个产品经理的角色,需求的反复和双方理解的歧义导致了研发周期的延宕。

这个场景相信很多创业公司,甚至规模不小的公司都出现过,我也不敢说自己就可以彻底的解决,但是还是分享一下关于产品需求设计与开发沟通的一些观点。


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


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


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


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


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

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

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


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


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

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

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

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


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


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

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

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

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

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


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


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

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


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


今天讲的主要是产品经理如何更好的与技术沟通;那么在产品设计中,如何更好的满足用户需求,是另一个特别大的话题,以后有机会我们再聊聊看。



有好几人觉得我前天那篇质量不好,有人建议我减少更新频率以提高质量,咳咳,发现订阅用户数多了,越来越身不由己,不敢肆无忌惮随便唠嗑了。


昨天其实写了一篇,后来觉得不是很合适发出来,就删除了。