如何才能保证需求是业务所需

其实我是一个抽烟的人，大概是抽烟可以走两步活动活动身体，亦或者是可以思考思考东西。某次和同事下楼抽烟的时候，他问我说，你有没有总结过怎么能保证做出来的需求产品是业务所需的，不会做错。我简单回答了下，正常的工作流做好（即需求沟通到方案出来，一直处于和业务沟通的状态下），一般不会出现，这也是后台产品的必备能力了。

不过上楼后，我又继续想了想，其实这个问题并不是本源，即后台的产品的基本素质就应该让需求不会偏离，这个问题应该切换成“你有没有总结过，什么样的方案是一个好的解决方案”。其实大概的意思就是，一个业务需求，大家都能解决，也就是满足业务所需，但是这里边方案有很多，比如A方案耗时一周，B方案耗时一天，假设业务需求都能满足，会选择哪一种？（这里排除一些特殊的，比如大的产品规划等，避开牛角尖，只是个举例说明）

进入今天文章的主题，如何去做一个好的产品方案，或者如何去评价一个方案的优不优。（前提，基于现状实现业务需求，不考虑长远的规划，或者其他因素等。涉及到更高维度的，我们后续再谈，这次只说需求确认后，到完成的阶段）

记得上篇文章说了流程化的思维方式，那么今天我们还可以按照流程化的方式来进行发难思考。正常来说，一个需求到需求实现，即功能可以使用，我们简单概括为以下几个环节。

我们首先从第一部开始需求的确认：

需求确认这里不做细说，也就是明确我们要干什么，一般来说需求不要搞错就好。网上有很多分析需求的方法，可以参照下。

简单确认需求的时候，一般就是需求背景是什么，要解决什么问题就好。但是这里会有一个问题，就是不对需求进入深入思考。最近面试的人比较多，我有时会问一个问题，就是你现在做一个导出怎么做。很多人会啪啪啪的说一大堆比如，按钮放在哪里，导出的是pdf还是excle。其实我们往往忽略了一个问题，为什么要做导出，就是背景是什么，假如不做导出可不可以，是否可以直接在网页上实现。。

好，我们这里需求确认的时候，面对是业务方，我们先得出一个标准：实现业务方的需求（其他的大家可以自己想想，我这里不做多的列举了）

然后进入第二部分产品方案：

产品方案设计的时候，更多是功能的路径，比如涉及到哪些环节，基于现在的功能，我们怎么做调整，这个时候会有多种方式：比如我采用A方案，跟着调整或者变动的环节有多少，涉及到处理的数据有多少，如果是B方案呢？这里往往在流程较多和业务复杂的情况下会出现的较多。我现在采用的就是列出方案，然后从流程开始，列出这些方案的有点和缺点，然后在确认。这个环节大家根据自己的业务特性做总结即可

进入第三部分研发，其实就是产品方案确认的时候，但是往往在这个时候，也可以叫需求评审，我们姑且不认为是直接写代码了，而是和技术沟通这一块的成本问题

最后的上线使用，其实还是回到了业务方，我们开始只是说要满足业务需求，那么需求满足了，对于业务方还有什么呢，比如操作问题（交互设计），操作周期（流程设计）等。

上边简单的说了4个方面，大家可以在思考思考。文章总结的也只是一部分，或者不一定就是对的，作者觉得，分享出来的，是一种思考方式。须有自己的想法，实践所得，胜于所读。

最后，谢谢阅读。