正规军的军规1

下面的文章是我转自我的老大Anderson的邮件，是对我们team一些问题的总结和经验分享。我里面有很多是可以拿出来与大家共享，所以得到作者的同意之后我把原文贴到了这里。

PS：文章取名《正规军的军规》是稍微有些戴帽子了，但是我当前所在的team是确实是我工作以后最正规的一个team，而且我觉得我们通过cmm5并严格执行的开发团队也可以称得上是正规军了，从项目启动到项目发布每个过程都是很严格的，而且在我们team里面要求的更加严格，我们在整个项目里面是质量最高bug最少的一个team。不过文章的内容很多地方也仅仅是我们team内部的一些经验的总结，不同的team应该有不同的军规。

<!----><!----><!---->  <!---->

编码人员的误区

误区一：因为任务紧迫，所以没有时间想

有些人认为只有在领导规定的时间内完成任务才是最重要和最紧急的。至于方向是否正确，功能是否完整则没有时间去考虑。

这些人陷入了多写些代码和程序就会安全了的假象当中。殊不知方向错了，跑得越快，损失越大。

抱有这种想法的根本原因在于他们的不自信，不知道如何分析问题，找出最佳解决途径和细致的评估影响面，因而无法向上级提出一个更加合理的时间。

例如： Bulk Address feature 的设计者也是说时间紧，没时间细想。后来的结果就是这个 feature 的 design 和代码被一次又一次的推翻和重做。而我们的 leader 也因为反复的向 Jerry Lu 解释上次做错了能否接受我们新的 Solution 而招致了 Jerry Lu 的反感。

 

误区二：在最后一刻告诉 Leader 代码写完就算开发任务完成了

这种人认为只要写完代码告诉 Team Leader ，自己就可以交差了。

如果做错了，大不了重做；

如果漏做了，大不了补做；

如果 bug 很多，大不了 fix bug ；

自己没考虑到，还有 Team Leader

例如：分配给做 Multi Agency admin 端 code owner 的开发时间原本是足够的。但是他写完代码后，只验证了最基本的增、删、改、查功能，主要的业务逻辑和其他的边边角角的功能都没有测试，直到上级规定完成时间的最后一刻他才对 Leader 说任务完成了。

这样做的严重后果有 2 个：

<!---->l  <!---->由于这个开发人员缺乏责任心，导致我们不得不花了比原计划多出 30% 以上的时间去补做和补测

<!---->l  <!---->开发人员没有意识到之前他的 Leader 对他的能力不太熟悉，所以给他的时间会比正常情况下多一些。只要发挥出正常能力和应有的责任心就可以提前完成任务。结果他不但没有完成任务，还浪费掉了预留给他的时间。这种情况下他的 Leader 对他能力的评估只会更差，同时也增加了 Leader 对他能力的不信任。

 

误区三：领导说得都是对的，我没意见

例如：一个 Leader 在给组员讲解需求和设计时，希望大家都能够提出自己问题和想法。有个组员就对这个 Leader 说你的分析设计能力比我强，工作经验比我丰富，你说的都对我能有什么意见。

发生这种现象时，开发人员和 Team leader 都有需要改进的地方。

开发人员这么说，有下列几种可能：

<!---->1）  <!---->他当时心情不好正在闹情绪，这时开发人员应当注意控制好自己的情绪

<!---->2）  <!---->他真的是全听懂了，只要回答“我全明白了”就好了

<!---->3）  <!---->绝大多数内容他没听懂，这时他可以回答“我暂时还不能完全理解你说的所有内容。我下来再仔细看看文档，估计 30 分钟后再来问你好吗？”

Team Leader 对于那些能力比较弱的人可以采取如下措施：

<!---->1）  <!---->给组员一些准备时间，在讲解前告诉他们着重看那部分内容。

<!---->2）  <!---->讲解完毕后，可以让组员讲出哪些分析点是他之前没有想到的，怎样分析才能够分析的比较全面。

<!---->3）  <!---->如果组员的分析能力实在太弱什么也讲不出来，我们还可以鼓励他们说出哪些内容他们没听明白。

这样一来，我们对组要的要求就可以做到因人而异，且比较具体化。同时我们要求的也是组员能够做得到的。 Team Leader 要学会 Case by Case 的教导组员如何逐步提高。

 

误区四：凡事都有 Team Leader 帮忙检查

例如：有一次 Hikelee 让一个组员给他写一封需要回复给客户的邮件。很快这个组员就告诉 Hikelee 写完了。

Hikelee 就问他说“我是否可以不做任何修改就可以把这份邮件直接发给 Anderson ？”这个组员回答说不能。 Hikelee 就让他拿回去参看以往 Hikelee 发出的类似邮件去改，直到达到这个标准后再发给过来。

过了一会这个组员又说写完了。这次 Hikelee 又问他，是不是 Anderson 也不需要做任何修改就可以把这份邮件直接发给我们的客户？组员回答说不能。 Hikelee 就对他说在去看看 Anderson 以往是怎么回复客户这类问题的，找到差别修改后再发给我。

 

误区五：只提出问题而不负责解决，解决问题是 leader 或 PM 的事

例如：有些组员会问，我们这个 release 的加班好像是比上个 release 少了一点点，但是说实话还是太多太频繁，我们能不能少加点班？

问话的组员只是提出了问题，却没有思考是不是有些必须要加班才能完成的任务自己也有责任 ? 有的话原因在哪里，你认为怎样做才能够减少或避免类似的加班？

经过我们的分析，导致这类加班我们自身的原因主要有：

<!---->1）  <!---->用人不当，由能力不足的人作分析设计导致设计失误太多，必须要花更多的时间检查和修补

<!---->2）  <!---->缺乏有效的分析设计技巧导致和业务领域知识，导致 Effort 估计不足

<!---->3）  <!---->编码和 UT 素质较差，需要成倍的时间进行修补和返工

<!---->4）  <!---->工作效率低导致在规定的时间内未能完成任务而加班

<!---->5）  <!---->工作方法不当，一些无谓的等待导致了加班

根据不同的原因我们可以采取不同的策略来处理。

 

误区六：整天写代码太单调太没劲

有的开发人员觉得自己整天都在写代码， fix bug 没劲。对上级布置的任务也太当回事，抱着应付差事的心态在做事，你布置一件我应付一件，你说怎么做我就怎么做，反正办好办坏都一样。

实际上我们应该认识到无论是谁，无论能力高低都必须做到让领导对自己所做的每一件工作满意，才有可能接受更高难度和更有挑战的工作，他的职务薪资也会随他所从事的工作难度的提高而逐步提高。

