离岸开发-最重要的东西-质量

 对于客户来说，什么东西最重要？质量是最重要的。

不管你的工作速度有多快，如果你总是犯错，你的速度还有意义吗？
不管你的思路有多新颖，如果你的系统总当机，客户会买你的帐吗？   
打个比方，你购买了一个云计算的服务，可是三天两头服务就连不上，或者十天半个月数据就丢失。就算它再怎么便宜，功能升级的再快，你会用它吗？

对于离岸开发来说，质量更是重中之重。如果offshore无法保证质量，onshore自然也不会把活交给你做。

说到质量，就不得不说另一个东西：交付期限。

每个任务都不是无限期的，那么就出现了这个矛盾：为了在期限内完成，经常需要加班加点，这时就很难再保证质量了。那么到底质量和期限哪个更重要？

假如你买了一个期房，按照合同一年后交房。开发商这材料供应出了问题。如果换符合质量的材料，那么要延期半年交房，如果就用现在质量有问题的材料，

那么可以按期交房。你选择按期还是延期？

大多数人应该都选择延期--谁会要质量不好的东西呢？从这个角度看来，质量应该排在第一位。
可见，在质量面前，期限并非是那么的无可调整。

但是不是质量一定大于期限呢？也并非如此。例如某个产品，一年后预计上市。各种宣传，广告已经开始了，这种时候延期就不太可能了，即使有一些缺陷，

也必须按时交付。

质量大于期限的，著名的代表当数暴雪娱乐。相信所有的暗黑迷都经历过不断跳票的感觉吧。
期限大于质量的，记忆犹新的当属苹果公司的地图软件。推出时错误极多，但是仍然上线了。
 
质量和期限相比，到底谁更优先，固然需要客户去决定，但是对于离岸开发中的offshore来说，如果客户没有特殊的要求，一定要把质量放在第一位。
正所谓“人的名，树的影”。offshore凭借什么来博得onshore的信任，进而得到更多的项目呢？质量就是最好的招牌。如果你能保证系统一年都不出一次事故，

那offshore队伍的壮大也仅仅是时间的问题。

 

相信每个人都清楚质量的重要性。但是如何提高和保证项目的质量？每天开会进行强调？还是制定赏罚制度，犯错的人严厉惩罚？

质量的管理，一定要找到行之有效的方法。

一、定期举行DP会议
所谓的DP，就是Defect Protection，就是缺陷预防的意思。DP会议的重要意义在于在事故还没有发生的时候，事先发现了事故的苗头，及时制定预防措施，

避免严重的事故发生。也就是所谓的“防患于未然”。

DP会议如何进行，也必须要讲究方法。如果只是随便的讨论，就很容易变成走形式的会议。

我们在工作中都会进行review。review中发现的问题一定会记录在一个地方，通常叫review form。每经过一段时间，review form中都会有一些问题的记录。
那么DP会议中就可以拿这些review form来进行讨论。

 

review form的格式也非常重要。可以参考下面的格式：

 

review时间	review者	问题分类	问题内容	是否发生过	修改者	修改时间	修改内容	确认者	确认时间
2013/12/01	张三	内容不正确	漏掉了一个条件判断	是	李四	2013/12/02	增加了出货时间的条件判断	张三	2013/12/01

 

对于问题分类，也需要根据项目的情况仔细制定。例如，问题分类可以为如下几种：

>记述内容不正确

>违反既定的规则

>单纯的错误（例如丢字，漏字）

>格式不正确

等等。

 

通过“是否发生过”，可以判断哪些错误是经常出现的，这可以带来一些警示，这样的错误有可能带来更大的问题。

 

在DP会议上，我们可以把一定期间内（例如2个星期）的review form汇总一下，按照问题的分类，看看哪些错误的数量占的比重多；

按照修改者，看看谁犯的错误比较多；按照“是否发生过”，看看哪些错误是经常发生的。

 

我们会从中发现很多有价值的问题，例如:
· 有些问题经常出现。如果不改善，今后有可能造成重大的问题。
· 有些问题经过分析，发现不是个人的问题，而是工作流程的问题。我们需要去改善流程。
· 我们会发现一些问题是由于个人的工作态度导致的，我们要想办法去改变他的工作态度。
· 我们会发现一些人的质量有问题，需要重点关注一下。 

发现了问题，如果想要解决它，一定要分析问题的根本原因。何为根本原因的分析？
举个例子：某个人给客户做报告，结果写错了一个数字，遭到了客户的指责。
那这个人犯错误的根本原因是什么呢？
有些人会说：太马虎，不仔细。
其实这并非根本原因。马虎只是表面的现象。根本原因是这个人没有self review的习惯。做完的东西，自己不会去仔细的检查的一遍，所以会把错误流转到客户那里。 

为什么要进行根本原因的分析？因为如果不分析出来根本的原因，那么针对问题所制定的对策，一定不是行之有效的对策。

例如上面的例子。如果认为原因是马虎粗心，那么解决的方案是什么呢？恐怕也只能是不断强调他不要马虎，要仔细。
毫无疑问，这种强调是没用的。相信具有多年工作经验的人更是有深刻的感受。

接下来看看真正的根本原因的对策：如何避免他不做self review？
制作一个checklist，让他每次进行交付时，都必须提交一个checklist。
这样他是不是一定会做self review了？
什么？他实在太懒惰了，虽然有 checklist，但是他基本不看，全部check OK。

那么就在他交付之前，坐在他旁边，看他一项一项地填写checklist。坚持一段时间，相信他会养成这个习惯。
或者我们就不用电子版了，改用手抄版的checklist。让你没那么容易写OK。
衍生的各种情况不深入的讨论了，总之要铭记一点：如果没分析出来根本原因，那么对策一定是无效的。

其实DP会议主要做的也就是两件事:分析根本原因以及寻找对应策。  

二、制定必要的规则

正所谓国有国法，家有家规，一个项目若想保证好质量，必须要制定必要的规则。例如：遇到自己不了解的情况，不要自己判断，一定要报告联络；

向onshore交付之前，一定要进行内部review。
这些规则其实主要来自DP会议：分析根本原因，制定对策。有些对策就必须通过制定规则来实施。

 

坚守这些规则非常重要，既是保证项目的质量，也是保护自己的一种方式。

例如，项目中有这么一个规则：登录进产品环境的服务器时，必须要得到leader的承认。

某个人在调查一个数据的时候，需要登录进产品环境的服务器。不过他觉得要leader承认有点费时间，而且只是一个简单的检查，就在没有承认的情况下

登录进了产品环境的服务器。结果运气非常不好，虽然是一个简单的检查，但仍然造成的其他的错误。

这个时候，onshore首先要看的是，整个过程中是否遵循了既定的规则。

结果发现他没有遵循既定的规则。这个时候，onshore会问一个简单的，但是让你十分难以回答的问题：为什么你不遵守既定的规则？

onshore的另一个问题更加让人难以回答：其他既定的规则是否也真的在遵守？

 

规则就是这样的东西，你遵守它，没有犯错误的时候，就没有任何问题。一旦你不遵守它，犯了错误，那么它就出现了，而且会让你很难以对付。

三、定期检查
规则是制定了，但是否真正有效的实施了，在实施过程中是否发现了问题而需要改进？这些都离不开定期的检查。
如果没有定期检查，大部分的规则都会在一定时间后消失得干干净净。 

质量的改进和保持是一个持续的过程，它没有终点，只有从一个阶段到另一个阶段的过程。