正规军的军规一

2012-07-26

正规军的军规1下面的文章是我转自我的老大Anderson的邮件，是对我们team一些问题的总结和经验分享。我里面有

正规军的军规1

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

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

?

编码人员的误区

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Team Leader的误区

) 几百人的公司所能体会到的.

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

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

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

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

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

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

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

我觉得执行力是一个态度的问题。规矩制定出来不是给人看的，既然定了，大家也都没有意见，那就应该严格执行。这里在严格的同时尤其要求leader应该以身作则，对于每个问题从一开始就严格要求，这样可以帮助大家把规矩变成自己的习惯了。举个例子，我现在的这个项目提交代码前需要由leader来review的，我的老大在第一次给我review的时候就对于代码的细节问题要求很严格，所以现在我已经养成了一个习惯就是，提交代码前自己一定要对提交的代码仔细检查。我觉得这就是执行力了：） ) 几百人的公司所能体会到的.

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

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

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

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

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

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

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

我觉得执行力是一个态度的问题。规矩制定出来不是给人看的，既然定了，大家也都没有意见，那就应该严格执行。这里在严格的同时尤其要求leader应该以身作则，对于每个问题从一开始就严格要求，这样可以帮助大家把规矩变成自己的习惯了。举个例子，我现在的这个项目提交代码前需要由leader来review的，我的老大在第一次给我review的时候就对于代码的细节问题要求很严格，所以现在我已经养成了一个习惯就是，提交代码前自己一定要对提交的代码仔细检查。我觉得这就是执行力了：）
为道日损，损之又损，以至无为。
rocket说的态度问题和规矩，可以理解为“道”，为“道”就是 “损己利人”，（增加自己的工作量，有利于整个项目，有利于项目内的其他成员）。
我认为”无为“和“管理”的前提条件是不同的，无为假定被管理者能够“为道”（损己利人），而“管理”假定被管理者是盲目的，甚至是损人利己的。所以怎样将“管理”和“无为”结合起来应用到软件工程里，我觉得有一定意义，欢迎大家拍砖。
有些人认为只有在领导规定的时间内完成任务才是最重要和最紧急的。至于方向是否正确，功能是否完整则没有时间去考虑。 
这些人陷入了多写些代码和程序就会安全了的假象当中。殊不知方向错了，跑得越快，损失越大。 
抱有这种想法的根本原因在于他们的不自信，不知道如何分析问题，找出最佳解决途径和细致的评估影响面，因而无法向上级提出一个更加合理的时间。 
例如： Bulk Address feature 的设计者也是说时间紧，没时间细想。后来的结果就是这个 feature 的 design 和代码被一次又一次的推翻和重做。而我们的 leader 也因为反复的向 Jerry Lu 解释上次做错了能否接受我们新的 Solution 而招致了 Jerry Lu 的反感。 
l? 由于这个开发人员缺乏责任心，导致我们不得不花了比原计划多出 30% 以上的时间去补做和补测 
l? 开发人员没有意识到之前他的 Leader 对他的能力不太熟悉，所以给他的时间会比正常情况下多一些。只要发挥出正常能力和应有的责任心就可以提前完成任务。结果他不但没有完成任务，还浪费掉了预留给他的时间。这种情况下他的 Leader 对他能力的评估只会更差，同时也增加了 Leader 对他能力的不信任。 
1）? 他当时心情不好正在闹情绪，这时开发人员应当注意控制好自己的情绪 
2）? 他真的是全听懂了，只要回答“我全明白了”就好了 
3）? 绝大多数内容他没听懂，这时他可以回答“我暂时还不能完全理解你说的所有内容。我下来再仔细看看文档，估计 30 分钟后再来问你好吗？” 
1）? 给组员一些准备时间，在讲解前告诉他们着重看那部分内容。 
2）? 讲解完毕后，可以让组员讲出哪些分析点是他之前没有想到的，怎样分析才能够分析的比较全面。 
3）? 如果组员的分析能力实在太弱什么也讲不出来，我们还可以鼓励他们说出哪些内容他们没听明白。 
1）? 用人不当，由能力不足的人作分析设计导致设计失误太多，必须要花更多的时间检查和修补 
2）? 缺乏有效的分析设计技巧导致和业务领域知识，导致 Effort 估计不足 
3）? 编码和 UT 素质较差，需要成倍的时间进行修补和返工 
4）? 工作效率低导致在规定的时间内未能完成任务而加班 
5）? 工作方法不当，一些无谓的等待导致了加班 
1）? 不要急着先说人家 Reopen 不对，首先自己要先核实 Search Portlet 里的 bug 和 Create Portlet 的 bug 是否无关。如果确实无关再耐心的和 QA 解释为什么应该提一个新的 bug 
2）? 但是无论如何出现这种状况，我们的开发人员自身也有问题。他们不了解， fix bug 不是头痛医头，脚痛医脚。我们首先要找到 bug 的成因，然后分析这个 bug 成因的潜在影响面，最后彻底的 fix 掉这个 bug 。另外， bug 有个扎堆的原理，当你发现一个地方有 bug 时，往往周围出现 bug 的几率就会比较高。所以我们一定要在这个 bug 的周围多做一些测试。 
3）? 不懂的只有高标准严要求，才能激励自己更快更好的发展。 
4）? 这种工作人员的工作心态也有问题，错了就是错了，不要对自己的错误做过多的辩解。知道自己错误，错在哪里，然后下次能够改进就好了。因此我们需要及时的调整好自己的心态。 
Team Leader 的误区 
编码人员的误区 
有些人认为只有在领导规定的时间内完成任务才是最重要和最紧急的。至于方向是否正确，功能是否完整则没有时间去考虑。 
这些人陷入了多写些代码和程序就会安全了的假象当中。殊不知方向错了，跑得越快，损失越大。 
抱有这种想法的根本原因在于他们的不自信，不知道如何分析问题，找出最佳解决途径和细致的评估影响面，因而无法向上级提出一个更加合理的时间。 
例如： Bulk Address feature 的设计者也是说时间紧，没时间细想。后来的结果就是这个 feature 的 design 和代码被一次又一次的推翻和重做。而我们的 leader 也因为反复的向 Jerry Lu 解释上次做错了能否接受我们新的 Solution 而招致了 Jerry Lu 的反感。 
l? 由于这个开发人员缺乏责任心，导致我们不得不花了比原计划多出 30% 以上的时间去补做和补测 
l? 开发人员没有意识到之前他的 Leader 对他的能力不太熟悉，所以给他的时间会比正常情况下多一些。只要发挥出正常能力和应有的责任心就可以提前完成任务。结果他不但没有完成任务，还浪费掉了预留给他的时间。这种情况下他的 Leader 对他能力的评估只会更差，同时也增加了 Leader 对他能力的不信任。 
1）? 他当时心情不好正在闹情绪，这时开发人员应当注意控制好自己的情绪 
2）? 他真的是全听懂了，只要回答“我全明白了”就好了 
3）? 绝大多数内容他没听懂，这时他可以回答“我暂时还不能完全理解你说的所有内容。我下来再仔细看看文档，估计 30 分钟后再来问你好吗？” 
1）? 给组员一些准备时间，在讲解前告诉他们着重看那部分内容。 
2）? 讲解完毕后，可以让组员讲出哪些分析点是他之前没有想到的，怎样分析才能够分析的比较全面。 
3）? 如果组员的分析能力实在太弱什么也讲不出来，我们还可以鼓励他们说出哪些内容他们没听明白。 
1）? 用人不当，由能力不足的人作分析设计导致设计失误太多，必须要花更多的时间检查和修补 
2）? 缺乏有效的分析设计技巧导致和业务领域知识，导致 Effort 估计不足 
3）? 编码和 UT 素质较差，需要成倍的时间进行修补和返工 
4）? 工作效率低导致在规定的时间内未能完成任务而加班 
5）? 工作方法不当，一些无谓的等待导致了加班 
1）? 不要急着先说人家 Reopen 不对，首先自己要先核实 Search Portlet 里的 bug 和 Create Portlet 的 bug 是否无关。如果确实无关再耐心的和 QA 解释为什么应该提一个新的 bug 
2）? 但是无论如何出现这种状况，我们的开发人员自身也有问题。他们不了解， fix bug 不是头痛医头，脚痛医脚。我们首先要找到 bug 的成因，然后分析这个 bug 成因的潜在影响面，最后彻底的 fix 掉这个 bug 。另外， bug 有个扎堆的原理，当你发现一个地方有 bug 时，往往周围出现 bug 的几率就会比较高。所以我们一定要在这个 bug 的周围多做一些测试。 
3）? 不懂的只有高标准严要求，才能激励自己更快更好的发展。 
4）? 这种工作人员的工作心态也有问题，错了就是错了，不要对自己的错误做过多的辩解。知道自己错误，错在哪里，然后下次能够改进就好了。因此我们需要及时的调整好自己的心态。 
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 。 
? 
? 
</div>
? 59 楼 dandy 2009-02-26 汉化的不彻底！为什么有些词非用英语？ 60 楼 nininia 2009-03-16 实在不敢苟同，我不知道你在的是什么样的公司，但是在中国，很多从业者如果这样做的话，那么他们的付出和收获是不成正比的，程序员的薪水和项目经理的薪水是不一样的，为什么他们要付出那么多，小公司有几个位子，能叫符合条件的程序员坐上项目经理的位子，拿到他们应得的薪水。

热点排行

软件开发

正规军的军规一