查看完整版本: 关于变更流程的执行

关于变更流程的执行

变更管理,可以说是配置管理非常重要的核心工作.

不知道大家在具体执行过程中有没有发现什么问题,我们一起来讨论一下吧.

我先说几个问题:

1.虽然变更流程制定了也得到了大家的认可,但执行人会觉得麻烦.不主动执行.

2.如果项目时间很紧,变更多，变更流程的执行效果会不好,比如会将几次变更合为1次进行.

变更管理的目的就是为了更早的识别变更，使变更带来的影响降低，以上问题出现就达不到这个目的了。

欢迎大家讨论::em64::

麻烦是必须付出的管理成本。所以必须采用制度或文化的手段强制养成习惯。也可采取利益导向==比如绩效考核的办法但是形成企业文化最好。

你说的第二种情况是经常出现的问题，

变更控制

1、执行：个人觉得流程控制制度的执行是依赖于领导的支持和开发人员的配合，如果这些因素都不成为问题，是可以正常控制的。
2、矛盾：而制定这个制度的依据在各家公司或者同一公司的不同项目是有较大差距的，如果制定一套相对规范的通用规则，那么估计很多东西没有办法具体控制，而如果面对每一个项目都制定一套规则，又有失规范化管理的初衷。
3、建议：如版主所说，把变更批量化是一个方法，可以根据项目进度定期大规模更新，制定一套相对完善的变更控制流程，而零散的变更可以考虑启用另一套流程来控制

关于第一条同一dellxps的说法,采用制度的手段来规范化控制,慢慢的让大家形成主动地习惯.

那么如果真的一旦形成了比较好的习惯的话,相信第二条也会不是问题的了...

规范化的习惯养成了后,那么就要看变更的执行效率了,这个还可以拿出来讨论下,如何更好的提高变更执行的效率,如何更好的减少变更等...

回复 #1 qingqing 的帖子

执行人觉得麻烦，除了没有建立习惯外，还有可能就是在不同影响的变更或不同阶段的变更走同一个变更流程不是效率最高的途径或方法，简单说就是变更流程的可配置性不够好。

通常一个变更流程都会有5至6个环节，涉及3到4个角色之间协作配合，这样流程对于影响范围很小、没有技术风险、成本几乎为零、工作量小于1人时的变更来说，显得有点“杀鸡用牛刀”了。

当然要让一套变更流程的可配置性足够好是相当不容易的，就算是“杀鸡用牛刀”杀个一两次也问题不大。

这里我做个设想建议，假定以编码开始的时间点将项目周期分为前期和后期，由于前期变更相对频繁而且对成本、风险的影响较小，可以适当放宽影响分析评估的严格度，或省去一些耗时的环节，只要保证变更原因、变更范围、变更人、时间等关键信息被记录，关键还要保证变更后及时通知到相关人员就可以啦。
后期变更通常要严格限制，因为影响范围涉及广、关联复杂，带来的成本消耗也大、工作量大，对进度的风险就更大，所以对待每个变更都要谨慎，在变更管理上投入的管理消耗是必须也是有价值的。

建议大家可以根据自身组织和项目的特点，将项目周期分为若干不同变更管理策略的阶段，以提高效率，让大家不会嫌麻烦。

rocky_rup 谈到的是另一个方面：就是流程的可执行性和有效性。因该是一个真正适合自己企业的，能够执行的流程。而不是一个看起来很完美，但缺乏实际针对性的流程。

我觉得这是一个过程，你要通过领导的配合，配置管理培训。还有一步一步说服，教育。慢慢来。

讨论

任何完美的制度、流程，再强大的配置管理工具，要实行变更管理最重要的还是靠人，从领导层到执行层都应该能认识变更管理的重要性，这样才能达到目标

变更的确是让人头痛的事情，对于某些对过程不了解的项目经理而已，他也许是会按照上层要求，去走变更，但是变更的意义所在，有体会的PM并不多，不过是我们说啥他做啥而已。制度也拿他没则啊。我想我们的工作还没有做到位，没有在工作中给他们灌输足够的思想，这种拉木偶式的工作方式实在不可取。

