标签：blog http os strong 2014 div 问题 sp log
场景再现
=========================
BOSS：喂，小侯，在这喝咖啡呢，项目进展怎么样？
小侯：进展还算顺利，您不是一直强调 质量、质量、再质量吗，我刚刚和团队骨干“碰一下”
这是会议记录，您看看？
BOSS：我看看。
“首先，向质量推进科借调两位经验丰富的要员，每隔两周安排一次质量监督日。这一天两位要员主要会检查每个人到目前为止的工作成果。
其次，在项目结束后，安排一个人对项目成所有果物进行全面审查，进行二次Check。
最后，我们再邀请客户代表来到现场，对项目最后整体质量把最后一关。”
首先、其次、最后这三点都不错，你们开发人员在两个质量日之间做什么？
小侯：前紧后松，主要是赶赶进度。
BOSS：…………………………
=========================
有哪位朋友可以大胆猜想一下，最后{BOSS}会说什么？
答案无外乎有三种：
▲（赞同）“不错，坚持下去 好好干”
▲（反对）“不行，根本行不通
▲（两者之间）“感觉不对劲，是不是差了哪里？”
谈到质量，如果说项目经理的重视度为80%，那么BOSS的重视度为160%。质量失败了，项目经理丢失的是“饭碗”而已，而BOSS失去的则是竞争力、公信力，甚至还有生存力。这就是为什么，有些组织不惜成本要去筹建质量推进科的原因。这个科室不会为公司营业额多赚一分钱，但是它们的存在却是至关重要。
场景中的{小侯}恰恰看中了这一点，准备从质量推进科拉进两个人来严把质量关，如何推进也说得头头是道，{BOSS}最后到底会说些什么？
问题一：
“每隔两周安排一次质量监督日”看似是对质量监督有了保障，但这自始至终是一个事件而已，并非日常工作的一个方面。
每两周都会有一次质量大检查，届时会把70%，甚至90%的问题排查出来，这种方法方式本身没有错，怕是怕他人对其的误解。
团队某成员故认为“现在项目周期比较紧，赶进度是首要任务，缺陷、问题会通过质量日排查，到时候改修、对应就OK了，平时对质量的要求暂且放放，没必要那么较真儿。”一旦这种思想蔓延开来，团队成员就没有尽到个人一次就把工作做好的职责，他们也可能把质量日看成一张捕获缺陷、问题的大网，是两个星期一次的事，并非是一个持续的过程。
后期发现问题、分析问题、修正问题，本身就是一件耗时的差事，效率也不高。项目返工次数多、成本骤增、Release延期往往皆因于此。
问题二：
“在项目结束后，安排一个人对项目成所有果物进行全面审查，进行二次Check。”采取此种方法应该有一个前提条件“要确保在检测过程中不会出现低质量产品”。换句话说 低级的MISS、Bug不是这个阶段检测的对象。
虽说在项目结束时捕获错误、缺陷要比没有捕获要好，但是这么晚捕获是再糟糕不过的一件事。做过项目的朋友都知道，项目结束时修改一个bug所耗费的成本和工时往往是前期的数倍之多。
如果团队成员把“质量日”、“二次Check”看做质量保障，而放弃平时对质量的要求，后期的麻烦事………
问题三：
“邀请客户代表来到现场，对项目最后整体质量把最后一关”，这句话我怎么听都感觉到是一种逃避，把质量问题转移到客户身上。如客户能参与进来是最好，但是在如何计划质量、管理质量是团队的事。
团队要为质量负责，客户仅是验证最终产品是否满足他的期望而已，他不会为产品质量埋单的。
{小侯}提出的三点质量推进建议逐一被{BOSS}指出了不足和缺陷，如果是你如何完善这三点建议呢？
标签：blog http os strong 2014 div 问题 sp log
原文地址：http://www.cnblogs.com/xiaohouchengzhangji/p/3967159.html
