写在周日的凌晨

一次思维的对话

sunshineormer@msn.com

孙向晖

看看时间,已经是周日了,也就是说,作为周六,昨天已经过去了。

昨天,开例会的时候,跟人吵架了。原因很简单,因为大家都是牛人 ^*_*^。

这确实不是我的初衷,我相信也不是他的初衷。引发争吵的根本原因,是因为大家思维之间存在分歧。(呵呵,象是废话,但是,我现在特想做的,就是分析一下这种分歧以及产生的原因)。

受了这么多年的教育,大道理,每个人都会说出一堆来:"发现问题,分析问题,解决问题","思想比工具重要","国外来的东西,不符合中国国情"。。。等等等。当这样的大道理挂在嘴边上,往往,直接影响我们对问题本质的思考。

昨天会议结束前,孟项目让大家谈谈对"团队文化建设"的意见和建议,于是,一个剑拔弩张的局面彻底得到了转变,足足变成一个"务虚会"。这的确是转移目标的一种好的策略,问题是:在这样的中庸思想的指导下,我们的问题被隐藏下来了。它没有被很好的消除和解决。甚至,我们的问题被加剧,有可能产生一个质变。

跟田相兄交流的时候,他给了我很多的忠告。按照他的方法,我把自己的思路从头开始整理一下。问话的人是一个假象者,好像它对当时的情况很了解。答话的是我,一个争吵的一方。我相信,作为争吵的另一方,他肯定也会有话说,但是我不知道他会说什么。

"为什么要发怒的?"

"因为他不懂装懂,站出来指责我们的工作,并试图指导我们的工作,并且在我们的工作内容中,加了很多项目管理的内容。这不属于我们的职责范围"。

"哦,我有三个问题问你。问题1:你为什么说他不懂装懂?"

"因为他说我们迭代小组应该不关心业务的内容,不应该深扣业务,而应该出一个详细的工作指南并配合一个详细的例子"。

"这有什么问题吗?"

"有,我们是迭代小组,按照迭代的含义,我们实现的必须是真实系统的一部分,如果我们不真正的去实践,是无法进行rup过程的裁减,其实裁减不裁减没有太大的关系，如果我们有时间和经历，完全实践RUP也是完全可以的。关键是,项目要求，我们要让v3项目组的所有成员有一个可以执行的标准,这个标准应该是对我们项目中常见问题的最有效的解决方案,我们迭代小组遇到的问题,也基本会是其他小组在工作时遇到的。 按照他说的,根本就是一个原型小组应该做的,原型是螺旋声明周期模型的最重要特定,而我们是迭代小组"。

"你说的迭代的含义以及与螺旋模型的不同他们是否知晓?"

"知道一点,我曾经给他们讲过 瀑布,螺旋,迭代的生命周期模型,特点,优点,缺点"

"他们怎么说?”

“他们说太理论了,他们希望我在培训的时候,能够直奔主题,告诉他们用例应该分几步写,怎么写才精确"。

"你是怎么做的?"

"上午想让大家达成共识,下午用实际的例子做的讲解,现在看效果还是不太好,上午讲课时,大家以为这样的大道理大家都懂,不用听都行。"

"看来你需要在培训内容上多下工夫"

"是啊。但是我还有一个问题,就是我们是不是对培训寄予了过多的希望?"

"为什么这么说?"

"培训是很有作用,但是,不应该在项目中有太多的培训，也不要期望培训能解决一切问题，因为培训的效果，往往更取决于参与培训的人的因素。成功的项目团队,通常不这样做。他们通常的做法是,启动一个项目,然后列出需要的人员技能,然后,在项目可以控制的范围中,找到具有这样技能的人,而不是在项目进行中培训新人。在他们看来,培训的最终目的,是让大家达成共识,而这个共识,不可能来源于对问题有着参差不齐的认知的人，即使我们通过努力能够达成局部的共识，但这样的努力通常是不值得的。"

"你不觉得这不符合中国国情吗?"

"不,正是因为有这样的想法,所以我们永远不能进步。"

"但这是现实的问题啊"

"我没说不是,但是如果我们不迈出第一步,只是坐在那里跟国外比较差距是没有任何意义的。找借口永远是解决不了问题的，不要让借口成为我们前进的有效阻力"。

"你感觉这第一步应该怎么走?"

"总结我们以往项目中需要的技能,提前做培训；对于新的项目,不急于启动,而是先统一思路。这个统一思路,不是几个人坐在家里冥思苦想,应该是广泛讨论一下,我们的人员,水平,技能离项目成功有多大差距；对于已经进行的项目,在出现问题时,先整理哪些是由于人的准备不足引起的,对这样的不足及时调整"

"等等,你说人的准备不足?这是什么意思"。