例如：以我为例，在转到 Accela 部门前就已经是 Team Leader 了。但是我还是被安排到从基本的编码开始，独自负责一个 Feature 。我把这种安排当作是一次对我的考验，尽自己最大的努力做好。结果这个 feature 做得很好，并且在做的过程中体现出了优秀的技术能力、学习能力、沟通协调能力和很高责任心和使命感，证明了我做 Team Leader 。因此在这个新的部门做回了 Team Leader 的职务。在做 Team Leader 的过程中，也是因为我所带领的 team 战斗力强，队员素质提高快而被提升为 PM 。

一个开发人员，只有在他的代码写的很好的情况下，才能够获得需求分析和设计工作；只有在需求分析和设计做得都很好的情况下，才能够做 feature owner ；只有在 feature owner 做得很好的情况下，才能够获做 Team Leader 。

 

误区七：工作既然交给我做就应该信任我

要知道“用人不疑，疑人不用”只是个结果而不是过程。我们每个人都必须经过严谨的考验后，才能够逐步的取得领导的信任。在完成任务的过程中，领导可以观察出我们的能力水平。以后安排那些在我们能力范围内的任务时，他就可以比较放心，投入较少的精力。相反如果他安排了超出我们能力范围外的工作时，他就必须要投入比较多的精力来监管。因此，信任不是绝对的。

如果我们想要取得领导的信任，就必须要尽我们最大的努力来做好领导安排的每一项工作，提高领导对我们能力水平的认识，做到事事让领导放心。

 

误区八：因为一些在 bug 描述中没有提到过得 issue ， QA reopen 我们 bug 是不对的

例如：有这样一个 bug ， QA 只描述了在 Create Portlet 里有问题。后来 QA 在验证 bug 时发现开发人员只 fix 掉了 Create Portlet 里的问题， Search Portlet 也有同样的问题但没被 fix 掉，因此 reopen 了该 bug 。

开发人员就说“不对， QA 你没有提到过 Search Portlet 也有问题，这个 bug 不该被 reopen ，你应该提一个新的 Search Portlet bug 。”

这种思想是错误的，原因如下：

<!---->1）  <!---->不要急着先说人家 Reopen 不对，首先自己要先核实 Search Portlet 里的 bug 和 Create Portlet 的 bug 是否无关。如果确实无关再耐心的和 QA 解释为什么应该提一个新的 bug

<!---->2）  <!---->但是无论如何出现这种状况，我们的开发人员自身也有问题。他们不了解， fix bug 不是头痛医头，脚痛医脚。我们首先要找到 bug 的成因，然后分析这个 bug 成因的潜在影响面，最后彻底的 fix 掉这个 bug 。另外， bug 有个扎堆的原理，当你发现一个地方有 bug 时，往往周围出现 bug 的几率就会比较高。所以我们一定要在这个 bug 的周围多做一些测试。

<!---->3）  <!---->不懂的只有高标准严要求，才能激励自己更快更好的发展。

<!---->4）  <!---->这种工作人员的工作心态也有问题，错了就是错了，不要对自己的错误做过多的辩解。知道自己错误，错在哪里，然后下次能够改进就好了。因此我们需要及时的调整好自己的心态。

 

误区九：上班时浏览技术网站学习新的技术没有问题

我们不反对组员学习新的知识。但是应当是在自己当天的任务已经完成的前提下。如果研究的内容与我们的工作有关，我们还会鼓励。

例如：为了提高 fix bug 的效率我们要求在 Fix bug 阶段，确认一个不能重现的 bug 最多不能超过 2 个小时。这个规定早上刚刚讲完，我们就发现有个组员确认了 2 个不能重新的 bug 后，就去上网学习新技术去了。

 

Team Leader 的误区

误区一：处理客户问题和处理一般开发任务没有区别

有些 Team Leader 或 Feature Owner 认为，处理客户问题和处理一般开发任务一样，都是把代码写完并完成 UT 就好了。

例如：有个组员在处理 Andrew D 要求增加实现 Filter Service 功能时，代码做完了就报告给 PM 说任务完成了。他忽略了 Andrew 提出这个要求的目的是为了在 IST 站点上给他的客户进行 Demo 。

因此我们不仅需要在 QA 和开发站点上测试，还需要在 IST 站点上更新和部署相关的代码和配置 (EMSE Script) 以验证 Andrew 不需要做任何配置就可以看到这个新的功能。最后在 IST 站点上也验证通过后，还要回复 Andrew 一封邮件，告知他问题已经解决。

 

误区二：任务分配出去后 Owner 有问题就来找我，但是我很忙没时间找他

Leader 要对自己管辖所有 Feature 心里没数，在分配给组员去做之前能够预见到可能出现的风险，提前告知 Owner 预防风险或者密切观察 Owner 是否能够自己发现和规避分风险。如果问题出现了，我们要帮助组员认识到导致问题的原因是什么，哪些方面的能力和技巧他需要学习和改进。

平时也要多和组员沟通，不要误认为组员不来问我就代表没事。

例如： Hikelee 自己在做 Dynamic Web Service feature 的 Expression 部分，就把 Bulk Address 和 Alter ID Mask feature 分给了他的 2 个组员去负责，中间几乎很少过问和检查 feature 的状态。结果两个 feature 双双都出了问题。

 

误区三：工作态度好，工作年限多的就可以做 Feature Owner

不是只要工作态度好，工作年限多或者希望当 Feature Owner 的人就可以做 Feature Owner 。这个问题的本质是用人要当量才而用。例如，有的人做事认真，但是面向对象的分析和设计能力较弱，就不能安排他去做分析设计工作；有的人分析能力较强，但是考虑问题不周做事常做一半，处事和沟通技巧欠佳，就不能安排做 Team Leader 。

 

 <!---->

评论

40 楼 jili 2008-12-22  

ozzzzzz 写道

才看了两点就发现两个大问题，其他的就以后在看吧。
第一，是不是会想，不完全是时间紧张不紧张问题，而完全是你们的组织和方法要求的问题，这很少与开发者自身有关。很多时候，一些企业希望把底层人员放在一个隔间里面叫他们完成自己的工作，而不叫他们相互交流。你在那边没见过这样的企业吗？反正国内是很多。在这中企业中不鼓励大家思考自己小隔断以外的事情，而且他们的所作所为完全是被规定好的没有半点商量的。
而且越是这样的企业，通过cmm高级评估的可能性越是大，而且在某些人看来只有这样才是正规军。不过确实他们也想军队，因为他们不需要有脑子。
当指挥员发出冲锋指令之后，战士们玩命快跑是应该的。他们究竟应该跑向什么方向，应该是指挥员负责的事情。
当然如果你的企业没军事化喜好，是另外一个问题。
而这个时候，就不应该有什么时间紧的问题。因为你既然叫别人对某些事情负责，就该给他们相应的资源。

