需求分析的方法论

    终于有时间可以总结了，十几年的代码经验，总是想有些可以写的，没多少写作经验，借此向朋友们多学习吧。

    一、从故事谈起

    （ 这个故事记不得出处了，多年来在给项目经理们讲课时，经常用到。）
    话说在上世纪50年代的一个人民公社的领导，找到我们软件公司的项目经理，说我们有一个项目由你来做吧。
    项目经理：“yes sire,你的需求是什么？”
    公社领导：我对公社养牛的家伙很不满意，他养的牛满足不了我们放卫星的要求，我想要一头吃的草比现在的牛少一半，干的活比现在的牛多一倍的新牛（像不像你们的BOSS）；我的需求很明确吧？
    项目经理：是的是的；我现在可以写出需求规格说明书了，然后你鉴上字，确定下来，我们就可以开工了。公社领导：好，就这样定了。
    在需求分析与评审会上，我听到了这个项目的初始需求，项目经理带回来的是让项目组开发出一头新牛的生物工程项目。
    如果按项目经理理解的需求，我们需求玩把DNA技术了，呵呵，反正软件公司是万能的嘛。
    可事情真的是这样？
    其实真的不是这样的，在项目经理与用户的交流过程中用户已经把实际需求显性的说了出来，其实就是想如何利用第三方产品或工具提高生产效率。
    如果项目经理能在需求分析过程中把握好用户的产业特点，并能理解用户的需求，那么提出的解决方案就能真正解决用户所存在的问题。

    所以这个解决方案很简单，卖给他们几台拖拉机！

    故事讲起来很轻松，可我发现在实际工作中我们的项目经理们经常在做生物工程。
    如何在工作中正确的识别用户的需求是项目成功的基础，这一点没有人会反对，可做起来非常不容易。多年来我所接触的项目大多是政府电子政务方面的，所以在这里所有的项目背景也将结合此类项目与大家进行探讨。
    首先遇到的问题，可能是最令我们头疼的，就是用户没有完整的时间来说明他们的需求，可能用户都说不明白一头牛！
    用户在通常情况下有两部份人与软件公司的开发人员接触，这时其实项目需求的风险有时会更大；因为业务的决策者通常会将重要的沟通任务交给了用户单位的信息管理人员，而这些岗位上的人员由于种种原因有一种职业优势，更容易出现生物工程的需求。
    先举一例（首先说明，在这里的例子虽然是从实际工程中提练出来的，由于可以理解的原因，需求是被修订了的），我们的用户需要上OA系统，而我们正好有OA产品；但由于用户需求的差异，每个用户的OA都是需要进行一些小的修正以适应用户在习惯上的差别。当客户单位的信息中心技术人员向我们的项目经理描述需求时，他头脑中有完整的OA产品功能与性能，因为在这之前他已经了解了许多OA产品，于是他就找了一家他认可的公司产品做为需求向我们提了出来。
    当我们的产品经过两周的调整后，布置到了用户的系统中，这时客户信息中心的技术人员很认可系统的功能，我们的项目经理也很轻松，可当领导来认真的考察一番后，对产品非常失望，因为重要功能与他们的要求相差很远。
    为什么会出现这类问题？其实到现在我还没有说出这是什么客户，我想有经验的项目经理早就在心里问了吧，对了这与用户的业务有着很重要的关系，这是人大办公厅，在通常的政府办公厅（室），公文流转是OA中的核心内容，可在人大办公系统，领导最关心的不是公文流转，而是会议系统，并且是相对比较复杂的会议管理，其实这与人大的核心业务有着很大的关系，不论是提案还是协调，都是在不同的会议中进行处理，而且每年都有重要的会议需要管理。我们的项目经理在并没有认真分析客户业务的情况下，轻信了所谓需求与方案，做了个小小的“生物工程”。
    当然要避免这类问题并不难，难的是能有一些方法及时发现这类，能在不同的项目中识别用户真正的需求，确实需要一些技巧。
    继续就这个案例来讨论一下，对我们来说，首先应有的是风险意识，在这个过程中，项目经理在风险管理上并没有完成任务，在第一个里程碑评审过程中，对客户业务的理解产生了偏差，而项目组并没有在这方面进行深入的研究，过分的相信了与用户沟通及以往的经验，在项目早期，项目经理也曾多次与客户主管领导进行沟通，也进行了相当规模的集中访谈；在这个过程中，用户针对OA中会议系统的不足，提出了他们的想法与要求，但当时领导并没能及时区分通常的OA与他们所需要的重要区别在哪？也没能全面的说明会议系统对人大办公厅核心业务的作用。其实在这个阶段，很少能有用户准确的说明他们希望的是什么，但他们能说明的是根据他们的知识以及理解而产生的需求，也就是一头生物牛，对项目团队来说，这已经能说明问题了，关键是项目团队如何能将这头生物牛理解成客户的真正需求：拖拉机。
    在项目管理过程中，能不能避免这类事情的发生？坦率的说，完全避免，至少我现在还没有什么特别有效的办法，但在实践中，我们总结了一些办法，希望能有效的在早期风险评估过程中能发现此类风险并采取一些规避措施。

    二、如何开始需求分析？

    我自己的习惯，总是先从理解客户开始。理解客户什么？其实就是理解客户到底在说什么？先从一个极端的例子开始吧，市场部在9月底非常顺利的签订了一份OA合同，在项目任务书中明确要求11月底以前上线运行，当项目经理到客户处进行了初步的接触后，向我汇报说客户要求的与我们的差别虽然不是很大，但要在11月底上线，只有九周的时间，这其中还有一个长假，所以延期布置的风险很大；对此我带着项目经理与客户的主管领导进行了一次交流，这才理解，客户在12月初要进行单位信息化建设的检查与评比，而客户在年初计划中已经将这个项目列了进去，由于种种原因，一直没能实施，只是到第四季度了，整个行业要进行评比与检查，而信息化建设又是重要内容，所以才有这样的时间要求。由此，整个项目的策略就完全不一样了，功能需求的等级就让位于及时布置与培训了。我们反而提前完成了领导的预期目标，至于检查以后，这个单位并没有在OA上继续提出需求变更的要求，原因也是极端的，领导换了，新的领导关注的是业务系统的信息化建设，对OA他认为可以放一放，所以他们根本就没有使用。
    还是回到一个常规项目上的需求分析吧，我们以一个全新的项目来进行一次需求分析之旅。
    我们还是来做一个某政府办公系统的OA吧。
    当然有许多公司有很成功的产品，这里只是想与大家讨论需求分析中的一些方法论上的问题，与产品无关啦。
    回头再来交待一下项目团队的组成，我还是借用曾经完成过西天取经这样大型复杂项目的四位高人吧，项目经理当然是师傅了，项目中的主力是高手候哥，当然还有魅力之星戒子，以及老实能干的老沙了。
    师傅召开了第一次项目组成例会，并就此开始了历经千折百转的开发之旅。
    <没有一场战役是在没有计划的情况下打赢的，可也没有一场战役是完全按照计划打赢的>
    这是二战时期同盟国元帅告诫后世的，我是很认同的，需求管理并不只在需求分析阶段，如果你喜欢按传统严格分成阶段的话。师傅以这样的开场白开始了项目经理的工作。
    需求分析要完成什么任务？如何制定计划？各村有各村的高招，我认为微软Microsoft Solution Framework(简称MSF)中的定义会更好的帮助项目经理进入状态，在MSF中它将其定义为“远景/范围”阶段。
    从里程碑的意义上讲，都是关键基线（baseline）的建立，但从远景／范围上理解在操作上要比需求分析更能与用户达成共识，远景与范围，其实更难让用户认可的是范围，需求的不稳定一部份是对需求的理解与进化带来的，另一部份就是范围的扩大带来的，使用远景／范围文档并与用户一起进行评审，以建立基线，比需求基线的建立更容易让用户理解，变更控制管理以及风险管理也会更有效。
    这就是需求管理计划制定的必要性，项目经理人对计划的管理普遍感到力不从心，其实计划的目的就是让项目团队与客户一起明确我们的项目远景与范围，并了解我们的项目团队是如何对项目远景与范围的进展变更，以及风险进行管理与控制的。
    需求管理计划的内容有什么那？一般我会将其分成两类，一类是项目团队自已要做的功课，这部份在许多情况下是不会与客户沟通的，我称其为补课阶段，这也是一个全新领域项目开始的第一课。第二类是必须与客户共同完成的，这其中起关键作用的是项目最终使用者以及项目的决策者。
    这也是项目计划前的计划，孙子兵法有云“知已知彼，百战不殆”，这开始的第一课就是了解我们的客户与任务。
    “好了，师傅，我们先要做什么？”;候哥还是第一个耐不住性子的。
    我们第一个要确定的就是切入点，其实就是项目着手的方向；
    首先要了解我们的客户是谁？他们是服务于单位领导以及各业务处室，公文处理当然是这个系统的主要任务了。
    “我们已经知道这些就可以了呀，师傅”，戒子想还用师傅说呀，这些我们都知道。
    公文还是要分成外来文与内部文，这个单位的业务会有大量的数据报表，这些数据报表是各处室之间处理业务经常用到的形式，需要审批的内容肯定是从下属单位到办公室到各业务处理之间运行的，我们不是去过联合办公大厅嘛。
    好了，看来需要处理异地公文流转了，同时肯定有许多业务报表。
    还有一点，戒子不是网上明星嘛，上网查查，与我们这个客户相近的行业OA软件，了解一下其中的特点。
    [不论项目内容是该单位的核心业务还是像OA这样的辅助性系统，一定要了解客户的核心业务内容及流程，有许多项目团队只对项目本身所涉及的业务比较重视，其实这有许多潜在的风险]
    [切入点要做的几件事：
    了解客户
    了解业务
    了解行业
    了解同行产品
    计划的制定就可以从这些角度开始吧。
    [这些事在与客户正式开始沟通之前就应尽量了解，这样在与客户交流时会有效的减少在业务上的陌生感，会尽快使客户对项目团队产生必要的信任。]