LOFTER-网易轻博

写在前面

整个四月，修改了200多项BUG、优化，加上接下来的重构，整个产品基本等于重做一遍。团队不停的出各种原型，做各种功能、页面，从需求到实现，看来我们走了弯路。

需求分析

怎么将用户需求转化可见的原型？

需求分析应该是严谨而科学的，每个产品经理都需要一套自己的方法论。不同于C端需求，B端需求都来自于垂直行业，高度贴合客户业务。所以，B端需求分析，需要有一套结合业务的分析方法。

从宏观，我将需求按其生命周期分为用户需求、功能需求和产品需求。用户需求是原生的需求描述，可能仅仅是一句话。功能需求是我们所要实现产品的具体功能。产品需求则会落实到具体功能如何实现。

从产出上分析，我将需求分析阶段的产出依次分为需求池、功能列表、需求功能对照表、功能清单/信息架构。

开始分析之前，先整理需求。将需求池中需求的来源、优先级标注清楚。B端产品的需求通常来源于客户、老板、竞品和对业务的深度建模分析。最重要的是划分优先级，然后去做版本控制。

需求池

得出需求与功能后，我们就要去具体的实现了。在出原型之前，我们需要对需求与功能进行分析，主要分为场景分析、角色分析、业务分析。

一、场景分析

场景分析目的是为角色分析和业务分析打下基础。主要通过与客户沟通，了解清楚用户的需求背景和业务背景，对需求有个明确的理解。除了通过客户沟通外，也可以使用其他的调研或分析方法。如果，机会合适的话，最好深度参与一下用户的业务。比如，将HR的招聘账号拿过来，亲自去体验整个招聘产品的业务流。

场景分析过程中，需要整理出场景故事、用户沟通记录等。

招聘产品的场景故事其实很简单：企业的招聘者在有招聘需求后，去各招聘平台发布职位。之后开始浏览收到的人才简历，打电话邀约面试。如果遇到紧急的人才招聘，会使用各种增值服务（置顶、刷新、猎头服务等）。

二、角色分析

角色分析的目的是整理出需求中包含的角色，以及明确角色所包含的属性。这里我们重点考虑用户。

根据场景故事，我们可以整理出核心用户角色：企业招聘者、人才,所处的环境：办公室，时间：上班期间

完成角色的分析后，下一步进行业务分析。

三、业务分析

业务分析的目的是，分析用户需求背后的业务流程，理清楚相关的数据结构和操作，为用户需求制定合适的解决方案，并把用户需求转化为实际的建模描述(用UML表示)，为功能清单/信息架构制作打下基础。

第一步，分析出角色和系统的关联关系。企业通过信息完善系统展示企业信息、通过职位发布系统发布招聘职位，人才通过简历系统创建简历，通过投递系统投递职位。系统通过标签系统为企业、人才添加标签并做匹配、排序、展示

第二步，完成系统的分析后，将用户需求转化为功能需求。我们分析出了需要哪些系统，系统包含哪些功能。再完成系统间的交互分析，明确每个角色行为，在业务内进行的运作。

明确系统的执行顺序后，就可以通过流程图完成描绘出整个业务了。如果是一个流程有多个角色参与，可以使用跨职能的泳道图。

流程图

泳道图

完成流程图后，就接近分析完成整个需求和业务。但是针对某些一些特殊内容，我们还需要更为深入的分析。比如某些实例的状态。

业务分析完成后，我们就完成了需求分析。我们需要产出直观的功能清单或者信息架构。通过功能清单，就将功能需求转化成产品需求。

完成功能清单后，就完成了需求分析，后面才可以开始制作原型。

四、总结

业务分析是需求分析最核心的部分。在B端产品的需求分析中，需求和业务是高度耦合的，没有深入业务层面的需求分析，都是不够客观的。

如果需求脱离了实际的业务，最后就变成了堆功能了。