[转贴]深入理解项目管理之需求

扬帆

随着对项目管理理解的深入，自己对项目管理的两点有了深刻理解：需求开发与管理、项目组织结构。
　　 一、需求开发与管理
　　宽泛地讲，需求来源于用户的一些“需要”，这些“需要”被分析、确认后形成完整的文档，该文档详细地说明了产品“必须或应当”做什么。所以如果只有一些零碎的对话、资料或邮件，你就以为自己已经掌握了需求，那是自欺欺人。需求是产品的根源，需求工作的优劣对产品影响最大。就像一条河流，如果源头被污染了，那么整条河流也就被污染了。 我们经常看到的是：人们并不清楚究竟该做什么，但却一直忙碌不停地开发。
　　需求开发与管理面临最普遍的问题是：用户说不清楚需求。
　　有些用户真的不知道需求是什么，或者对需求只有朦胧的感觉，他当然说不清楚需求。例如，早期的政府信息化项目用户通常只有一个朦胧的信息化感觉而已，需求分析中会这样写："总之，要实现那种能够想到就能做到功能。"。如果开发方的营销人员水平比较高，他能够在用户不清楚自己要什么的情况下引导用户“消费”。
　　有些用户虽然心里明白想要什么，但却说不清楚需求。 比如说买鞋子。我们非常了解自已的脚，但很难用语言说清楚脚的大小和形状。通常拿鞋子去试，试穿时感觉到舒服才会买鞋。一些企业的信息化项目，每个子部门对自身的需要很清楚，但不知道如何从系统角度来要求。
　　因此，我们可以说项目开发最困难的部分也就是准确说明开发什么。最困难的概念性工作是编写出详细的需求，包括所有面向用户、面向机器和其它软件系统的接口。此工作一旦做错，将会给系统带来极大的损害，并且以后对它修改也极为困难。为此，需求分析员绝不能以用户说不清楚需求为借口而草率地对待需求开发工作，否则会连累整个开发团队的。
　　业内来看，一个成熟、成功的项目，通常它在前期需求、系统设计投入的工作量比例会大于30%。
　　1、需求开发 与分析
　　需求开发的目的是通过调查与分析，获取用户需求并定义产品需求。根据需求调查和需求分析的结果，进一步定义准确无误的产品需求，产生《产品需求规格说明书》。系统设计人员将依据《产品需求规格说明书》开展系统设计工作。 一个良好的需求说明书，应该有如下特征：
　　1.1 正确
        需求规格说明书应当正确地反映用户的真实意图，开发者和用户自己都不明白用户究竟“想要什么”和“不要什么”。为确保需求是正确的，开发方和用户必须对《需求规格说明书》进行确认。
　　1.2 清楚
        清楚的需求让人易读易懂，包括文档的结构、段落等是否清晰。
　　1.3 无二义性  
        “无二义性” 是指每个需求只有唯一的含义。
　　1.4 一致  
        “一致”（Consistent）是指各个需求之间不会发生矛盾。矛盾常常潜伏在需求文档的上下文中。
　　1.5 必要  
        开发者应当集中精力先完成必要的需求，如果条件允许则再做“锦上添花”的需求。为了避免主次颠倒，应当在《产品需求规格说明书》中将那些“锦上添花”的需求设置为较低的优先级。
　　1.6 完备
        “完备”（Complete）是指《产品需求规格说明书》中没有遗漏一些必要的需求，比如是否覆盖了所有的功能、性能、交叉、安全等需求。
　　　1.7 可实现
        《产品需求规格说明书》中的各项需求对开发方而言应当都是可实现的（Attainable）。
        “可实现”意味着在技术上是可行的，并且满足时间、费用、质量等约束。
　　1.8 可验证
        《产品需求规格说明书》中的各项需求对用户方而言应当都是可验证的（Verifiable）。如果需求是不可验证的，那么用户就无法验收软件，可能会发生商业纠纷。
　　1.9 确定优先级
        需求的优先级其实就是需求“轻重缓急”的分级表述，例如划分为“高、中、低”三级。一般地，由用户和开发方共同确定需求的优先级。
