时间: 2021-07-30 11:14:54 人气: 8 评论: 0
编辑导语：需求评审对于产品经理来说是再熟悉不过的一件事了，产品经理作为需求的承接者和中间枢纽，需要对需求进行整理分析和准确输出，而输出需求，是一个不小的难题。
产品经理在工作中扮演者一个角色为“枢纽”，枢纽负责是承上启下，我们从业务、市场、老板方面得到需求，经过我们的调研设计，需要呈现出一份供所有人阅读的文档，如果要做出一份让所有人都能看懂的文档，我们的“输出能力”就显得特别重要。
很多产品同学在工作中，经常**出现和技术同事“扯皮”，**陷入困惑，明明需求写的这么清楚，逻辑都是正确的，为什么技术同事就是不能理解呢？
业务部门是需求的提出者，也是后续系统的使用者。我们与业务进行沟通的时候要深谈，了解业务现在的痛点，我们如何解决这样的问题，所付出的成本是多少，能为公司带来的效益是多少？
后端负责处理系统逻辑和数据，后端关心的是数据如何存储，数据是怎么流转，如何保证系统运行的性能，出现异常是怎么处理的？
前端负责信息的展示，功能的操作，界面的跳转；前端需要了解系统的控件怎么使用，哪些控件是可以统一的，要符合什么样的界面设计。
我们先来回想一下新闻媒体的发展历程，纯文字报纸->网络图文->短视频，传递信息的媒介越来越趋于具象化。
我们淡出使用文字来进行描述往往比较苍白，例如文字“嗯”，单纯这个字，我们很难说这个字表达出的是什么意思，如果加上标点符号再来看：“嗯。”“嗯？”，能看出来一个是肯定，一个是疑问，同样的文字，因为标点符号不同，所表达的意思也不同。如果这个文字通过声音传达出来呢？再辅助人的脸部表情呢？
近几年敏捷开发越来越流行，我在了解敏捷开发知识的时候，对“增量和迭代”两种模式有所困惑，翻找资料过程中，我看到了这样的描述：
增量模型 (Incremental Model) 是您在部分中构建整个解决方案的地方，但是在每个阶段或部分结束时您没有, 任何可以审查或反馈的东西。您需要等到增量过程的最后阶段才能交付最终产品。
迭代模型 (Iterative Model) 是我们迭代这个想法并在迭代各种版本时不断改进的地方。你从一个版本移动到另一个版本你决定（根据反馈）在新版本中需要什么作为更好的选择以及需要丢弃什么。
不明所以，然后我又翻找资料，看到了这样的解释说明，1为增量，2为迭代，一目了然，这就是图**的力量：
我们与业务沟通的时候，已经分析了业务的痛点和要求，在需求确认时，可以辅助例如这样的脑图，清晰的展示业务点：
后端的逻辑是最复杂的，特别是一些算法和业务场景。我曾经负责一个项目【备货计划系统】，我们对备货计划的定义是这样的：
备货系统依据销量、库存、时效进行一系列运算，预测出未来市场趋势和备货需求，由采购负责下单，仓储进行收货、物流执行发运，这一套完善的供应链服务，支撑客户的需求，提高库存周转率，达到降低缺货减少库存资金压力的目标。
在与技术沟通需求时，我发现技术同事很难理解一些关键参数名词定义，于是我画了下面这张图，来表达各个参数之间是什么样的关系，于是我们针对这张图的各个节点展开了需求讨论：
在模拟库存变化情况的时候，我们有了这张图：
在模拟异常销量排除时，我们有了这张图：
我使用了大量的图文结合来表达我希望实现的需求，后端技术同事能够很快的了解我的意思。
前端同事对于逻辑没有太多的关注，他们更关心数据的展示。
例如我们在表达希望前端同事在时间选择器上面加上快捷搜索的时候，可以这样表达需求，时间搜索项中加快捷搜索，快捷搜索的为以下几个：今日、昨日、近2天、近七天、近15天、近30天，解释如下；
假设今天是2021/3/30：
今日：2021/3/30 00:00:00-2021/3/30 23:59:59
昨日：2021/3/29 00:00:00-2021/3/29 23:59:59
近2天：2021/3/29 00:00:00-2021/3/30 23:59:59
近3天：2021/3/28 00:00:00-2021/3/30 23:59:59
近7天：2021/3/24 00:00:00-2021/3/30 23:59:59
近15天：2021/3/16 00:00:00-2021/3/30 23:59:59
近30天：2021/3/1 00:00:00-2021/3/30 23:59:59
我们再工作中了解需求，设计系统很重要，我们把设计方案传达给下个工作部门去实现也同样重要，PRD文档只是我们用来表达需求的一种媒介而已，与技术同事的频繁沟通可以减少系统的出错概率。
孰能生巧，希望大家能找到自己的方法论；望与君共勉，欢迎评论骚扰~
本文由 @elvin 原创发布于人人都是产品经理，未经作者许可，禁止转载。
题图来自Unsplash，基于CC0协议。
