“过程改进之我谈”

williams

自毕业4年以来，我一直在公司承担内审员及QA的工作，伴随工作的不断深入，公司管理文档和软件工程的模式的不断改进，比对市场及行业的需求，我渐渐感受到产品的过程改进不仅必须的，且也是急迫的。

产品的开发过程包括管理客户的需求、设计过程、代码开发、集成和测试。在组织中，应该包括对这些过程识别和管理，比如“是否监控过程质量”、“是否标识了满足客户需求的关键过程”等。如果从组织发展的长远角度考虑，这些活动是必须的，那么针对这些活动将会提供许多过程改进的机会，这些将会协调好成本、计划和质量之间的关系。能够帮助改进组织过程和提高每个过程的性能。在组织中亦是如此，在项目中过程改进应该是什么呢？在项目中，过程改进实实在在的展现就是 提供可预测性、控制、有效性。但是做过程改进的初期，组织内部的实施人员会遇到一些非技术性问题，那就是具体实施人员会很不理解，他们会说，“这个办法行不通”、“过程要建档，麻烦”、“会影响我的创造性”、“这不是我们非干不可的”等等。如果我们不认真对待过程改进的活动，那么对于项目而言可能就是响应性的方式、没有估测和计划、会出现很多的风险，最后导致项目的时间拖延、成本增高、返修率高等问题。

案例1

计划（PP）：

Lead 果是我们公司一名项目经理，他项目的经验丰富，并且这是他的曾经做过A项目的延续——B项目。公司和他约定，10月交付项目，他保证无论如何会在10月内完成项目的。在项目内部，他宣布要在8个月的时候完成所有的编码和集成测试，后两个月准备文档和上线测试。由于他有了A项目的经验，所以想当然认为B项目会如期完成，项目进行到7个月的时候，项目发现，许多集成测试还没有进行，于是他跟公司领导及客户协调，（因为他和客户承诺8月内，客户可以参与上线测试）为了保证上线测试的顺利进行，能否延期一个月。

从这个案例可以看出，Lead果，由于他自信自己项目经验，在项目初期没有制定清晰的计划、没有对风险进行管理，导致在关键点（8个月的时候）计划延期。

对此，我个人的建议是：

1、
对于所有的项目，都应该作为新项目来执行，严格按照 选人、估算、计划的步骤进行；

2、
当计划制定后，为保证承诺的时间，在此之前，根据产品的特性和规模划分不同的模块，对每个模块的节点进行评审和度量，控制软件开发的规模；

3、
产品规模是影响开发进度的重要因素之一，（大项目的集成复杂度很高，难于估算；随着项目趋向小，复杂和估算难度减小）所以在计划的时候，尽量让开发人员按照统一的标准，快速开发软件，在集成阶段多留些时间用于应付集成测试所出现的问题；

4、
所有软件项目都在集成测试和系统测试会出现很多反复编码，所以要求建立专门的测试小组，并在编码阶段进入，这样有两点好处：能够较早的进入编码更适用于集成阶段测试、另一方面能够增加团队的协同力。

案例2

风险（RSKM）：

公司的大部分项目基本按照预定的时间完成，剩下的项目，在客户允许的延期的情况，也都得以完成。但是作为项目组内部的人员，已经为了这种保证承诺完成项目的时间而加班加点完成任务的情况厌烦不断了。但为什么计划好的项目在正常开发的时间完成不了呢？

这种虽然计划有度，但产品未及时完成的项目有一个通性，那就是没有进行较好产品计划前的风险评估。大部分项目的风险都是出自对产品特性的不了解，导致编写代码的出现功能和实际运行不符合的情况，同时在项目进行中，需求的不断增加及用户手册的编写因产品的变化导致许多项目的面临延迟的风险。

对此，我个人的建议是：

1、 在项目的初期制定风险检查列表，列出可能出现的风险，并每周进行跟踪汇报；

2、 在计划的时候，项目将难度较高的功能模块划分给技术成熟的编码人员，并对主要编码工作重点检查；

3、 在需求阶段，根据产品特性对产品仔细调研分析，在需求阶段关闭较大的功能需求，并得到客户的确认，用以保证整体项目按照时间完成。（小的依附模块的功能在和客户协调与时间允许下可以更改，但要统计好做好需求变更的纪录。）用户手册在产品需求的时候就已经明确软件功能，所以当需求确定后，将会确保软件功能与文档工作的协同一致。

案例3

需求开发及管理（RD&RM ）：

上面案例2提到需求，那么作为一个软件的产品的入口或者说起始，需求将会是很重要的，关系到是否能够满足客户的要求，在高的标准中超出客户的预想。公司曾经有一个项目经理在与客户交流出现问题。事情是这样的：项目经理在经过广泛调查的制定一份详尽的需求，并将让客户在需求说明书上签字确认。但是在产品开发过程中，客户不断提供新的需求，但是项目经理以增加新需求会影响项目进度及客户已经在需求说明书上签字确认为由，拒绝了客户的要求，最后客户找到项目经理的上司，最后以项目增加新的功能和延期为代价，完成项目。最后，此项目经理因为这个原因更换到别的部门去工作。

