产品经理的需求（含PRD）能够被精准不麻烦的复现，说明产品经理描述此需求比较清晰。

产品经理一般是通过先自我吃透需求，然后再对需求进行聚类、递归和因果表达出来。

如下图：

作为产品经理（万金油角色）也需要去梳理了解产品角色逻辑，方便更好的沟通交流，其实产品逻辑可以分为四大类：基础产品逻辑、业务逻辑、系统逻辑和思维逻辑。一般通过四个方面如下：

业务逻辑篇

基础产品逻辑篇

系统逻辑篇

思维逻辑篇

具体理解如下：

业务逻辑：需要业务伙伴解释清楚：这个业务想为哪些用户提供什么样的解决方案，目的是什么？——业务评审会

产品逻辑：需要产品经理在这个场景中能满足业务的哪些需求，通过原型交互方式、不同页面的跳转规则、角色判断等来对项目组其他同事梳理清楚。——产品评审会

视觉逻辑：需要依托于产品经理做这样的原型背景下，UI应该用怎样的视觉来让对应用户沉浸在该场景中。——设计评审会

交互逻辑：UE协同产品经理表达怎样的交互让用户感觉更加的友好，增强用户的操作感——交互评审会（和产品评审会一起）

开发逻辑：有些逻辑可能用技术语言描述更清楚一点，以及对技术有特殊的要求。前后端介面、数据对接等。——介面评审会

至此描述一个需求功能点需要产品经理站在被传达著的场景，思考被传达者所了解的需求数据，如果他知道的不多，那么产品经理帮忙补上。

这是一个比较大的问题，但可以简单地回答几个核心要点。

在回答之前，我觉得这个问题问的多少有些模糊，不够清晰，比如：

  • 这个需求是否是关于软体的需求？
  • 产品经理和谁清晰地描述？

不同的对象，描述的方法也会不太一样。对业务有业务的描述方法，对技术有技术的描述方法。所以，在描述需求功能点的时候，一个最基本的规则就是：

用对方能够听懂而且可以深入理解、无歧义的方式来描述需求。

接下来我们假设这个问题是在问关于软体的需求，我们来看一下某一个需求功能点的描述方式：

  1. 如果需求功能点比较小、比较简单而且独立，可以用User Story的方式来描述需求，如果情况刚好相反，那就用Use Case。
  2. 交互可以用低保真原型，如果一定要『清晰』，那就得用高保真了。
  3. 用文字的方式说清楚业务规则，可以举例说明，这一步如果做的比较到位，测试用例也就快出来了。

通常来讲，能做到以上3步，单一的需求功能点就已经很清楚了，如果还不够，可以继续：

  • 对于技术团队，如果遇到了复杂的业务逻辑，文字描述容易引起歧义的话，伪代码是消除歧义的必杀技。
  • 为了消除各方可能出现的歧义，需要说清楚项目的目标、需求的由来、相关的背景、制约的因素、未来的规划、相关需求之间的关系等等。
  • 需求功能点不仅涉及到功能，通常还涉及到其他类型的需求，例如：性能、质量、管理、维护......，在必要的情况下，需要弄清楚，不要遗漏。

如果你做到了上面这些，可以说，单一的需求功能点已经清晰无歧义了，当然，还有一些方法可以在需求过程中保证需求功能点的清晰度，在这里就不再展开了。

希望回答了你的问题。

先整理个名词表，务必统一所有名词及解释。如果受众无法接受英文缩写，请务实一些，用朴实的中文 ------ 你信手拈来的 CP （内容方），你的程序员可能百度了一下，曲解成「情侣」。

复杂的功能点，说之前，自己先画一遍；公开场合，自己先预演一遍。

能画清楚的，不用加旁白，剩下的时间交给别人看、琢磨、提问题。

画不清楚的，补文字，让别人看的同时自己做解说。

如果是可视化产品，利用好原型工具，时间准许的前提下，事无巨细，尽量 100% 还原。

如果是非可视化的，学习使用各类流程图。

不要试图描述如何实现，不论是技术工作、美术工作、或者跑腿工作，只聊想要的结果。

