我有一些业界的朋友给我探讨一个问题，到底是管人容易还是管项目容易？我也在思考这个问题，不知道各位是什么答案。



其实人和项目的结合点就是在流程，流程很好的把人和项目结合在一起。一个是软件开发面临的问题和对策，怎么找到这个对策，利用什么样的流程比较合理。第三在我们IBM研发中心是怎么利用这个流程，有什么样的经验。

　　这个地方列出了一些软件开发中可能面临的问题，或者叫做不良的状况。这个是通过业界调查上百家IT厂商、开发商和应用商得出的一些结果，主要是用户需求，变更管理，性能资料还有协同上的问题。

　　我们出现这么多不好的症状（如图），这里列出了一些原因的解决办法。比如说有一个模块无法集成，这里可能对应一叶根源，比如薄弱的架构设计，还有一致性不够，还有主观判断等等。这里面列出了六个IT应用最佳的结果方案，一个是迭代式开发，在准备这个题目之前的时候，有人问我，说有没有新的业界流程。其实没有一个最佳流程，只有说在不断发展变化合适环境里面实用的流程。业界发展了这么多年，逐步形成了，可能有一些变化。

　　第二个是管理的需求，再一个是基于组件的架构，我们到目前为止，还不能像汽车一样，就是发动机坏了换一个就可以用。我们的软件就是一次性部署，一次性使用。如果不行的话，就要重新开发生产。不能像汽车那样方便，所以我们提出一个基于组件的架构模式。

　　再一个是可视化建模，便于我们沟通，保持我们的一致性。

　　再往下是持续验证质量。我也跟很多的企业有过这样的交流，过去中国的企业因为人力、物力、时间上面，可能对测试这块投入得不够。

　　再下一个是管理的变更。

　　刚才讲到有这么多的原因，有这么多解决办法，我们就考虑到，怎么样把这个解决办法融合到我们的流程中去。这里给出了一个流程的重要性。

　　这里简单说了一致性、可预见性、再一个是控制质量。

　　没有一个防止四海皆准的流程，只是一个流程有什么好的方法。这里面提出了一点，第一是实用，很多厂商都有自己的流程，但是很多都是最后放弃，很重要的原因就是这个流程没有可操作性，没有实用性，很大一点有的可能是过于晦涩、过于文档化，缺乏一些工具，缺乏一些可视化的手段。

　　第二个是可扩展性，任何一个公司或者一个不同的部门都有不同的需求。比如我们IBM研发中心，我们是共同的一个平台，但是事实上到了每个部门，还会有各自的差异，为了满足特定商业部门的特定需求，可能有定制，你的流程有没有定制的手段，这是一个比较重要的方面。

　　再一个是包括裁减，包括文档、模板、工具、平台怎么裁减，有没有提供一种裁减的手段。

　　下面是我们一直在应用的一种流程叫做RUP，大家对于RUP也不陌生了。它来源于上百家比较有经验的公司多年来的综合，融合在一起，再经过IBM的升华，然后变成可视化规范的流程，再加上一系列的方法论，还有操作层面的模板、文档，最终可定制的工具。

　　RUP是业界公共的标准，到了IBM有另外一个词，就是IRUP。如果说到了某家公司，叫做什么C的可以叫做CRUP。

　　分四个阶段，在每个阶段可能不只做一次，比如构造阶段可能有三次迭代，大家看一下纵轴，有不同的学科领域，需求分析领域，有设计领域还有项目管理技术管理，每个领域都有相关的工作流和相关的工作细节在里面。每个迭代都会发生相关的动作。

　　这些像山峰的东西是意味着投入的代价（如图），可以看一下，每个峰值都不一样。

　　我这里简单表述一下几个关键的概念。一个是迭代式开发的概念，这个是循环状的图，中间有一个起始的颜色，就是驱动力，然后就是开始转，然后下面是RUP一些关键的元素，再往下有一些工作流的细节，每个工作流都有工作的步骤，然后中间是角色，有可能一个角色戴多顶帽子，下面是我们真正的一个行动，比如说项目经理在初始阶段要去调查客户的需求，就是一个动作。

　　中间是我们的产出，包括很多文档、设计、代码都可以是产出这类。再一个是工具，再下面是一些模板、报告检测点等等，这些是学科领域的方法论，这些是流程主要包含的一些内容。

　　这个图还是对刚才话题的延续，这个是协作，左边是统一的流程，最终三部分构成，比如上下文中间有一个互动的关系，在这里很重要的一点就是需要用迭代的方式，能够把一系列的都串起来，所以每个环节都会有所体现。

　　这个地方特别强调的是迭代的动作会影响什么样的元素。比如说在开发阶段，我认为开发阶段比较复杂，可能有三个迭代，一个迭代就是要做什么事情，就是相关的人员进入到这个里面，从需求一直到描述、一直到设计到最终部署，到最终的项目管理这些领域的学科都会在迭代里面启动，最终出来的是一个可递交的产出物。

