需求的是是非非

前些日子有一个朋友向我要一份需求的标准文档，因为他现在正在负责一个项目。我对他说，我的需求文档只适合我用，并不适合你用。如果你是真的想在开发过程中引入科学的管理方法，静下心来，认真的学习需求的方法论，仔细的思考适合你们自身的方法。如果你只是需要一份好看的模版来哄哄Boss的话，那你就随便去找一份文档来修改一下就行了，保证糊弄得住人。最后我的朋友毅然的找了一份漂亮的文档走了。

    朋友走后我思考了很久，中国目前有很多的软件公司都很有实力，可是他们在管理方法上却很成问题。上半年在业界炒得沸沸扬扬的CMM是个什么东西呢？说穿了，就是一套适合软件行业的管理方法。这套管理方法并不是说你花了大堆的票子去过了CMM的评估或是购买了Rational公司的什么产品，而是在于你是不是真的理解了里面的管理精髓。前些日子看一篇报道联想实施ERP系统的文章，里面一句很不起眼的话给了我很大的感触。它说，联想在实施ERP之前，虽然也有大量的管理规范，但都是空谈的管理，公司主要还是靠“人治”。而我们现在很多的软件公司还是处于“人治”。“人治”的后果是很严重的，必将导致你的软件企业成本居高不下，管理上不传，下不达，企业无法快速发展。软件行业历来以利润高出名，利润是高，你想想软件的边际成本才多少（拷贝一份软件需要多少钱？）。可是中国的软件行业却做的不好。看看我们的台湾同胞们，虽然他们在软件平台的研究方面并不出色，但是在软件应用水平上是很了不起的。当然，台湾有他的历史原因：深受美国文化影响，属于美国制造外包的主要地区。

    上面说了一大堆的废话，我们还是回到我们的需求上面来。

    沟通是一切

    需求是一个过程，一个在软件生命周期中很重要的过程。在上一篇中，我们讨论了需求的层次、需求的风险、需求的特点。而在这么多需求要素之上的要素只有一个：沟通。沟通是什么，说小了是需求过程的重要技巧，说大了是软件企业的生命线。一个项目失败的原因有很多，而绝大多数都可以总结到沟通不畅。需求过程中充满了沟通：需求分析员和用户的沟通，不同的用户之间的沟通，需求分析员和需求审核人员的沟通，项目经理和需求分析员的沟通。沟通到一个什么程度，是需求成功与否的标志。

    曾经和几个老同学聊天的时候说起他们去用户哪里做需求调研，用户报来一堆资料，和他们聊了半天，他们就回去开始设计、编码。我说你后面肯定吃苦头了。果不其然，项目返工的时间差不多等于整个项目的时间。这太可怕了，意味着这个项目企业极可能亏本。为什么会这样呢？项目好比一座大楼，如果设计师连大楼要盖多少层都不清楚，那你说盖出来的会是个什么东西。

    《软件需求》一书中提到了一个很有意思的概念：软件客户需求义务和权利

    优秀的软件产品是建立在优秀的需求基础之上的。而高质量的需求来源于客户与开发人员之间有效的交流与合作。通常，开发人员与客户或客户代理人，如市场人员间的关系反而会成为一种对立关系。双方的管理者都只想自己的利益而搁置用户提供的需求从而产生摩擦，在这种情况下，不会给双方带来一点益处。

    只有当双方参与者都明白要成功自己需要什么，同时也应知道要成功合作方需要什么时，才能建立起一种合作关系。由于项目压力与日渐增，所有风险承担者有着一个共同的目标这一点容易被遗忘。其实大家都想开发出一个既能实现商业价值，又能满足用户需要，还能使开发者感到满足的优秀软件产品。

    软件客户需求权利书列出了十条关于客户在项目需求工程实施中与分析人员、开发人员交流时的合法要求。每一项权利都对应着软件开发人员、分析人员的义务。而软件客户需求义务书也列出了十条关于客户在需求过程中应承担的义务。如果愿意，可以将其作为开发人员的权利书。

    软件客户需求权利书

    1. 要求分析人员使用符合客户语言习惯的表达。

    2. 要求分析人员了解客户系统的业务及目标。

    3. 要求分析人员组织需求获取期间所介绍的信息，并编写软件需求规格说明。

    4. 要求开发人员对需求过程中所产生的工作结果进行解释说明。

    5. 要求开发人员在整个交流过程中保持和维护一种合作的职业态度。

    6. 要求开发人员对产品的实现及需求都要提供建议，拿出主意。

    7. 描述产品使其具有易用、好用的特性。

    8. 可以调整需求，允许重用已有的软件组件。

    9. 当需要对需求进行变更时，对成本、影响、得失（trade-off）有个真实可信的评估。

    10. 获得满足客户功能和质量要求的系统，并且这些要求是开发人员同意的。

 

原文转自：http://www.ltesting.net