第二点就不是人是的问题，而是你们实施方法的问题。
一个开发者的进度情况，不应该是依靠他们自己主动的汇报，而应该是依靠leader主动搜集。搜集有各种不同的方法，不断的去询问是一种低级的做法。依靠scm等系统自动的获得数据才是应该追求的。

其实从这两个地方看，所谓的agile跟cmmi的结合就是概念罢了。当然我的这些发言完全是针对Anderson说的。楼主自己没什么问题。

我认为，任何问题，人和制度都有影响，实际上，这两个因素是互相作用的，很难有单纯化的问题。
第一点来说：把事情事先“想”清楚，其实是个很技术性的活，就软件开发来说，需求、架构、设计和代码如果说要能思考全面，并能侵袭的表达表达出来让大家都能理解，其实是需要通过一些公认的方式方法来的，这些方式方法都是需要靠天赋、花费很多学习成本，并通过大量工作经验支持，不是任何人有时间就能做到的。我所任职过的it公司，算不上是业内顶尖，但也不算最差，但一个团队中有这种能力的人也不多。所以在我的过程改进经验中，过程管理人员凭一己之力可以很快改进很多东西，但团队人员素质所形成的瓶颈是无法“巧妙”解决的，反而有时要通过调整过程来迁就这些瓶颈，至于人员素质问题的解决，就只能通过人才策略、企业文化以及内部艰苦的培养来提升。
当然，某些公司原始的手工作坊式开发流程下，很多即使有多年开发经验的人员已养成了边做边想的坏习惯，已经无法适应或者没有能力去事先把问题想清楚，这可以说很大责任在于制度上。我看到很多做应用项目的程序员，在这种工作环境下工作个两三年后，被毁了。

第二点：我承认实施方法占很大因素，但每个层次都有自己的权利和责任。我们先要承认一个前提，及任何计划都无法事前做到完美，都会有缺陷或问题，这些问题要通过执行中不断反馈来调整。即使进度的制定、发布和监控本身被方法和工具很好的支持，但计划其本身的问题反馈，要靠执行人员的事前或事中主动提出，相对于单纯事后从结果来判断，还是有很大效率上的差别的。因此，方式方法、人事态度，这两个问题不是非此即彼的。把责任纯粹推给方法或工具，反而是抹杀了每个项目成员在整个团队中的作用。

39 楼 fins 2008-12-22  

楼主说的这些军规 80%的程序员 leader pm 都是知道的

关键在于执行力 以及 面对各种复杂的客观情况时的抉择.

楼主列出的军规里 没有一条能够帮助提高执行力的.

======================

我曾经在某大型公司就职过 那公司的规矩不是一些(注意 是一些 不是那些 其中区别自己体会---此解释防止 下一站火星 来抬杠 ) 几百人的公司所能体会到的.

但是实际贯彻执行的情况呢??

======================
有时候我曾想 那种 员工违规就罚钱 甚至开除的 公司 真的很烂 真的很差劲 不人性化 没有道德 ... ...

但是 有时候想一想 其实这未尝不是一个简单粗暴 但是有效的办法.

======================

有句俗话: 规矩是给守规矩的人定的.

从实际情况来看 如何让大家守规矩 要比如何定规矩难得多.

期待楼主 在更有难度的领域内发表一些看法





================

在此 再次 强烈谴责一下 JE的管理员,  JE的管理员不按套路出牌.

吐舌头的表情符号是  " : wink : " (去掉空格)
而不是按照 国际惯例  " : P " (去掉空格)

而且更可恨的是 JE把 " : P " 这个经典符号 JE擅自做主的做成了 一个不知所云的笑脸.
示例如下:

: wink :   ----- 
: P   ----- 

而且 :+单词+: 的表情符号是 早些年 VBB等论坛遗留下来的, 属于"单词类"
而 : P 这类符号是 表情符号的另一派系 属于 "象形类".
把两种不同风格的表情符号混合着来用 这种用法实在让人很ORZ.



由于JE不按国际管理行事, 导致的结果就是,
我在发帖子时 需要在键盘与鼠标之间来回转换
因为我不知道 我按照国际惯例输入的表情 ,会被JE转换成什么鬼东西
为了安全起见 我必须去点击表情图标.

在此 对JE的这种做法 表示强烈抗议 & 谴责.

此谴责声明我会附带在我发的每一篇帖子之后 直到JE管理员改进 表情符号 系统为止.


从中国zf以往的"抗议 & 强烈谴责"中 我们可以了解到
我这种行为其实是极其幼稚 而且也是根本没JB用的
(早就在站务圈子里提过这个问题了 无人理会)

不过 我想我还是 表达一下我的态度吧 否则心里难受的想哭 :'(

38 楼 welllove53 2008-12-22  