　　1.10 阐述“做什么”而不是“怎么做”
        开发人员常常身兼数职，可能把需求开发、系统设计、编程等工作从头做到尾。他们经常在整理需求的时候习惯性将如何实现的信息涵盖在需求中，导致需求可读性、可验证性无法保证。
　　2、需求管理过程域
　　需求管理的目的是在客户与开发方之间建立对需求的共同理解，维护需求与其它工作成果的一致性，并控制需求的变更。
　　需求确认是指开发方和客户共同对需求文档进行评审，双方对需求达成共识后作出书面承诺，使需求文档具有商业合同效果。
　　需求跟踪是指通过比较需求文档与后续工作成果之间的对应关系，建立与维护“需求跟踪矩阵”，确保产品依据需求文档进行开发。
　　需求变更控制是指依据“变更申请－审批－更改－重新确认”的流程处理需求的变更，防止需求变更失去控制而导致项目发生混乱。
　　2.1需求跟踪
　　需求跟踪的目的是建立与维护“需求－设计－编程－测试”之间的一致性，确保所有的工作成果符合用户需求。 需求跟踪有两种方式：
　　正向跟踪。检查《产品需求规格说明书》中的每个需求是否都能在后继工作成果中找到对应点。
        逆向跟踪。检查设计文档、代码、测试用例等工作成果是否都能在《产品需求规格说明书》中找到出处。
        正向跟踪和逆向跟踪合称为“双向跟踪”。不论采用何种跟踪方式，都要建立与维护需求跟踪矩阵（即表格）。需求跟踪矩阵保存了需求与后继工作成果的对应关系。
　　我们就曾经出现大家埋头于开发，最后才发现项目协议书中的一个小基本功能没有开发的事故。
　　2.2 变更管理
　　需求变更通常会对项目的进度、人力资源、经费产生很大的影响。
　　如果在项目开发的初始阶段，开发人员和用户没有搞清楚需求或者搞错了需求，到了项目开发后期才将需求纠正过来，会导致产品的部分内容需要重新开发。这是要坚决避免的。
　　如果由于市场变化而导致产品需求发生变更，开发商大可不必为此烦恼，应当高兴才对。倘若市场静如死水，那么开发商吃了“上一顿”就没有“下一顿”。正因为市场在变化，才会产生更多商机，聪明的开发商才会有活干，有钱赚。  
　　其实需求变更并不可怕，可怕的是需求变更失去控制，导致项目混乱。所以需求变更控制是需求工程的重要活动。如果需求变更带来的好处大于坏处，那么允许变更，但必须按照已定义的变更规程执行，以免变更失去控制。 如果需求变更带来的坏处大于好处，那么拒绝变更。
　　需求变更控制过程中最难办的事情是莫过于“拒绝客户提出的需求变更请求”。通常情况下开发方是不敢得罪客户的，但是无原则地退让将使开发小组陷入困境。解决这个问题的一个办法是事先建立规则：如开发方与客户方达成“事不过三”的约定，即允许客户变更三次需求；如果客户第四此变更需求，开发方有权提请客户补偿开发投入。
　　3、深入理解需求
　　需求的开发和管理有一些规律或经验可以参考，核心是沟通确认、沟通控制。
　　3.1认清谁才是"上帝"
　　我们说客户是上帝，是因为客户的重要性，客户占有决定性的地位。对于广大不能清楚描述需求的客户，项目开发人员负有教育客户的义务，需要引导客户，让他们说出自己的心声。客户往往都是领域专家，对自己的工作有很深的认识，可是由于对软硬件开发的不了解，往往表达不清，甚至表达不出自己的需求。这时候，就是体现你的功力的时候了，象对待上帝一样对待你的客户。
　　3.2 耐心是首要的，学理工科的人，一般在逻辑思维上会比较好，可是对于客户来说，可不一定是这样。一些客户在了解需求的时候，扯东扯西，含糊不清，只有耐心才能获得真正的需求。耐心最后会仍会体现为沟通，只有耐心的沟通，你才能揭开需求的重重面纱。人的行为总是会受到思想的指导，如果你解不开客户的心结，你就不可能了解他真正需要的。
　　3.3 参与是重要的
　　方法的一个重要实践，就是提倡"现场客户"（on-site customer）。也就是说，客户应该随时和开发人员在一起，随时提供资料和做出决策。而这个客户，也必须领域专家，而且能够有权做出决策。非常的贴近客户，甚至可以在做游戏的过程中完成卡片的填写，能带来很强的客户参与度。
　　4 拥抱变化
　　需求变化是开发人员最讨厌的一件事了。可是，就像我们常说"哭不能解决问题"一样，讨厌能解决问题吗？拒绝客户的变更要求，要求客户在需求规格说明书上签字。这些做法只能是适得其反。没有任何正面的、积极的意义。需求变更要求我们的开发工作要迭代式进行，包括需求、设计、实现等阶段。这样才能将变更风险减到最小。
　　5 测试
　　这里的测试指的是考核软件项目是否成功的一个"执行性目标"。例如，开发物流系统的目的是为了缩短产品周转周期，降低库存；开发供应链系统是为了加强和供应商的联系，降低库存。这些和具体业务有关的指标都是可以通过细化，用多种分指标来度量的，所以是可以做到的。
　　我们把这种目标称为测试就是要提醒开发人员，要把满足这种目标当作最终的测试。
　　有了明确的需求，我们一定竭力做如下几件事情：
　　什么(WHAT)：按顺序列出达到目标所需完成的工作；
　　何时(WHEN)：完成工作所需要的时间；
　　做到的程度(HOW-WELL)：要完成的工作以何标准来度量；
　　资源(RESOURCES)：完成工作需要的人员/资金等；
　　谁(WHO)：由谁负责完成任务。

