正规军的军规1

rocket

浏览: 90690 次
性别:
来自: 金城

最近访客更多访客>>

yuan

tizhui4180

HowieFeng

浪漫樱花大侠

博主相关

博客

微博

相册

留言

关于我

文章分类

社区版块

存档分类

博客分类：

项目管理

CMM 企业应用项目管理设计模式软件测试

下面的文章是我转自我的老大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 。

分享到：

正规军的军规2 | DEV2DEV TECHDAYS SOA 体会二

2008-12-17 18:14
浏览 1984
评论(60)
论坛回复 / 浏览 (64 / 33691)
分类:研发管理
查看更多

60 楼 nininia 2009-03-16

实在不敢苟同，我不知道你在的是什么样的公司，但是在中国，很多从业者如果这样做的话，那么他们的付出和收获是不成正比的，程序员的薪水和项目经理的薪水是不一样的，为什么他们要付出那么多，小公司有几个位子，能叫符合条件的程序员坐上项目经理的位子，拿到他们应得的薪水。

59 楼 dandy 2009-02-26

汉化的不彻底！为什么有些词非用英语？

58 楼 qingwengang 2009-02-20

<div class="quote_title">rocket 写道</div>
<div class="quote_div">
下面的文章是我转自我的老大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 。 
 
  
</div>

57 楼 terryang 2009-02-18

真不习惯汉语里掺杂几个英文单词，I服了you！

56 楼 fflame 2009-02-17

哈哈，如果遇到喜欢今晚出需求后天跟客户汇报的项目经理，不知道LZ还会不会这么乐观^_^

55 楼 mating 2009-02-15

ly_parma 写道

为啥文章里要夹杂几个英文啊。

很正常啊！不懂查一查就当是学习一下！呵呵

54 楼 mating 2009-02-15

有点规矩当然好，要做大做强就得有自己的一套规！对于一个项目组如果没有自己一套规很难想象项目的成功率！

53 楼 ljs510 2009-02-05

52 楼 linginfanta 2009-02-05

关键在于落实

51 楼 alfred.w 2009-01-27

引用

编码人员的误区
误区一：因为任务紧迫，所以没有时间想

日程安排完成后，几乎直接除3安排给你，每天光大的功能模块满负荷（早9，晚12），完成都有困难，你还能想什么。
不是我抬杠，前一个项目刚碰到过。
同样的team在这样的项目中出现了3000多个bug,但是类似的项目由于时间合适只有300多个bug,相差一个数量级，你经历过吗？？
更反省的是，日程是怎么定出来的吧？不要老想马儿跑还不想马儿吃草。

引用

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

提倡自身提高质量是对的，不过
流程里是不是完成不是某个人说了算，正规军里是不是应该正规的验证标准和验证人员？

引用

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

这个算是编码人员的误区么？

引用

误区四：凡事都有 Team Leader 帮忙检查
例如：有一次 Hikelee 让一个组员给他写一封需要回复给客户的邮件。很快这个组员就告诉 Hikelee 写完了。
Hikelee 就问他说“我是否可以不做任何修改就可以把这份邮件直接发给 Anderson ？”这个组员回答说不能。 Hikelee 就让他拿回去参看以往 Hikelee 发出的类似邮件去改，直到达到这个标准后再发给过来。
过了一会这个组员又说写完了。这次 Hikelee 又问他，是不是 Anderson 也不需要做任何修改就可以把这份邮件直接发给我们的客户？组员回答说不能。 Hikelee 就对他说在去看看 Anderson 以往是怎么回复客户这类问题的，找到差别修改后再发给我。

这个我觉得还不算是误区，我觉得你这个要求有误区。工作细心，负责我是同意的，不过你上面的例子确实不太合适，

试问一个程序员适合发一封直接给客户的邮件么？如果是一个问题，程序员会从专业的角度去分析，或许有一些术语，

甚至公司内部不愿或者没有必要被客户知道的东西，还有语气，用语，修辞，都不是程序员与必须考虑的问题。

能代表公司直接面对客户固然是好的，但我觉得不是必须的。我觉得，发给客户的邮件就是代表的公司的形象，