<div class='quote_title'>rocket 写道</div>
<div class='quote_div'>
<div class='quote_title'>Julien 写道</div>
<div class='quote_div'>
<div class='quote_title'>rocket 写道</div>
<div class='quote_div'>windows是不是一个<span style='color: #ff0000;'>创造性，设计性的构筑？ </span><span style='color: #ff0000;'><span style='color: #000000;'>我不相信没有管理Windows能做成今天这个样子。所以不可能管理这个命题是错误的。问题其实是什么样的管理更合适，判断合适的标注是要可以度量的，可惜的是我们现在没有一个有效的度量方法（可以看看我前面和o6z讨论的过程）。我认同你关于设计性构筑管理过程里享受生产性构筑管理的确定性和高效率这个观点，但是我不认为我们可以把任何一个软件的开发简单的定性为创造性的，还是重复性的构筑</span></span>
<p><span style='color: #ff0000;'><span style='color: #000000;'>此外，我现在开始不愿意把软件生产和任何一个熟悉的领域进行类比了，因为我发现不论是制造业，还是建筑业都会把我们引导到一个去尝试把软件生产改变为流水线生产或者建造房子的误区中来。</span></span></p>
<p><span style='color: #ff0000;'>所以对于你后面那个问题，我的回答是我不认为软件工程师是所谓的流水线工人。毕竟还有个工程师的头衔呢，是不？ 哈哈 </span></p>
</div>
<p> </p>
<p>光给一个工程师的头衔，是远远不够的。</p>
<p>windows虽然成功，但是那个代码成品量和投入的人力比，肯定是远远小于你接一个增删改查的活，需要的编码量和人力比的。</p>
<p>说白了，你做一个增删改查，需要1个人月，那么你是否愿意投入10个人月，把这个活做到像windows这么高的质量？</p>
<p>你真的是以微软对待一个工程师的姿态来对待你的工程师的么？</p>
<p>我就不明白凭什么一定要认为依靠管理就能够创造奇迹，没错，管理不好，原本能做到80分的事情只能做到20分，但是你管理好了，最多也就是做到100分而已。</p>
<p>但是当你想要做1000分的事情的时候，还是老老实实从如何组织和投入10倍于前的成本上下功夫，不要总幻想着依靠什么雄狮般的领导鬼斧神工的谋略以一当十创造奇迹，然后失败了就把这个失败归咎于兵不精将不良，决口不提自己的后勤。</p>
</div>
<p>呵呵，我觉得这里我有一些相左的观点，资源是死的，但是我们知道人是很奇妙的，是能够创造奇迹的，不然我们的历史上就不会有那么多以少胜多，以弱敌强的故事。当然，从自然规律来说，以多胜少是常见的。其实这里我觉得你举的例子都有些偏激，我想说的资源和管理是相辅相成的，两者只有在一起才能做好项目做好事情。而不是简单的抛开资源谈管理，或者抛开管理谈资源，巧妇难为无米之炊。</p>
<p> </p>
<p>使用组合的方式来整理一下吧</p>
<p>少资源，弱管理=没娘没奶的孩子</p>
<p>多资源，弱管理=失败的多，成功的少，通常成功的都是小项目</p>
<p>少资源，强管理=失败的多，成功的少，成功的往往都是奇迹</p>
<p>多资源，强管理=基本上没有失败的可能（天灾人祸那就另说了）。</p>
</div>
<p><br/>所谓管理，首先要做到让每个资源发挥他们应该具备的能力，把正确的人放到正确的位置上做正确的事。</p>
<p>管理重要性，只有在资源不足时效果才比较明显，如果资源丰富，应该更多的使用无为的方式。</p>
<p> </p>
<p>不过，还是强调我之前一直说的，在要求别人做事之前，要想想你给别人的报酬是否够得上你要求他做的事，不然不可能把事情做得出色的</p>

37 楼 tuti 2008-12-19  

rocket 写道

tuti 写道

rocket 写道

