Demo

Demo 阶段只回答一个问题：这个玩法好不好玩。为了尽快得到答案，一切能省的都省——美术用白模和网上找的临时资源，代码怎么快怎么写，系统只做核心循环那一小圈。业内常说”find the fun”，Demo 就是干这个的：把创意从文档变成手上能玩到的东西，因为玩法这事儿光靠嘴说和写文档是验证不了的，必须上手。

Demo 和垂直切片的区别要分清：Demo 验证”好不好玩”，可以糙；垂直切片验证”最终品质做不做得出来”，必须精。顺序上通常是先有 Demo 证明玩法成立，立项后再做垂直切片定品质标准。

PM 视角

Demo 阶段的项目管理原则是”轻”，这恰恰是很多 PM 不适应的：

第一，别在这个阶段上重流程。Demo 团队通常就几个人，每天方向都可能变，这时候上 WBS、写详细排期纯属自嗨。PM 该做的是保节奏（比如每周一个可玩版本）、记录每次验证的结论、确保团队聚焦在”验证玩法”而不是”完善功能”上。

第二，帮团队守住”糙”的纪律。美术看到白模手痒想精修，程序想把临时代码重构漂亮——这些冲动都要拦住。Demo 阶段花在品质上的每一天都是浪费，反正立项后大概率重写。

第三，最难也最有价值的一件事：推动团队诚实面对”不好玩”的结论。Demo 验证失败是正常结果，不是团队失败。PM 要帮团队建立”快速否定、快速换方向”的心态，在泥潭里反复修补一个不成立的玩法，才是最大的成本黑洞。