大话需求分析中的方法论（3）

 

继续就这个案例来讨论一下，对我们来说，首先应有的是风险意识，在这个过程中，项目经理在风险管理上并没有完成任务，在第一个里程碑评审过程中，对客户业务的理解产生了偏差，而项目组并没有在这方面进行深入的研究，过分的相信了与用户沟通及以往的经验，在项目早期，项目经理也曾多次与客户主管领导进行沟通，也进行了相当规模的集中访谈；在这个过程中，用户针对OA中会议系统的不足，提出了他们的想法与要求，但当时领导并没能及时区分通常的OA与他们所需要的重要区别在哪？也没能全面的说明会议系统对人大办公厅核心业务的作用。其实在这个阶段，很少能有用户准确的说明他们希望的是什么，但他们能说明的是根据他们的知识以及理解而产生的需求，也就是一头生物牛，对项目团队来说，这已经能说明问题了，关键是项目团队如何能将这头生物牛理解成客户的真正需求：拖拉机。

在项目管理过程中，能不能避免这类事情的发生？坦率的说，完全避免，至少我现在还没有什么特别有效的办法，但在实践中，我们总结了一些办法，希望能有效的在早期风险评估过程中能发现此类风险并采取一些规避措施。
二、如何开始需求分析？
 

我自己的习惯，总是先从理解客户开始。理解客户什么？其实就是理解客户到底在说什么？先从一个极端的例子开始吧，市场部在9月底非常顺利的签订了一份OA合同，在项目任务书中明确要求11月底以前上线运行，当项目经理到客户处进行了初步的接触后，向我汇报说客户要求的与我们的差别虽然不是很大，但要在11月底上线，只有九周的时间，这其中还有一个长假，所以延期布置的风险很大；对此我带着项目经理与客户的主管领导进行了一次交流，这才理解，客户在12月初要进行单位信息化建设的检查与评比，而客户在年初计划中已经将这个项目列了进去，由于种种原因，一直没能实施，只是到第四季度了，整个行业要进行评比与检查，而信息化建设又是重要内容，所以才有这样的时间要求。由此，整个项目的策略就完全不一样了，功能需求的等级就让位于及时布置与培训了。我们反而提前完成了领导的预期目标，至于检查以后，这个单位并没有在OA上继续提出需求变更的要求，原因也是极端的，领导换了，新的领导关注的是业务系统的信息化建设，对OA他认为可以放一放，所以他们根本就没有使用(^-^)。

还是回到一个常规项目上的需求分析吧，我们以一个全新的项目来进行一次需求分析之旅。
<待续>