都需要特定的人，经过特定的培训，在修辞，语气，称谓等等都有特殊的要求，你要求每个程序员就从几封历史邮件中

就必须具备这种素质么？而且有必要每个人都具备吗？每个人都应该干自己擅长的事情，而不是学会一堆堆的客套话。

当然，我是按照你的“正规军”的要求说的，如果说没有这个条件就另当别论了。

引用

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

写到这里我觉得用误区真的不是太合适。

能看到问题的人，我觉得已经不错了，能主动看到问题并提出的，已经值得表扬了。

一般这些人，只要不是闹情绪时提出的问题，通常会说出自己的解决方法。

要求每个人提出问题的时候都准备出一二三四的原因分析和解决方案是不是不要求全责备了。

引用

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

这个我还是同意的，一个电影里有句话‘Do u have a sparkle?’如果你有就展示出来，如果你有了不被赏识，那就可以考虑离开了。
如果你在一个公司几年还做一件单调的事情，那就要反省了。

引用

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

问一下，你这里的不信任是如何表现的？随意的监管？不停的督促？是否需要考虑一下管理的方式呢？

引用

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

lz表达的意思就是程序员要主动找到深层次的问题，这个我同意。

但是qa 随意的reopen我觉得是不对的，每个bug修复时，我们会用一个根本原因选择，叫做root cause,

每个项目结束后，

会对每个原因做出分析。两次问题可能真的是有自己对立的原因。最好不要随意的reopen.

从qa角度来看，我们应该鼓励qa，能透过现象测到本质，而不是只停留在表面上，也不是被动的在一个问题上reopen.

从心理学上来看，每个人面对指责都会本能的辩解，reopen 通常会让人觉得你的代码质量差，返工次数多，自尊心强

责任心强的人才会比较在意，我反倒是觉得有点值得鼓励。

引用

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

这个我是同意的，但是脑力劳动的管理还是有些特殊的，我不知道lz写过多少程序，因为我看到你有句话说你

喜欢做指挥员。考虑下为什么google 有松散的工作制度呢？

确实公司有一些规定，我们应该遵守，这个我认同。但是或许你的组员确认了

bug以后，脑袋比较混，或者心情刚好不好，或者确实是个难题，需要帮助。于是在没有搞定bug以前，去看了

貌似和bug没关系的东西，又不巧被你偷偷发现了（身后瞄到？监控软件？）。

“2个小时”的要求是不是显得很木讷了一点？？！！

引用

Team Leader 的误区

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

我觉得你这里的角色功能可能没有明确的交代，每个公司对team leader的职责划分会有区别。

不过我觉得对于team leader来说问题就是问题，确实没必要区分，只有对问题考虑全面不全面的问题，而不是在乎问题

是客户的还是内部的。

引用

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

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

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

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

主动了解进度是对的，不过知人善用是不是需要提高的，就这个例子而言。

如果一个成熟的团队，几乎每个任务分配完以后，就心里应该有个底，如果同时有两个owner的小组都出了问题，

首先看看你任命这两个owner以及这两个owner本身是不是有问题，而不是先反省你平时有没有跟在他们屁股

后面看着他们吧？

我想最高境界就是分配了以后不管有没有问题都不用你管，自己都能解决。呵呵。

引用

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

这个我同意，前面乱说了一点自己的看法，欢迎指正！

50 楼 ly_parma 2009-01-21

为啥文章里要夹杂几个英文啊。

49 楼 rocket 2009-01-13

汪兆铭写道

不过看起来你现在的公司还不错。至少比起其他公司来负责得多。

最近也在看XP，Agile之类的信息。

其中对于故事点的描述我比较注意。
在一些公司里。进行评估的时候就很随意的指定这个功能（通常类似你说的，指导员来做）多少工时，但实际上并不符合实际情况，那么不符合，就加班吧。
但Agile的方式是：你到一个团队，那么我们先不估算这个时间，大家先工作，比如三天，一个星期，你就做。看你在正常的工作时间内能完成多少，然后以此作为参考，然后才展开评估。
敏捷的开发感觉最主要的优势是质量和成本的控制，必须以TDD方式开发以及提倡重构。
以下的词摘自某XP书籍：
关于项目：
成本时间质量范围
关于开发：
沟通简单反馈勇气
编码测试倾听设计