最后，不论对方是否真的明白了，都要不厌其烦的从头核对一遍。

补一个小故事：

15年前，要给公司开发一个网页。

之前合作过的策划（当时公司没有产品经理这个概念，我们称为策划），通常是交给我一张A4纸，上面1、2、3、4的罗列功能，用心一点的会像写论文一样，每一点下面再罗列（1）、（2）、（3）小点，然后补充大量文字。

这次这个策划有点特别，一个新入职的同事。他交给我一堆A4纸，大概60多页，每页纸上面都手绘了整张网页的所有细节，然后在互动的元件边上用类似 「word 批注」的方式绘声绘色的描述为什么有这个互动、要如何互动、互动后的结果、能解决的问题。

当时觉得他这个搞法很新颖，而且特别效率，顿时对他有了极大的好感。当然，直到今天我们也是非常好的朋友+合作伙伴。

他的这一套，之后有了更专业的说法和工具，比如原型设计（Axure），敏捷开发中的 user story 。

遇到脑子清楚的人，确实是工作中最值得庆祝的事儿。

以人为本，从用户出发，找到用户的需求点，根据这个需求点设计和开发产品，进而可以清晰的找到产品的需求功能点！

首先，先界定好你的产品要解决目标用户的需求是什么？这里需要描述：

  • 你的目标用户是什么样的？
  • 他们在什么场景（时间、地点）产生了什么样的动机（问题、目标），因而产生了什么需要？
  • 在这个过程中，你期望解决什么问题，帮助用户达成目标

其次，你为解决这个问题，提供什么样的解决方案？这里需要描述：

  • 为什么是这个解决方案？你的思考排序维度都是什么？（投入产出比，试错成本低还是商业价值等等）
  • 都有哪些功能集合来支持这个解决方案
  • 最核心而重要的功能是哪些？有哪些是非必要的功能（锦上添花，可舍弃的）？

最后，展开重要核心的功能详细描述：

  • 用户如何使用这个功能，也就是用户流程
  • 关键的业务辞汇描述，让协同者理解你传递的专业或业务辞汇，降低后续沟通成本
  • 明确描述验收和走查的标准，让开发和测试聚焦关键范围

也可以参考如下需求文档的样例：

这是我们工作多年对需求描述的最好的实践理解，希望能回答题主的问题，帮到你

说不清楚就画出来，软体用的不顺手，就直接在纸上画，如果画都画不出来，那么就说明自己的思路还不清晰，继续整理思路。如果能画出来，那么基本上也就可以清晰的表达清楚了

这个问题很抽象，而产品经理在实际工作中需要把抽象问题具体化，具体办法就是明确问题的用户场景目的。

所以我们首先要明确这个问题的三个重要要素，也就是，产品经理给谁讲需求，背景是什么，描述需求的最终目的是什么？以下举几个例子:

  • 产品经理日常做技术评审，给开发讲需求，希望开发理解需求并启动排期上线计划
  • 产品经理要做晋升述职，需要给领导描述自己做过的需求，从而获得认可和晋升
  • 产品经理要与业务方同步需求方案（tob场景），确认该解决方案能够解决问题，保证需求上线后符合业务方预期效果。

基于背景目的才能明确问题，才能明确解法。我们来简单看下其中某个场景的解法:与业务方描述需求。

业务方关注的一定不是技术实现方式，而是这个需求能解决我什么问题，我要怎么用，效果是什么。

  1. 解决什么问题

开头的描述往往就是介绍需求提出背景，谁遇到了什么问题，影响有多大，相关涉及方都有谁。这样双方才能在同个目标去理解这个需求，这一步基本上也是其他场景介绍需求时必备项。

2. 要怎么用

接著要阐述为了解决这个问题，设计相应的功能方案具体是什么样的。

基于这个功能，运营上线前需要做什么操作？日常又要怎么去使用，

3. 效果是什么

最后一步也是最关键的，这个需求上线后可以带来多少效益。这个效益如何体现，可以通过哪些数据指标进行观察。

推荐阅读：
相关文章