偶现在就面临着实施的问题,几个经理不肯配合,郁闷,我们本来制定要每个CR一个branch, 然后CM定期build,发给test 组去测试,
这样有了问题就会好tracking,但是经理们嫌那样太麻烦,要每个工程师一个branch,可能要过很久才会merge,问题不能早期发现,
到了后期就会很麻烦.郁闷

难道PM都没有做过技术吗？
做过的就都知道CM的重要了啊！
不过，配置管理员的沟通技巧真的很重要！
好像可以开个帖子专门聊一聊哦

变更控制可以考虑使用缺陷管理，需求管理，计划管理等的流程工具。所有涉及缺陷及需求，计划变更的，均需在此流程中进行记录及跟踪，所有的配置项的修改也需根据此流程中裁决的结果进行。这样的话，变更就变得易于控制了。

关于变更以及变更的流程，其实都需要考虑一个问题：成本。其实对于软件开发来说，可以说从开始的需求文档的建立到最后的产品发布，往一个大的方面看，变更其实是很多很多的。不仅仅是需求的变更，设计的变更，就是一个小的UI问题都可能是一个变更。但是这些变更如果都去执行变更流程，我想是个PM他都会崩溃的。
所以这里要有一些合理的定义，什么变更走什么流程，跟成本挂钩。因为一个项目的成本应该是确定的，你不能说想要花多少成本就花多少成本，项目的延期，多招人进项目组，包括多余的沟通都是需要成本的。配置管理要跟踪的问题其实很简单，控制好源头的需求就很容易了，任何的变更都抓住需求来做跟踪，最后也容易发现问题

支持rocky_rup的说法，根据项目的不同阶段，采取不同的变更控制，在成本和风险之间寻求一个较为理想的结合点。比如项目前期，如果各模块之间的耦合度较小，变更频繁，我觉得就没有必要投入过多的人力和时间来评估、讨论，可以考虑精简一些审核环节。对于执行人员来说，也易于接受。变更管理领导重视、支持是一方面，但同时还得考虑执行人员。如果执行人员有较大的抵触情绪，变更的效果也会打折扣。
实际情况更复杂一些，不好一概而论。没有放之四海而皆准的定律，只能根据具体情况具体分析，在不同的阶段作出合适的选择。

项目紧的情况下，变更流程总是打折扣啊

第一个问题：  麻烦，不主动执行
关于这一点同意DELLXPS的观点: 流程的执行需要一系列相关配套的流程制度和管理控制的方法才能保证其执行效果（ 将流程的执行情况纳入月度的考核当中，这是一种控制的方法） ，然后才逐步养成习惯。

第二个问题： 时间紧，变更多，几个变更合为一次进行；
关于第二条： 首先可能两个方面存在问题：
1、时间紧张，变更很多，那么这么多变更是否有个轻重缓急呢，关键执行人是否清楚那个更急那个更重要，如果清楚，可以得到很好的处理；
2、将几个变更合为一次（ 我的理解： 是不是变更已经执行完成了，后续补走变更流程所牵涉到相关文档等），如果是这样那是不是流程本身就存在缺陷，或整个变更执行链条中的相关人员并不清楚变更流程的要求，否则假如其中一环没有按照流程走到话，是无法进行下一环节的，即使到下一环也会被退回；
另外ROCK-RUP 的意见也值得好好思考
将变更进行分类可使流程简洁、有效，从而可加强流程的可执行性；
流程尽量剔除重复、没有任何意义达不到任何目的步骤和环节；
第一次在这个论坛发表个人观点，请指教：）

变更流程的制定和执行必须得到管理层支持，如果只依赖QA或者SCM制定和推广流程的话，很难得到工程师的支持。

流程花费时间真的很多，如果领导层及开发人员不配合，制定了也是白费