正规军的军规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 。

 <!---->

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

 <!---->