Showcase简单来说就是开发团队把开发好的需求或产品雏形，给产品相关干系人、专家进行阶段性成果展示的过程。目的是为了获取对产品的反馈，确认工作完成度，是否满足预期、是否有较好的用户体验。它是敏捷开发流程中的一个实践，一般适用于开发周期短，需要快速交付的项目。项目会通过这种滚动性的展示来不断完善自己的产品，让产品更贴近用户，同时尽可能的将需求变更前置，降低风险。通常情况下，需求 showcase通过后才能正式上线，在一个迭代周期内的新需求都需要进行演示，但也可以根据项目具体情况做出调整。

        在日常的项目过程中，你有没有遇到下面这些状况，让showcase没有发挥应有的作用？或者说根本就没有showcase？

1、准备不充分  

所有人就位，开始showcase的时候，发现环境没有ready，好不容易把环境弄好了，又发现体验包版本错了，导致showcase无法进行。

2、低级错误  

终于可以演示了，却被参与者发现低级错误（界面显示错别字）和明显的bug，浪费了大量的时间。

3、问题无人跟进

大家聚在一起对功能吐吐槽，showcase变成了茶话会，然后散会啦，showcase环节形同虚设。

4、showcase太晚

产品马上就要灰度了，然而被专家们提了一堆意见，一改再改，上线时间一延再延。

那我们该如何做好产品的showcase呢？结合之前的经验，下面给大家提供了一些流程方法，供参考和讨论。

一、准备阶段

1、Showcase时机：建议安排在每个迭代开发的系统测试前，越早发现问题，修改成本越低。

2、Showcase组织：组织者需要确定具体的时间（建议每周固定时间），提前收集要演示的功能内容、确定参加人员，预约专家时间。参加人员一般包括：产品、测试、开发、设计及各角色leader、产品专家、设计专家、部门经理等。可根据需求的重要程度选择不同级别的人员参加。

3、设置前置条件：满足前置条件才能进入Showcase环节，提高每次Showcase的效率和质量。

> 需求自检通过：自检条目可以包括showcase中常见的错误及一些基本要求，尽量避免演示过程中出现低级错误。

> 保证演示内容完整：不能是半成品，若涉及不同平台，至少有一个平台的流程可以跑完。

> 各角色体验通过：涉及需求开发的各角色，包括产品、设计、开发、后台等体验通过，如需给公司高层演示的需求可根据需要上升体验通过级别。

> 用户体验通过：预先进行用户CE（customer Engagement），一般由用研工程师根据产品特性挑选特定用户体验功能，记录用户的操作习惯、问题、意见等。CE发现的体验问题需要评估修改后才能进入showcase。

二、Showcase阶段

1、环境准备：提前准备好演示环境，包括演示设备，部署好需要演示的应用程序版本、演示需要用到的数据。一些重大项目和重要阶段的功能演示，演示者最好从业务的角度把产品要演示的功能尽可能的串起来，准备好演示的步骤和关键路径。

2、组织形式：一般采用面对面的会议形式，由组织者主持。产品经理（开发人员）按顺序进行演示，先介绍该功能的业务价值，满足了用户的什么需求，再进行演示。会上专家们根据演示结果反馈意见。对于手机终端类的产品演示，演示者还可以引导参与者按功能点进行一对一的实操体验。

3、全角色参与：尽量保证全角色在场，包括PM、产品、设计、开发及各角色leader，避免团队对反馈问题的理解不一致。

4、问题记录：组织者或专职人员负责记录现场反馈的问题，会后同步给与会人员。

三、问题跟进及复盘阶段

1、问题修改：showcase结束后，需求对应的产品经理（开发人员）需要组织开发团队（包括开发、设计、后台、测试等）针对修改点进行评估，确定优先级、责任人和修改完成时间，部分需求可能还需要重新评审功能逻辑以及交互设计。

2、问题验证：开发修改完后产品、开发、测试协作一起验证关闭问题，重大的改动还需要再次进行showcase复盘。

3、复盘：showcase会议需要对上期的需求修改点进行复盘。针对每个复盘需求上一次问题的修改情况进行演示，确保每一次的修改都有闭环。

4、过程改进：组织者可以针对每次showcase出现的问题记录、分析和总结，完善自检list或优化现有的showcase流程。

总结

        showcase的目标观众，往往是决定需求是否能上线，是否认可团队开发功能的重要人物，因此在showcase过程中表现出专业性和高效性非常重要。上述方法提供参考，相信大家的showcase一定会做好。