|
年前做一个TO B的产品（系统），从接到业务方需求到敲定一份可开发的PRD，光荣的跨年了，中间走过一些弯路，也有一些自己的思考。今天当敲下PRD最后一段文字的时候，终于可以回顾一下整个历程了。概括为一个主题就是“做2B产品我是怎么进行需求的梳理分析”。 2016年12月左右，与业务方进行了一些前期的方案沟通，在7日接到了业务方的第一份需求文档。因为业务方没有实践经验，所以需求文档的状态基本是“业务以为怎么来就怎么来”。还好我先前有过一些类似的项目经验。于是开始了漫漫的需求梳理、分析之路。 接下来我会从以下几个方面讲：需求拆解，需求梳理，需求回顾，需求敲定。另外文末会加一些离坑指南O(∩_∩)O 一、需求拆解 业务方考虑的是怎么样用产品支持他们的业务，达到他们的目标。但是我们的关注点应该是怎么让产品可用，易用。 （1）依据业务流程确定需求分布模块 每个业务目标的实现都是有对应的流程的，特别是2B的产品，业务方向相同的话，往往在很多流程上是相似的。所以依据我先前的一些项目经验，我首先把产品涉及到的业务流程都进行了总结，然后把流程中的每个环节对应的需求进行了对号入座。通过这一步就可以摸清楚业务方到底要干哪些事情，至少短期内可以看出来，更何况一般业务方给的都是一期需求。 （2）确定每个需求要实现的目标 通常来说，需求虽然表面看起来是不相干的，但是他们的目标是关联的，往往有上下，支撑，补充关系，比如实名是为了后续的筛选，历史数据是为了报表的制作等等。通过这一步我们基本明白了业务方这些需求要实现哪些目标，那么我们可以参考相关人员的工作经验，对这些目标进行评估，哪些是有必要去做的，哪些是没必要或者短期没必要去做的，特别是非常个性化但是开发量较大的目标，我们是有义务去进行引导和优化建议的 （3）确定初级功能列表 对于一个业务目标或者产品目标来说，通常是由产品功能来实现的。通过上述业务流程的梳理，结合业务方给到的需求目标，我们可以大概捋出一份初级的功能列表。 这一阶段的产出大概有：业务流程文档、功能列表文档 二、需求梳理 通过了上述阶段，我们基本掌握了业务方的大致目标和产品应该具有哪些功能来满足了。那么这一步我们就要对需求进行梳理分析了。其实也可以着手开始写PRD了，做界面设计了，不要以为太早，PRD和产品原型不是一蹴而就的，也是需要快速迭代的 需求的梳理其实是一个需求、功能优化的环节。 （1）该需求是否有必要？ 有一些需求可能对于当前产品要实现的主要业务目标没有太大关系，业务方往往是从方便自己进行管理而提的需求，因此那些多余的需求可以在协商一致的前提下删除或者优先级降低。 （2）该需求要实现的目标是否和已有需求的重合？ 比如对于一款TO B产品往往有报表的需求，但是大多数情况下，由于产品前期投入使用数据有限，所以不一定非得专门做报表模块。正好一些模块中，有相关的数据展示，那么我们可以直接在里面查询相关的数据即可，如果这些数据可以生产EXCEL下载，那么基本可以完成报表的目标了。在时间紧迫的情况下，没必要去单独开发报表模块。 （3）实现需求的功能最佳解决方案是什么？ 业务方，尤其是没有先前时间经验的业务方，往往都是根据自己的认知去提一些需求和功能，因此我们要利用我们的经验去刻意引导业务方向最佳解决方案靠拢。 总之，需求梳理整个过程就是一个不断打磨细节的过程，越细越好，然后事与愿违，往往由于人力，时间问题，会出现各种各样的问题。那么我们就需要进行下一个环节了。 这一阶段的产出大概有：PRD初稿，产品原型初稿 三、需求回顾 需求回顾是对需求梳理环节的补充，主要是对需求进行再一次审查，防止出现问题。 我主要分了几个类别：遗漏点、新增点、新发现、待优化。 遗漏点：就是在进行需求分析的过程中忽略了某些细节。通常这类细节可能是一些规则，性能要求等 新增点：在进入开发之前，业务方的需求文档也是一个不断迭代的过程，所以对于那些新增的需求要立刻在自己的PRD上面响应 新发现：这里主要是指最初自己对业务方需求的理解，随着逐步沟通，可能会出现新的理解，而这种情况必须要和业务方进行确认 待优化：是指后来发现需求可以优化的点 这一阶段的产出大概有：接近最终版的PRD和产品原型，交流沟通邮件、会议记录等 四、需求敲定 当然这里主要是指最终版的PRD通过了业务方的认可，并且通过和开发沟通，没有任何疑问。 下一阶段可能是一些需求管理和开发跟进的工作了，待更ing |
|
|
