产品经理与技术沟通,需要注意这几点

其实这个话题旧文《产品经理的软性能力:协同力与领导力》已经聊过,我觉得我已经讲的很清楚了,回看觉得再细化具体一点。

其实,协同能力和领导力都是需要靠沟通能去实现,今天就聊聊[沟通]。

我们在研发生产过程中,需求反复和双方理解偏差导致研发周期总是被拖,还有产品与技术各种撕,等等。

这些情景在网上被吐槽了很多很多了,而且是更古不变的话题。也是我们产品经理最为头疼的问题。

我有些方法能够解决一些问题,但是我不能保证解决所有的沟通问题,毕竟人是复杂的,取决于沟通双方个人因素。

在旧文中,我说产品经理是首席解释官。

因为整个项目只有你最清楚项目的背景。

所以一个产品项目沟通你需要基于背景/目标、业务范围及流程、功能及流程、交互元素和操作逻辑去沟通。

01 介绍项目背景/目标

很多产品人员经常这样做项目,直接告诉工程师我要做一个产品需要什么功能,多久能够实现。

并不说明,我为什么要做这个,我做这个的背景因素是什么,在什么情景下解决用户的什么问题?达到什么目标?

也许你觉得,工程师知道这些干什么?工程师只需要实现功能就好了。但实际上,这往往造成双方理解的偏差。

举个例子,在一个项目立项会后,我们一位硬件技术负责人跟我说,我们为什么不像谁谁那样做一些高精尖技术的产品,总是做这些我们做过很多次的成熟技术项目,没什么意思。

因为他不明白我做这个产品的市场目的,以及这个产品诞生的背景。

当我告诉他我们目前产品线遇到的问题,同行竞争的状态,公司目前能力和资源,以及我们的市场状况以及之后的规划后。

他说,原来是这样啊!那我们快马加鞭把这个问题解决,争取我们提前上马既定的规划。

我们总是说,工程师不给力,你看这样工程师马上从消极状态变成积极状态。

这是针对市场的背景和目标。

另外,还有针对技术的,产品经理应该清晰的表达出产品的使用场景。

还是举个例子,比如我们要做一个人脸识别设备,你直接告诉技术要实现人脸识别可行吗?

你想想,设备看不见人脸怎么办,哪种安全度更好?

当你跟工程师充分沟通之后,才能设计出合理的、成本合适的产品。

因为,我们产品经理很多往往没有技术背景或者技术背景很弱,你自己吭哧吭哧设计的产品,技术人员按照你的定义设计的不一定满足场景的需要,或者不一定有经济性、效率性。

当然,有些公司不希望技术人员知道的太多,比如项目背景,都是极其保密的。但是至少项目要达成的目标你应该与技术人员沟通。

这样有几个好处:

  1. 技术人员能够更好的理解产品,减少对需求理解的偏差。避免出现做出来的功能/性能达不到要求;
  2. 在技术实现方案上可以获得更优解,也可能在实现成本上具备优势(时间和经济成本);
  3. 提高项目组的积极性,因为对产品不再是一知半解,不明白的全靠脑补;明确目标更加热爱产品,因为有期望。

02 梳理出项目的业务及流程图

我们常说,功能组成业务;业务组成模块;模块组成产品;产品组成产品线。用产品及产品线和服务来实现你的战略。

很多产品经理在设计产品的时候及立项会上,一上来就从功能开始。

不仅自己脑子是一团浆糊,听的人更是。

在做具体的功能设计和介绍的之前,应该给一个业务范围和流程。

先介绍,你的产品为了解决什么问题需要做什么业务,又为了什么规划要将范围做到哪里。

这样做是为了加深项目组成员对需求的理解。以此更好的做产品技术设计。

很多时候,产品经理觉得我已经讲的很清楚了,那是因为你从一开始就知道这个项目是什么,你知道整体的背景、产品与产品与云服务之间的关系。你早就把自己带入了实际的场景之中,

但是工程师不一样,他只从你一个个的功能上去自己脑补,他总感觉挺乱的,一会儿到这儿,一会儿到哪儿。到底要怎样?他们不明白其中的逻辑关系。

