项目管理是门大学问，尤其是快速迭代的互联网产品，如何在效率和规范之间做取舍，考验着产品经理的项目把控能力。昨天晚上的一次版本提审，引起了我对今天话题的思考：如何保证项目上线前临门一脚的准确度。
很多公司在产品迭代初期做的很好，无论是需求分析、计划排期、日常进度跟踪，都能有清晰产出，但到了测试阶段，UI、开发、测试、产品同时介入，改Bug、发版、测试、验收循环进行，一方面产品经理要参与测试，另一方面还要构思、设计下一期需求，很容易导致后期的验收不足，节奏混乱，甚至提审前的最后一个包都没验收就上线，造成线上Bug风险。今天就讲讲如何规避这一风险，尽量让这一过程可控。
以我个人经验，建议从提测到提审阶段，设立严格的“走查”流程和“上线验收”流程，以此保证产品质量。具体流程如下图所示：
整个流程分3个阶段：走查期、测试期、提审期
走查期
走查的目的，是希望保证开发提交给测试的，是一个主流程跑通，UI布局正确的包，从而提高测试效率，也能通过这个流程倒逼开发保证代码质量。尤其是UI方面，越早介入，越能提前发现问题。
具体执行中，建议以邮件形式记录每次的走查结果。内容为：
走查邮件：开发发出，邮件中包括可以被测试的安装包地址、可以被测试的主流程、提交走查的时间。发给产品、UI设计师。
走查结果邮件：由产品、UI发给开发，如果不通过，则要罗列每一个不通过的问题点，UI问题还要辅助以图片说明。如果通过，则开发可以将走查结果邮件转发给测试，附上通过走查的安装包地址，申请提测。
这一流程的目标是尽量保证1次走查通过，最多2次，如果超过3次就表示代码质量过差，或者开发根本没理解需求，需要反思和调整。
测试期
测试期通常包括2轮测试环境测试，1轮线上环境回测，要求开发在每次发提测包时，都要有邮件体现。内容为：
提测邮件：开发发出，包括通过走查的测试包的安装地址，可测试功能模块，提交测试时间。
每完成1轮完整测试，就对提测邮件进行回复，回复邮件中包括所有测试中发现的Bug数量，测试覆盖情况，以及Bug率等指标，并督促开发修改。
提审期
是否进入提审期一般由测试决定，测试完成最终线上回测后，觉得达到上线标准，就应该给产品经理发送提审邮件，申请产品经理做最终上线前验收。内容包括：
验收邮件：测试发出，包括准备提审的最终线上包安装地址，以及Bug的遗留情况。
产品经理最终根据产品主流程再进行一次操作，觉得没有问题达到提审标准，则可回复验收邮件，同意提交应用市场，接下来可以由测试，或开发人员进行正式提审发布。如果验收不通过，则继续由测试确认Bug程度，交由开发修复，直到可以提审为止。
提审期也是希望测试质量能得到保证，尽量减少不通过的次数，这也考验着测试人员的耐心和用例覆盖度，当然产品经理的验收经验也是关键。
以上流程属于理想情况，虽然能保证进度可控和清晰，但每一步均要发送邮件、回复邮件，无形之中也增加了执行时间和成本，因此真正应用这一流程时，还是要根据团队的实际情况予以取舍。
以上是今天针对提测流程的思考，期待你的回复与我讨论~
