最近一周基本上都是加班到深夜，原因是最近有两个产品的发布，不凑巧的是这两个产品的开发是还在试用期的新人，更不凑巧的这两个产品是原来的产品经理遗留下来的需求。需求本身也存在些许需求描述不清晰的地方。所以加班看来就是在所难免的通往不确定未来的必经之路。
加班是苦逼和悲催的，但是莫名其妙的加班尤其是加班后的奇妙莫名就就是不可原谅的，作为没有理想破灭的PM，我就像那个专治各种牛皮癣的老中医一样，在各种不服和纠结后尝试再一次去寻求解决问题的方法。也许我不能看到曙光，但我一定不能允许自己在黑夜中沉睡。因为我TMD就不相信这个世界上有专治老中医的牛皮癣。
互联网企业和传统软件企业在流程上最大的不同估计就是互联网为了适应用户需求而必须做出快速反应。所以互联网企业的研发流程多是敏捷的。敏捷就目的是适应变更，敏捷的表象是快速发布，但是从来不会有Boss告诉我，敏捷就意味着损失质量。
项目管理的三要素是：时间、范围、成本，从来就没有把质量放在三要素中，如果有人告诉你项目的三要素包括质量，那就让他去查查PMbok吧。
因为对于项目来说，质量是前提，是很难妥协和变通的。但是显然、质量即使不和时间成线性上的反比，但肯定是反向相关的。一个女人12个月生出来的孩子不一定会更好，但是5个月就把孩子生出来，大概是好不到哪里去了。
然后，无论是PM或者Dev抑或是Qa对线上故障都战战兢兢、如履薄冰。原因在于老板只看结果，不看过程。出来问题，老板的板子迟早是会打下来的，谁的屁股都不是金刚不坏屁股。
快速发布，如何保证质量？
在我看来如下三个关键点上的质量保证尤为重要1：PRD的Review； 2：代码的Review； 3：Testcas的Review。当然这里的Review是指保证质量的方法和手段，而不是大家走马观花的看看。并且我也从来不认为其他环节尤其是过程的执行力就不重要，就如同一个男人，如果3分钟都坚持不了，那还谈何技巧呢？
在这里，我们先假定质量是指狭义上的软件质量。
1、PRD的质量。所有软件开发模式都认可这样两个原则，a：质量是规划出来的，而不是测试出来；b：越在项目早期进行质量保证活动，效果会越好，并且成本也会越低。基于这两个原则，我们就更加可以相信，PRD文档的重要性。PRD文档作为产品的Mother和DNA在一开始就决定了产品未来的摸样，并且PRD是指导开发进行设计开发以及测试人员进行测试设计的关键性文档甚至是唯一文档。因为PRD文档在整个产品开发生命周期中的作用牵一发而动全身。PRD文档的质量依赖于用户、需求调研的广度和深度以及需求分析的经验和技能这无容置疑。但我们在此显然并不是为了告诉大家如何做好需求分析。我们只从Review的角度来看看如何在最后环节来保证PRD的不出错，没错Review不能保证我们的产品是一款优秀的产品，但是能够保证这款产品是一个不容易出错的产品。PRD的Review需要关键人物的参与、尤其是当PRD涉及到多个产品项目或者多个模块时，因为只有关键人物才有对系统整体的把控能力，能够帮助产品人员预防各种潜在和难以发现的陷阱。这些关键人员一般包括：业务的代表、开发的代表、测试的代表、运营的代表，这里的代表不是随便找个人就代表的，应该是这些team的leader.
2、代码的Review。结对编程和测试驱动是敏捷流程在开发阶段保证代码质量的关键方法，然后大部分公司的资源都很难允许这样做。在所有老板的概念中如果公司不出现争抢资源以及资源不够的现象，那个就是应该裁员的时候了。然后开发团队总会有些新人的进入或者对新的项目不熟悉的团队成员。在这种情况下，让经验丰富的工程师去Review新手代码或者做交叉代码Review是一种成本较低但性价比还不错的选择。
3、Testcase的Review。Testcase最应该被保证的是所有用户操作而导致程序运行的轨迹和分支需要覆盖，功能测试是无法覆盖到代码分支的，这是因为功能测试和单元测试的测试对方不同，但是功能测试已经要覆盖到用户的所有操作，正常或者异常，以及这种操作下程序可能的处理结果，从而确认结果是符合预期的。在这里有两种选择，PM写Testcase还是专业的测试工程师，在我的职业生涯中，这两种情况都有发生，但我个人更倾向于由专业的测试工程师来写Testcase。的确，PM一定是所有人里面对需求最清楚的人，但PM的思维模式是用户正向参与产品，也就是说绝大部分的用户是基于满足自己需求的方式来使用产品的，PM首先要思考的是如何让用户的核心需求最容易和方便的得到满足或者实现。但软件的问题中80%的问题却恰恰发生在犄角旮旯的程序毛刺中，而如何从鸡蛋里面挑骨头却是测试工程师的思维模式。所以说，PM很难写出来高质量的Testcase。但是，Testcase Review的关键人物一定是PM和Dev。没有谁比他们更加清楚自己设计和实现的产品了。
对于互联网产品来说，重量级的质量保证流程显然无法适应快捷的发布需求，所以对软件中关键阶段的产出进行质量保证是解决问题的最有效方法。但是我并不敢肯定这种方法的普遍适用性，所以你自己看着办吧！
====================================分割线================================
最新内容请见作者的GitHub页：http://qaseven.github.io/