　　每一个迭代可能出现在四个阶段的任何一个部位。

　　这个地方又强调了了一点，从这个角度可以看一下软件开发流程的思想。（如图）

　　我们在应用开发很重要的经验，就是迭代式开发。我们所有的流程如果能够变成可用的可执行的、可操作的一定要借助一些工具和平台。

　　刚才讲的是迭代式开发的一些优点，在迭代式开发之前还有一些比如瀑布式开发，这种是完全理想的、线性的关系，完全是一次性的。它认为需求之后就一定会到设计，设计完了之后一定会有编码，然后就是子系统的集成，还有系统的测试，这个是传统瀑布式开发的理念，当然这是很理想的状况。但是在现实中，最难应对的就是变化，需求的不明确。除非说项目停在那里需求全部满足，但是这个不是能做到的。很多项目经理很头疼的就是一半的时候来了一个变更。

　　首先从理念上，瀑布式开发很难从这个上面来解决问题，带来的问题就是滞后了关键风险的解决，难于准确衡量项目的进度，如果这个时候有变更的话，你可能就会觉得项目的进度很难控制了。

　　延迟并加重了集成和测试的工作，必然导致测试要等，一直要等到全面的事情全部做完。导致你被迫的不断的修改计划，不断的重复，这个就是被动的关系。

　　无法满足尽早部署的要求，往往导致未计划的迭代。

　　迭代式开发很重要的一个理念就是承认需求变更、承认变化是正常的。就是认为比较要去面对变化，适应变化。所以在这样的情况下应对的办法就是，我每次项目不是只做一次，在一个很长的阶段内，有多的循环，每个循环是一个什么样的概念？每个循环都会起动需求分析，起动代码编写，起动代码测试，所有的过程都会走一圈。每次迭代式的时候有一个可递交的产出物，这才叫一次迭代。这个迭代首先产出物是其中的一部分，代码是其中的一部分，但是每次迭代以后，产出物在不断的增长，最终就是达到100%。最大得好处就是风险驱动，让你最早的发现风险，因为每次迭代就是让所有的过程重新做一遍。在初级阶段没有测试的时候，怎么引入呢？这个也是一个问题，其实在初始阶段、概念阶段的时候一样要测试，前面有人讲到业务需求测试，这个跟大家想象到的工具，黑盒可能不一样，这个更多的是基于文本的静态测试，比如检测表、白板等等，一样会出来结果。

　　瀑布式的概念风险是什么样的呢？他是正像的，从初级阶段一直到后，可能风险越来越高，因为项目经理很难知道项目是否真正的有问题，很难预计到所以风险就是到后期才全部爆发出来。

　　用迭代式开发，到后面风险很快的就会降低到一个很低的值。它可以主动的调整每次迭代的周期，每次迭代的需求，每次迭代的计划，这样很容易得到风险产生的一个地方。通常一次迭代时间是两到四周左右，整个项目迭代通常是六、到七次，每次迭代的时候可能有一些考虑，把什么样的内容放在第一个迭代里面，早期要把高风险的、不明确的放到第一个迭代里面。

　　这个地方讲到如何规范开发及管理的流程。我们IBM内部的是IRUP软件开发的流程，我们为什么要用它，肯定有一些好处，比如迭代式的方式，节约成本，可控，降低风险等等都是一系列的东西。在IBM内部，研发中心、开发中心还有售后服务团队，还有技术支持团队用的流程都各不一样，这个是一个现实，我们也是一直采用的手段，目的就是符合特定部门，更有效的提高效率。如何去规范这个流程呢？

　　大家可以看到，这里列了几条，第一从流程的角度，对它进行裁减，这个是大的部门首先要做的事情，建立一个企业统一的流程框架，这个框架很重要，如果没有框架，裁减是很费劲的事情，然后通过相关的手段、方法和工具。我们所有的研发中心用的平台都是一样的，而且是跨网段无缝的，可以跟美国的、印度的连接在一起，这样就提供了很好的机制。因为代码、文档相关的产出物都是可以完全同步的，到各个不同的站点。

　　第二点，就是要从最佳的实践入手，其实每个部门做的时候都会有自己最好的经验可以拉出来或者跟其他部门共享，每个部门特定业务流程不同的时候，都是基于最佳实践。我们特别有一个部门，是专门做流程改造的部门，他们会负责对各个流程进行审核，有的可能提出，这个业务不是很适合这个部门的时候，可以提出建议，然后到流程改造部门去审批，可以进行定制。我们这个流程发布以后，是一系列可视化的知识库，并不是说一堆文本文件。这个时候需要做一些定制，这个时候就是一系列的东西。

