流程重要还是人重要

1）过程（process）是非常重要的。
2）过程是可以根据项目的特性等进行设计的。
3）过程是需要通过量化指标(metreics）来衡量的。
4）量化指标是用来显示项目的状态的，更是用来进行项目控制的。
5）“人”和“过程”相比，“人”是次要的，“过程”是主要的。就是说，不能因为什么人水平很高就可以不按照“过程”去做。

  jiajin    [发表于 2005年6月30日 18:10:10 ]   [回复]  [引用] 
 
前两天贴了一个“负责一个比较大项目的感受”，今天继续说说自己感受到的CMM/CMMi和项目管理的关系。

我在一家通过了CMM/L5认证的公司工作，我自己还参加了CMM/L5的认证工作，其中感受最深的就是，不管你所在的公司是不是要实施CMM/CMMi来作为质量保证的方法，但是，作为任何一个PM，都应该把CMM的300多个KP(Key practice)和PMBOK一样放在案头，经常地查阅。

虽然有些公司通过获得CMM/CMMi认证来作为marketing的宣传工具，那时公司决策层的事情，作为第一线的PM们，应该充分利用CMM/CMMi这个工具来做自己的工作。

CMM/CMMi最大的好处就是告诉了世人Project的质量是通过process来保证的，而不是通过参加项目的人的素质决定的。尤其是参加人数比较多的中大型项目，如果不运用CMM/CMMi的这个指导思想，几乎是不可能控制的。

所以，如果大家今后有机会负责比较大或比较复杂的项目的时候，希望大家注意到
1）过程（process）是非常重要的。
2）过程是可以根据项目的特性等进行设计的。
3）过程是需要通过量化指标(metreics）来衡量的。
4）量化指标是用来显示项目的状态的，更是用来进行项目控制的。
5）“人”和“过程”相比，“人”是次要的，“过程”是主要的。就是说，不能因为什么人水平很高就可以不按照“过程”去做。

个人意见，仅供参考。
 
 zhf_karen    [发表于 2005年6月30日 22:38:48 ]   [回复]  [引用] 
 
嘿嘿，现在还真看不得这种话啊。
首先，中国通过CMM5的企业就是那几个，嘿嘿，我多少还是了解一些这些企业到底如何做的。这里我不想多说。否则有点攻击的味道了。
其次，CMMI和CMM“告诉世人Project质量是通过Process来保证”的，这句话至少在目前，我明确可以说，是理想化的，和不现实的。流程给你提供的帮助，使固化优秀的做法，以及快速团队成长。但是，流程不能保证质量。我们不是在依靠流程在构造软件，而是人员构造软件。
另外，人是次要的，流程是主要的。真憋不住了：这是典型的胡扯！如果你愿意，我可以展开这个话题，并且给你看一些数字，在项目成功率中，到底什么是重要的。软件工程是我们解决软件危机的一个思路，但是这个思路走得太过了。而且，CMM几乎没有告诉你，在什么项目中，他是适合的，什么是不适合的。公司高层使用CMM作为Market的宣传工具，是有一定道理的，因为最适合CMM的环境是极其大型，需求变化很少的项目和外包软件环境。
不要说你们公司过了CMM5，就如何如何。嘿嘿，我们在2年以前过了CMM4
，但是我很清楚我们是如何过得，而且我也很清楚，国内的公司是如何过得CMM，而且，在CMM环境下4年以上的研发经验，可以告诉我，什么是重要的，CMM的前置条件是什么。
这种想法收敛一些！至少在目前国内IT行业中，这种想法是不可能的和不可行的。而且，我不认为这是将来的方向。 
 
 zhf_karen    [发表于 2005年6月30日 22:49:40 ]   [回复]  [引用] 
 
给楼主推荐几个站点，
www.javaeye.com上有一篇对CMM的评论的帖子，里面的探讨很不错，得空可以看看。至少也是另外一种思路。软件工艺这本书也不错，至少是另外一种思路。其次，敏捷站点，也是不错的。至少在我们目前大多数面向客户的项目来说，敏捷虽然不是银弹，但是他更现实一些，而且他也更明确告诉你，什么时候，使用什么开发方式更有效，而不是类似CMM，并不做这种说明。似乎它是通用的。但是实际上，他往往在误导我们。
CMM并非一无是处，CMM的KPA对于我们还是有帮助的。但是这不能推导出来软件中流程最重要的说法。典型的目标偏离，流程是为了目标更好的达到，但是他仅仅是其中一个因素而已。过分夸大这个因素，我很难接受。
事实上，我在2001年的时候，观点和你很相似，但是现在不是了。我们需要在流程和人员之间进行平衡。软件开发类似陆军，我们为军人配备武器，软件以人为本！
好了，不再多说什么了。作为一个高素质的管理者，我们需要平衡能力，在人和流程之间平衡好吧。管理者都在钢丝上跳舞，让我们跳得漂亮一些吧。 
 
zhf_karen    [发表于 2005年6月30日 23:06:13 ]   [回复]  [引用] 
 
其实，我也能理解Jiajin的难处，做为一个大型团队的管理者，流程的作用是非常大的。但是我也希望一点，不要因为此，而过于忽视其他地方的作用。
呵呵，当年我觉得自己项目管理已经很不错了（对于不同团队进行不同流程裁减，监控里程碑，推进项目等等），但是后来的2-3年里面，我陷入了一种混沌，觉得突然觉得项目管理几乎无法掌控了。我觉得我们也许做错了一些东西。同时，在当时CSDN上的一些朋友就这个问题进行了很长时间的讨论。我同样也希望，我能够就这个问题和Jiajin进行一次讨论。我想这对於我们都是重要的。
发布流程和要求别人执行总是简单的；但是针对不同团队，我们流程重点会完全不同，针对不同项目，我们的流程也会完全不同。我们是根据人和团队来调整流程，而不是让人去适应流程。这种做法会使得活动发起很难执行（很多管理者会把这个问题归咎于员工的执行能力，但是我更多地看成一个管理者的管理能力），那么SEI都问出一个问题：“为什么他们不按照我们说的去做？”的讨论，那么为什么我们还在做这种绝对的认同呢？
软件工程的出发点是什么？
软件工程提出希望解决的是什么问题？
这些问题域在我们目前的环境中和当时提出的环境中，是否发生了什么变化？
对大量软件的研究表明，什么是最重要的？
我们应该如何在人和流程之间进行平衡？
绝大多数项目之间的共性和不同性到底哪个更大？
我们现在面临的软件主要问题，到底什么因素？那么这个因素应该如何来排解？
在讨论这些问题的时候，我希望我们始终从成本、可操作性着手。
我想，这些讨论对于我们大家都有有益的。 
 jiajin    [发表于 2005年7月1日 9:27:40 ]   [回复]  [引用] 
 
心平气和的与ZHF_Karen同学探讨“流程”和“人员”的问题。
其实，在软件工程领域，一直存在着是“流程”重要还是"人员“重要的争论，我个人两年前是”人员“重要论的支持者，但是，这两年做CMM，尤其是亲自参加了CMM/L5的评估（我作为评估小组的一员来评估我们公司是否符合CMM/L5的要求），我逐渐改变了我的观点。

首先，我就ZHF_Karen同学的几个观点来发表我个人的意见。
〉〉CMM几乎没有告诉你，在什么项目中，他是适合的，什么是不适合的。
其实，在CMM的各个KPA中都有一个Ability的段落，就是说组织（CMM/L3以上的是针对公司极的，CMM/L2是针对项目级的)或项目应该具有什么样的能力，所以，只要按照这个Ability去衡量开发团队，就可以判断这个团队是否是合适的。

〉〉我们需要在流程和人员之间进行平衡。
基本上是同意这个观点的，当时我有个人的意见。我经常被问到的一个问题就是，如果你的团队里有一个害群之马，你如何用CMM来处理呢？只是我和公司同事们在辩论时总被质问的一个问题。其实，我的答案是这样的。CMM中的任何一个KPA都没有告诉你如何解决团队中有害群之马这样的问题，当时，如我所说，CMM告诉大家的道理是”流程重要”这么一个道理，所以，根据这个道理我们就可以分析问题了。为什么会有“害群之马”？是员工的培训不好吗？那么，我们的培训流程也许有问题。是这个员工有什么不满的事情所以故意表现不好？那么，我们的管理流程也许有问题。是这个员工本来就是一个不好的人而被错误的招收进来了？那么，我们的招聘流程有问题。所以，按照这样的分析问题的方法，总可以把一个看似很小的事情归结到一个对流程改进的地方上。这就是CMM也好，6 sigma也好，ISO也好，这些工具的真髓就是对流程的持续改进（CMM/L5的PCM就是这个真髓的集中体现)。所以，在项目的实际情况中，我非常同意ZHF_karen同学的观点，需要去平衡，去运用实际的处理问题的技巧来解决问题，但是，问题的分析和解决却不应该停留在仅仅是解决了一个问题这个层次上。而真的应该在流程方面下功夫。否则，你处理了这个项目的一个害群之马，谁可以保证你的下一个项目中不出现两个这样的人呢？