从案例3可知，与客户的沟通是必须的。因为产品的是客户要求的，客户的要求是产品的需求。那么如何能够满足客户要求、研发出符合需求的产品呢？

对此，我个人建议是：

1、 积极让客户参与到项目里，现在产品都再将面向客户的设计，那么与客户的沟通也是项目日常活动之一。许多客户很少花时间去阅读文档、管理和监控进度，也有些客户中不同的人针对一个设计提出不同的观点，而开发人员也无法确定特定问题应该按照谁的决定来执行，那么，项目早期关注客户的关系将会有助于减少这些问题的存在，所以说在计划需求的阶段就要积极参让客户参与到项目开发中，在评审会议和关键点评估会上尽量邀请到客户来参加，如果不能参加的也要将会议纪要递呈给客户。

2、 对待需求，刚才上面那点说到了人，我认为需求应该包括两点，一个是人（客户），另一个产品。那么这样研发满足客户的要求的产品应该怎么做呢？大体应该分四个步骤：计划、需求分析、设计、实现。

A计划，好的计划是增加客户对项目满意度，项目及组织在项目初期应该选择适当的模型、确定使意客户的承诺、建立有效的沟通渠道、选择适合双方的合理解决方案、进行风险管理。

B 需求分析，提取需求的时候，要了解什么是真正需求，在项目组做需求调研的时候，在需求列表中需求可能和客户实际需求不符甚至是冲突，所以获取需求的时候，要让客户充分了解需求，可以通过调查问卷、深入客户的业务中、与客户的沟通、根据不同意见列举不同决策方案让客户选择等方式收集。通过这些面向客户的需求收集方法能够是开发人员挖掘客户真正需求，并最大限度理解这些需求，有效减轻以后客户额外要求的时间。

C 设计，需求收集完后，在产品设计阶段，留出一段时间和一段工作来应付偶尔产生的需求变更。

D 实现，尽可能采用比较简单编码手段，来应付客户需求变化，这样适用于改变软件的某些功能，同时，在进度计划中标识一些小的里程碑来监控软件开发进度，同时将信息定期汇报给客户，让客户了解项目的进度，最好将某些简明的说明文档每周或每月给予客户，毕竟文档的展现能更有说服力，比口头承诺要好。

（产品需求是客户要求，灵活变动沟通的方法有利于双方信任，易于达到双赢）

以上我通过三个大方面（计划、风险、需求）来论述自己在这些方面的理解和建议，由于时间及个人水品的问题，如果不周及不妥之处，请各位给予指正。


上一篇：《度量软件过程》高成熟度CMMI企业必备教材
下一篇：软件开发过程各种不同角色在各个不同阶段都从事哪些不同活动，大家讨论一下

step365he

偶补充些案例一的建议
设计阶段对工作内容的适当有效细分非常关键，一则帮助估量工作量，二则有助于挖掘风险，三则使得制定的计划更为可行。

ljaabb44

可以补充一些测试

williams

step365he ，谢谢 具体实施对于过程改进而言还有很大的时间距离 ，不管针对过程的本身（规范制度），还要考虑到企业的文化 行业的气候，所以每个公司在最改进的时候，都在先按图索骥，然后在创造。我现所在的公司仅是想而不做，顾虑重重的，看来最重要的不仅是客户的成熟 还有 leadership呀

iswlvhp

可以看出楼主是很用心的工作及总结，我受教了。谢谢。

楼主提出的这些建议实际上是在CMMI3中提到的一些经验做法。
我补充一点，关于风险跟踪，其实是一个复杂的过程，定时跟踪及分析
是非常必要的，而且每个风险是要一直跟踪到项目结束的，因为风险变化多端，
在一个时间点结束并不表示以后永远不会再复生。所以跟踪一定要彻底。

还有，我觉得既然楼主有这么多好的心得，把这些建议实际运用起来就非常必要，
只有在实际应用中才会检验这些做法是否有效。

liucherry

我现在惆怅的是如何预见风险，好多风险都是事后发现，很少是可以提前预防的

端木若希

plan is nothing，planinng is everything

燕尾蝶

学习中，谢谢分享~

lee_huo

liucherry 发表于 2010-4-8 13:51
我现在惆怅的是如何预见风险，好多风险都是事后发现，很少是可以提前预防的

风险管理的魅力是哪些不可预见的风险。可以从风险可能产生的结果上做点事，就是如果发生了该如何缓解、规避、转移或者接受。及时我们不知道什么风险会出现或发生，但是我们从现有的状况出发，想想会有哪些后果或结果发生

拿破伦二世

确实不错，顶先

紫丁香

我是个凑数的。。。

施连志

我了个去，顶了

独家等待

没人回帖。。。我来个吧！

一秒钟的永恒。

我也来顶一下..

耀眼的阳光

没人回帖。。。我来个吧！