　　还有很重要的一个问题，就是我怎么去运用流程？觉得是不是买一些测试的工具，或者买一些开发的工具就可以带动呢？不是不可以，可以通过一些手段，比如配制一些平台一级的产品和系统来提高流程，但是不能以流程来代替企业的文化改造，而是应该以文化来引导流程。因为开发中心的流程部署也是我一直在负责，其实IBM前前后后的流程一直在变，以前很常用的一个词叫做IPD，就是集成产品开发的流程，后面用到IRUP，每个流程都有优缺点，为什么要重新永远呢？就是企业文化上的考虑。所以组织级的变化还是更为关键一点，当然可以以项目带动组织级变化，其士任何一个流程都是基于团队的，每个团队里面有测试团队、开发团队、业务分析团队，每个团队在业务流程里面都有定义，一旦流程定义好了以后，这个项目就会建立相应的组织机构，一旦流程改变以后，也会有相应组织机构的调整。

　　下面很重要的一点是结合工具，很多人很关注企业的流程，也很有兴趣改造企业流程，甚至花了很多的成本、人力投资到流程的建设当中去，但是到后面会发现流程没有贯彻下去，或者中途废止，很重要的一点，大家知道，人是最难控制的因素，因为每个人的性格、习惯、工作模式都不一样，所以为什么一个新的团队新的项目组风险很高的。所以如何贯彻流程的最重要的一点就是想办法把流程固化下来，比如说变更，有什么样的状况，递交状况、接收状态，然后是确认状态，然后到下面就是去执行状态，然后后面就是做验证状态，就是要把整个流程走完了以后，就是很多人。如果只是没有好的工具去跟踪帮助跟进的时候，往往被人忽略掉，或者没有办法执行，如果有平台一级的工具的时候，就会发现这个自动的流转，而且很便于大家的沟通，有实时的报告。

　　比如说现在大家经常讲的就是软件工程和制造业配合最高的是什么呢？就是汽车设计出来，制造出来跟设计出来的一模一样，因为是流水线，汽车的质量为什么能保证呢？福特公司目标就是把汽车卖到每一个工人家庭，因为就是有流水线。而我们的流程设计很难做到流水线生产。

　　还有一点我们要注重知识传递和培训，在IBM部署流程也花了很多的精力，在前几年我看这个事情的时候，投入了很多的人力和物力来做培训，因为牵涉到很多的东西，人员的技术、人员的划分、重组、工具的应用、模板等等都是需要进行培训的。IT行业最大的特点就是知识在人的思维里面，所以知识的培训是很重要的一点。

　　我们做流程的时候通常都是从上往下。换句话说就是高层支持，我碰到很多其他国内的公司他们也有这样的问题，就是困惑，往往在某一个层面大家感觉不到一个需求，但是真正在部署的时候会发现很大的阻力。最底层的可能愿望不会很强烈，只要不给额外的负担就是最想要的事情，但是他会考虑到，如果离开这个岗位，其他人怎么接手，怎么保证质量。所以最大的驱动力流程的应用和规范是来自于高层。

　　各位在做这种事情的话，特点重要的一点就是要从高层来做。其实我们做培训的时候就是先从中高层领导做一些相关的工作。

　　我们就是建立这样的一个团队，必须要从上往下推动流程的规范和实施才有可能达到效果。CSDL就是中国的软件开发中心，这个团队就是从总经理一层去推广，然后是管理层代表，再往下就是部门的代表，然后是每个职能部门都有一个代表，这个代表更多的目标是要收集每个部门对流程的需求，然后把碰到的问题反馈到上面去，同时向管理层汇报应用的情况。还有一个区域代表，因为整个软件开发中心不在一个地方，每个地点可能都会有相关的区域代表。然后就是咨询团，在真正部署一个流程的时候，大家要有耐性，我们的IRUP用了两年的时间，就是逐步的在使用，也是一个很长的过程。也有一些历史遗产，还有怎么做工具的转换，过去知识的迁移都是非常大的量，这一系列的问题都要考虑到。

　　所以我们要多想一些这些团队，通常是先挑出一两个，或者一两个这样的部门来做培训，来实施，然后把他们培养出来，得到最佳的实践，这些人就会成为最后的咨询团，在碰到这个问题的时候，他们就可以出来给他们解决问题。

　　如果要真正部署流程的话，要花很多的时间很多的代价去做培训。这个是一个柱状图，每一项是一个培训的项目，然后又一个软件测试的规则，大家可以看到一个白色的框，就是这一项软件测试的基本原则，规则，可能要几百人参加这种培训，每次可能只有几百人，然后就是培训的过程，然后要找出来所有培训的科目，然后搜集不同的需求。流程里面有方法论，要把这些运用到流程里面去，在这个里面要做这些事情，就必须要有一定的方法论来指导它。比如要以客户为中心的界面设计，然后相关的产出是什么样的，给出模板来。随着时间的推移，这个数据量在不断的增加，所以要有相关团队的工作支持。

　　我们开发中心有很多很细的体会和经验，也包括我们对流程的介绍，如果有机会的话，欢迎大家到我们那里参观交流。谢谢大家！