分享

计划赶不上变化,怎么办

 blackhappy 2021-12-22

在产品开发的过程中我们随时都要应对变化,客户需求变更了,关键技术问题迟迟解决不了,团队关键成员变动,项目费用不够了,这些变化都会导致计划的变更,所以做完计划并不代表着万事大吉,我们得保警惕,对可能造成变化的因素保持“敏感”,一旦识别到对项目冲击的风险在增大,我们就要采取必备的一些手段进行防范。如何通过范围管理,基线管理,有效地管理变更,减少对项目的冲击。

对于产品开发来说,投入的是时间,成本,获得的是产品的功能、性能、质量,产品的功能、性能与产品的范围有关,影响时间、成本的因素还有项目的范围、团队的能力,所需技术的难度等。对于一个人员比较稳定的团队来说,团队能力是经过评估和验证的,能实现的技术基本也是可以评估的,因此影响项目的时间、成本最重要的因素就是项目以及产品的范围了。范围小,所需时间以及耗费的成本也小,反之亦然。因此,为了更好地管理项目,在项目开始前,都会确定范围,并根据范围制定相应的项目计划,质量策划,安排团队成员,计算项目成本。

项目范围和产品范围有什么区别与联系呢?产品范围是指产品所包含的特性和功能。项目范围是对项目应该包括什么和不应该包括什么进行相应的定义和控制。对于产品开发项目来说,项目范围的管理不仅要对产品所具有的特性和功能进行定义和管理,同时还要对产品开发项目的范围进行管理,包括交付要求(时间、验收标准、过程交付件、文档管理方法),项目管理要求(流程、管理方法)等;所以项目范围要大于产品范围。

基线是什么?

基线是软硬件文档或源码(或其它产出物)的一个稳定版本,它是进一步开发的基础。所以,当基线形成后,项目负责SCM的人需要通知相关人员基线已经形成,并且哪儿可以找到这基线了的版本。这个过程可被认为是内部的发布。至于对外的正式发布,更是应当从基线的版本中发布。
基线是项目储存库中每个工件版本在特定时期的一个“快照”。它提供一个正式标准,随后的工作就基于此标准,并且只有经过授权后才能变更这个标准。建立一个初始基线后,以后每次对其进行的变更都将记录为一个差值,直到建成下一个基线。
参与项目的开发人员将基线所代表的各版本的目录和文件填入他们的工作区。随着工作的进展,基线将合并自从上次建立基线以来开发人员已经交付的工作。变更一旦并入基线,开发人员就采用新的基线,以与项目中的变更保持同步。调整基线将把集成工作区中的文件并入开发工作区。

需求+计划+成本,应该在项目进入总体设计阶段之后,有一个基线。

文章图片1

范用管理是指收集和定义项目的需求,标识项目的交付和验收标准;通过变更控制和验收活动,确保交付满足项目要求。

项目范围是指为了交付产品必须完成的工作,包括业务需求(比如产品的产品属性和功能、如何实现节能减排等),交付要求(比如交付时间、验收标准、交付件等),项目管理要求(如管理方法、流程等)。

范围管理通过分析范围、定义范围,确保项目做正确的事情;通过控制需求变更,确保项目范围满足交付的要求;最终通过验收范围确认交付成功和客户满意。

产品范围和项目范围的区别:

产品范围,即产品或服务所包含的特征或功能;项目范围,即为交付具有规定特征和功能的产品或服务所必须完成的工作。例如,公司开发一个新架构的网管系统。产品范围就是给客户提供一套最先进的网管系统。为了完成项目交付,还需要为员工提供培训和必要的管理活动,这也是项目范围的一部分,但这些活动不包含在产品范围内。