[
呵呵，纠正一点，虽然是我的帖子，但是不是我提到。我只是想拿这些点出来和大家讨论讨论。
这里你讲到老子的无为而治我觉得可以深入讨论一下：
理解一，无为=无创造，没有创造就是没有风险，没有风险自然就不会失败。
理解二，无为=不做限制，没有限制就可以创造更有价值的，而我们所追求的不就是价值和和意义吗。

1.我的理解“无为”指顺应自然规律,或者说不做逆自然规律而动的事情。
在管理上表现为，系统思维的理解自然动力，动作要早，幅度要小。


2. 考虑可以给ozzzzzz颁发一面锦旗“思考质量大奖”。

1 再深一点，什么是自然规律，什么是自然动力?用个case来讲，我们国家的文革运动是顺应自然规律还是违背了自然规律，那么改革开放呢,当前的金融风暴呢？回到软件管理上来讲，cmm是顺应了自然规律还是违背了自然规律，agile呢?

2 第二点我相信javaeye的朋友们应该没有反对的。

深入的话 请参考《质量.软件.管理——系统思维》

36 楼 rocket 2008-12-19  

amonlei 写道

rocket 写道

shishi11 写道

少见的好贴。
对CMMI和agile都没有太过深入的研究，但从实际工作和楼主的军规来说，和CMM没什么太过关系。管理管的是人，CMM的度量也是为了管理，但谈及人的又有多少呢？“因为不同的公司在开发过程中成本，资源，盈利方式都将有所不同，所以度量规则也应该是不同的。 ”这是实话。由一个作坊到一个小企业，和由一个小企业到一个中企业，和由一个中企业到一个大企业，是决然不同的。在原始积累的阶段，一切可能都是简单粗暴的，可以简化的，但到高级的形式，要正规军的时候，一切又变得过于程式化。这是矛盾的，但也只有在解决矛盾的过程中，才能发展。我的感觉，CMM有些限制了矛盾的产生，保证了项目地安全，但对于企业的长期发展不一定是好事。
创造性的讨论，其实可以很朴实地想，创造就有失败，而CMM不允许失败，唯一能保证不失败的方式就是不创造。是不是有点儿老子的无为而治的意思？哈哈。所以据我之所想，CMM不是终级的，像IBM之类公司，在这方面也是广种薄收，所以你会看到一会儿SOA，一会儿层计算什么的，什么都推，什么都推到定出规范，但不是什么都成功。所以，可能有一些项目就是这样，不知道成功还是失败，也要做。因为这是做公司，不是做项目。但前提是得有这个实力。
做为忠告，我觉得楼主提的都非常之好，值得思考。也是想到哪，写到哪儿。

呵呵，纠正一点，虽然是我的帖子，但是不是我提到。我只是想拿这些点出来和大家讨论讨论。
这里你讲到老子的无为而治我觉得可以深入讨论一下：
理解一，无为=无创造，没有创造就是没有风险，没有风险自然就不会失败。
理解二，无为=不做限制，没有限制就可以创造更有价值的，而我们所追求的不就是价值和和意义吗。
我个人更喜欢第二种理解，当然道德经，我也没有看完整过，什么是无为，如何又才能做到无为这个就是我不熟悉的东西了，暂时先断章取义一下。希望能够熟读四书五经的朋友出来给我们讲讲我们博大精深的文化与现在管理方法的结合。
不过看过一本书《中国式管理》，我觉得现在在感觉到管理团队困难的朋友都可以看看。

一知半解，就不要作为论证依据了。。。。要严谨。。。做技术。。

做技术，严谨，我同意。不过所谓的严谨是逻辑上的严谨，对于上面谈到的问题我在逻辑上没有出现什么纰漏。而且我在对无为这个问题进行探索和研究，如果你觉得你的理解更多，你的逻辑更严谨，欢迎提出来大家一起探讨。

退一步讲，一百个人读老子会有一百种理解和体会，这是这个世界多样性的精彩。我们应该鼓励并尊重多样性。

再退一步，就算老子的无为有一个标准答案，但是人类发展到了今天，经过很多人的升华，无为也已经不仅仅属于老子了，所以对于这个概念的任何假设和推断都不可能用是否符合老子本意来进行判断它是否严谨了。

所以，学问是让我们拿来怀疑的，不是让我们天天供在庙里进行膜拜的。

35 楼 rocket 2008-12-19  

<div class='quote_title'>Julien 写道</div>
<div class='quote_div'>
<div class='quote_title'>rocket 写道</div>
<div class='quote_div'>windows是不是一个<span style='color: #ff0000;'>创造性，设计性的构筑？ </span><span style='color: #ff0000;'><span style='color: #000000;'>我不相信没有管理Windows能做成今天这个样子。所以不可能管理这个命题是错误的。问题其实是什么样的管理更合适，判断合适的标注是要可以度量的，可惜的是我们现在没有一个有效的度量方法（可以看看我前面和o6z讨论的过程）。我认同你关于设计性构筑管理过程里享受生产性构筑管理的确定性和高效率这个观点，但是我不认为我们可以把任何一个软件的开发简单的定性为创造性的，还是重复性的构筑</span></span>
<p><span style='color: #ff0000;'><span style='color: #000000;'>此外，我现在开始不愿意把软件生产和任何一个熟悉的领域进行类比了，因为我发现不论是制造业，还是建筑业都会把我们引导到一个去尝试把软件生产改变为流水线生产或者建造房子的误区中来。</span></span></p>
<p><span style='color: #ff0000;'>所以对于你后面那个问题，我的回答是我不认为软件工程师是所谓的流水线工人。毕竟还有个工程师的头衔呢，是不？ 哈哈 </span></p>
</div>
<p> </p>
<p>光给一个工程师的头衔，是远远不够的。</p>
<p>windows虽然成功，但是那个代码成品量和投入的人力比，肯定是远远小于你接一个增删改查的活，需要的编码量和人力比的。</p>
<p>说白了，你做一个增删改查，需要1个人月，那么你是否愿意投入10个人月，把这个活做到像windows这么高的质量？</p>
<p>你真的是以微软对待一个工程师的姿态来对待你的工程师的么？</p>
<p>我就不明白凭什么一定要认为依靠管理就能够创造奇迹，没错，管理不好，原本能做到80分的事情只能做到20分，但是你管理好了，最多也就是做到100分而已。</p>
<p>但是当你想要做1000分的事情的时候，还是老老实实从如何组织和投入10倍于前的成本上下功夫，不要总幻想着依靠什么雄狮般的领导鬼斧神工的谋略以一当十创造奇迹，然后失败了就把这个失败归咎于兵不精将不良，决口不提自己的后勤。</p>
</div>
<p>呵呵，我觉得这里我有一些相左的观点，资源是死的，但是我们知道人是很奇妙的，是能够创造奇迹的，不然我们的历史上就不会有那么多以少胜多，以弱敌强的故事。当然，从自然规律来说，以多胜少是常见的。其实这里我觉得你举的例子都有些偏激，我想说的资源和管理是相辅相成的，两者只有在一起才能做好项目做好事情。而不是简单的抛开资源谈管理，或者抛开管理谈资源，巧妇难为无米之炊。</p>
<p> </p>
<p>使用组合的方式来整理一下吧</p>
<p>少资源，弱管理=没娘没奶的孩子</p>
<p>多资源，弱管理=失败的多，成功的少，通常成功的都是小项目</p>
<p>少资源，强管理=失败的多，成功的少，成功的往往都是奇迹</p>
<p>多资源，强管理=基本上没有失败的可能（天灾人祸那就另说了）。</p>

34 楼 rocket 2008-12-19  

引用

说道度量问题，我们一直在探索，但是有一个很大的问题摆在我的面前，用数字去衡量自己团队的人是一个不友好的事情，因为这样很容易让他们知道谁强谁弱，并且很多算法也不完全公正，不利于团队稳定。

至于物理参数，我想说说我的：
1：基本单位：Task（包括name,from date, end date, one page document, reference requirement document，etc）,描述的是任务的一些基本要素，最重要的是定义好完成任务的一个标准
2：计分方式
在给定时间内完成任务能得到任务所有的TP（task point），是否完成任务需要有leader和qa共同review
第一次如果不合格，然后生成一个新的子任务，时间不长，task point = parent task point * 95%
为什么是95%？因为一次完成难度对大部分人都太大，并且有些也是文档的问题，
第二次，三次的重新的子任务就不一样了，因为是否做好，完全是个人的能力和责任的问题
3：现在有很多数据了，怎么统计和度量就不用说了。

task的分值其实是一个很必要的东西，做迭代内的燃尽图很不错，把它挂在墙上很有意思的，老板很喜欢这个

呵呵这是一个有意思的方法，但是我发现这里也仅仅是针对于完成了任务来说。对于同一个任务来说，你们主要的评分包准是基于时间的，这时候也许对于外部质量来说有QA可以控制，那么内部质量呢？就是代码质量呢，不同的代码质量对于以后的维护来说是至关重要的。
当然这里又有一个新问题出来了，如何度量内部质量？

实际上我有过类似于此的管理经验，其中给我印象深刻的是维护那个烦人的task list，那么多属性，大家填写的时候都不是很认真，最后得到的数据我觉得和实际情况有很大的差距。

当然我提这些问题不是说你的度量方法不好，其实当年我和你想的差不多，甚至还没有你的全面。现在想想，我觉得当时犯下的一个问题也许就是用技术来管人了。

再深一步来说，也许我们度量的方法不一定是技术，或者不一定是简单的技术方法。

33 楼 rocket 2008-12-19  

tuti 写道

rocket 写道

[
呵呵，纠正一点，虽然是我的帖子，但是不是我提到。我只是想拿这些点出来和大家讨论讨论。
这里你讲到老子的无为而治我觉得可以深入讨论一下：
理解一，无为=无创造，没有创造就是没有风险，没有风险自然就不会失败。
理解二，无为=不做限制，没有限制就可以创造更有价值的，而我们所追求的不就是价值和和意义吗。

1.我的理解“无为”指顺应自然规律,或者说不做逆自然规律而动的事情。
在管理上表现为，系统思维的理解自然动力，动作要早，幅度要小。


2. 考虑可以给ozzzzzz颁发一面锦旗“思考质量大奖”。

1 再深一点，什么是自然规律，什么是自然动力?用个case来讲，我们国家的文革运动是顺应自然规律还是违背了自然规律，那么改革开放呢,当前的金融风暴呢？回到软件管理上来讲，cmm是顺应了自然规律还是违背了自然规律，agile呢?

2 第二点我相信javaeye的朋友们应该没有反对的。

32 楼 rocket 2008-12-19  

amonlei 写道

呵，楼主的正规军，目前只是描述了程序员部分，针对测试、发布、实施就不理会了？

呵呵，听着语气里有些情绪啊，是不是感觉被骗了？我前面说了，题目是为了吸引眼球让大家来讨论的。
而且，如果要真钻牛角尖，我没有说正规军是什么部队啊，是炮兵，后勤兵，还是医疗兵。

31 楼 rocket 2008-12-19  

welllove53 写道

rocket 写道

welllove53 写道

讨论比较深入。
对于第一点，其实我们大家都想到一个梦想的开发团队，每个人都有极强的主人翁意识，把项目或产品看作自己的作品，其实这样不太现实。
公司一边强调低成本，一边又想找最好的开发人员，这个本身就是一个矛盾。
一个好的组织，强调的是各司其责，最好预备几个自由人的。
所以，你说的第一点，设计和考虑是这个开发人员的事情吧，如果是，请明确指出，并描述在JD里面，并且给与相应的报酬，不是，就不要要求太高。
既要牛耕田又不让牛吃草，哪有这样的事情

简单说说我自己吧，我工作以来我做的每一个项目我都努力把项目当作自己的艺术品在雕琢。这样做的一个可以说出来的好处是，毕业到今天我的工资增长了6倍。
不知道你有没有看过一本书，《自动自发》，如果没有我给你换个方向讲讲，如果仅仅因为报酬而拒绝自己提升的机会，你觉的是谁的损失更大，你还是老板？对于老板来说，他可以简单的换个人来做，这不会阻碍他赚钱。但是对于自己来说，你没有提升自己，你用什么去要求任何一个老板给你超出你能力的报酬呢。要明白，所有老板都是聪明的，他永远只会给你低于你能力的报酬，所以你能做的只能是不断的提高自己的能力。

很明显，如果每个人都是你这样想并做到，为什么你还会出现这个问题；
如果每个你团队的人都是你这样想并做到，你有机会加6倍工资，有机会脱颖而出？
如果世界上每个人都是你这样想并做到，人类早就灭亡了。

所以，不管什么组织里面，都强调JY文化，都是少数JY领导其他人，这个道理很简单啊。

不过每个人的追求不同，有些人不想太多努力，因为不想得到；有些人想得到，但是不去努力；

我稍微说一下，我觉得这个问题可以收尾了，有点偏题了。
做事态度这个问题往小了说是一个人的成长问题，往大了说是一个民族的问题了。也许让所有的人成为JY很难，但是但是如果一个民族都能有一个认真做事，用心做事的态度那么这个民族将是强大的（说道这里我觉得德国和日本是值得尊敬的民族，这里有如果有准备来个民族讨论的的朋友请免开尊口，我胆小，呵呵）。在这里提到我的做法也只是希望大家能改变一下自己的思维，人活在世上，最容易改变的还是自己。
好了，就此打住了，偏离讨论的主题太远了。

30 楼 Julien 2008-12-19  

<div class='quote_title'>rocket 写道</div>
<div class='quote_div'>windows是不是一个<span style='color: #ff0000;'>创造性，设计性的构筑？ </span><span style='color: #ff0000;'><span style='color: #000000;'>我不相信没有管理Windows能做成今天这个样子。所以不可能管理这个命题是错误的。问题其实是什么样的管理更合适，判断合适的标注是要可以度量的，可惜的是我们现在没有一个有效的度量方法（可以看看我前面和o6z讨论的过程）。我认同你关于设计性构筑管理过程里享受生产性构筑管理的确定性和高效率这个观点，但是我不认为我们可以把任何一个软件的开发简单的定性为创造性的，还是重复性的构筑</span></span>
<p><span style='color: #ff0000;'><span style='color: #000000;'>此外，我现在开始不愿意把软件生产和任何一个熟悉的领域进行类比了，因为我发现不论是制造业，还是建筑业都会把我们引导到一个去尝试把软件生产改变为流水线生产或者建造房子的误区中来。</span></span></p>
<p><span style='color: #ff0000;'>所以对于你后面那个问题，我的回答是我不认为软件工程师是所谓的流水线工人。毕竟还有个工程师的头衔呢，是不？ 哈哈 </span></p>
</div>
<p> </p>
<p>光给一个工程师的头衔，是远远不够的。</p>
<p>windows虽然成功，但是那个代码成品量和投入的人力比，肯定是远远小于你接一个增删改查的活，需要的编码量和人力比的。</p>
<p>说白了，你做一个增删改查，需要1个人月，那么你是否愿意投入10个人月，把这个活做到像windows这么高的质量？</p>
<p>你真的是以微软对待一个工程师的姿态来对待你的工程师的么？</p>
<p>我就不明白凭什么一定要认为依靠管理就能够创造奇迹，没错，管理不好，原本能做到80分的事情只能做到20分，但是你管理好了，最多也就是做到100分而已。</p>
<p>但是当你想要做1000分的事情的时候，还是老老实实从如何组织和投入10倍于前的成本上下功夫，不要总幻想着依靠什么雄狮般的领导鬼斧神工的谋略以一当十创造奇迹，然后失败了就把这个失败归咎于兵不精将不良，决口不提自己的后勤。</p>

29 楼 amonlei 2008-12-19  

rocket 写道

shishi11 写道

少见的好贴。
对CMMI和agile都没有太过深入的研究，但从实际工作和楼主的军规来说，和CMM没什么太过关系。管理管的是人，CMM的度量也是为了管理，但谈及人的又有多少呢？“因为不同的公司在开发过程中成本，资源，盈利方式都将有所不同，所以度量规则也应该是不同的。 ”这是实话。由一个作坊到一个小企业，和由一个小企业到一个中企业，和由一个中企业到一个大企业，是决然不同的。在原始积累的阶段，一切可能都是简单粗暴的，可以简化的，但到高级的形式，要正规军的时候，一切又变得过于程式化。这是矛盾的，但也只有在解决矛盾的过程中，才能发展。我的感觉，CMM有些限制了矛盾的产生，保证了项目地安全，但对于企业的长期发展不一定是好事。
创造性的讨论，其实可以很朴实地想，创造就有失败，而CMM不允许失败，唯一能保证不失败的方式就是不创造。是不是有点儿老子的无为而治的意思？哈哈。所以据我之所想，CMM不是终级的，像IBM之类公司，在这方面也是广种薄收，所以你会看到一会儿SOA，一会儿层计算什么的，什么都推，什么都推到定出规范，但不是什么都成功。所以，可能有一些项目就是这样，不知道成功还是失败，也要做。因为这是做公司，不是做项目。但前提是得有这个实力。
做为忠告，我觉得楼主提的都非常之好，值得思考。也是想到哪，写到哪儿。

呵呵，纠正一点，虽然是我的帖子，但是不是我提到。我只是想拿这些点出来和大家讨论讨论。
这里你讲到老子的无为而治我觉得可以深入讨论一下：
理解一，无为=无创造，没有创造就是没有风险，没有风险自然就不会失败。
理解二，无为=不做限制，没有限制就可以创造更有价值的，而我们所追求的不就是价值和和意义吗。
我个人更喜欢第二种理解，当然道德经，我也没有看完整过，什么是无为，如何又才能做到无为这个就是我不熟悉的东西了，暂时先断章取义一下。希望能够熟读四书五经的朋友出来给我们讲讲我们博大精深的文化与现在管理方法的结合。
不过看过一本书《中国式管理》，我觉得现在在感觉到管理团队困难的朋友都可以看看。

一知半解，就不要作为论证依据了。。。。要严谨。。。做技术。。

28 楼 shishi11 2008-12-19  

我只是说有点儿那个意思，断章取义地讲，就是达到CMM5的要求的前提下，它不太希望你改变现状，或者说，它认为你的新尝试会导致项目失败，所以不要去试，而且就成本上来讲，新尝试总要花点学费的。所以就项目本身而言，当然不值了，但就公司长远来讲，一个项目的得失比公司总的发展是不算什么的。
无为=不做限制 ，这个解释也讲得通，因为你已经被自然地限制住了，不需要再多限制了。从人的角度讲，我有代码库了，我有项目经理了，我不能再要求项目组代新人了，不能再要求新方法了。如果只是简单地组建项目团队，不做限制，你是项目经理，你当然不会找新手来，你希望配置都是熟练工。公司很“无为”，任由社会达尔文主义泛滥，适者生存，理论上好像也没有什么不对。但这不能使企业长久发展，有些东西是没法度量的。如果你是新手，你就是新手，不要去想新手以外的问题，过了一段时间，变成了熟练的新手，还是新手。怎么可能只做好自己的事，就治了，一想那不是我的事情，就不管了，那项目经理从哪儿来，新手想，那是项目经理的事，关我什么事，项目经理想，这不是我项目的事，关我什么事，老总想，不是项目经理就别来，关我什么事。跑题了。

27 楼 amonlei 2008-12-19  

呵，楼主的正规军，目前只是描述了程序员部分，针对测试、发布、实施就不理会了？

26 楼 welllove53 2008-12-19  

就度量问题需要做专门的讨论，而且这个是一般必须的讨论。这个问题可以说是现在软件开发工程方面一个最迫切需要解决的问题，注意是问题不是问题之一。现在虽然有一门学科叫软件工程，但是实际上这门学科还算不上是工程学科，原因就在于度量方面还没有到达标准。这个方面主要有两个方向需要去做，一个是寻找更多的物理参数，一个是寻找将现有物理参数进行组合以与软件的某些属性应对。而现在最迫切的一点是如何把现有的软件属性跟原有的企业经营系统进行连接。这个链接不是一个为连接而连接的事情，而是应该有理论有实际统计做基础的连接。比如人们常拿软件工程跟建筑工程类比，也有很多人反对这样的对比。现在的工作就是要将这两个学科进行对比和联系，当然是要有说的通的方法和原理方面的印证。比如说建筑的设计如何如何，软件的设计如何如何，那么是不是考虑到了建筑的设计在投资和资源分配的比例同软件开发中设计的差别这个关键的问题。在比如说建筑工程如何如何文档化，那么是不是考虑到建筑工程的文档化支持所付出的成本与软件工程文档化付出的成本之间的差别。这些东西如果你不考虑，不解释。仅仅单纯的凭外观去对照，就跟中医说的以型养型仅仅只能是一种模糊的说法（其实就是吃什么养什么，比如吃心养心，吃肝养肝，是没有科学依据的）
quote]
说道度量问题，我们一直在探索，但是有一个很大的问题摆在我的面前，用数字去衡量自己团队的人是一个不友好的事情，因为这样很容易让他们知道谁强谁弱，并且很多算法也不完全公正，不利于团队稳定。

至于物理参数，我想说说我的：
1：基本单位：Task（包括name,from date, end date, one page document, reference requirement document，etc）,描述的是任务的一些基本要素，最重要的是定义好完成任务的一个标准
2：计分方式
在给定时间内完成任务能得到任务所有的TP（task point），是否完成任务需要有leader和qa共同review
第一次如果不合格，然后生成一个新的子任务，时间不长，task point = parent task point * 95%
为什么是95%？因为一次完成难度对大部分人都太大，并且有些也是文档的问题，
第二次，三次的重新的子任务就不一样了，因为是否做好，完全是个人的能力和责任的问题
3：现在有很多数据了，怎么统计和度量就不用说了。

task的分值其实是一个很必要的东西，做迭代内的燃尽图很不错，把它挂在墙上很有意思的，老板很喜欢这个

25 楼 welllove53 2008-12-19  

ozzzzzz 写道

就第一个问题，我觉得核心点在于是不是应该应用战士和指挥员这个方式，和应用这个方式需要一些什么条件。而在军事指挥中一个最大的特征，就死战士基本没有要求资源的权利，他们也没有做出决定的权利。而一旦他们可以要求资源，那么这个模式实际就已经不存在了。传统思维方式的问题就在这里，那些希望调和两种方式将传统引入现实的做法，也往往绕不开这个陷阱。在这个模式的特征战士思考是有罪的，指挥员是负责一切的。战士是不需要考虑对错的，指挥员的命令就是一切的尺度。战士越是不思考，这个体系越是有效。

而今一步有一个问题，几乎是没什么关注的。那就是cmm高级别实施制定的目标计划几乎都是可以被完成的，这一项是被认为是cmm的优点。并且很多反对cmm的人一再绕开这个关键点。而实际上这才是cmm这种方法是非理性的，非科学的，非管理学的，以至于非道德的。实际上为什么要计划，为什么要指挥，为什么要管理，根本原因就在于目标是不一定被实现的，并且是很可能不能被实现的。一个好的体系，不是保证你完全的完成你能够完成的目标，而是叫你能够不断的提高，去完成本不能完成的目标。好的方法和方式是教你不断的寻找极限并突破极限进行前进，而不是叫你原地踏步，以至于为了实现目标的高实现性逐步后退的。就好比你派一个1000人的部队，去一定确定的地点消灭一个5个人组成的没有武器非战斗不防御的小组，这样的目标你实施100次就应该成功100次。以这种方式进行指挥绝对不是一种好的指挥方式。
同时请注意我认为cmm的一个致命缺陷是其对于度量的支持不好，也就是进度的把握和显示不好，这一点一会我会在介绍软件度量的时候可能涉及到。

说说我对cmm的理解，我觉得cmm只是一个软件项目管理的框架，他没有告诉你该怎么做，只告诉你需要做什么，就拿度量，量化和改进来说（4，5level最难的地方），他只是说需要有数据能够量化当前的工作，并且能到根据数据分析当前状况，并为你的措施给与指导和蚌组，并且能预测下一步可能会出现什么情况，提醒你及早采取措施。
cmmi完全是就过程来说的，确实忽略了人这个重要的因素，但是，如果你站在管理者角度，他们思考的就是 只要每个人能做好自己的事情，整个project就能很好的运行。这就是工程化的思想。

24 楼 hypercube1024 2008-12-19  

<div class='quote_title'>rocket 写道</div>
<div class='quote_div'><br/>呵呵，纠正一点，虽然是我的帖子，但是不是我提到。我只是想拿这些点出来和大家讨论讨论。<br/>这里你讲到老子的无为而治我觉得可以深入讨论一下：<br/>理解一，无为=无创造，没有创造就是没有风险，没有风险自然就不会失败。<br/>理解二，无为=不做限制，没有限制就可以创造更有价值的，而我们所追求的不就是价值和和意义吗。<br/>我个人更喜欢第二种理解，当然道德经，我也没有看完整过，什么是无为，如何又才能做到无为这个就是我不熟悉的东西了，暂时先断章取义一下。希望能够熟读四书五经的朋友出来给我们讲讲我们博大精深的文化与现在管理方法的结合。<br/>不过看过一本书《中国式管理》，我觉得现在在感觉到管理团队困难的朋友都可以看看。</div>
<p> </p>
<p>个人理解，所谓的无为而治就是顺应潮流，每个人都完成自己该完成的，就无所谓管理了，每个个人都做好自己的事情了，自然就治了。:-)，至于怎样达到这个境界，怎样做到无为，老子也没有给出明确的答复，他只是说：“道可道，非常道。名可名，非常名。”所以要达到 道 的境界需要自己去领悟，说出来的就不是“道”了。 :-)</p>

