之前有一个项目，是给一家大型的国有企业做一个关于资产管理的APP。因为这家公司是国有企业，所以他们要求我们每周都要去他们公司一趟，毕竟两家公司不在一个地方，隔得还是有点远。因此通过双方领导确定要做这个项目以后，产品经理也开始慢慢的切入到这个项目中来了。
我们要做的第一步就是调研需求并收集整理需求，于是我们整理了一个需求调研计划表。这个表主要就是从调研部门和调研时间安排2个维度来展开对客户方的需求调研。在调研开始之前，我们准备了一个PPT，准备在调研开始之前先和各个业务部门的领导和主干业务人员开一个会议，给大家通知一下我们调研的主要内容、主要要达到的目的、调研的时间安排等。
开完会议后，我们便开始一个部门一个部门的做调研了。虽然这个项目的性质是互联网性质的项目，但是我们的做法还是有点像做传统IT项目那样。做调研我们是两个人一起，一个人负责问，而另一个人主要是负责记录。很快的，我们便用了2天不到的时间就搞定了所有业务部门的需求调研。所谓的搞定就是指收集好了所有部门的需求并做了记录，然后接下来就是画原型和写产品相关的文档了。
我先用visio画了一个关于资产管理的整个的业务流程图，然后我又按照不同的模块维度画了几个分开的业务流程图。然后从逻辑上先推导这样做是不是通的，画好流程图后我便开始及时的整理了需求分析文档。其实，我们当时的需求分析文档写的颗粒度是很粗的，因为我们要将具体的实施方案和实施步骤放在我们的项目实施方案中来写。然后，做完这些以后，我们便开始参照需求分析报告搞了一个概要设计文档。
其实，在这个过程中，我们在之前做的需求分析文档和项目实施方案这2个文档是可以合成一个文档来写的，就是一个需求分析报告就可以了。而我们也是由于客户的要求，所以将一件事做了2次。做好这些以后，由于之前我已经将产品的大概的原型勾勒出来了，所以现在要做的主要就是再对一些地方进行调整和完善。
原型做好后，我又在原型的基础上将产品的详细设计报告和功能清单整理了出来。完成所有准备工作后，我就及时召开了一个项目内部的评审会，而此次会议的主要目的就是大家对该产品进行评估并提出修正意见。
会议开始后，大家都是七嘴八舌的开始了激烈的讨论。有的开发同事说这个功能点之前没有做过，估计不好做，能不能换一种方式来实现这个功能；又有开发说，这些细节方面的东西我在这个demo上都看不到，这个你和客户确认过吗？还有的开发说这个地方的功能是多余的吧，能不能删除不要呢？
于是，在一个需求评审会议下来你会发现你的这次需求分析做的还是很不到位，总结起来也就是有一些几点的问题：
1、对需求调研和分析的颗粒度做的太大了。我们只是将大的方向和大的方面的需求做到了，但是对于细节方面的东西和客户确认的不够，同时自己分析的也不够深入。
2、我们对技术的理解程度不够，开发做事是站在他们对技术的理解层面上来提出意见的。而产品经理做的需求是站在用户使用的角度上提出的问题，所以维度不同，在需求评审时就会出现偏差。但是，产品经理如果懂技术的话，这种问题就会在设计阶段就及时的规避掉了。
3、对开发过于妥协。作为产品经理，我们要把控整个项目的实施进度，于是当开发提出这个问题在技术实现上有点难度的时候，我们总会觉得只要能够实现这个功能就可以了。技术上不好实现，那就换一个简单的方式甚至是不要这个功能。如果你这样想，那就很危险了。我们是对开发妥协了，可是客户会对我们妥协吗？况且你实现的功能客户一看就说这不是我想要的结果，此时你又要做何选择？你是继续要求开发必须实现这个功能还是极力说服客户不要这个功能？此时你将陷入两难的境地。所以，最好的办法就是不对开发妥协，除非是有些地方实在是无法实现的时候，这个时候再和客户沟通看是否可以换一个方式来实现。
所以，需求分析阶段如果做的不到位或不细致，最终你会在后面的阶段感受到说不清的尴尬。如果你想在后面的项目过程中好受一点，那就在需求分析上多下点功夫吧。
之前有一个项目，是给一家大型的国有企业做一个关于资产管理的APP。因为这家公司是国有企业，所以他们要求我们每周都要去他们公司一趟，毕竟两家公司不在一个地方，隔得还是有点远。因此通过双方领导确定要做这个项目以后，产品经理也开始慢慢的切入到这个项目中来了。
我们要做的第一步就是调研需求并收集整理需求，于是我们整理了一个需求调研计划表。这个表主要就是从调研部门和调研时间安排2个维度来展开对客户方的需求调研。在调研开始之前，我们准备了一个PPT，准备在调研开始之前先和各个业务部门的领导和主干业务人员开一个会议，给大家通知一下我们调研的主要内容、主要要达到的目的、调研的时间安排等。
开完会议后，我们便开始一个部门一个部门的做调研了。虽然这个项目的性质是互联网性质的项目，但是我们的做法还是有点像做传统IT项目那样。做调研我们是两个人一起，一个人负责问，而另一个人主要是负责记录。很快的，我们便用了2天不到的时间就搞定了所有业务部门的需求调研。所谓的搞定就是指收集好了所有部门的需求并做了记录，然后接下来就是画原型和写产品相关的文档了。
我先用visio画了一个关于资产管理的整个的业务流程图，然后我又按照不同的模块维度画了几个分开的业务流程图。然后从逻辑上先推导这样做是不是通的，画好流程图后我便开始及时的整理了需求分析文档。其实，我们当时的需求分析文档写的颗粒度是很粗的，因为我们要将具体的实施方案和实施步骤放在我们的项目实施方案中来写。然后，做完这些以后，我们便开始参照需求分析报告搞了一个概要设计文档。
其实，在这个过程中，我们在之前做的需求分析文档和项目实施方案这2个文档是可以合成一个文档来写的，就是一个需求分析报告就可以了。而我们也是由于客户的要求，所以将一件事做了2次。做好这些以后，由于之前我已经将产品的大概的原型勾勒出来了，所以现在要做的主要就是再对一些地方进行调整和完善。
原型做好后，我又在原型的基础上将产品的详细设计报告和功能清单整理了出来。完成所有准备工作后，我就及时召开了一个项目内部的评审会，而此次会议的主要目的就是大家对该产品进行评估并提出修正意见。
会议开始后，大家都是七嘴八舌的开始了激烈的讨论。有的开发同事说这个功能点之前没有做过，估计不好做，能不能换一种方式来实现这个功能；又有开发说，这些细节方面的东西我在这个demo上都看不到，这个你和客户确认过吗？还有的开发说这个地方的功能是多余的吧，能不能删除不要呢？
于是，在一个需求评审会议下来你会发现你的这次需求分析做的还是很不到位，总结起来也就是有一些几点的问题：
1、对需求调研和分析的颗粒度做的太大了。我们只是将大的方向和大的方面的需求做到了，但是对于细节方面的东西和客户确认的不够，同时自己分析的也不够深入。
2、我们对技术的理解程度不够，开发做事是站在他们对技术的理解层面上来提出意见的。而产品经理做的需求是站在用户使用的角度上提出的问题，所以维度不同，在需求评审时就会出现偏差。但是，产品经理如果懂技术的话，这种问题就会在设计阶段就及时的规避掉了。
3、对开发过于妥协。作为产品经理，我们要把控整个项目的实施进度，于是当开发提出这个问题在技术实现上有点难度的时候，我们总会觉得只要能够实现这个功能就可以了。技术上不好实现，那就换一个简单的方式甚至是不要这个功能。如果你这样想，那就很危险了。我们是对开发妥协了，可是客户会对我们妥协吗？况且你实现的功能客户一看就说这不是我想要的结果，此时你又要做何选择？你是继续要求开发必须实现这个功能还是极力说服客户不要这个功能？此时你将陷入两难的境地。所以，最好的办法就是不对开发妥协，除非是有些地方实在是无法实现的时候，这个时候再和客户沟通看是否可以换一个方式来实现。
所以，需求分析阶段如果做的不到位或不细致，最终你会在后面的阶段感受到说不清的尴尬。如果你想在后面的项目过程中好受一点，那就在需求分析上多下点功夫吧。