〉〉我们是根据人和团队来调整流程，而不是让人去适应流程。
同意这个观点。所以，在我的帖子里我是说“ 2）过程是可以根据项目的特性等进行设计的。”。当时，我想强调的是，一旦这个流程设计好了，所有的人就必须遵守，而不能因为什么人特殊而废弃流程的执行。因为现实中的人都是特殊的，由一个人不执行流程，就会出现第二个，第三个，最后项目就会有危险。
当然，在要求大家都来执行流程是会遇到阻力，其实，这个还是因为流程没有做好的原因。就是培训的流程有问题。没有很好的通过培训让大家都明白流程对保证项目质量和成功的重要性。所以，大家自然都会有各自的想法，然后就各自为政，然后项目就失去控制了。

我的这些想法也许有理想化的一面，当时，对这种理想的追求才是使我们可以这些做IT的人不断提高的动力。有了这种追求和行动，就可以不断完成成功的项目，自己也就可以逐渐成长为一个成功的Project manager。

 zhf_karen    [发表于 2005年7月3日 18:35:14 ]   [回复]  [引用] 
 
嘿嘿，类似的讨论总是落到这样的境地，大家都把自己的地盘去不断扩大。
然后积压对方的空间。
对于这也很重要，那也很重要。我都不知道该如何说了。
我简单说几个数据：软件中，一个良好的项目管理者给项目带来的成功率提升是20%不到，但是一个优秀的架构设计人员，对项目成功率的提升是33%。无论对于大型项目来说，还是对于极限的小型项目来说，其中有一些人才是本身不可或缺的。提出这个数据的意思是：并不是所有的问题，最后都能够落实在流程的改进上的。
流程的确重要，这一点我从来不否认，如果说你认为流程重要，只是从大家都需要遵守流程这一点来说，流程更重要，我就无话可说了。因为这是必然的。
另外，纯粹理论的讨论，很令人郁闷。那么我来说几个实际的例子好了。每个公司都会有自己的开发流程，但是我们面临的项目大大不同，那么你如何解决这个问题？我们应该如何做？某一个团队很优秀，我们可以执行日创建自动化冒烟的工作，另外一个团队相对来说很普通，连一般的版本控制都做不好，那么该如何坚持流程？当然，我们可以进行流程定制，针对项目和团队来进行流程定制，但是你是否明确知道这种做法在成本上，和操作性上是否恰当？
我们针对流程的一个看法是：事情做细一些总不是坏事，但是明确记住一点，你需要成本。
就像理论上说起来，主动补位等等要求纯属胡扯，理想状态下公司根本不需要这种事情，但是事实上，我们都在如此做，而且公司对此要求很高。
理想化不是坏事，存在理想是向上的表现。但是，管理者需要是个实际的人。软件还不是那种靠着流程就能做好的（当然，我的意思并不是，不要流程就能做好软件），更重要的人员。
这种讨论的确很扰人，其实，我们在争论两者之间平衡的5%的空间。
说一个最简单的吧。你手下有一个项目经理，他承担一个10人左右的研发任务，客户需求变化很快，周期为3个月。你要求他如何做需求？做设计？如何做测试？你从哪些点来监控防止项目失控，当出现问题的时候（比如发现某一个风险没有被预估，并且造成很大的损失的时候），你如何解决这个问题？你如何解决沟通问题？等等。
然后我们一起来看看，流程在其中起到了什么作用，人员本身起到了什么作用？好吗？空泛的讨论实在让人很浪费时间。让我们用一个实际工作来说明问题好了。
另外，顺便说一句，我不喜欢被称之为“同学”，叫我zhfkaren好了。因为太学院化的东西，一直是我最讨厌的东西，一点个人习惯而已。OK？
 royli    [发表于 2005年7月4日 11:53:21 ]   [回复]  [引用] 