"准备模型（readyness） 。 这是微软MSF 框架中一个非常重要的模型。 对不起,这样说下去会跑题的,我们先打住吧。"

"哦,我有点脸红了,呵呵。在开始第2个问题前,你可以对第一个问题做个什么样的总结?"

"项目中进行培训,有点为时过晚,而且效果并不明显;还有就是即使做了培训,也应该注意培训的质量,要注意理论必须联系实践;另外,参加培训的人,无论你认为你有多牛,都不要感觉自己什么都懂了,一个满的杯子是放不下其他东西。另外，理论是指导实践的最有力武器。"

"好的。那么我们来看第2个问题。问题2:你说 ‘指责并试图指导’ 但是很多人认为这是对你们提意见,没有你说的那么严重"。

"哦,这样的问题,主要来源于责任和标准的问题。首先,他发言的出发点是,他对我们小组的责任是不明了的,他认为我们是原型小组。关于他提到的里程碑和过程模型,不是由我们小组能够左右的,我们是在项目管理者的指令下工作的,而且我们的工作是从需求分析开始切入的。对于从需求分析以后的过程,我们是走通了的,对于需求分析阶段前面的工作和制品 (artifact),我们只能说它离我们的要求有多远。我们只能提意见并极力推动改善,采纳与否,是项目管理的范畴。"

"那也不是指责啊"

"你可以这么说,但是,如果在没有对问题达成共识的前提下,所提的意见往往就是指责。因为这是由于你自己的原因,而对别人工作的一种变相的否定。这其实是一件很严重的事情。"。

"你们小组不是也对前面的工作提出否定了吗?这样会让大家很不高兴"

"呵呵,前提是不一样的,我们的项目是要求保证质量的,并且我们小组也有责任对前一阶段的工作缺陷提出要求的。我们不是要打击大家的工作兴致,而是告诉大家,前面还有什么泥潭（风险）,我们必须规避,性质是两样的。至于你说的让大家不高兴,我想,这是我们的职责所在。"

"你总是好像很有道理啊"

"这真是工作要求,不是强辞夺理"

"那好,把你的依据拿出来给大家看看。"

"项目启动时,对小组有明确的分工和职责要求。这其实也引发了我说的标准的问题"

"什么标准的问题?"

"这个职责分工要求,是不是做为我们工作的标准?大家对这个标准是否有不同的理解?按照这个标准,我们小组负责指定出的标准,有我们自己的工作步骤,这个步骤,是我们小组来制定的,欢迎大家提出意见,但是,前提是你对我们的工作内容要熟悉;我们小组负责出的制品,如果在你的应用中,遇到问题,可以提出问题所在,我们小组负责修改标准,以满足你的要求。 但是,仅限于对标准中对你以为遗漏的问题进行修改。否则,这个标准是没有权威性的。因而也是没有意义的。如果谁感觉对这样标准制定工作感兴趣，并有足够的准备，敢于承担责任，可以向项目管理者提出加入这个小组，并根据问题，提出解决办法。中国软件业不缺乏牛人，中国软件业缺乏的是默契的团队；中国软件业不缺乏标准，中国软件业缺乏的是切实有效的标准，缺乏的是对标准的认同和执行。每个牛人都想制定带有“X特色的”标准。"

"我对这个小组很感兴趣，呵呵。能再明确一下你们小组的职责吗?"

"我们小组负责制定标准,指导标准的实施,对标准的维护,对标准引发的失误负责,但不负担项目管理的责任。"

"那么,最后一个问题,问题3:让我们回头看看,问题的本质在哪里?"

"项目或者说团队文化中,对于培训的理解有误,对于学习没有积极主动性的,团队中的学习意识和学习内容太弱,职责和标准权威不明确。我们欢迎交流，但交流是有前提的。前提就是，你对交流的边界有明确的了解，并且对交流的内容有足够的准备。如果没有准备，又想交流，就请多学习。"。

"那是不是必须通过吵架的方式来解决?吵完架后会对问题有什么实质性的改变吗?"

"没有,我错了。。。"

“你还有什么其他要说的吗?”

"我引用一句约翰?冯?诺依曼的话--'如果你根本不知道自己在讨论什么，那么对其强求精确是毫无意义的。',这句话作为讨论或是探索的前提,是非常有意义的。"

“呵呵，我是想让你说点道歉的话。。。”

“对不起，各位同事。虽然争吵会让问题本质更明显的袒露，但是还是有更多的方式来发掘问题的。我会在今后的工作中，努力的改正自己的急脾气。我不会再拿脾气说事了。同时，感谢你给了我这么好的机会，说出自己的心理话，以及自己的歉意。”

草于2004年建军节凌晨

Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=58355