一、为什么会出现方向跑偏
做项目最怕的就是快做完的时候，项目经理或者用户看了之后说，这压根不是我想要的，遇到这种情况，轻则变通修改，重则推到重来。不管哪一种，对项目团队带来的损失都是重大的。
出现这种情况的原因有很多，比如常见的如下：
互联网环境多变，产品自己的想法在不断地随着环境发生迭代变化，当然了，这种情况严格来说属于需求变更的范畴了，这个在后面的文章中会讲，该如何合理地处置。
需求和设计的确定没有经过严格地把关，可能用户只是对某个需求提了一下，开发团队就开始干活了，中间过程由于开发的特殊性，无法整体有效地给用户展示流程和效果，导致临近结束，用户才发现根本不是他要的。
二、如何防止方向跑偏
针对如上第二种情况，跑偏的原因在于项目的推进过程中没有形成反馈修正的闭环链条。它完全就是一个开环状态，用户发出指令之后，再无收到反馈和主动干预的措施，最终做成什么样子，只能听天由命，出现偏差的结果也就在所难免了。
通过以下一些方法可以有效地解决项目推进方向跑偏的问题。
2.1 方案评审机制的建立
界面设计、需求文档、开发设计等方案在必要的时候都可以进行评审。评审并不是仅仅开一个会，照本宣科读一下方案的内容，而是需要各个角色发挥自己的作用，把评审工作做到位：
负责人，指给出具体方案设计的人，组织和推进方案的落地；
批准人，方案的最终批准确定人；
审核人，负责人和批准人委托的审核角色，负责对方案仔细核对审核，搜集众人建议并给出反馈等；
参与人，提供其它意见的人；
方案的评审并不是一蹴而就的，中间可能反复多次迭代，螺旋上升，这取决于负责人前期和各个角色的沟通效果以及收到的反馈多少有关。
2.2 进行Bug Bash
Bug大扫除是指在项目开发某个里程碑的末期，专门找出一个时间段，让团队所有人聚在一起，集中大家的精力一起来帮项目找找BUG，目的是从各个维度衡量和体验产品。
可以进行Bug Bash的阶段不光只有系统代码，在设计稿、需求稿、测试案例等即将交付的时候，也可以组织进行。一个人的思路和想法也许是有局限的，所以导致产出的东西可能存在一些意想不到的Bug。但是大家凑在一起，思路和看法是各种各样的，经过这样一轮扫除下来，能把问题基本全部暴露出来了，避免后期因为这些问题而导致的返工和风险。
那么如何举行一次有效的Bug Bash呢？
时间上应该安排在里程碑的末期，Bug数量趋于收敛的时候，毕竟团队中本来就应该有专人来做专事，大家的Bug Bash只是从不同角度来验证，起到的是辅助的作用。
地点需要选择一个单独的不被打扰的会议室，大家自带纸笔电脑等，确保大家这段时间能几种精力独立作战。
参与者应该尽可能包含丰富的角色，不同角色的思考角度不同，能最大限度上发挥Bug Bash的效果。
现场应该准备物理或者电子的白板，将大家的反馈Bug（无论是否真的是Bug）滚动更新到白板上，进行跟踪统计。
最后统计搜集到的Bug内容，进行去重和评审，分类和定级，对于提出重要Bug的人员应该给予奖励，最后通过邮件等方式公布结果，明确修复的计划。
Bug Bash的进行一定要在轻松有趣的氛围中进行，项目经理可以视情况增加游戏性和一些零食福利等，目的在于提高大家的积极性和热情，将Bug大扫除的效果发挥到最大程度。
2.3 冒烟测试用例评审
冒烟测试，在软件生命周期中所占有的时间比例较低，同时具有注重通过性轻细节的特点，是软件测试过程中一个不可或缺的节点，一个好的冒烟测试过程，对于软件测试效率的提升具有重要意义。
-
冒烟测试是对软件质量的总体检验。
通过冒烟测试，能够快速确认软件是否具备测试准入条件，避免出现正式测试阶段全面开展后甚至到测试中后期才才发现阻塞型缺陷等严重影响测试进度浪费人力物力的情况。
-
冒烟测试是测试人员对测试流程的熟悉。
通过冒烟测试，测试人员可以迅速熟悉测试总体流程，这一方面有助于测试人员准确制定测试时间计划，合理安排工作进度；另一方面也有助于测试人员提前做好相关设备、数据的准备，为正式测试的开展奠定基础。
冒烟测试执行，与正式测试的区别在于二者侧重点不同，冒烟测试关注的是阻塞型缺陷，包括但不限于流程不通、主要功能未实现等，而正式测试则属于全面、细致的测试，需要尽可能的发现全部缺陷并按其严重性进行区分。
因此，冒烟测试用例的评审，可以看作是开发和测试的交付准则，大家对这些案例的通过达成了共识。开发需要评估这些案例是否全面有疏漏，然后根据这些案例自测代码流程，确保符合交付测试的标准。测试同事则需要在提测后进行冒烟案例的执行，记录执行结果，统计冒烟测试达标率。一般要求达标率在80%~100%之间，团队也需要根据每次冒烟测试的结果进行审视改正，力争每次都能做到100%。
