当前的工作 ～记述 —2011年7月9日

今天周五，比较空闲一下，我想记录一下当前工作的感受：

MR的工作对于我来说还是具有很大的吸引力的，虽然MR的工作很繁重，需要十分的细心，面临各种挑战，但我从内心深处还是蛮珍惜这份工作的，也是蛮喜欢这份工作。

首先， MR这个团队有着Open的氛围：

不管你是leader，还是普通的工程师，只要是你说的有道理，能够改进我们的工作，对产品质量有好处，我们都愿意听。这点从我们日常的CodeReview中可以看出，我们都可以在code review的时候比较大胆地给出自己的看法和考量。这样正是我比较看好的一点，我们每个人都可以从自身的角度，以问题为中心进行发散性思维 ，从case的总体概况到各个细节。

其次，MR工作富有挑战：

MR做的差不多都是十分复杂的case，单纯的考虑远远解决不了问题，我们团队的目标是第一次就把事情做对，零Defect Fix。 这个目标还是十分具有挑战的，尤其是对于复杂的Case而言。MR的case复杂的分为两种，一种是技术上难以实现的，比如客户期望的功能，从我们技术角度很难实现的，但客户却十分想要的。 第二种是关系复杂，涉及面广的，scope大的，由于本身的产品就是平台性质的，模块多，逻辑复杂，有些case需要解决的问题远远超出case本身，我们需要针对整个产品，做全盘考虑，或是针对产品的某个层次做全面考虑，在实现过程中，技术的筛选，性能的考量，深层次逻辑的挖掘验证，单元测试的覆盖都需要把工作做到实处。因为一不小心就容易出现Defect Fix的情况，那是我们最最不愿意看到的。

用Ken的一句话说就是，单纯的从代码上Fix原始问题只是一个开始，它占不到一半的工作量，更多的工作，比如同类问题的研究，解决，性能的测试，各种声明支持的平台系统（各种操作系统，数据库，客户端）上验证，Code Review，代码格式，solution是否最优，甚至收集所有相关的已有问题，本次case不做fix的都需要按照流程走。

外包的工作性质决定了我们需要更多的为客户考虑，从客户的根本利益出发，处处小心谨慎。

再次，MR有着一套适合自己的流程和规范：

MR组有一个严格的流程，我个人并不认为这仅仅只是形式，因为这个流程的很多环节能确实的提高工作的质量。

Issue Description: 这个环节就是对于原始Case 的理解，不仅抓住case的问题所在，还要把所有疑点都搞清楚，不清楚的尽早跟客户沟通。

Root Cause: 这个环节我们需要对Case 进行更深入的研究，一般是从技术层面找出问题的症结所在。

Workaround: 这个是用户都喜欢的好东西，Bug的Fix,测试,含有Fix的Build的release需要一个比较长的周期，而workaround是一些折中的技巧或是方案，让客户在不Fix产品问题的情况下克服掉他们的问题，满足用户的需要。如果有workaround我们一般都会在第一时间提供，并放到JIRA的case中，以便客户在第一时间拿到。

Solution: 包含方案的设计，实现。这是个具有挑战的环节，我们需要考虑综合各种因素给出最优的方案。经常会遇到 “牵一发而动全身”的情况，这其中的酸甜苦辣估计只有MR的同仁们才最有感触。

Unit Test: 这个单元测试不是指类似于Junit的单元测试，这个单元测试是指从Develop角度的测试，我们尝试通过这个测试来保证Case的质量，所以这个测试的内容就十分宽泛，所有有可能影响到的模块，我们都需要测试。这个环节往往也是最有挑战的环节，因为一旦测试不全面，没有发现潜在的问题，Defect Fix就会不期而至。所以你会发现，对于一个简单的Case，可能只修改了一行代码，但我们MR的同仁却四处找环境来测试，测试Thin Client， 测试HMI... 一开始进入MR，我感觉真的蛮麻烦的，但现在已经喜欢，感觉挺有必要的。

Code Review: 这个是个十分有价值的环节，很多问题都在这里被公之于众，把潜在的问题扼杀在萌芽中。这个环节也是我们MR的同仁共聚一堂，各抒己见的时候，虽然有的时候会因为有些问题的看法不同而各执己见，但大家都是对事不对人，所以我们仍然是很好的同事。有时活跃的气氛让大家在保证质量的前提下轻松度过。有的时候，对于复杂，和我们这边自信心不足的case，我们会发送SJC Code Review 给我们的客户Rockwell，由他们十分资深的工程师，或是架构师来审核我们的方案。 