项目范围的变化或者蔓延是导致计划变更及延期的主要因素,根据经验来看,最容易造成项目范围变化以及项目延期的,又是产品范围的变化和蔓延。因此,对产品范围的有效管理是避免计划延期的重要措施。从产品本身来看,产品范围由产品需求确定,从产品开发的过程来看,产品开发项目的过程交付物跟产品范围密切相关,而且每个阶段是环环相扣的关系,一个阶段的变化会影响下游所有环节,因此我们都要确定每个阶段的交付物,并且对交付物的状态进行管理。在项目的生命周期中,各个阶段所产生的各种形式和各种版本的文档、程序、数据都属于交付物。基线则是交付物在项目生命周期的不同时间点上通过正式评审并进入受控状态后,就形成了这些交付物的基线。可以理解为基线是一种状态,当交付物达到基线的状态时,说明它已经具备一定的稳定性和一致性了,也可以看作是对这个阶段的工作的承诺,标志着可以开始下一阶段的工作。因此基线的建立是严肃的,交付物的质量要能达到基线的状态,而基线一旦建立,不可随意更改,其变化需要接受严格的变更控制,以此保证项目计划的严肃性,减少项目风险。

文章图片2

从开发的流程可以看出来硬件产品开发项目在以上的每一个阶段都会有相应的基线:

需求基线在需求分析完成并通过评审后建立,此时的产品需求原则上是全面、清晰、准确的,并且已经稳定化的。常见的需求文档包括《产品包需求清单》、《需求分析规格书》等等,具体的文档根据各个公司的规定会有差异,但通用性的原则,不变。

计划也会有基线,当计划基线确定后,意味着计划有了严肃性,代表了项目组对计划的承诺,不能随意修改。当然,前提是计划的制定是严谨的、科学的、合理地评估了各项工作需要的时间,以及存在依赖关系的模块之间的衔接。

同样,总体设计、详细设计的基线需要在相关设计完成并经过评审后建立,这两个阶段文档包括《硬件设计规格说明书》、《关键物料清单》、《硬件成本测算表》《硬件详细设计方案书》,原理图,PCB布局布线等等,如果产品的复杂度高,规模大,还可能会有关键器件的分析文档,接口分析文档等专题分析文档;如果产品的复杂度低,总体设计和详细设计也可以阶段合并;这些都需要经过评估产品开发难易度以及必要性后确定。

文章图片3

上面这个图可能大家会觉得眼熟,是的,这就是华为公司的产品开发流程(IPD)框架,也是近些年来科技制造类企业争相学习的对象。IPD最重要的一个特点就是开发过程结构化,阶段化,每一个阶段都有严格的准入准出条件,保证每一个阶段的产出质量,避免问题一环流向一环。Charter review、CDCP、PDCP、ADCP、GA、EOX这些阶段均是重要的决策评审点,只有通过评审,产品开发才会进入下一阶段并获得相应的资源。通过评审,也意味着上一阶段的产出基线化了。

在产品开发过程中,还有技术评审流程对技术成熟度进行把关,用于检查产品开发流程实施到一定阶段以后产品的技术成熟度,发现遗留的技术问题,评估存在的技术风险,给出技术上的操作建议。下面这张图表明了技术评审点和决策评审点的关系。可以看到,从立项通过后到产品发布前,每一个大的阶段里都有技术评审点,而且技术评审先于决策评审。这样设置的目的是为了确保每一个阶段的技术已经达到了一定的成熟度,往下推进的风险可控,才继续投入;否则,随着风险的堆积,整个产品开发可能会返工,导致前期的投入全部打水漂。

文章图片4

TR1重点关注产品包需求的完备性以及选择的产品概念是否满足产品包需求。同时,TR1还对产品设计需求的关键点进行评估:比如产品的标准策略、部件重用计划等。

TR2重点关注产品设计需求到产品设计规格的完备性,确保设计规格包括并适应每单元和构建模块(譬如单板、软件模块)的设计。

TR3是对概要设计的评审,确保设计规格已经完、全、正确地在概要设计中得到体现,确保概要设计足以指导产品项目计划制订、产品业务计划制订、以及后续的详细设计活动。