比如,我们智能硬件,物联网。通常是 A 产品与 B 产品连接,数据传输,从云端处理或者中转等等。

你应该首先给一个产品关系图,怎么连接到一起的,通过什么连接的。

然后介绍,你的产品做了什么业务,然后这个业务流转到哪里?

一项一项的介绍,介绍完某几个相关业务之后,给出他们的逻辑关系,最好用图的形式表示。

03 梳理功能及功能流程图

业务及业务流程图梳理清楚了,那整个系统产品的轮廓就行了。

还记得我们说功能组成业务吧!

将业务拆解成一个个的功能,因为业务是由功能完成的结果。

所以需要将一个个的功能串起来,形成关系。

将这些背景向工程师解释清楚,功能需求的目的。

有时候,产品经理认为自己已经说的很清楚了,为什么工程师并不明白呢?

主要是因为产品人员在项目早期,深入到用户的使用环境,已经了解了工作流程,遇到的困难和麻烦。

对产品的背景、结构、要实现的目标有了亲身的体会,非常清晰其中的功能关系。

那工程师就不一样,他们了解的信息是支离破碎的。

他们需要你梳理功能范围以及功能流程,异常处理机制,所产生的信息流向是哪里?

比如,用无人机进行一个绕自身一周的自拍视频发朋友圈。

这个业务,是由多个功能组成的实现的。

无人机离拍摄者多远,离地面多高?以什么速度绕圈,怎么去设置这些功能?什么条件下可以执行,什么条件下不可以执行任务,执行完任务,又作何处理?等等。

如果,产品人员在设计需求的时候,没给出整个业务的结构和流程,那么工程师只能靠自己的脑补。那这样就彻底偏离了产品的方向。

要么产品偏向,那么整个系统不完整,漏洞百出。像无人机这样的产品会出现人身安全风险。

还有一个重要的沟通,我们产品经理可能不懂,那就是算法。智能硬件很多都涉及算法,包括我们做自主移动机器人,前几天还写了一篇关于 PID 的文章。但是产品经理需要与工程师沟通,了解其逻辑,实际表现出来的效果,参与其中,是否符合用户需求和预期。

04 交互元素和操作逻辑

智能硬件产品多是具备联网功能和与人交互的。无论是人与机器的交互,还是人与 App 的交互,还有操作逻辑。

App 这个咱们就先不讲,我们看看人与机器的交互需求设计。

人机交互有很多方式,比如扬声器、显示屏、灯光、按钮等等。

产品经理应该清楚的交代表现和动作方式。

拿按钮来讲,为了安全和误触需要设计成“短按+长按”来实现开关机,间隔多久;按钮的设计元素。

显示屏显示哪些内容信息,格局如何?是否可以进行触摸操作,操作逻辑。界面元素是怎样的?如何表现?如果进行操作,产生的数据逻辑是怎么样的?等等!

这块儿就不多讲了,互联网在交互上有很多我们学习的地方。

05 最后

关于产品文档的事情,真的不需要找什么模版,没有用。只要清楚的交代出产品需求就好了,至于什么格式,用什么软件那都不重要。

哪怕在纸片上龙飞凤舞都行。

说说我自己关于文档的事情吧!我往往是将文档写的越细越好,当然存在一个问题是,沟通的时间成本比较高,我认为,写的越精确越好。好记性真不如烂笔头,无论是后期查阅,还是当你不在的时候,技术不能及时的沟通,查阅文档也是一个比好优质的方法。

后期复盘也是重要的依据,知道产品是如何演进的。

文字多了确实麻烦,工程师也不爱看。

但是,业务、功能流程图,操作逻辑,数据流向等结构/关系图一定要画。

所谓文不如表,表不如图。

好了,产品与技术沟通的方法技巧还有很多,但总体原则是不变的。

 

作者:Arvinzhou,微信号:zf519678391;公众号:面壁求知,ID:AIPM001)欢迎关注我!

本文作者 @周较瘦 。

版权声明

本文来自互联网用户投稿,文章观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符,请点击 举报 进行投诉反馈!

相关文章

立即
投稿

微信公众账号

微信扫一扫加关注

返回
顶部