产品经理与技术沟通，需要注意这几点
其实这个话题旧文《产品经理的软性能力：协同力与领导力》已经聊过，我觉得我已经讲的很清楚了，回看觉得再细化具体一点。
其实，协同能力和领导力都是需要靠沟通能去实现，今天就聊聊[沟通]。
我们在研发生产过程中，需求反复和双方理解偏差导致研发周期总是被拖，还有产品与技术各种撕，等等。
这些情景在网上被吐槽了很多很多了，而且是更古不变的话题。也是我们产品经理最为头疼的问题。
我有些方法能够解决一些问题，但是我不能保证解决所有的沟通问题，毕竟人是复杂的，取决于沟通双方个人因素。
在旧文中，我说产品经理是首席解释官。
因为整个项目只有你最清楚项目的背景。
所以一个产品项目沟通你需要基于背景/目标、业务范围及流程、功能及流程、交互元素和操作逻辑去沟通。
01 介绍项目背景/目标
很多产品人员经常这样做项目，直接告诉工程师我要做一个产品需要什么功能，多久能够实现。
并不说明，我为什么要做这个，我做这个的背景因素是什么，在什么情景下解决用户的什么问题？达到什么目标？
也许你觉得，工程师知道这些干什么？工程师只需要实现功能就好了。但实际上，这往往造成双方理解的偏差。
举个例子，在一个项目立项会后，我们一位硬件技术负责人跟我说，我们为什么不像谁谁那样做一些高精尖技术的产品，总是做这些我们做过很多次的成熟技术项目，没什么意思。
因为他不明白我做这个产品的市场目的，以及这个产品诞生的背景。
当我告诉他我们目前产品线遇到的问题，同行竞争的状态，公司目前能力和资源，以及我们的市场状况以及之后的规划后。
他说，原来是这样啊！那我们快马加鞭把这个问题解决，争取我们提前上马既定的规划。
我们总是说，工程师不给力，你看这样工程师马上从消极状态变成积极状态。
这是针对市场的背景和目标。
另外，还有针对技术的，产品经理应该清晰的表达出产品的使用场景。
还是举个例子，比如我们要做一个人脸识别设备，你直接告诉技术要实现人脸识别可行吗？
你想想，设备看不见人脸怎么办，哪种安全度更好？
当你跟工程师充分沟通之后，才能设计出合理的、成本合适的产品。
因为，我们产品经理很多往往没有技术背景或者技术背景很弱，你自己吭哧吭哧设计的产品，技术人员按照你的定义设计的不一定满足场景的需要，或者不一定有经济性、效率性。
当然，有些公司不希望技术人员知道的太多，比如项目背景，都是极其保密的。但是至少项目要达成的目标你应该与技术人员沟通。
这样有几个好处：
- 技术人员能够更好的理解产品，减少对需求理解的偏差。避免出现做出来的功能/性能达不到要求；
- 在技术实现方案上可以获得更优解，也可能在实现成本上具备优势（时间和经济成本）；
- 提高项目组的积极性，因为对产品不再是一知半解，不明白的全靠脑补；明确目标更加热爱产品，因为有期望。
02 梳理出项目的业务及流程图
我们常说，功能组成业务；业务组成模块；模块组成产品；产品组成产品线。用产品及产品线和服务来实现你的战略。
很多产品经理在设计产品的时候及立项会上，一上来就从功能开始。
不仅自己脑子是一团浆糊，听的人更是。
在做具体的功能设计和介绍的之前，应该给一个业务范围和流程。
先介绍，你的产品为了解决什么问题需要做什么业务，又为了什么规划要将范围做到哪里。
这样做是为了加深项目组成员对需求的理解。以此更好的做产品技术设计。
很多时候，产品经理觉得我已经讲的很清楚了，那是因为你从一开始就知道这个项目是什么，你知道整体的背景、产品与产品与云服务之间的关系。你早就把自己带入了实际的场景之中，
但是工程师不一样，他只从你一个个的功能上去自己脑补，他总感觉挺乱的，一会儿到这儿，一会儿到哪儿。到底要怎样？他们不明白其中的逻辑关系。
比如，我们智能硬件，物联网。通常是 A 产品与 B 产品连接，数据传输，从云端处理或者中转等等。
你应该首先给一个产品关系图，怎么连接到一起的，通过什么连接的。
然后介绍，你的产品做了什么业务，然后这个业务流转到哪里？
一项一项的介绍，介绍完某几个相关业务之后，给出他们的逻辑关系，最好用图的形式表示。
03 梳理功能及功能流程图
业务及业务流程图梳理清楚了，那整个系统产品的轮廓就行了。
还记得我们说功能组成业务吧！
将业务拆解成一个个的功能，因为业务是由功能完成的结果。
所以需要将一个个的功能串起来，形成关系。
将这些背景向工程师解释清楚，功能需求的目的。
有时候，产品经理认为自己已经说的很清楚了，为什么工程师并不明白呢？
主要是因为产品人员在项目早期，深入到用户的使用环境，已经了解了工作流程，遇到的困难和麻烦。
对产品的背景、结构、要实现的目标有了亲身的体会，非常清晰其中的功能关系。
那工程师就不一样，他们了解的信息是支离破碎的。
他们需要你梳理功能范围以及功能流程，异常处理机制，所产生的信息流向是哪里？
比如，用无人机进行一个绕自身一周的自拍视频发朋友圈。
这个业务，是由多个功能组成的实现的。
无人机离拍摄者多远，离地面多高？以什么速度绕圈，怎么去设置这些功能？什么条件下可以执行，什么条件下不可以执行任务，执行完任务，又作何处理？等等。
如果，产品人员在设计需求的时候，没给出整个业务的结构和流程，那么工程师只能靠自己的脑补。那这样就彻底偏离了产品的方向。
要么产品偏向，那么整个系统不完整，漏洞百出。像无人机这样的产品会出现人身安全风险。
还有一个重要的沟通，我们产品经理可能不懂，那就是算法。智能硬件很多都涉及算法，包括我们做自主移动机器人，前几天还写了一篇关于 PID 的文章。但是产品经理需要与工程师沟通，了解其逻辑，实际表现出来的效果，参与其中，是否符合用户需求和预期。
04 交互元素和操作逻辑
智能硬件产品多是具备联网功能和与人交互的。无论是人与机器的交互，还是人与 App 的交互，还有操作逻辑。
App 这个咱们就先不讲，我们看看人与机器的交互需求设计。
人机交互有很多方式，比如扬声器、显示屏、灯光、按钮等等。
产品经理应该清楚的交代表现和动作方式。
拿按钮来讲，为了安全和误触需要设计成“短按+长按”来实现开关机，间隔多久；按钮的设计元素。
显示屏显示哪些内容信息，格局如何？是否可以进行触摸操作，操作逻辑。界面元素是怎样的？如何表现？如果进行操作，产生的数据逻辑是怎么样的？等等！
这块儿就不多讲了，互联网在交互上有很多我们学习的地方。
05 最后
关于产品文档的事情，真的不需要找什么模版，没有用。只要清楚的交代出产品需求就好了，至于什么格式，用什么软件那都不重要。
哪怕在纸片上龙飞凤舞都行。
说说我自己关于文档的事情吧！我往往是将文档写的越细越好，当然存在一个问题是，沟通的时间成本比较高，我认为，写的越精确越好。好记性真不如烂笔头，无论是后期查阅，还是当你不在的时候，技术不能及时的沟通，查阅文档也是一个比好优质的方法。
后期复盘也是重要的依据，知道产品是如何演进的。
文字多了确实麻烦，工程师也不爱看。
但是，业务、功能流程图，操作逻辑，数据流向等结构/关系图一定要画。
所谓文不如表，表不如图。
好了，产品与技术沟通的方法技巧还有很多，但总体原则是不变的。
作者：Arvinzhou，微信号：zf519678391；公众号：面壁求知，ID：AIPM001）欢迎关注我！
本文作者 @周较瘦 。
版权声明
本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！