其中对：成本时间质量范围这四项的描述就是：让“客户”从中选3个。剩下一个我们来处理。假如你是客户的话是不是觉得很难选？

高质量的软件成本更低。这点我体会深刻，不过公司不知道，因为我加班是免费的。我需要花大量的时间去修正在我来公司之前N年的代码。进行重构。

推荐一本书，敏捷估计和规划，里面会有很多实用的方法和技巧的。

48 楼 rainv 2008-12-30

支持rocket!!!

47 楼 jcs7575 2008-12-28

好文，学到了不少知识

无为而治
>无所为，无所不
>无为是一种处世的境界,达到人与自然的一种和谐. 无为而治是道家治国的一种方法
老子的五千字道德经不是简单用语言可以描述出来的
研究至今的那么多学者都还存在分歧，更何况我们
所以说这个东西无所谓对错，只是每个人的理解不同而已

46 楼天空不空 2008-12-24

太多了，精简一下比较好接受~~

45 楼 mliz 2008-12-24

我一贯认为态度这个东西不是靠压出来的，是靠潜移默化的教育和感染出来的，最近一直带应届生团队，是的，毛病不少，但我更喜欢他们的纯净，一直崇尚一种理念，润物细无声，面对新员工，我觉得在帮助他们提高技术技能和服从公司纪律的同时，我更希望他们能有一种基于职业自豪感的是非观，在违反规范的时候，我更希望他们首先想到的是。作为技术人员做这样不专业的事情是不对的，而不是想到可能的惩罚和纪律，一贯不喜欢用压力去达到目的，每一件事情都希望教给他们的不是简单的规范，而是真正的原因，我一贯认为，每一个新员工都应该被告知为什么这样做，何地这样做，何时这样做，如何这样去做（what,where,when,how)的3W1H原则，在做学校里面对开放式教育很有兴趣，工作之后，希望自己的团队既是工厂也是学校。

44 楼一点点 2008-12-23

rocket 写道

fins 写道

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

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

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

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

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

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

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

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

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

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

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

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

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

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

为道日损，损之又损，以至无为。
rocket说的态度问题和规矩，可以理解为“道”，为“道”就是 “损己利人”，（增加自己的工作量，有利于整个项目，有利于项目内的其他成员）。
我认为”无为“和“管理”的前提条件是不同的，无为假定被管理者能够“为道”（损己利人），而“管理”假定被管理者是盲目的，甚至是损人利己的。所以怎样将“管理”和“无为”结合起来应用到软件工程里，我觉得有一定意义，欢迎大家拍砖。

43 楼 rocket 2008-12-23

fins 写道

42 楼 jili 2008-12-22

rocket 写道

二我在一个公司曾经使用过jira，当时jira给我的感觉是无形中增加了我的工作，作为开发人员，有时候下班都在研究一个问题，然后就关机走人了，这时候就很容易忘记去填写状态信息。在agile中，也没有使用什么强大的系统来收集，而是用卡片加每日站立会议的方式来收集状态信息。

试试mylyn，集成到ide中后应该更难以忘记了吧？
事实上，大多数的管理工具的本质都是通过增加工作成本来保证质量，满足管理要求的。这就是所谓的管理成本了吧，负担很多都在第一线人员身上，很直接，但效果却在长期和整体。

41 楼 jili 2008-12-22

ozzzzzz 写道

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

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

按我的理解，cmm只是对过程的一些判断准则，而不是具体的做法。ozzzzzz大人所说的度量这个缺陷是指cmm对度量的定位和判断准贼有问题，还是说某些实施的具体方法有问题？ps：我自认为对cmm理解不够深入到可以赞扬或批判，因此以上仅仅是疑问。

发表评论

您还没有登录,请您登录后再发表评论

最近访客更多访客>>

博主相关

文章分类

社区版块

存档分类

最新评论