范围管理（项目范围管理六个过程）

　　范围管理（项目范围管理六个过程）原创硬件十万个为什么2021-02-16 20:32:31这是之前今年5月份的一个新闻，软件公司老板被员工用显示器砸脸。看这受伤的程度，一定不是丢过去，只砸一下。一定是：
　　为什么工程师对修改需求的人如此深恶痛绝呢？随意变更需求、随意增加需求，也是对工程师早期劳动的极大的不尊重。造成公司资源的极大浪费。
　　因为需求的更改，是对工程师与之相关的前期工作的否定。
　　好的产品只会修改细节，不会乱改主体结构，不改需求是产品经理不称职，但动不动改主体就是对产品不负责。
　　工程师也很郁闷，当初需求没有描述清楚，做出来之后才说，不断的增加新需求，导致不断的修修补补。很多时候老板提出的需求也是一时兴起，第二天起床可能又觉得头一天说的那个需求不合理了。
　　工程师想表达的是：我本善良，往往是被逼得出手的。
　　那么如何才能这种暴力事件减少呢？
　　措施1、找一个超强的架构师，或者产品经理，设计出来的完美，考虑完美的需求。这个措施，我随便说说，你不要当真。
　　措施2、建立一个好的机制，对需求进行评估，避免返工，避免频繁的需求更改，避免随意的需求更改。
　　这个体制的建设，其实就是一种项目的＂范围管理＂。
　　那么我们看看华为是怎样在这个领域进行范围管理的。
　　范围管理的定义
　　范围管理是指收集和定义项目的需求，标识项目的交付和验收标准；通过变更控制和验收活动，确保交付满足项目要求。
　　简单地说就是：范围是需求的集合。
　　范围管理与需求管理的区别：
　　范围管理包含：分析范围，定义和明确范围、控制范围、控制范围变更、验收范围。
　　范围管理包含一系列的过程，用以确保项目包含且只包含达到项目成功所必须完成的工作，范围管理主要关注项目内容的定义和控制，即包括什么，不包括什么。
　　而需求管理是确保各方对需求的一致理解，管理和控制需求的变更，以及需求的跟踪。
　　所以需求开发和管理的目的是通过调查与分析，获取用户需求并定义产品需求，还要确保各方对需求的一致理解，管理和控制需求变更，需求的双向跟踪
　　而范围管理的目的是确保项目包含且仅仅只包含项目所必须完成的工作。
　　需求管理是对已批准的项目需求进行全生命周期的管理，过程包括需求管理定义、需求管理流程、制订需求管理计划、管理需求和实施建议等，其主要的工作就是需求的变更管理
　　范围管理过程包括范围计划编制、范围定义、创建工作分解结构、范围确认和范围控制。
　　他们之间的联系：
　　首先通过需求开发来获取项目的需求，再此基础上确定项目的范围、进行项目范围管理
　　其次需求的变更会引起项目范围的变更
　　需求的收集与接受
　　首先，在需求收集和接受过程中，需要仔细思考，深入讨论。在华为这样的企业可能从上层会有一些战略部署，和规划。一些初创公司可能需要全民皆兵的去思考需求，思考项目的范围。
　　先说，华为的情况：
　　1、需求获取：
　　2、需求分解：项目的目标和成果，在早期会被分解成为可管理、可交付的组成部分。同时明确项目成功交付的标准，例如：需要满足什么功能，什么性能、什么准确度。除了从客户层面去考虑问题之外，还需要考虑自身条件:成本、性能、技术限制、配套、节能减排、可靠性、准入限制、可安装性、可维护性、易用性、可制造性、可测试性、归一化、可行销性、安全性、全球化、可采购性等等维度需要考量。
　　3、需求分析：
　　对所有需求进行分析，并把啊分析结果文档化，可以是《包需求列表》。所有需求都应该用恰当的语言进行描述。对每个需求的验证方法也需要定义清楚，并且与客户讨论确定下来，这是客户验收标准的输入之一，是成功移交项目成果和客户客户满意的必要条件。
　　需求分析需要采用 5W2H方法（What，Why，Who，Where，When，How，How much）
　　4、需求优先级排序
　　考虑几个因素：投资回报率、需求来源及客户优先级、对客户满意度的影响、对竞争力的影响、实现难度、成本等。
　　当然，自然有人是把Boss或者领导的指令当做优先级第一的需求，这就是任老板说的：＂脸朝着领导，屁股就会朝着客户；脸朝着客户，屁股就有可能对着领导＂
　　对于初创公司，在范围分析环节，建议：
　　a、关键需求文档化，便于跟踪，设计不能太随意；可能不可能像华为那么完备的范围分析，但是关键需求需要文档化。
　　b、搞清楚，自己的目标客户到底是谁，不要搞大而全的产品，需求不要贪多、贪全，要一招制敌；专注、极致、快！
　　c、小步快跑，阶段功能测试，阶段需求确认，快速迭代，避免需求理解错误，导致大量返工。别指望憋大招。
　　d、需求务必讨论清楚，再动手，不要浑浑噩噩开发。
　　落实需求
　　估计有些工程师，在施工的时候，会发现：一开始讨论需求时，热火朝天。但是，做出来的东西，跟一开始的设想完全两样。
　　这里里面缺少的环节就是，如何去分解需求，落实需求。
　　WBS是一个把交付成果层次分解的工具。
　　WBS：工作分解结构（Work Breakdown Structure） 创建WBS：创建WBS是把项目可交付成果和项目工作分解成较小的，更易于管理的组成部分的过程。
　　WBS是项目管理重要的专业术语之一。WBS的基本定义 ：以可交付成果为导向对项目要素进行的分组，它归纳和定义了项目的整个工作范围每下降一层代表对项目工作的更详细定义。无论在项目管理实践中，还是在PMP，IPMP考试中，工作分解结构（WBS）都是最重要的内容之一。WBS总是处于计划过程的中心，也是制定进度计划、资源需求、成本预算、风险管理计划和采购计划等的重要基础。WBS同时也是控制项目变更的重要基础。项目范围是由WBS定义的，所以WBS也是一个项目的综合工具。
　　WBS可以是树形图，也可以是表格，也可以是甘特图
　　范围蔓延
　　指项目在进行期间需求缓慢增加，超出原先的范围框架，造成质量，成本，进度等的失控。例如，未对时间和成本影响进行评估，增加额外的功能和服务。
　　项目要严格控制范围变更，评估范围变更对进度、成本、质量的影响，防止项目失控。
　　在目前，快速迭代的时代，如何能够控制项目的蔓延，就是一个非常重要的课题。
　　其实仔细分析过上图中小米的开发节奏，需要做到一周一版本的水平，其实是有一定难度的。这里面需要对需求准确的把握，需要对任务的分配做准确的把握，同时，在做的过程中应该是严格杜绝范围蔓延。一周的项目计划就是一周的项目计划。当然，这个过程中，需要工程师持续的高强度的努力和责任心。
　　范围其实跟计划一样，都是在项目的进展过程中，渐进明细的，随着项目进展，项目信息越来越精确。由于认知能力的局限，项目范围在开始的时候有可能不清晰，需要不断的细化和完善。在很多项目中，客户或者项目干系人在项目初期往往只能提出大概要什么，但无法很具体、怎么做，那些需求的优先级和工作量也都无法评估。
　　不管是开发者，还是管理者，都应该有清醒的头脑。提醒自己，不要范围蔓延。
　　特别是初创团队，可以做的事情很多，可以讨论和发展的方向也很多，是不是能像余承东、任正非说的那样呢？
　　＂脚踏实地，做挑战自我的长跑者＂
　　＂我们一再强调终端要有战略耐性，要耐得住寂寞。＂
　　＂如果你们匆匆忙忙发展，可能因为一个零件问题，这批手机几十万部、几百万部出问题，就会毁了整个终端公司，有时很难再爬起来。所以我们还是要踏踏实实，控制欲望、控制合理发展速度，＂鸡血＂沸腾一定是犯错误的前兆。＂
　　应对老板需求蔓延的办法：
　　1、对于你自己产品的需求一定要很清楚，要做到比老板更专业，要有权威性，这样在进行需求讨论的时候他才会听取你的意见，需求才会让你主导。如果需求是你主导的，那么很多问题就很好解决了。
　　2、在老板提出需求之后，要认真的分析这个需求的可行性，如果明显是跟产品的大方向相反或者其他显而易见的不合理，那么就直接的回绝老板，但是回绝老板要讲究技巧，不要直接说什么＂你想的不对＂，要有理有据有分析。
　　3、对于某些需求你觉得合理，但是做起来很费劲的，你可以跟老板沟通实现这个需求的成本。毕竟老板的目的就是为了要赚钱呢，你要把时间、成本和质量三方面跟老板讲清楚，如果老板觉得时间长，成本高都无所谓，那么对工程师来说也需就没那么的反感了，因为时间没有要求那么的紧张，程序员压力也不至于那么的大。
　　所以你需要跟老板说故事：
　　瓦萨王朝统治时期，瑞典是欧洲的强国之一。为了与劲敌丹麦、波兰对抗，称霸波罗的海，瑞典国王古斯塔夫·阿道夫斯二世要求建造一批新的战舰，并要求战舰航速要快、火力要强、装饰要华丽，因为这样才足以显示瓦萨王朝的权力、财富和战斗力。1626年初，作为其中最大的战舰＂瓦萨＂号在国王的亲自监督下正式开始建造。
　　国王总是有太多要求。在＂瓦萨＂号建造期间，他不断下令依照他的旨意改变设计和建造要求。在＂瓦萨＂号的骨架已经安装好的时候，他下令增加战舰的长度。1627年,国王得知了丹麦建成双层炮舰的消息，于是他又决定，为原计划修建单层炮舰的＂瓦萨＂号增加一个枪械甲板，把它改建成＂双层＂炮舰。这样一来，＂瓦萨＂号便拥有了双排共64门舰炮，全长达到了69米，成了当时装备最齐全、武装程度最高的战船。
　　1628年8月10日，离岸还没来得及扬帆远航的＂瓦萨＂号在一阵大风浪过后，开始倾斜，接着又慢慢恢复平衡，但随即再一次朝右舷倾斜。岸上的人们都惊得目瞪口呆。＂瓦萨＂号的下层甲板在慢慢进水，舰体开始晃动下沉。＂瓦萨＂号就在众目睽睽之下沉没了。
　　范围控制
　　控制范围，不是不让改需求，不是用显示器砸老板，而是保证范围的正确变更。对于可能的、合理的范围变更，应积极主动的分析是否存在价值，尽可能的创造条件让高价值的需求变更落地。
　　在范围变更分析的时候，需要重点考虑对项目价值、项目策略、项目质量、项目周期、产品目标成本等的影响。变更之时，还需要考虑：项目中需求的冗余、错误之处，新技术引入带来的风险，导致的连锁需求变更。
　　CCB(Change Control Board) 在CMMI(Capability Maturity Model Integration)中，是＂变更控制委员会＂的含义，同时具有配置控制委员会（Configuration Control Board）的含义。
　　CCB可以由一个小组担任，也可以由多个不同的组担任，负责做出决定究竟将哪些已建议需求变更或新产品特性付诸应用。典型的变更控制委员会会同样决定在哪一些版本中纠正哪些错误。
　　当组建包含软硬件两方面项目的CCB时，还应当包含来自硬件工程、系统工程、制造部门或者硬件质量保证和配置管理的代表。
　　CCB是系统集成项目的所有者权益代表，负载裁定接受那些变更。CCB由项目所涉及的多方成员共同组成，通常包括用户和实施方的决策人员。CCB是决策机构，不是作业机构，通常CCB的工作是通过评审手段来决定项目是否能变更，但不提出变更方案。
　　正式基线（需求基线、概要设计基线、详细设计基线、代码基线、测试基线、运行基线）的改变必须由项目组的CCB审查和批准。正式的基线，如客户需求和运行基线。正式基线的控制权威是CCB，CCB的主席通常由组织中的高层经理来担任。工程过程期间建立的开发基线，如设计和代码基线、测试基线由项目经理和/或项目技术负责人非正式地控制。
　　对于初创团队，需求变更也应该是：有制度、有记录、有讨论、有跟踪；而不是随意变更。否则船还没出海就沉了。
　　范围验收
　　在项目的结束，或者中间节点，可以检查项目已经完成部分的交付成果的过程。可以按照需求跟踪表，或者需求跟踪矩阵一一核对。
　　方法：可以是评审、内部测试、客户测试、试验验证、准入测试、认证测试等活动的集合。
　　总是是要看看我们做出来的东西是不是客户要的。
　　最后，祝愿大家找到好老板。
　　提醒一句，工程师如果会空手道、跆拳道、截拳道、中国功夫，已经成为就业的劣势条件了，找工作时，注意隐藏这些经历或技能。