对“正规军的军规”的再思考

    开发和开发团队的管理是软件开发中的永恒话题。好在一些先行的实践者已经总结出了很多经验和技巧。这些经验和技巧针对的现象是我们几乎天天可能遇到的、触手可及的。借鉴这些从教科书上根本学不到的东西，对指导我们的工作很有帮助。最近我有幸看到这样的一篇文章，文章的观点我基本认可，推荐在本文的最后。

    但我又免不了鹦鹉学舌，对文章的某些观点进行了一番生发，以备自己将来查看，也想听听大家都想法。

    因为任务紧迫，所以没有时间想：“没有时间想”本身就是一个怪异的提法。就是“Ctrl+C”“Ctrl+V”也要想想来龙去脉是否合适。难道我们天天闭着眼睛、梦游一般的写代码？“没有时间想”的背后的思想根源就是逃避和推卸责任，打字、复制、粘贴……完工，交差，“我死后哪怕它洪水滔天”。这样子生产软件，不说创造性何来，就是一般的 Bug 也很难避免，错误会随着版本一代一代的继承下去，永远不能被发现和修正。
    所以，任务再紧，还是建议每天抽出哪怕10分钟来 use your head，对提高软件质量，对自己的技术进步都会有极大好处的。

    在最后一刻告诉Leader代码写完就算开发任务完成了：我宁愿相信这是编码者对付Leader的一个手段。没有一件开发任务其完成的时间和计划的时间正好一秒不差，一般都会让完成的时间少于计划的时间。编码者完成任务后应该向Leader及时交付工作成果。如果在最后一秒交付，就没有了验收的时间，编码者会认为Leader就会省掉验收的步骤，自己就可以侥幸过关，不用承担可能的返工的辛劳。
    很多项目，都是因为小的任务的拖延和质量不过关而导致延期甚至失败。

    领导说得都是对的，我没意见：这是典型的推卸责任的做法。领导交代任务时满口“是！是！是！”没有一点自己的想法的建议。其实潜台词就是：这可都是你领导的想法，将来我可不担任任何责任。还有一种可能，要么该人是个白痴，要么该人是个十足的马屁精，不愿或不敢反对领导。
    很多公司，要么是没有民主，领导一言堂，导致员工不愿承担责任。要么是放任自流，无为而治，员工随心所欲，像一盘散沙，不能形成有效的生产力或者效率低下。

    凡事都有Team Leader帮忙检查：这也是典型的推卸责任的做法。把责任给领导一推了事，自己乐得自在。不多说了。

    只提出问题而不负责解决，解决问题是leader或PM的事：也是推卸责任的做法。也不多说了。

    工作既然交给我做就应该信任我：这确实是一个误区，但经常被人不当回事。问题主要出在对“信任”的理解上。“信任”不是放任，不是全权移交。记住任何“信任”都是在一定条件下的信任。虽然“信任”，但一定的监督和过程控制还是必不可少的。

    上班时浏览技术网站没有问题：公司和团队领导鼓励大家学习，有个说法就是“缔造学习型组织”。事实是，没有任何一个人能够控制自己在学习结束立即投入工作，或者是在工作之余上网学习。上网学习往往成了别的浪费时间的合法借口，“上网学习”其实经常是在 QQ 里闲聊或迷失在互联网的丛林里不能自拔。
    建议：公司内部用于开发的局域网不连接互联网，专门设立上网机房/机器，由领导监管。

    工作态度好，工作年限多的就可以做领导：不一定。工作态度好说明是个好员工，工作年限多说明资历老，但这都仅仅是成为当领导的必要条件之一，当领导还需要很多其他条件，比如管人和管事的沟通和协调能力。
    但是，公司必须注意，对工作态度好，工作年限长度员工，必须给予足够的尊重，即使不能当领导，也不能让他们在经济上、地位上吃亏。这些员工是公司的宝贵财富，是他们让公司的文化和业务一步一步的传承下来，成就了公司的今天和明天。但也不能让老资格干涉和阻挠现任领导的工作。怎么取得一个平衡，就要看更高的领导的能力了。

    提供机会锻炼组员的表述能力：这个是个很好的做法！沟通和信息传递是工作中很重要的步骤。而能不能有效和精确(!)地沟通，则完全依赖于员工的表述能力。不知道是因为什么原因(又是中国教育体制的原因吗？)，现在的很多程序员，其语言(包括口头和书面)能力很差，说不能说，写不能写。所以“提供机会锻炼组员的表述能力”是弥补和提高员工语言能力的好办法。其实这对塑造员工的个人人格也是很有益处的。

    要请别人帮忙就要站在对方的立场上来考虑问题：这个我举双手赞成！道理不再罗嗦了。我建议把这个原则推广一下，不仅仅是在软件开发组织中是这样，在社会生活中这条规则照样适用。如果别人不是欠你的，任何人都没有义务无条件给你帮忙，所以首先站在别人的位置上考虑问题，是一种思想方法，也是一种品德。

    张庆(网眼) 2009-3-5
    来自“网眼视界”：http://blog.why100000.com
    “十万个为什么”电脑学习网：http://www.why100000.com
    CSDN博客：http://blog.csdn.net/zhangking

    /***********************************************************************
    转载来自程序员俱乐部的“【转载】正规军的军规”
    （2009-02-26 http://club.xasoft.org/?uid-4-action-viewspace-itemid-7464）
    程序员俱乐部的来源[http://www.javaeye.com/topic/296128 ]
    ***********************************************************************/

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

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

     - 开发人员没有意识到之前他的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。

    工作技巧

    1.及时回复

    及时的回复向你寻求帮助的人，可以给人一个好的的印象，同时也可以减少一些不必要的麻烦。

    例如：有一次Lucky发邮件要求所有team leader协助她检查FRD，FSD和DSD之间的gap。结果邮件发出后，只有Hikelee回复了她的邮件，告诉她会尽快完成任务。事后Lucky曾多次公开赞扬Hikelee的这种良好的行为习惯。

    Winter在负责督促检查Document任务完成情况前，也没有觉得及时回复别人To给他的邮件有多么的重要。直到他负责了这项任务没人回复他的邮件后，他才深切的体会到原来及时地回复邮件是多么的重要。这不仅是个礼貌的问题，可以减少很多的沟通成本。

    此外，及时的回复邮件还可消除发件人的顾虑，避免一些不必要的麻烦。Andrew D有一次要求我帮他增加一项Filter Service的功能来演示给他给客户看。当时我因为工作忙，没有在立即回复他我们已经在讨论Solution，Impact和LOEE了。结果4天后，他开始向我的领导们抱怨我没有受理他的请求。可见及时回复邮件的有多么的重要。

    2.消除或减少不必要的Wait和Rework

    我们的Team Leader应该学会发现和总结我们的组员在哪些方面或什么情况下容易造成不必要的Wait和Rework。Case by case的教导他们主动沟通，分清轻重缓急和如何提高工作效率。

    逐步建立和完善现有制度和流程，把我们的流程和经验记录到wiki中。

    下面有些实际例子以供参考：

    例1：如果讨论一个问题时，在场的人没人能够最终拍板时，应该在问题得到澄清后立即停止。找到有仲裁资格的人裁决，而不是无休止的争论。

    例2：最近一段时间每天早晚都有很多人等着在VSS里录入bug fix计划和bug完成情况。等着别人check in或时时惦记着去检查是否可以都不是最好的办法。

    此时，我们可以先发邮件TO给主管bug fix的Saul，CC给PM和自己的组员，尽早通知到所有相关人员。然后在一个比较空闲的时间再去更新bug tracking sheet。

    3.提供机会锻炼组员的表述能力

    我们应当多提供一些机会锻炼组员的表述能力。例如让组员自己讲解DSD，自己做Demo，自己准备一些training给大家。

    但是事先应当提前告知，让其做好充分的准备。以免达不到效果，还让组员觉得我们是有意刁难他们。

    4.要请别人帮忙就要站在对方的立场上来考虑问题

    例如：最近有一个Abu Dhabi的ASI Table Share Drop Down的feature。Jerry Lu认为现在的solution不好，要求我们rol - back已完成的代码，并在当前版本内按照新的approach做。

    我经过细致的分析和比对发现Jerry Lu的solution的确比现在的solution高明的多。但是因为临近release而且重构的代码改动量比较大，所以最好是推迟到下个release从做这块的代码。

    为了说服Jerry Lu同意我的观点，我首先站在他的角度去想他可能会问到哪些问题，如果不同意他的主要顾虑是什么，他需要知道哪些信息才可以去说服其他的人？

    带着这些问题和预先准备好的答案，我晚上找到了Jerry Lu。先告诉他旧的solution的弊端有哪些，新的solution好在哪里，Jerry表示这正是他决定弃用旧的solution的原因。然后我告诉他要按照新的solution我们做需要做哪些方面的工作。这时Jerry意识到现在改代码的风险较大，但是他又担心如果不按新的solution做，旧的solution又不能满足客户的需求，而这个功能又必须要在6.7.0提供。我告诉他旧的solution也能满足客户最基本的需求。

    听到这里Jerry说他已经同意postpone了，但是还需要想办法去说服Andrew D。我就告诉他，不用担心，我们有办法可以在后续版本中删除旧solution的代码，同时还可以将旧的solution自动切换到新的solution中。这样我就帮助Jerry找到了合适的理由去说服Andrew D。