个人比较支持jiajin，对大型的跨国企业来说，一个project的生死并不是至关重要的，重要的是无数project积累下来的最符合企业的process，人可以流动但project的process和于此相关的公司的营运方式对公司来说是可以保留的资产。

作为一个pm，还需要站在更高的角度考虑问题。项目管理毕竟是公司整体营运的部分。
 jj020804    [发表于 2005年7月4日 14:40:35 ]   [回复]  [引用] 
 
看了各位的讨论，有感而发。以下是我的观点：

1. 什么是流程？
太过学术性的定义不适合我们的讨论，比较实在的定义是：流程就是我们的做事方式。它没有什么高深奥妙的地方。它只是把过去成功的做法按照需要进行归纳、改进，并强化成一种制度，使下次执行时可以重复成功。套在个人身上，其实就是个人习惯和处事，套在公司上，就是我们所熟知的制度和流程。

2. 流程和人没有所谓的谁重要谁次要的矛盾
我们知道，流程、人、工具和技能是构成公司综合能力的三大要素，任何一方面能力欠缺，都直接影响公司的综合能力。从来没有一家公司只需要这三者之一就可以成功的。出现谁重要的问题在于看问题的角度。从流程的角度看，因为流程控制的实体对象是资源，很自然得出流程比资源重要的结果。从人的角度看，因为流程是来源于人的成功经验，是由人去制定和操纵，自然得出人比流程重要的结果。其实，从企业发展的高度看，哪一方面是企业发展的最短板，那一方面就是企业的当前最重要的矛盾，那一方面就是最重要的。所以，不要不讲前提的谈论谁重要的问题，这也引出了下一个观点。

3. 问题导向思维
不要孤立地思考，我们要清楚自己的问题所在。无论走CMMI还是不走CMMI，我们首先要做的就是清楚自己的问题。根据自己的问题分析其根源，选择合适的改进模型。千万不要陷入为流程而做流程的误区。SEI在这一方面已经给出明确的指导。按照这个思维，对改进模型的选择，例如CMMI、ISO、6Sigma等，只不过是在特定问题环境下的最优化选择。

4. 走出CMMI与公司综合能力关系的误区
CMMI给项目带来的其中一个好处在于公司对项目管理的可控能力和可预言能力的提升。举个形象的例子，我们掷飞镖，可能每次掷的结果都不同，这是必然的。现在我们要控制的是结果之间的差异度。CMMI可以做到的就是这一点。CMMI可以帮助你在你掷飞镖之前预先告诉你结果会在哪个区间浮动，如6~8环。没有流程控制是做不到这一点。但CMMI不能马上让你可以掷出10环。所以，过了CMMI最高级的公司未必是市场上最强的公司。这个也是和之前谈到流程、人、技能和工具三角关系有关。当好的流程制定出来后，人、技能和工具其中之一可能就成为公司下一个最短板了。

5. 过程改进是过程，不是结果
认证、过级只是过程改进的其中一个里程碑，是对过程改进工作的阶段性检验。如果认为过了级拿了认证就已经达到过程改进最终目标的话，那是对过程改进的误解。过程改进是漫长而艰巨的过程，它必须围绕公司的商业目标而进行，并且随企业的终结而终结。CMMI为过程改进提供了框架和实践性指导。所以，过了CMMI等级仅仅表明公司的过程改进行为已经站在更高的起点上，但公司只要经过持续不懈的改进其威力将会令人瞩目。在SEI的网站上，有18家国际知名企业的CMMI Performance Result报告可为一例证。
 
laolie    [发表于 2005年7月4日 16:30:42 ]   [回复]  [引用] 
 
任何一个偏向都会出现问题。这个矛盾，就如同丈夫夹在老妈和老婆之间一样。处理不当就会出现问题。所以说，没必要争论哪个更重要，而是去想怎么样才能做的更好，流程不足则补流程；人员欠缺则提升人员素质。

如果真能站在客观的角度长远的角度去思考，那么重要的就是怎么提升管理者的能力和水平，流程和人员是必要的工具罢了（这话可能听着不舒服啊，向大家致歉，我自己也是“工具”，哈）
 royli    [发表于 2005年7月4日 17:12:12 ]   [回复]  [引用] 
同意jj020804的观点，正如眼睛和嘴巴谁更重要的话题一样，不必要去争论太多。前几年有场关于物质财富重要还是精神财富重要的辩论，最终的结果是因人而异，富翁选择精神，乞丐选择物质，呵呵~~。 
 howard_hong    [发表于 2005年7月5日 8:35:41 ]   [回复]  [引用] 

其实，我个人在理论上同意 jj020804的观点，之所以会说出“流程比人”重要的话，请大家看我的最原始的那个帖子，其实我是从实际的项目经理的立场出发在评价这个事情。

作为项目经理，尤其我是负责IT项目外包项目的，在若干的项目因素中，我个人是很关心质量的。而对质量的控制这是通过对流程的设计/裁减/实施来实现的。因为我不想过多地依赖个人的因素，这样的话，我只能说如果我找到了能力高的人，所以，我这个项目成功了，如果没有，我就失败了。所以，我希望可以用流程和流程的改进来保证公司整体水平的提高，就是保证公司的大多数项目的成功。

所以，我们公司的实施CMM（现在在实施CMMi）的过程中，我们做得比较好的一件事情就是没有为了流程而流程，真的是把流程和流程的改进作为了我们所有项目的一个重点。同时，我个人通过带领现在这个将近70人的开发团队，也充分的享受到了如何通过对流程的控制来做对项目的控制，并且效果挺好。

其实我个人因为接触日本很多，我觉得日本就是一个比较典型的不重视流程而重视人的因素的国家（当时想丰田汽车那样把过程追求到了极限的公司也有很多。） 很多日本人，尤其是做IT的，每个人的技术都挺好的，但是，超过10个人在一起做项目，最后这个项目就很有问题。我从来没有接触过日本的通过了CMM/CMMi的公司，不知道他们是如何实施的，当时就我接触的范围来说，他们的项目管理能力是非常的弱的。

jj020804的观点是很正确/正规的观点，也许jj020804有过CMM/CMMi咨询顾问的背景，因为这些观点在我看来是似曾相识，很像我们公司在实施CMM的时候请来的咨询顾问的观点。所以，我都很接受这些观点。

