古之成大事者,不惟有超士之才,亦唯有坚韧不拔之志

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

其实我是一个抽烟的人,大概是抽烟可以走两步活动活动身体,亦或者是可以思考思考东西。某次和同事下楼抽烟的时候,他问我说,你有没有总结过怎么能保证做出来的需求产品是业务所需的,不会做错。我简单回答了下,正常的工作流做好(即需求沟通到方案出来,一直处于和业务沟通的状态下),一般不会出现,这也是后台产品的必备能力了。
不过上楼后,我又继续想了想,其实这个问题并不是本源,即后台的产品的基本素质就应该让需求不会偏离,这个问题应该切换成“你有没有总结过,什么样的方案是一个好的解决方案”。其实大概的意思就是,一个业务需求,大家都能解决,也就是满足业务所需,但是这里边方案有很多,比如A方案耗时一周,B方案耗时一天,假设业务需求都能满足,会选择哪一种?(这里排除一些特殊的,比如大的产品规划等,避开牛角尖,只是个举例说明)
进入今天文章的主题,如何去做一个好的产品方案,或者如何去评价一个方案的优不优。(前提,基于现状实现业务需求,不考虑长远的规划,或者其他因素等。涉及到更高维度的,我们后续再谈,这次只说需求确认后,到完成的阶段)
记得上篇文章说了流程化的思维方式,那么今天我们还可以按照流程化的方式来进行发难思考。正常来说,一个需求到需求实现,即功能可以使用,我们简单概括为以下几个环节。
《如何才能保证需求是业务所需》
我们首先从第一部开始需求的确认:
需求确认这里不做细说,也就是明确我们要干什么,一般来说需求不要搞错就好。网上有很多分析需求的方法,可以参照下。
简单确认需求的时候,一般就是需求背景是什么,要解决什么问题就好。但是这里会有一个问题,就是不对需求进入深入思考。最近面试的人比较多,我有时会问一个问题,就是你现在做一个导出怎么做。很多人会啪啪啪的说一大堆比如,按钮放在哪里,导出的是pdf还是excle。其实我们往往忽略了一个问题,为什么要做导出,就是背景是什么,假如不做导出可不可以,是否可以直接在网页上实现。。
好,我们这里需求确认的时候,面对是业务方,我们先得出一个标准:实现业务方的需求(其他的大家可以自己想想,我这里不做多的列举了)
然后进入第二部分产品方案:
产品方案设计的时候,更多是功能的路径,比如涉及到哪些环节,基于现在的功能,我们怎么做调整,这个时候会有多种方式:比如我采用A方案,跟着调整或者变动的环节有多少,涉及到处理的数据有多少,如果是B方案呢?这里往往在流程较多和业务复杂的情况下会出现的较多。我现在采用的就是列出方案,然后从流程开始,列出这些方案的有点和缺点,然后在确认。这个环节大家根据自己的业务特性做总结即可
进入第三部分研发,其实就是产品方案确认的时候,但是往往在这个时候,也可以叫需求评审,我们姑且不认为是直接写代码了,而是和技术沟通这一块的成本问题
最后的上线使用,其实还是回到了业务方,我们开始只是说要满足业务需求,那么需求满足了,对于业务方还有什么呢,比如操作问题(交互设计),操作周期(流程设计)等。
上边简单的说了4个方面,大家可以在思考思考。文章总结的也只是一部分,或者不一定就是对的,作者觉得,分享出来的,是一种思考方式。须有自己的想法,实践所得,胜于所读。
最后,谢谢阅读。

点赞

发表评论

电子邮件地址不会被公开。 必填项已用*标注