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

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

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

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

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

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

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

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

谢谢讨论，Karen。

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

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

但是，我想的是，有了这么一个牛人，我的项目确实挺顺利的，但是，别的人，在作开发团队大一些的项目上同样会碰到我想在遇到的一些问题，所以，我觉得今后外包项目中，如果开发团队超过了一定的人数，比如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)混在一起了。

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

我们来探讨一下几个关键问题：
首先：过程在什么情况下是有效的？我前面已经说过了，是在规范性较强，变化较少的环节下是有效的。所以生产线就是这种思路的概念。但是，软件并不是这样，因为从来没有公司或者个人需要两个相同需求的软件，所以，我们面临的永远是新的工作，当然其中部分内容是可以通过过程来落实和规范的，比如我们的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

呵呵。