以下为本人在公司内部关于项目质量和工作效率邮件回复的一此意见和想法。

1、 谈流程

不可否认流程的重要性，但我们需要根据具合格情况分析，不断的梳理和优化我们的流程，让流程更好的指导我们工作，而不是束缚。目前，我们的流程慢慢多了起来，感觉不如以前敏捷了。经过rpm改造后，无论在测试环节还是发布阶段，较之前失去了很大的灵活性。测试阶段，开发bugfix后想在测试环境验证，每次必须重走aone的流程及打包布署，相比之前的build效率真的差了好多。当然，也许是我们项目组对这个流程熟练度、方法还不够，很多环节有待改进。

发布阶段，目前统一由SCM来发布，必然会导致开发对线上环境及发流程更加陌生，同我们提倡的打破边界，敏捷响应有些相背。再者，SCM资源有限的原因，要支持ITU众多产品线，能否应付的过来，始终是个问题。发布统一管理有好处，同样也带来了弊端，ITU不同于网站，大多数的技术团队共同在维护在几个应用，而itu的应用多、规模相对小、环境各异，这样的产品线采用统一管理性价比不高。希望相应的owner，能不定期的搜集各产品线的意见和反馈，不断的优化，让我们的流程更合理。

2、 谈自测

我们团队一直在强调自测意识，也在这方面不断的总结和改进。我觉的要提高自测，首先应让每位开发同学形成较好的自测意识，而不是自上而下的命令式管理，只有自己有这方面的意，才会去思考、去想办法，去实践。再者，需要PM或技术经理去思考，目前阶段实行自测会有什么困难，如没有系统的自测方法、时间不充足（需要熟悉下阶段的UC、下迭代的设计、单元测试补写等），找到这些困难或问题，就容易对症下药了。最后，不断总结和积累自测方式，优化项目流程。自测不是一种形式，而要追求效果，开发自测同样需要计划和方法，所以我们需要向QA同学请教，总结过去 bug常犯的错误，整理自己的check项。相信通过这样的一些自测方法，能真正提高我们的项目质量，打破同QA的界线，我们的开发、测试资源比例可以得到更大的优化，将以前开发阶段紧，测试阶段松的状况加以改善，使整个项目过程中的紧张度趋于平缓。

3、 谈故障分

“尽量不要让故障分成为大家包袱，可以考虑被实施产品对事故级和A类才对个人计故障分，B和C类故障分记在主管头上！”，个人也比较支持骆驼的观点。目前大家对线上故障都小心翼翼，大家对质量的意识很高，这当然是好事，但同时带来的影响是效率低了。我的观点是，作为增值服务的互联网产品，我们更需要快速迭代增量提供用户价值，尽快获取用户反馈并改善产品，产品推出的迟早，不仅影响获得回报的时间，还影响到获得价值的多少，错过了一个时间窗口，产品可能就不再有任何价值。所以，我们需要找到一个平衡量点，可接受的质量状况达到最大的效率。

从客户第一角度谈质量，某些时候，客户可以接受服务偶而不可用重启下，却不能接受产品没价值、交互性太差，操作太复杂。所以，对于客户来说什么对他们更重要，就需要我们每个人去分析和评估。所以，我们一味只注重质量，而忽略客户真实需求，那就太悲哀。我的观点是，case by case，带着这样的观点去思考和解决问题。

4、谈敏捷项目团队

从打破边界，我想到了一体化的敏捷项目管理团队，一个目标一致、自我管理的团队，应该具备良好的目标意识和执行力，不仅能管好自己的一亩三分地，同时也能站在项目、团队的角度看待问题。PD出现了问题，开发积极去弥补；开发出现了问题，QA积极去弥补，项目团队的目标非常一致。每位项目组成员一定要把好每一关，万不可把问题向下抛，因为还有开发或QA会把关，所以差不多就行了，这样往往就是灾难的开始。