‘需求分析’在产品管理体系中的作用

好久没有写过东西了，自从来到目前这家公司，由于比较忙就没有再写多少博文了，呵，想想偶的博客是不是要长草了呢：）。今天早上醒的比较早，睡不着，想了下最近的工作，突然有一种想写博文的冲动，于是准备写一下与需求分析相关的一系列文章，这也是与最近几年的需求分析工作相关，算作是一种总结或是提练吧，拿出来晒一下。

在一个产品成功的面世，并且得到大家的承认，背后也有一串‘故事’呢，这些‘故事’由产品定义、需求分析、设计、开发、测试、市场等等组成。其中需求分析在整个产品体系当中首先起到的就是一个桥梁和纽带的作用，它是将用户的希望和要求通过语言转换成程序人员能识别的语句，这样希望才会在最终产品中得以体现。

准备做一个产品，首先要了解用户的希望和要求，这也就是所谓的‘用户调研’所要做的工作。需求分析人员就是要从客户的角度出发，在理解客户的要求的基础上，将之转变成一种程序人员识别的文档。下边说一下用户调研需要注意的几点：

首先，要选好调研对象。调研对象的选择要有代表性，最好能选某个区域里的典型行业，具有行业特色，这样才不会片面，至于客户的选择，可以找当地的代理商进行了解后再确定，或是通过市场调研过滤后进行选择。

其次，要深刻挖掘用户需求。在找好调研对象后，要对其行业背景进行了解，然后根据需要制定调研计划，最好能写一个比较细致的调研目标，这样去了才会有的放矢，不至于太盲目。可以针对客户的行业特色，引导用户说出尽量多的业务场景，并做好记录；另外还要收集一些用户的业务数据及资料，带回以备研究。

再次，要有一定量的客户调研，避免片面性。在做一个产品要尽量多的了解客户实际需求，为了避免片面性，同一行业最好多找几家；针对不同区域，客户需求可能不同，对于做产品，要满足大部分客户需求，就要找不同区域进行调研，这样产品才会相对全面，市场覆盖率才会广。

刚说的是做产品之前调研很重要，但在需求分析阶段，也可以有针对性去调研，针对某个问题或某些问题，找相关领域客户进行详细了解，这样分析出来的需求会更接近用户的真实要求。

调研完成之后，在理解用户真正需求的基础上，就要将调研内容形成报告，以备对其进行详细分析，转化为程序员可阅读性文档（业务需求文档），由于各公司风格不同，可能要求会不同，不论哪种，只要写出来后续环节的人员可以看懂即可。另外在此想提一下的是，由于产品划分模块的不同，可能会有一些公共的东东，这些东东最好是先出具，然后再出各业务需求，这样不至于重复劳动，也会为后期的变更打下好的基础，减少变更量。另外在做产品需求分析过程中，还要‘取长补短’，顾名思义就是要学习友商产品的长处。

在理解用户的需求之上，将用户需求转为设计可以理解的文档，设计将按着需求的思路去制作产品的框架，在设计框架的过程中，需求分析人员起到指导、沟通、讲解并最终验证设计思路作用。

首先，需求分析是设计对需求的理解的导航者。需求分析人员出具的需求分析文档是以文字或图表形式表达需求的想法，由于中国文字的博大精深，难免会有一词多意的情况，所以在设计人员查看需求文档过程中，难免会有一些理解出入，在此，需求人员就要起到导航者的作用，即在设计前，需求人员要邀请设计人员参与需求文档的评审，即产品管理体系中称之为‘需求评审’，在此过程中讲解需求文档，通过评审讲解业务，尽可能多的让设计人员理解业务，以便设计人员在理解的基础上进行设计，减少偏差，从而需求分析人员起到导航作用。

其次，需求分析人员在设计过程中起到确认者作用。有了评审过程，使设计人员 对产品需求有一定的认认，在理解业务的基础上，实现产品框架的搭建。由于技术实现的可行性以及工期的约束，所以在设计过程中，还会有一些业务需要双方进行思路的确认，在尽可能满足用户真实需求的基础上，实现产品框架的搭建。对于有技术难度的业务，需要双方达成共识，也许会使用变通的方法实现业务，因此需求分析人员即承载了对设计对需求理解的确认者的角色。

再次，需求分析人员是设计成果的检验者。基于前边两点，设计人员可以根据对业务的理解，设计出产品的框架，但实现的是否真的与真实业务需求一致？这还需要有一个检验的过程，在产品管理体系中称之为‘设计评审’。与‘需求评审’类似，是设计人员将自己的成果展现给大家的机会，在评审的过程中需求人员要根据实现的业务需求，检验设计思路实现的准确性。当然在此过程中会有一些问题，双方会在“技术可实现度、时间因素、真实业务需求”三个因素之间进行平衡，并找出相应的解决方案。也因此在设计评审过程中，使需求分析人员起到检验业务需求的作用。

经过以上三点，基本可以使真实的用户需求向最终产品又迈近一步，从用户需示->产品需求->产品设计，到了第三步，当然以后还会有相应的开发过程、测试、验证、市场等一系列活动，在此之后我还会有相继的博文发表，希望大家继续关注。