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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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