离岸开发-最重要的东西-质量
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的另一个问题更加让人难以回答：其他既定的规则是否也真的在遵守？?规则就是这样的东西，你遵守它，没有犯错误的时候，就没有任何问题。一旦你不遵守它，犯了错误，那么它就出现了，而且会让你很难以对付。
三、定期检查
规则是制定了，但是否真正有效的实施了，在实施过程中是否发现了问题而需要改进？这些都离不开定期的检查。
如果没有定期检查，大部分的规则都会在一定时间后消失得干干净净。?
质量的改进和保持是一个持续的过程，它没有终点，只有从一个阶段到另一个阶段的过程。??
?