CheckList: 这个CheckList可是MR工作经验的结晶，我们用它来检查Cas存在的潜在问题，CheckList会提醒我们从各种角度来层次来考虑case解决的质量，比如性能，比如各种平台，client端，比如code的格式，比如我们的各种约束条件..

Close it: 如果以上环节都没有问题，那么就进入最后一个环节了，即Close环节，这个环节也并不单纯，我们需要十分小心的Check 代码的提交URL，提交到PTR branch，并且Merge到 Patch branch，找同事做一次Double Check确保提交没有问题。然后就是在JIRA case上更新信息和状态，把我们上面几个环节的产出，比如Root Cause, workaround, solution, known issues更新到JIRA上去，状态改为Ready For QA, 需要FP或BP的，就把FP， BP开出来。那么这个Case在Develop环节算是结束了，等待专业QA的测试。

再次，英文沟通的提升：

在MR一个很明显的一点就是对英文的要求提高了，我们不能那么随意的写几个句子就发送给客户的。MR的英文沟通有自己的套路，也有自己的流程。

套路：MR英文的邮件沟通一般是和Rockwell的纯老外沟通，针对Case的问题沟通，着眼于解决客户的问题，回复客户想要的东西。为了能够让收件人十分容易的获取我们想要表达的信息，我们的邮件一般都是标题醒目，主题内容框架清晰明了，采用plain English，一般是对写出的句子进行不断的重构，希望获取更好的表达效果。为了获取更好的表达效果，我们有好多技巧可以采用，下面是我总结的一些：

1. 变换内容的顺序，先把结论放在最前面，然后描述细节，这样如果收件人很忙，那么他就不用通篇来查找他想要的结论。

2. 对于复杂的逻辑块采用图文并茂

3. 采用清晰的格式， 比如一问一答的格式

Q:

A:

; 比如对于步骤的描述，采用格式：

Repro Steps:

（1）.

（2）....

4. 慎用一些词语：比如By design，我们不可以那么随意的就说一个问题是By design, 除非有文档明确的指出. 比如Maybe, many， some，我们一般倾向于给出确切，肯定的信息。

5. 切换角度，邮件内容的描述要考虑收件人的认知层次，比如客户Elaine，她对技术不是太熟悉，我们一般是从容易理解的角度来描述一个问题，而不是单纯的从技术层面上描述。

6. 采用一些有力的材料来证明我们的结论，比如产品文档的内容，界面的展示，或是核心代码的截图...

流程: 我们不会写完邮件就直接发送给客户，我们会先把邮件发送到MR组内的所有人，然后MR的成员一般都会对这个邮件进行检查，如果发现问题都可以随意的回邮件提出问题的所在，这样我们最后发出的邮件就是我们所有人审核过的，那么质量就有了保证。

总之写邮件的目标就是：内容的方向正确，陈述准确，涵盖内容全面，表达脉络清晰，简洁，开门见山，格式一致。

再次，可以和RA一群十分资深的工程师合作：

Rockwell的技术工程师，大都有着10年以上的工作经验，他们在美国加州，有些人一辈子着力于代码的设计，所以他们的资深毋庸置疑，我们通过学习他们设计的软件来提高自己，也通过工作中和他们的技术沟通来像他们学习。学习他们逻辑的设计，复杂问题的解决办法。

再次，MR让员工成长的更快，能力更强：

MR的规范是要对于escalated case(紧急case)，每天都要有更新，那么这就督促着我们每天都要有进度的前进，因为没有进度上的前进，我们的更新似乎难以启齿。所以我们经常需要抓紧时间，获取问题上的突破，不拖拉，这对我们更快的成长无疑是弥足珍贵的。

最后，MR有着一支老中结合，友善互助的团队：

老员工工作年限比较久，Ken和Gil是我们的前辈，他们身经百战，经验丰富，他们的帮助让我们能够在关键点上寻求突破，也引导我们学会如果处理复杂问题，如何应对难题。由于MR的性质特殊，很少有工作年限尚浅的人加入。

后语：

有挑战，才有激情，才有克服困难后的成就感，这种挑战和成就感给我的工作输入了源源不断的动力，让我在欢快的气氛中迎接更大的挑战，收获更多的乐趣。