TR4保证BuildingBlock用于系统级构建之前是完整的。对于一次构建(Build)涉及到的每一个BuildingBlock,应该有且仅有一次TR4对其进行评审。

TR4A在SDV完成后,对产品技术上的成熟度进行评估,确保所有存在的问题和风险都进行了评估,并生成了相应的改进计划,以保证供应和制造能力足以支撑初始产品生产活动。

TR5是在发布给客户前对项目整体状态在设计稳定性和技术成熟度方面的独立评估活动。TR5目的是确保产品符合预定的功能和性能要求,以满足前期确定的产品包需求。

TR6是一个关注于系统级的评审,确保产品的制造能力已经能适应全球范围内发货的需求。

每一个TR评审通过后,都会形成这个阶段的基线,并进行受控管理。

实际上技术评审流程执行起来还需要很多的配套支持,比如每个TR点的评审要素,评审流程,评审责任人,以及TR的裁剪规则等,因此希望大家在学习华为IPD的时候,多思考IPD的本质逻辑,以及做好IPD需要哪些支撑要素。细节很重要。

前一段时间在给某个企业培训的时候,讲到著名的范围蔓延的案例,不堪重负的“瓦萨”号:

瓦萨王朝统治时期,瑞典是欧洲的强国之一。为了与劲敌丹麦、波兰对抗,称霸波罗的海,瑞典国王古斯塔夫·阿道夫斯二世要求建造一批新的战舰,并要求战舰航速要快、火力要强、装饰要华丽,因为这样才足以显示瓦萨王朝的权力、财富和战斗力。1626年初,作为其中最大的战舰“瓦萨”号在国王的亲自监督下正式开始建造。国王总是有太多要求。在“瓦萨”号建造期间,他不断下令依照他的旨意改变设计和建造要求。在“瓦萨”号的骨架已经安装好的时候,他下令增加战舰的长度。1627年,国王得知了丹麦建成双层炮舰的消息,于是他又决定,为原计划修建单层炮舰的“瓦萨”号增加一个枪械甲板,把它改建成“双层”炮舰。这样一来,“瓦萨”号便拥有了双排共64门舰炮,全长达到了69米,成了当时装备最齐全、武装程度最高的战船。

1628年8月10日,离岸还没来得及扬帆远航的“瓦萨”号在一阵大风浪过后,开始倾斜,接着又慢慢恢复平衡,但随即再一次朝右舷倾斜。岸上的人们都惊得目瞪口呆。“瓦萨”号的下层甲板在慢慢进水,舰体开始晃动下沉。“瓦萨”号就在众目睽睽之下沉没了。

此时参加培训的同学说:“老师,你这个例子很好,关键点就在于提出需求变更的是国王,我不能忤逆他。”

这里需要

1、基线,即:在任何人提出需求变更的时候,都需要相应的归档版本。需求跟踪表和计划进度表拿出来。任何的需求变更,需要在需求跟踪表上核对,评审及修改。任何需求变更导致的计划变更,需要在计划进度图表中表示出来。

2、有评审制度,任何的变更需要进行评审。国王当然更能理解需求变更带来的商业价值,但是变更带来的风险和影响,需要我们评估准确,以供评审。

3、如果公司层面组织一个变更控制的委员会,每个项目组都有相应的组织去控制便更难,则最好。如果没有,当发生变更之后,应该成立临时组织,进行评审,通知相关利益相关人。

4、变更之后,要修订需求和计划响应的文档,并归档。

5、所有的需求变更都需要跟踪到位。

6、不可随意变更。

文章图片5

文章来自,硬件十万个为什么

    本站是提供个人知识管理的网络存储空间,所有内容均由用户发布,不代表本站观点。请注意甄别内容中的联系方式、诱导购买等信息,谨防诈骗。如发现有害或侵权内容,请点击一键举报。
    转藏 分享 献花(0

    0条评论

    发表

    请遵守用户 评论公约

    类似文章 更多