正规军的军规2
这个文章是接前一个文章的，本来是一起的，但是贴不下，就另外开一个文章了。这篇是讲一些技巧的，虽然不是严格的规则，但是使用这些技巧将让你从合格转向优秀。
<!----><!----><!----> <!---->
工作技巧
及时的回复向你寻求帮助的人，可以给人一个好的的印象，同时也可以减少一些不必要的麻烦。
例如：有一次Lucky发邮件要求所有teamleader协助她检查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和自己的组员，尽早通知到所有相关人员。然后在一个比较空闲的时间再去更新bugtracking sheet。
?
3.提供机会锻炼组员的表述能力
我们应当多提供一些机会锻炼组员的表述能力。例如让组员自己讲解DSD，自己做Demo，自己准备一些training给大家。
但是事先应当提前告知，让其做好充分的准备。以免达不到效果，还让组员觉得我们是有意刁难他们。
?
4. 要请别人帮忙就要站在对方的立场上来考虑问题
例如：最近有一个AbuDhabi的ASI TableShare Drop Down的feature。Jerry Lu认为现在的solution不好，要求我们roll back已完成的代码，并在当前版本内按照新的approach做。
我经过细致的分析和比对发现JerryLu的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。
?
1 楼 rocket 2008-12-17 介绍一下我们公司的背景知识，我们是一个通过cmm5的软件外包公司，呵呵，又是外包，好在我们这个项目组是项目外包，所以是在公司所在的办公而不是在客户所在地研发（其实我们的客户和我们是同一个老板），因为客户在美国，而美国的工程师比较贵，所以就采用这种离岸开发的方式。我们的客户也是专业的软件公司，有优秀的分析和设计人员，唯一没有就是我们这种工蚁了，呵呵。我们在每个开发中每个过程都需要和客户进行确认的，所以严格的过程和文档是保护我们的有力工具，呵呵：） 2 楼 rocket 2008-12-19 其实我觉得这些技巧已经不仅仅限于软件开发的工作了，1和4可以对于所有公司通用，2和3主要应用于技术性的工作。 3 楼 shishi11 2008-12-19 我的一点儿看法：