熟透番薯

我们经常看到的是：人们并不清楚究竟该做什么，但却一直忙碌不停地开发。...
扬帆 发表于 2010-7-8 09:46

                               
登录/注册后可看大图

呵呵。
一个项目，必须清楚范围(scope)，定义边界，否则，就是这种情况。

熟透番薯

有些用户虽然心里明白想要什么，但却说不清楚需求。 ...
扬帆 发表于 2010-7-8 09:46

                               
登录/注册后可看大图

不少HIS公司缺少业务领域专家。医院不缺少医学专家，但他们不能代替/充当这个角色。至少医疗行业的医生护士充当不了这个角色。

mouse

业务描述——》业务语言——》自然语言——》逻辑语言——》机器语言

每个环节的翻译解析都会产生偏差，大家都呼吁专家，专家能专哪一块呢?
通常情况下，要求项目经理（或者系统分析员）能够承担这个全能的角色，这未尝不是一个好的思路，但是看看现在项目经理的资质及水准线，就会知道这是超出实际的奢望了

yangzheng

这样要求项目经理是否要求过高了些.

ironstone

实际上现在项目管理也逐步认识到这个问题，现在的范围管理的概念与以前已经有所区别。以前讲范围管理就是在项目开始时就要明确这个明确那个，这个做那个不做；现在这个范围管理不是说在项目初期就要限定项目边界，明确项目要求和细节，因为认识到无论是在多么高水平的专家也不可能把控项目过程中的所有影响因素，所以项目范围是一个逐步细化和明晰的过程，既然是个过程就会融合在项目的进展中，因此最主要的是在项目过程中要及时决策哪些是项目范围内的，哪些是项目范围外的并制定相关策略。也就是项目管理中所谓“拥抱变化”

扬帆

石头是真正理解了范围的概念。合同只能定义软件大范围，功能可以确定软件小范围。功能是根据需求变化的，也可以说需求决定了范围的大小，但需求受合同、技术、成本、时间、风险、人文环境等很多因素的影响，当需求影响到范围改变时，一定要引起高度关注，并设置相关的约束机制，控制住范围才能控制需求无限蔓延，在“拥抱变化”过程中才能不迷失自我！