正规军的军规2

这个文章是接前一个文章的，本来是一起的，但是贴不下，就另外开一个文章了。这篇是讲一些技巧的，虽然不是严格的规则，但是使用这些技巧将让你从合格转向优秀。

<!----><!----><!----> <!---->

工作技巧

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 。

 

介绍一下我们公司的背景知识，我们是一个通过cmm5的软件外包公司，呵呵，又是外包，好在我们这个项目组是项目外包，所以是在公司所在的办公而不是在客户所在地研发（其实我们的客户和我们是同一个老板），因为客户在美国，而美国的工程师比较贵，所以就采用这种离岸开发的方式。我们的客户也是专业的软件公司，有优秀的分析和设计人员，唯一没有就是我们这种工蚁了，呵呵。我们在每个开发中每个过程都需要和客户进行确认的，所以严格的过程和文档是保护我们的有力工具，呵呵：）

其实我觉得这些技巧已经不仅仅限于软件开发的工作了，1和4可以对于所有公司通用，2和3主要应用于技术性的工作。

我的一点儿看法：
也许是受了《人件》的影响，我认为没有及时回应向你寻求帮助的人，并不一定是态度问题。事要分轻重缓急，回应是必要的，但你得保证自己的效率。其实是一个工作习惯，早上来check out，晚上走check in，你不能专心做好你自己的工作，而是关心解决别人的问题，除非你的工作就是问题处理专家。
另，“我们在每个开发中每个过程都需要和客户进行确认的，所以严格的过程和文档是保护我们的有力工具”，真好，我们就做不了，人家说你们自己确认签字都行了，牢骚啊。

有没有看过另外一本书《尽管去做》（我已经发到论坛上了），可以下载看看，
还有一本值得推荐，《如何掌控自己的时间和生活》

对于文档确认的方法，我觉得不是最好的，更好的方法应该是让团队和客户之间建立起紧密的信任，质量好，用起来方便-》客户信任-》更好的质量，更好用的功能-》客户更加信任
这才是一个良性循环。