但是，我还有一点补充，有的时候我也参加一些公司管理方面的工作，发现同样是流程要重要一些，尤其是对一些关键流程的优化/改进，对公司的运营非常有帮助，比如人才招聘流程，培训流程等等，如果仅仅是找一个好的招聘总监或是培训负责人，而不配合以相应的流程，那他们工作起来也会非常的困难。相反，如果流程很清楚，同时，有相应的组织(比如SEPG等）不断在推进流程的改进，那么，在这些关键岗位上的人即使不是很优秀的人，公司一样可以很好的运营的。
 jj020804    [发表于 2005年7月5日 9:50:21 ]   [回复]  [引用] 
 
很高兴看到jiajin及其所在公司对过程改进精粹的理解。不管从哪个角度看待流程、人、技能和工具的关系，这些都是看问题的方向不同而已。

另外，jiajin说对了，我现在确实是在做CMMI咨询顾问的工作并正在主导一家公司的CMMI项目。欢迎大家与我交流讨论CMMI方面的问题。
 camer    [发表于 2005年7月5日 18:25:04 ]   [回复]  [引用] 
 
没想到这儿还藏着一个优秀帖子（斑竹失职了～）

这个讨论让我看到了另一个讨论（对于IT项目经理，管理还是技术重要。。或者在一个公司中：市场重要还是研发技术重要？？）

一定要非此即彼吗？

我更赞成zhf_karen 的务实风格，就事论事，针对具体的项目，孰轻孰重，有一定的判断，而且也只有在具体的案例和环境中，这种讨论才有实际意义。。。

zhf_karen 的案例：
－－－－－－－－－－－－－－－－－－
说一个最简单的吧。你手下有一个项目经理，他承担一个10人左右的研发任务，客户需求变化很快，周期为3个月。你要求他如何做需求？做设计？如何做测试？你从哪些点来监控防止项目失控，当出现问题的时候（比如发现某一个风险没有被预估，并且造成很大的损失的时候），你如何解决这个问题？你如何解决沟通问题？等等。
－－－－－－－－－－－－－－－－－

这样的项目，项目组，除非以前有非常好的流程支持，否则这个时候还是把流程放在一边比较合适，因为进度是至关重要的目标，质量、范围在目标优先级上就要让位于工期。。。

另一个案例：一个公司通过非常艰难的市场营销，得到一个价值400万的软件项目合同，但是客户要求非常高（4套软件系统协同工作，在7个不同的客户公司实施，要适应不同客户公司在业务上的个性化需求，这个项目必须在2004年底完工）。。。。通过一个成熟的项目经理评估，这是个死亡项目，但是如果公司不接这个单，公司可能倒闭。。项目经理曾经要求按照预定的开发过程去做事，但是不行，老板要求加快进度。。后来项目经理放弃了流程，迭代式的开发（让客户不断看到新版本），后来这个项目延后了差不多半年收尾，但是已经是尽了力了。。。

这个案例比较极端，让我想到了小平的那句著名的话“无论白猫黒猫，抓到老鼠就是好猫”。。。在80％的软件企业都处于相对艰难的阶段，过分理想化的谈论没有多大意义

 Manjusri    [发表于 2005年7月5日 19:17:03 ]   [回复]  [引用] 
 
流程实际上是牺牲了一定效率的。CMMI最合适来套日本外包项目。 
 jiajin    [发表于 2005年7月6日 13:15:54 ]   [回复]  [引用] 
 
来回答camer和 zhf_karen的就事论事的问题。
其实，jj020804文章中那个飞镖的例子真的是非常的贴切，这是我看到的有关PCB（Process capability baseline）解释的最贴切的一个例子。

就是说在流程在稳定下来以后，保证的是一个统计性的结果，而不是可以保证任何一个个案。而对流层的优化和改进，也将是对所有运用这个流程的项目/公司有影响，这样就可以是项目/公司在整体水平上得以提高，而不是过多的依赖于个人的因素。

也许是和camei和zhf_karen的关注问题的方向不一样，在任何一个个案中，如果也不考虑流程的改进和优化，那么，人/工具的因素的会起更大的作用。当时，我还是强调我的观点，我不想把一个项目只是独立的对待，我希望可以和流程的改进/优化结合起来，即使我这个项目失败了，我希望可以通过流程的力量，让其他人不犯类似的错误。（DP（defect prevention）的一种吧。）
jiajin    [发表于 2005年7月18日 14:23:04 ]   [回复]  [引用] 
 
在经历了“流程”和“人员”的一番讨论，现在来做做"如何平衡流程和人员以持续提高公司或项目的综合能力"这个作业。

即使在这个问题上，我还是要强调“流程”的重要性，也许，人员的重要性在项目中也好，在企业也好，都是显而易见的，但是，流程的重要性却不是很明显的。如果只是依赖人，而忽略了流程，直接的结果就是有了能人，项目就成功，企业就发达；没有了能人，项目就完蛋，企业也就衰退。

即使在发现和留住人员（也许应该用“人才”这个词）这个问题上，流程同样起着关键的作用。固然千里马是需要伯乐来识别的，当时，如何让流程来保证3个臭皮匠算一个诸葛亮就是可以解决如果没有伯乐，如何来识别千里马这个问题。

举一个我们公司自己的例子。虽然公司有猎头公司替我们做第一轮的履历筛选，有统一的考试试题，有统一的HR部门来进行第一次面试，但是，真正关键的是第二轮/第三轮面试。第二轮面试主要集中在技术环节，用公司的技术比较好的人来面试。第二轮的面试官已经拥有了一票否决权，就是说如果第二轮面试官说不行，这个人就不会被我们公司录取。但是，后来我们发现，尽管第二轮的面试官都是公司公认的技术比较好的人，但是后来发现录取的人还是参差不齐的。经过调查，发现虽然面试官技术都很好，但是每个人都有自己的侧重和喜好，所以，在面试的时候总是就自己侧重的地方多提问。如果应试的人也正好这方面有准备，或是基础较好，就容易通过；相反，就很难通过。

我们后来是这样修改这个面试流程的。我们让各个面试官每个人在自己最得意的领域内准备5道问题和相应的答案，然后要求每个面试官在面试的时候，除了自己准备的5道题中可以提问3道以外，其他的领域也必须提问至少一道题。

我觉得这样做的好处在于，避免了个人的印象和影响；即如这些人今后因为工作忙/离开公司/休假等原因不能参加面试了，一样可以保证挑选出合适的人才。

总结一下就是，如何平衡流程和人员的问题我们是这么来解决的，就是尽量让流程完善从而不要绝对的依赖人的因素。（当然，还有工具，这个因素我们还一直没有涉及到呢。）

因为人/流程/工具这个三角关系中，“人”的作用总是被夸大，使得一个平衡的等边三角形变得不那么规范，所以，我就在这里强调一下流程。
 zhf_karen    [发表于 2005年7月22日 10:06:00 ]   [回复]  [引用] 
 zhf_karen    [发表于 2005年7月22日 12:59:48 ]   [回复]  [引用] 
 
OK,总算忙完了，开始说吧。
首先，我们必须承认，无论你使用何种流程，你的工作还是依赖于牛人。我不希望让流程为公司管理买单。我一般情况下，会花更多的精力在提高我团队成员的工作满意度身上，比如我一般会使用自己20-30%的时间用于沟通。来获取大家的不满，我在绩效考核的时候，都会询问大家由于我对于大家工作造成的损害是什么？并且把我的同仁对我提出要求，第一时间去满足。对于人员离开导致的损失，我不花太大的精力，人员离开，项目一定受到损失，我只是希望这个切换期最好在2周以内，我就满意了。不做更进一步的要求。
不是说有了一个好流程，公司不要能人就能发展。这……有点太看重自己的能力了吧，管理者首要的工作就是留住能干的人，和把他们放在能干的地方上。
所以，你的第一个观点：“直接的结果就是有了能人，项目就成功，企业就发达；没有了能人，项目就完蛋，企业也就衰退。”不是流程能够给你带来的。事实情况正是你要避免的。
其次，流程是一种经验的固化，可以相对比较快地把经验进行推广开。这就是流程的作用所在。我认可这一点。所以不要再和我说流程很重要了。
我们讨论的关键点是：流程和人谁是基本点？我认为人是基本。原因如下：
1 在一些相对沟通比较少，变化比较少的领域，比如流水线上的工作，流程的作用会大很多，但是对于一些变化大，而且下属对某件事情比你做得更好的情况下，流程能够发挥作用，但是不能发挥如此大的作用。
2 管理方面有缺乏管理，只看重人不看重流程是，凡事无规章无制度是就是无管理；一种是有效管理；一种是过度管理。至少在IT行业中，60%的公司游离在无管理上，30%的公司是过度管理，真正有效管理的公司，我非常少看见。过度强调流程，迷信流程为你带来的价值的同时，请小心滑向过度管理。比如我认为，给面试官5个问题，要他问3个，再问一个其他问题就是一个典型的过度管理。理由很简单，面试是需要经验和技巧的，我不会让一个没有充分经验的人去面试，任何这种辅助他的流程对于我没有太多用处；如果我来作，我只是会定一个表格，无论你用什么问题，我需要了解这个人员的某些特制，举一个例子来说，我希望知道某一个工程师在压力下的反应能力，记忆能力和逻辑是否清晰，一般我们会建议说连续问8-10个问题（有内在逻辑），并且在他回答问题的时候，插话问一些其他问题，看他清晰的思路能够维持到什么地方。当然，也有人不喜欢用这个，喜欢对别人自豪的强项点加以攻击，或者设计问题，让他处于两难境地，来获取同样的结论。一般我们只是在交流经验过程中交流而已，并不定规范。我们只是需要不管你用什么手段，方法，最后需要给我一份表格，填写完毕即可。至于这个人干得好不好，很简单，你招聘进来的人，如果绩效不高，那么你的能力就成问题。当然了，相同的面试人员，相同的岗位，他的问题中30-40%是相同的，但是这不是我们的规定，这是每个人自己的选择，比如我的一个同事就喜欢让面试者处于压力下，对于某些高级岗位的面试，他会当场给这个人的过去上级打电话。从而增加很多压力。当然我不喜欢，我喜欢问多个问题。你企图通过这种面试方法设计，使得谁都可以面试，是不恰当了，如果面试人员很忙，或者今天请假，我就停止面试。晚1-2天到岗不是问题，但是到岗一个垃圾，就惨了。很简单，不是吗？某些工作不是经过流程简单培训就可以做的，如果是那样，还要高级人才干什么？
我的结论是：针对不同团队，考虑你的流程。Jiajin，你做的日本软件的外包，我有不少朋友就是做这一块，我可以很认真地告诉你，你使用CMM或者CMMI是正确的，因为本来他就是为这块领域做的。但是，对于变化快速的实际商业环境，他并不完全适合（当然他还是有很多借鉴价值的）
另外，我说一个例子，做为我对这个问题的一个结尾。我认识一批MS的朋友们，和他们沟通项目经理的作用的时候，问他们是如何做的。MS的哥们很认真地告诉我：我们也要做文档，比如Spec，比如HLD，比如meeting minutes等等，但是我们实际上没有你们做得那么复杂。我们认为研发人员，测试人员最清楚他们要做什么和如何做，所以PM对于这块介入很少，基本上控制住CR就OK，研发和测试Leader对一下就可以了。当然如果是跨国团队开发，流程会更严谨一些，但是如果在一个区域，没有你们想像得那么流程化！
当然我的意思并不是说MS很牛，所以他说什么都是对的，但是我欣赏MS的一个做法，我们企图找优秀的人，这样管理成本就可以下降。所以，至少我本人不企图使用流程来化解部门管理上的责任。
流程用来辅助，流程不是目的。流程不能构造软件。不要给自己背负太大的不是你承担的责任。比如由于工资低廉，人员大量流失，然后造成软件长期成本提高，然后追求让开发人员可以随时互换的做法。这……不会吧……如果是那样，还不如从第一天，我就结队编码好了。用什么复杂流程啊……累。
我希望我说明白了，我的意思仅仅是：
使用流程固化经验，规范优秀做法；但是Base是我们的人！
流程不能解决很多问题，唯一能够解决问题的是人！
我们现在不是对人过多关注，而是过少关注！（举一个例子，你的直接下属多少人，你对他们进行绩效考核填写的时候，他们的评语部分你考虑了多少？你知道他们会花多少时间去反复阅读你写的东西吗？你知道你的手下，他们的个人期望是什么？他们希望成为什么人吗？你知道他们认为你哪些地方上妨碍了他们的工作了吗？）多关注关注人，很多事情就会变得简单。
最后一句话：IT行业中，有一句名言：实际上我们目前真正管理别人，我们只是企图让别人自己管理自己而已。
我希望以上这些东西，分清楚了我们之间5%的不同。OK？再说一次，不要再告诉我流程重要，我知道这一点。但是只是我们在碰到5%的冲突的时候，我们的Base点不一样而已。我相信，我另外的95%的工作，会和你做得一样。
 jiajin    [发表于 2005年7月22日 13:00:45 ]   [回复]  [引用] 
 
现在我们公司正在做CMM/L5 -> CMMi/L5，所以，请来了CMMi的咨询顾问。我就流成和人这个观点又和这个顾问进行了讨论，现在把讨论的一些结论总结一下，供大家参考。

咨询顾问：持续的过程改进是必须由领导力和执行力来支撑的，而这两个要素都是人的要素，不是流程的，所以，人更重要一些。举例：GE和摩托罗拉都实行6 Sigame，但是GE就成功，摩托罗拉就没有那么成功，原因就在于GE的领导，特别是CEO，有着极大的领导力和执行力。

Jia Jin：同意领导力和执行力是支撑过程改进的关键，但是，有没有流程来保证公司有足够的领导力/执行力更是关键。如果觉得这两个因素重要，那么，在招聘高层或是提拔员工的时候，就需要有一定的流程确保招进来的人或是提拔的人都具有足够的领导力或执行力。GE的招聘和培训体系比摩托罗拉的优秀，确保了像威尔奇这样的人可以顺利的走道前台。如果摩托罗拉仅仅觉得觉得自己输在没有威尔奇这么个一个人上，还不让研究如果培养更多的“威尔奇”呢。流程是人在执行的，所以，也许可以得出人更重要这么一个结论，但是保证人在执行流程的这个流程才是最重要的。（对不起，像绕口令）。

有人说流程是人制定的，所以，人重要。这个观点我同意，就像美国的独立宣言和第一部宪法，是美国的开国元老们写的，所以，这些人很重要，但是一旦行成了法律，这些人也就必须接受法律的约束。这个时候，法律就比人重要了。

最早的刘成一定是人制定的，所以，人很重要。但是，流成形成了，对流层的改进/优化/创新，就比人重要了。

顺便说一句，你所说的设计技术题目，我们也干，但是我们是用在笔试上，那时候，我根本不安排面试官，因为笔试题目对于所有的人都是一样的（当然，你搞几套卷子也可以）。
另外，cicime，对不起，我不很愿意做这套问卷，我在最近5年中，几乎每年填写4-5套（都是一些朋友的朋友的朋友的邻居，让我填写的），最早的一份是CMM在中国的应用。当时还认真填写了。但是现在实在没有太大的动力去填写这些东西了。反正我也不会认真填写，那么这种问卷对你价值也不大。我不填写也罢。对不起。
呵呵，我的这种态度也可以说明流程推进中的一个问题，好好想想，我们的流程到底管理了什么？和多少人愿意和有能力，有成本执行我们的流程。当然，这和这个话题无关，只是随口说起而已。 

 zhf_karen    [发表于 2005年7月22日 13:32:12 ]   [回复]  [引用] 
JiaJin：
对不起，看来你还是没有理解我们分岐点是什么？不是说人重要就是可以不执行流程。而是说，流程无法达到你期望的效果而已。
两个是不可偏废的两点，但是，我看你们的流程的认同有点过火了。
你的观点是：用流程来降低人的作用，改进从流程入手，是基本点；
我的观点是：流程作用并不是你想想的那么大，企业（软件）就是要依靠牛人做起来的，不管你用什么流程都是一样，无管理很成问题，但是过度管理也同样是问题，你们招聘流程中的内容，基本上是典型的过度管理。不要企图用流程问题，解决管理问题。这只是在一定层面上有效。但远远不是所有层面有效的。
唉，不说了，不说了。真累，讨论了这么长时间，还要说明分岐点是什么。真累。如果你希望说明你的观点，请就前面的话题继续下去，比如说明为什么通过这样的招聘流程，就可以提高招聘的成功率？
你这么一个回帖，又用别人的口，把你以前的观点说一遍，没有更多的深入，让我感觉简直不知道该如何说起了。当然，流程很重要，人也很重要，然后你好，我好，大家好。那有什么意义啊？我不如一定“顶”就可以了。
不说了，不说了，感觉很无奈 
 jiajin    [发表于 2005年7月22日 13:50:54 ]   [回复]  [引用] 
 
我想我明白我和 zhf_karen 之间的5%的意见不同在什么地方。
我更多的关注在流程，而这个流程不仅仅是项目上的流程，我想将之融入到公司的运营/管理/策略制订中去。

所以，我的意见在很多人看来都特别的虚，就像Karen两次问我，在一个快速多变的项目环境中，如何来用这些流程呢？当时我都没有回答。因为，这个问题是一个个例，如何做，我需要更多的资料才好回答。

忘了是谁，一个质量大师说，不要责怪人，去责怪流程。所以，如Karen所说，“你招聘进来的人，如果绩效不高，那么你的能力就成问题。”这个观点我就不同意。也许现象的表面就是面试人员水平低，但是除了你把这个人骂一边，扣他的工资以外，还可以做些什么呢？其实，所有的问题如果都能过触发一个过程的改进，那么这样的企业就是充满了生命的，因为这样的企业真的是一天一新。

“某些工作不是经过流程简单培训就可以做的，如果是那样，还要高级人才干什么？”
我眼中的高级人才是真正的可以理解流程，改进流程的那些人，是可以把尽量多的复杂工作简单化，简单工作标准化，标准工作流程化的那些人，这样的人需要对企业有充分的理解，对企业的未来有清晰的Vision，还需要清楚自己企业所处的竞争环境，而不仅仅是做过多少的项目，负责过多大的团队，因为这还是属于技术人员的行列，这样的人员在市场上还是相对容易找到的。

我个人主要是做日本方面外包项目的，当然我们公司里，欧美项目也有，国内项目也有。欧美项目上更多的是那种快速多变的项目，国内的项目也是，但是，我们在实施CMM也好，现在的CMMi也好，没有局限在每一个项目上都要求严格按照一个不变的模式运行，每一个项目都按照各自的项目特点在不同程度上制定着适合自己的流程。比如，日本项目上，在单体测试中出现的defect我们要求都log下来，向用户汇报，但是所有的欧美项目/国内项目把这个地方都采剪掉了。我想说的是，通过CMM的实施，我们更想达到的是让员工可以改变Mind set，知道流程是可以无限改进的，流程对每个人的工作是有帮助的。这样，才会不拘泥于流程，也不会对流程的实施有抵触。而作为一个高级人才（好像有点给自己脸上贴金的感觉，对不起），从另一个视点看问题，有的时候可以看到一些平时自己看不到的东西。

最后，关于面试，其实Karen所说的那种对反应能力的测试，我们公司也有，只是放在最后一轮面试作。最后一轮的面试官都是经理一级的，主要是侧重soft skill方面。（因为technical skill在第一轮作）。我们用的是Performance Factor interview方法，就是通过总结公司的一些优秀员工，找出他们的Performance factor，然后针对这些factors,设计一些问题来观察应聘者是否具有这样的factors。
 jiajin    [发表于 2005年7月22日 14:01:56 ]   [回复]  [引用] 
 
 同意，同意。

既然我们的观点都表述得清楚了，就可以停止了。

让大家看了我们的这些讨论，去发表意见吧。

各家企业不同，项目情况也不同，如果我们的这些讨论对其他人有一点帮助的话，也就算很有意义了。

谢谢讨论，Karen。
 zhf_karen    [发表于 2005年7月22日 14:31:08 ]   [回复]  [引用] 
 
呵呵，这样就OK了，我们可以就此进一步讨论了。但是，有一个问题，你的结论是什么？我不太清楚一点。
我无的放矢，所以就再多说一些好了。是对以前的一些补充，我的观点没有改变。只是增加一些对你上面的意见的感受而已。
的确，流程，计划在我们现在的社会中，做出来就是要准备改的。这一点我赞同，而且，你说你们欧美的团队，我就多少感觉有点熟悉了，的确我不相信一个公司真的一个模子套一切，管理上“千人一面”是一个初步的管理者最容易犯错的地方。
尽量使得复杂工作简单化，简单工作标准化；的确，我们很多管理者都在这么做，比如以前我们用汇编，现在很少有人用了吧，基本上由机器完成即可了。但是这样的工作方式，有一个前提，就是环境变化比较慢。管理学上，把环境分成4种，根据需要决策的快速程度，根据决策的后果严重，分为4个区域。很不幸，我们就是处于需要决策速度很快，而且决策后果比较严重的领域。所以，事实上没有那么多东西，你有时间或者有精力，有足够的成本来简单化和标准化。这时候，牛人的作用就体现出来了。比如大型High load，和高可用性的软件的设计，恐怕不是什么流程能够解决的。我们可以整理出来经验和教训，但是无法给你一个流程，说你如何如何设计，就离开成功更近一些了（而且，事实上，我不放心。我们更常用的一种做法是，让一个牛人带一个小组去做，然后让这个小组在合作过程中得到成长。而不是依靠什么流程来保证的）。

你在这里说了市场上的东西，OK，我们就说进入一个新行业为例子吧，一般我们会做竞争模型分析，会做SWOT分析，会做三年现金流分析，会做业务环分析，会做投资回报期分析等等。这些步骤就是流程，但是通过这些流程，我们无法确定自己做的是对的；事实上，缺乏经验和商业知识的人员，我们期待与他的估算能够在数量级以内，就算OK了。

还是老话，在制定流程，推广流程的时候，在你看见他好处的同时，要时时记住他的弱点：他将使得组织缺乏弹性（虽然很多理论告诉你不会的，但是我没有看见过一个实例），同时我赞成这样的观点：牛人造就公司。流程可以复制，但是，牛人不可复制。而且高级人才的范围远远不是能够改进流程和制定流程的人。这样的人太多了，SQA就能，但是我从来不认为中国99%的SQA是牛人。呵呵，我觉得牛人很简单：就是把业绩带上去的人；没有那么多条条框框的，业绩说明一切！如果一个人公司业绩很高，就是牛人。否则就不是。当然这一点很多人感觉是一种无政府主义，我也认同，这只是我本人喜欢简单的标准和简单的事情而已。
另外我们讨论面试，并不是说哪一个环节更重要，或者缺少了哪个环节，而只是说，我不赞同在流程中，给面试官以各种事先设计好的问题，认为这样可以降低面试官的能力要求。如果真的设计得那么好，那就让面试者做笔试题目就是了，还面试个什么啊。浪费成本呢。既然要面试官，就是要他的经验。仅此而已。所以，你需要证明的是：通过这种设计题目的做法，你们的面试满意度提高了很多，并且证明，为什么通过设计题目的做法，可以降低对面试官的技能要求？这一点我不太明白。
呵呵，对不起，我得干活了。改天再说了……
Jiajin：我想我们之间的讨论，对于很多人，包括你，我都会有很多收获。
呵呵，改天见！
 jiajin    [发表于 2005年7月24日 17:46:19 ]   [回复]  [引用] 
 
我很同意你说的“牛人”在项目中起到的关键作用，其实，我自己现在的这个60多人的项目中就有这么一个牛人，还是我们从别的别的公司专门为这个项目挖过来的。

但是，我想的是，有了这么一个牛人，我的项目确实挺顺利的，但是，别的人，在作开发团队大一些的项目上同样会碰到我想在遇到的一些问题，所以，我觉得今后外包项目中，如果开发团队超过了一定的人数，比如30个人，就需要一个对技术/系统式样/开发技巧都很精通的人，但是这个人不会出现在Workplan上，是Technical support那种角色。我的这个建议已经通过SQA作为best practice报到了公司的SEPG（Software engineering process group），希望今后可以融入到公司级的流程中。

其实，几乎所有的PM都是在这么做，但是，我还是希望这些东西可以作为流程的一部分，今后，无论什么样经验的PM来做项目，都可以顺利的做项目，这不就是把人的因素减少了一些，而流程在起作用了吗？

还有，Karen说的那种快速多变的项目，也许经过分析，就是只有“牛人”在可以完成，其实，这样的结论也可以上升到组织级的流程资产中啊。如果能分析出什么样的项目特点，就需要由有什么样经验的人来做，否则就是Risk，这样的东西也是对公司很有意义的。而今后，如果不是Karen，而是一个比Karen经验差很多的人来做PM，根据这些流程，如果是一个快速多变的项目，但是又没有符合要求的团队，这样，这个PM就可以非常容易的识别出Risk，这样也可以早些准备规避的方法。（比如，通知HR到别的公司挖人，找Contracotor，或者，如果是在风险大，干脆就外包，把这个high risk的项目转嫁掉。）

你看，这样的话，项目管理就变得规范，有章可循，PM就可以有更多的时间去解决其他的重要的事情。

最后，关于“高级人才的范围远远不是能够改进流程和制定流程的人。这样的人太多了，SQA就能，”这个观点，我基本上完全不同意，国内很多公司过了CMM/CMMi五级，但是，其实水平一般，关键就是没有高层的介入，把过程的制定和改进完全交给了SEPG和SQA，而这些SEPG和SQA成员又不能站在CEO的角度上，通过VOB/VOC（Voice of business/Voice of customer）来驱动过程的制定和改进，仅仅是为了过级，这样才会发生你说的那种流程变得坚硬/死板。

流程应该是活的，充满生机的，不停的根据商业环境和公司的能力而改变。

我有一点感觉，也许Karen把流程(Process)和过程(Procedure)混在一起了。
 zhf_karen    [发表于 2005年7月24日 22:15:11 ]   [回复]  [引用] 
 
呵呵，jiajin，你对于高级人才的认可太管理至上了。呵呵，实际上，现在市场上的认可情况并非如此。我和不少猎头公司（至少5家以上，他们几乎每天都会用Mail告知我有什么岗位需要人员，薪资情况和技能要求，软性技能是什么。在过去的两年中，我推荐了几个个高级人才给猎头公司，不是那种年薪30-50万的普通人才，而是70-100万Base年薪的比较高级的人才。所以我也明确知道我还不属于高级人才，因为他们具备的某些素质正是我缺乏的）的人员有5年多的交往，对于市场上需要的高级人才是什么，我相对来说还是知道一些的。他们并不存在你说的特质。
如果将来可能，我可以在另外一个话题中，我可以列出这些高级人才所具备的共同的特质，和公司的期望是什么，他和你所说的高级人才的特质相差甚远。

对不起，我用词上的不规范，导致了我们的讨论可能出现一些误会，这一点我以后注意一些。

我们来探讨一下几个关键问题：
首先：过程在什么情况下是有效的？我前面已经说过了，是在规范性较强，变化较少的环节下是有效的。所以生产线就是这种思路的概念。但是，软件并不是这样，因为从来没有公司或者个人需要两个相同需求的软件，所以，我们面临的永远是新的工作，当然其中部分内容是可以通过过程来落实和规范的，比如我们的SCM制度等等，就是如此。所以，我们的概念是：规范可能规范的，在规则之内发挥人员的效能。仅此而已。
其次，我们需要克服的两个极端的情况，第一认为一堆牛人就是成功的保证；远远不是如此，这一点我们看见的太多了；其次，认为通过过程保证，就可以使得新手也能开发出好软件。这是两个极端。是不现实的的极端。

国内并没有很多公司通过CMM5/CMMI，几乎是凤毛麟角。这一点CSDN上有过一次统计。我不想重复。另外，说CMM没有高层介入，这一点可能有些过于武断了，事实上，如果SEPG和SQA没有高层的辅助，他们的工作在公司中根本无法展开。这一点我不想展开说，这是一个基本的常识。
另外，我推荐一个帖子，你得空可以看看，看完这个帖子需要2小时的时间，不过还是值得看一看的，讨论的两方是CMM方面的专家（至少我到目前为止，看到的最好的CMM方面的专家，可惜还没有机会认识），以及敏捷方面的专家（我个人觉得，他们是中国敏捷最优秀的一批人），看看他们是如何讨论的。当然，我并不是意味着，要你认同敏捷，或者认同CMM，他们都不是银弹，都无法拯救软件。我只是希望你从他们的讨论中，看见一种平衡感，看见一种过程适用前提的讨论。这是我在这三个月来看见的最好的帖子，我相信我不会令你白白浪费时间。
任何管理都是需要平衡的，世界上没有一种管理在强化规范的同时，还能推进灵活性的，这在战略管理上，如果两者都要，就是陷入什么都没有的境地。这是战略管理的一个基本观点。也许你是那样认为，我们的流程的确根据外部环境在变化啊。问题不是说别人的流程就不变化，而是说，复杂定义的流程和万事流程定义的方式，将使得响应速度变慢，和组织僵化。这基本上是管理上的一个公论，我将来如果有时间，可以把IBM和联想的不同管理方式Share出来，看看柔性管理和刚性管理各自的特点是什么，他们的劣势是什么“我们是活的流程，充满生机的流程，不停地根据商业环节和公司能力而变化的。“呵呵，这句话不象一个高级管理者说的话，太孩子气了！商业就是商业，组织就是组织，不是我们说我们的流程能够变化就自然变化了。不然哪里还有什么刚性文化和柔性文化啊，谁不知道拥有活的流程，充满柔性的刚性文化是最诱人的？呵呵。没有其他意思，也许你只是太想表达流程柔性的一面了。呵呵。

做为结论吧……
既然我们也已经认识到了流程的作用，人员的作用，我觉得我们的接近点越来越多了。
我并非想否认过程的作用，我也不想否认规范的作用，事实上，在一个管理者从管理10以下的团队上升到管理20人以上的团队，我们建议第一个下手的地方就是流程。因为我们也清楚流程的作用。
我只是不喜欢赋予一个过程如此多的东西而已。比如，你所说的，我们分析出来什么特点的项目，需要什么经验的人来做，否则就是Risk，这一点很好。但是你如何做？呵呵？我也希望如此做，但是难以下手，主要是难以获取数据，难以分析数据，难以辨别幸运还是真实有效，难以操作和难以落实在过程中。至少我们认同，经验集不是过程吧。过程是要用来操作的。

呵呵，我以前和一个朋友聊过，IT经常有一些夸张的愚蠢现象，管理学方面同样也是一个愚蠢辈出的领域，两者结合起来以后，就出现了令人难以置信的愚蠢。我们经常犯的一个错误，就是在一个本来就没有猫的地方，大家摸黑抓猫，一堆人号称抓住了猫。当然，我也是愚蠢者的一员。
呵呵，我对于这个话题感觉有点累了（因为我们一直在很虚地讨论，没有落在实际的点上，这样的讨论更象文字游戏了），这样吧，太长的帖子不便于大家浏览，如果大家有兴趣，可以开一个新的帖子，对一个典型的项目中的典型过程，可以进行一个讨论，哪些过程可以定义，如何定义，对于这个过程风险是什么？我们推进这个过程对于避免风险起到了什么样的作用？我们付出了什么成本？我们将采用什么手段来更新流程？等等，我想，这种经验的也许会对论坛中的很多新手项目经理有用的。而且我们的讨论也可以更落在实实在在的地方上。
jiajin：后面是那个链接……如果得空可以看看。我感觉自己有点老了，开始推荐别人看书了，恩，大概吧……
http://www.javaeye.com/viewtopic.php?t=9459

呵呵。