23 楼 tuti 2008-12-19  

rocket 写道

[
呵呵，纠正一点，虽然是我的帖子，但是不是我提到。我只是想拿这些点出来和大家讨论讨论。
这里你讲到老子的无为而治我觉得可以深入讨论一下：
理解一，无为=无创造，没有创造就是没有风险，没有风险自然就不会失败。
理解二，无为=不做限制，没有限制就可以创造更有价值的，而我们所追求的不就是价值和和意义吗。

1.我的理解“无为”指顺应自然规律,或者说不做逆自然规律而动的事情。
在管理上表现为，系统思维的理解自然动力，动作要早，幅度要小。


2. 考虑可以给ozzzzzz颁发一面锦旗“思考质量大奖”。

22 楼 welllove53 2008-12-19  

rocket 写道

welllove53 写道

讨论比较深入。
对于第一点，其实我们大家都想到一个梦想的开发团队，每个人都有极强的主人翁意识，把项目或产品看作自己的作品，其实这样不太现实。
公司一边强调低成本，一边又想找最好的开发人员，这个本身就是一个矛盾。
一个好的组织，强调的是各司其责，最好预备几个自由人的。
所以，你说的第一点，设计和考虑是这个开发人员的事情吧，如果是，请明确指出，并描述在JD里面，并且给与相应的报酬，不是，就不要要求太高。
既要牛耕田又不让牛吃草，哪有这样的事情

简单说说我自己吧，我工作以来我做的每一个项目我都努力把项目当作自己的艺术品在雕琢。这样做的一个可以说出来的好处是，毕业到今天我的工资增长了6倍。
不知道你有没有看过一本书，《自动自发》，如果没有我给你换个方向讲讲，如果仅仅因为报酬而拒绝自己提升的机会，你觉的是谁的损失更大，你还是老板？对于老板来说，他可以简单的换个人来做，这不会阻碍他赚钱。但是对于自己来说，你没有提升自己，你用什么去要求任何一个老板给你超出你能力的报酬呢。要明白，所有老板都是聪明的，他永远只会给你低于你能力的报酬，所以你能做的只能是不断的提高自己的能力。

很明显，如果每个人都是你这样想并做到，为什么你还会出现这个问题；
如果每个你团队的人都是你这样想并做到，你有机会加6倍工资，有机会脱颖而出？
如果世界上每个人都是你这样想并做到，人类早就灭亡了。

所以，不管什么组织里面，都强调JY文化，都是少数JY领导其他人，这个道理很简单啊。

不过每个人的追求不同，有些人不想太多努力，因为不想得到；有些人想得到，但是不去努力；

21 楼 rocket 2008-12-19  

shishi11 写道

少见的好贴。
对CMMI和agile都没有太过深入的研究，但从实际工作和楼主的军规来说，和CMM没什么太过关系。管理管的是人，CMM的度量也是为了管理，但谈及人的又有多少呢？“因为不同的公司在开发过程中成本，资源，盈利方式都将有所不同，所以度量规则也应该是不同的。 ”这是实话。由一个作坊到一个小企业，和由一个小企业到一个中企业，和由一个中企业到一个大企业，是决然不同的。在原始积累的阶段，一切可能都是简单粗暴的，可以简化的，但到高级的形式，要正规军的时候，一切又变得过于程式化。这是矛盾的，但也只有在解决矛盾的过程中，才能发展。我的感觉，CMM有些限制了矛盾的产生，保证了项目地安全，但对于企业的长期发展不一定是好事。
创造性的讨论，其实可以很朴实地想，创造就有失败，而CMM不允许失败，唯一能保证不失败的方式就是不创造。是不是有点儿老子的无为而治的意思？哈哈。所以据我之所想，CMM不是终级的，像IBM之类公司，在这方面也是广种薄收，所以你会看到一会儿SOA，一会儿层计算什么的，什么都推，什么都推到定出规范，但不是什么都成功。所以，可能有一些项目就是这样，不知道成功还是失败，也要做。因为这是做公司，不是做项目。但前提是得有这个实力。
做为忠告，我觉得楼主提的都非常之好，值得思考。也是想到哪，写到哪儿。

呵呵，纠正一点，虽然是我的帖子，但是不是我提到。我只是想拿这些点出来和大家讨论讨论。
这里你讲到老子的无为而治我觉得可以深入讨论一下：
理解一，无为=无创造，没有创造就是没有风险，没有风险自然就不会失败。
理解二，无为=不做限制，没有限制就可以创造更有价值的，而我们所追求的不就是价值和和意义吗。
我个人更喜欢第二种理解，当然道德经，我也没有看完整过，什么是无为，如何又才能做到无为这个就是我不熟悉的东西了，暂时先断章取义一下。希望能够熟读四书五经的朋友出来给我们讲讲我们博大精深的文化与现在管理方法的结合。
不过看过一本书《中国式管理》，我觉得现在在感觉到管理团队困难的朋友都可以看看。