项目(三)执行

文章来自 https://time.geekbang.org/column/article/156858 修改

打造品质，要从头开始“闭环”

一定要避免出现 项目或功能点开发完成后, 发现和项目发起人想要的结果以及当初指定好的结果大相径庭, 这就代表项目是失败的, 出现这种问题一般由以下几点导致:

• 用户需求和市场环境变化而没有及时同步到产品规划中, 互联网公司的产品一定是螺旋式快速迭代和调整的
• 需求和设计根本没有经过严格的把关，就匆忙投入开发
• 在传统的研发中间过程中，很难看到串连起来的功能效果，产品经理必须等到快上线了，才能看到和真实体验到可完整运行的产品
  在产品的执行过程中, 我们应当允许适当的试错出现, 目的是为了避免更大的错误被隐藏.
  在项目执行的过程中，想要降低偏差、减少返工，需要构建系统能力，在产品研发的整个过程中，建立起真正闭环反馈的产品验证机制
  开环与闭环之间的关键差异，就在于有没有反馈环节，以及系统是否会根据反馈自动调节
  所以我们需要通过几种手段来保证执行阶段不出现问题

方案评审

OARP 决策机制

需求评审、交互评审、视觉评审都是非常基本的闭环验证方法
要想执行中不走样，就必须把方案评审做到位, 评审的精髓不在开会，而在于背后的决策机制, 只有决策机制清晰，职责分工明确，方案评审才会有好的闭环效果.
OARP 是 Owner、Approver、Reviewer、Participant 的缩写，分别对应四个关键角色：

• 负责人（Owner）：负责给出方案，组织各方讨论并推进做出最终的决定；
• 批准者 （Approver)：最终批准者；
• 审核者（Reviewer）：负责人和批准者挑选出的审核人。审核者有责任对文档进行讨论分析，并提出反馈意见，负责人必须重视并给予回复；
• 参与者 （Participant）：其他提供意见的人。参与者会收到文档的相关信息，可以对相关问题做出反馈
  

OARP 是一套决策机制，你需要为项目中每一类方案的评审，确定明确的角色和职责，让各角色应享有的权利、应履行的职责，都得到规则上的保障，这样才能更好地确保方案质量，把后期的返工降到最低。

Bug Bash（Bug 大扫除）

发动干系人, 在若干阶段对项目目前的产出进行整体的使用和评估

• 在版本的需求稿和交互稿完成之后，专门安排一段时间，组织团队成员一起，集中精力给需求稿和设计稿找问题
• 在项目开发里程碑的末期（比如 Beta 版发布前），划出一个专门的时间段，在这期间，所有参与项目的人员，集中全部精力一起来给项目找 Bug，目的是从各个维度衡量和体验产品。
  通过多种方式刺激干系人的参与激情:
• 时间：测试类的 Bug Bash，你可以选择在全面功能测试结束后，Bug 趋于收敛的时间段开展；需求设计类的 Bug Bash，一般会放在需求或设计稿完成后举行。这个活动需要一到两个小时的时间，你一定要提前排除所有干扰；
• 地点：你需要设立一个单独的作战室，鼓励参与者自带笔记本，让他们尽可能集中精力做这一件事。同时，作战室可以提供一些零食和饮料，让活动更有氛围；
• 参与者：除了研发和测试，产品、设计、市场、运营、销售等项目组不同角色的人群，都需要参与到这场活动中，这样你就可以获得更加丰富多维的视角；
• 现场安排：你可以把现场反馈的问题直接贴在白板上，或者通过电子白板，来滚动更新 Bug 或建议的排名情况。需要注意的是，营造互动的氛围非常关键，如果因为空间受限，参与者做不到在同一地点进行，你至少也要在通信群中实时更新排名情况的变化。
• 活动结束：在活动结束后，要直接公示 Bug 或建议数，现场给奖品，并发邮件通报全组。
• 最后，在对 Bug 进行去重后，还要分类定级，确定哪些是必须修，哪些是改了会更好。另外，千万不要忘记公示结果，明确修复计划。

冒烟测试

测试人员推荐使用冒烟测试法

做计划时要明确定义完成标准，而冒烟测试用例，可以说是开发和测试之间最基础的合约
进入开发环节后，需要安排专门的测试用例评审，让开发和测试对标准冒烟用例集达成约定，这个约定就会成为进入测试的准入标准
开发发起提测以后，测试人员就会依照这个标准用例集进行冒烟，并记录冒烟测试通过率，如果通过率不达标，就打回修正并再次提测
如果你是在完全没有基础的团队中推行这个做法，可以先从测试人员记录冒烟测试通过率开始。接着，收集相关数据，和团队在回顾会上一起看看冒烟用例失败所导致的后期返工成本，讨论出一种更好的确保质量的做法
可以选择从一个合适的起点开始，比如 80%，然后再一步步逼近更好的提测质量(100%)