这个文章是接前一个文章的，本来是一起的，但是贴不下，就另外开一个文章了。这篇是讲一些技巧的，虽然不是严格的规则，但是使用这些技巧将让你从合格转向优秀。
<!----><!----><!----> <!---->
工作技巧
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 不好，要求我们 roll 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 。