以实例讲产品改版（上）：准备与推动
《以实例讲产品改版方法论》系列，是一个时间跨度接近半年的全站改版大项目，留下的一点经验，共分为两个部分。本文为上篇，主要讲改版准备与驱动，下篇为改版语境下的产品设计实操技巧。
前期准备与铺垫：
加入公司的时候，产品经过半年马不停蹄的持续丰富，刚刚进入稳定期，此时有足够的内容和数据积累，且各条功能线的体验均为最初版。我正好就此讲下，想要改版，产品上的基础工作准备：
上一版产品没有留下专业的产品文档，那么我要做的第一件事情就是全盘体验梳理整个产品前后台，并顺带把迭代路径和产品定位摸清楚。这个过程对我来说有三个关键产出：
- 第一是以前整个产品都没有文档体系，我建立了，包括产品定位与规划、产品页面结构图、流程图、信息架构图与规则说明、后台角色与权限图表。前面的很好感知和修正，后面的都是体力活。这么一套东西，做了大概三周，精细到每一个列表的分页、排序、特殊布局位，每一个字段的取值范围、约束条件、来源与关联关系。前端很好处理，开着web查看器挨着试，后台逻辑就需要先记下问题，找个时间集中问问开发了。
- 第二个，建立了需求池。在体验的时候发现了很多问题，一些是关于功能定位的，会发现有些功能没做起效果来，或者和自己的想像不一致。一些是发现细节纰漏，交互体验上的，流程引导上的。这些统统记录在需求池里，大概有一百来条，加上找一些同事聊过的，加起来120条左右了，都是有名目、有来源、有场景的优化需求，有些也记录了需求方直接提出的解决方案。
- 第三，结合数据表现，来看每个功能的使用量、人群规模、频度、时间分布，还有用户轨迹、身份特征、产生的内容特征，进一步摸清楚每个场景下的用户画像。
1. 改版和优化的区别？
先区分这个问题，我们再来谈改版还是优化的选择。
产品上讲，优化比改版的方向性更为清晰，问题产生的时候同步就有了可量化的上线指标，而改版则不一定，甚至可能往相反方向进行尝试，连产品功能的定位都可能改变。
技术实现上来讲，改版不一定重构，但如果是连定位都变了的大改，很难能保证原来的信息架构和页面流程不会重做，所以产品一旦确认是要改版，那么就会给研发团队一个暗示：这次改版方案决策，一定是解决问题 > 开发时间成本的，并会给开发重构代码的时间窗口。而我们如果采用优化的方式，实际上还是在产品目标内，尽量照顾现有的产品框架，考虑实现方案的性价比，做多个局部处理来实现优化目标。
2. 为什么要改版而不是逐步优化？
这个问题要想清楚，否则一定会被团队成员问到。这时候梳理了下这个需求池，发现事情并不简单：
- 有几条需求同时指向一个问题的，不能独立击破，得跳出来提出一个整体解决方案。
- 有些需求问过开发了，重构的时候来做吧，现在没法动，积重难返。
- 部分功能是多个人在不同时间的意见简单叠加，不成整体。
概括的来说，通常有四种情况，我会认为有整体解决的必要：
- 多个问题指向一个板块。
- 能直接从现有产品中看出设计者和执行者之间的理解偏差。
- 三是能看出需求跟着时间变了，但产品只是简单做了加法。
- 四是需求深度不够，没有往下细想，上线后发现落地场景出了问题，数据很差。
这些毛病，病因清晰但盘根错节，大刀阔斧整体性解决反而划算，小步快跑容易变成打地鼠。
3. 推动改版的客观条件
无非是看看天时、地利、人和。
- 正好目前没有排期中的新需求，且改版需求任务量大（100+条）。
- 各部门的负责人好像都聊过了，都有产品诉求，各自的价值主张也比较清楚了。
- 开发似乎是有重构意愿的，主动提过，也有性能/代码优化的想法。设计师改版意愿也很强烈，毕竟上线产品就是带链接的作品集。
4. 改版驱动的技巧
- 在一段时期内，把一些需求池中记录的疑难杂症，向关键人物一点一点地提一遍，可以是口头，也可以IM+口头。关键点是要把握适当的频度和时机，如在开发资源紧张时做绵长而有频度的铺垫，维持话题在领导心中的热度到60分左右，然后抓住一个窗口时期全盘托出。
- 展示用户反馈的统计数据，点出反馈集中的某个板块，讲讲优化后的预期效果（向上画饼，或者叫“灌输理念”），全站改版没机会的话，至少可以拆解出这一块先改。
- 对于一些确实重要的问题，可以在话术上适当放大，把可能的极坏情况陈述出来。
- 找到或者创造目标一致的伙伴，如设计师或者开发，多个职能一起贡献推进影响力。
5. 改版后的跟进与坚守
时间来得及的情况，改版后我们需要出具改版说明文档、规则变化说明文档（如新版广告位图片需求表格），有时候甚至要做后台使用培训。改版后，还需要时刻监控着改版关键指标的变化，及时发现问题，看看和自己的预想有无偏差。
另外一方面，作为整体负责改版的产品经理，要站出来面对所有的反馈。
- 对于内部质疑性反馈，一定要非常耐心且及时地解释清楚改动的目的，解决了什么问题，让所有未直接参与改版前讨论的同事，也能最快理解改版目的。这样，我们树立了一个正确的靶子，让大家的讨论意见跟着牵引，不至于失控。
- 对于合理的有效反馈，立即建表执行修改并跟进，及时通报进度。
- 对于难以判断的主观意见，要阐明我们需要尊重设计师的专业意见和开发实现成本等。
- 对于个性化的需求，要讲明该功能所服务的人群是哪几类，比例分布如何，对哪些人影响更大，哪些人的意见更为重要。
每次改版后一定会有争议。
但，只要前期经过充分论证和仔细推敲，我们就有坚守的信心，站出来，保护自己的设计，也保护UI和开发团队。
拿出耐心的态度，逐个处理反馈，控制并主导意见走向，避免陷于被动的局面导致返工，甚至新意见大量涌入后的需求失控。
