试-设计篇-需求落地最后一公里

2022年11月7日 2022年11月11日

这一讲，我们分享的是需求应该怎么落地，以及如何检验我们实现的需求，是否满足设计的初衷。
首先，对于长周期的产品，可以通过评审流程机制和阶段性的资源投入，降低来之产品方向调整和技术实现方向的风险，避免来回折腾。
其次，对于短周期和迭代优化的产品，需要关注用户反馈和系统异常，并通过灰度和实验，来验证我们对于用户的猜想，不断打磨和完善体验。
最后，在需求正式发布前，要在产品、技术、数据、运营和传播等方面做好充分准备，避免因一时疏忽，造成团队的努力“一夜回到解放前”。
其实，我们一直都不知道，什么时候是真正的最后一公里。产品经理需要永远保持如履薄冰和求真务实的心态，把控节奏、把控质量、不断校正和还原用户真正的需求，在被用户真正买账之前，在获得用户真正认可之前，永远都是最后一公里。

长周期产品

品质决定资源投入——用流程极致为长周期产品的落地保驾护航。
Gate Review（GR）
GR是一套产品制作立项的审批帮助流程。GR评审从最初的创意到产品正式对外发布，一共分为5个步骤，从GR1到GR5，只有通过每一轮GR评审的产品，才可以进入下个阶段，并获得匹配的资源投入。
1、GR1又叫Concept（概念）阶段，团队在这个阶段需要筛选和提炼产品的核心概念。同时，需要关注市场分析、用户定位、用户体验、和产品风险等方面。
这一轮评审的目的是：产品创意符合当前形式，并能使组织在可预见的未来，获得进一步的（或可持续的）成功。
如果GR1顺利通过，将组建项目核心小组，启动筹备工作。
2、GR2的关键词是Prototype（原型），项目筹备小组在此阶段需要开发产品原型。验证技术风险，通过真实的美术资源确立美术风格，同时确立产品特性优先级，确定项目计划和资源计划。
这一轮评审关键，是判断在GR1的基础上所开发的产品雏形，是否符合预期，同时由各领域的专家对项目的策划、美术、程序、计划等各方面进行深度诊断和分析，给出专家建议。
如果GR2顺利通过，意味着项目立项，将由HR发文，正式成立项目组。
3、项目组在GR2评审前，需要完成可验证核心玩法的试玩版本。试玩版本需要提现产品核心概念，并达到面向市场的品质；完成量产工具和制作流程的准备；细化项目计划、资源计划、刷新后续工作量和CP计划。
如果GR3通过，BG将投入资源开始大规模量产。
为了避免投入较多资源后再推倒重来，需要及早确认和验证技术风险，确保直接关系到的产品核心特色、玩法亮点的开发目标能被顺利达成。
4、接下来，将投入大量项目资源进行量产。项目在此阶段要完成产品的全部开发，并逐步开始封测，通过用户反馈，验证和打磨产品品质。
如果GR4通过，进入Beta阶段，决定项目可以开始内测。
5、Beta阶段：项目组在此阶段进行反复内测，验证和打磨产品品质，进行上市前最后的check。团队每月对产品运营数据指标进行评测，在经过一段时间内测后，项目组才可以进行申请GR5。GR5要看产品的各项数据，特别是有效留存，将直接决定产品的定级，也决定了产品能获得的各项资源。如果GR5通过，意味着项目终于可以正式对外发布，开启公测。
所以，事先我们要求一定要把文档写好，你的concept（概念）是怎样的，你要做一个prototype（原型）出来，你的原型能够验证你的concept（概念），你要做最核心的feature（特性），能够确保这些feature技术上可以实现，拿出来也很好玩，我们才允许你做全面铺开的产品，开起来浪费了很多时间，但是这样真的是减少了你后面反复的时间。
产品评审流程的所有努力，都是为了让“产品品质决定资源投入”这一原则深入人心，通过流程机制，倒逼团队更有动力打造精品、为用户创造价值。

短周期产品

在不断试错中验证对用户的猜想
第一条秘方：引导发声。
比如，在产品之外，组织用户群进行自由交流。
又比如，在产品之内，设计契合用户场景的发声通路。
第二条秘方：灰度策略。
1、随机灰度——全局随机
2、定向灰度——细分群体——QQ厘米秀
3、邀请灰度——社交/社区属性——知乎
第三条秘方：善用试验。
A/B Test试验——图片、标题、按钮、样式、逻辑等
第四条秘方：关注异常。
问题或机遇——新需求的起点——视频播放度超过100%，小朋友喜欢重复观看，产品做循环播放功能。

腾讯敏捷开发的目标，在于快速验证我们对用户的猜想，不论是灰度、试验还是关注异常，这里共同的前提，是需要保障关键数据的收集，在符合相关法规及保护好用户隐私的基础上，增加用户行为的监控埋点。
用户所做的，往往比他所说的，更能代表他的真实想法，我们可以通过用户的操作步骤，来分析他们的实际想法，不断打磨和晚上我们的产品。

需求落地的最后一公里

首先，要做好产品层面的准备，确保功能实现符合预期，并且没有明显影响用户体验的BUG。
其次，要做好技术层面的准备，做好性能和压力测试，根据新版本发布后可能的用户访问量、交易量，做好系统容量评估，及时对服务器、带宽进行扩容，避免热情涌入的用户把系统压垮。
再次，要做好数据的准备，避免因为前端上报或后端统计报表的缺失，无法及时监控产品发布后的数据表现，给运营和后续的优化造成被动局面。
最后，也是最容易被忽略的，要做好运营和传播方面的准备，需求发布前，准备好相关的公告和用户指引，提前和客服、PR等同事沟通对齐新需求的内容及可能造成的影响，输出话术和FAQ提前应对，并在发布后密切关注用户的反馈，以及各媒体的评论，避免用户投诉和舆论带来的风险。

（完）