【复盘】一个新功能上线的始末

这个新需求是在个人主页上新增相册功能，刚开始接到这个需求的时候，我想当然的以为这个需求挺简单的，后来随着需求梳理的不断深入，我发现我错了…

最终这个需求横跨了N多团队，包括对内的产品、设计、开发(Android、iOS、服务端、运营后台)、测试，以及对外的商务、财务、法务部门…Anyway，最终功能是按时上线了。

目前在观察数据阶段，先简单的复盘一下这个功能上线的始末…本文会按照需求上线的全流程进行组织，文章包括背景和目的、需求方案、设计方案、开发测试和踩过的坑这几部分。

目前产品中的个人页是有背景墙这个功能的，约有2%的用户使用了这个功能。现在的背景墙是被折叠起来的，即使用户上传了自定义的背景图，也需要在个人页面下拉很多才能看到整张图。

此外，产品后续会做一些社交化的尝试，但是产品目前是没有社交元素的，个人页后续会慢慢改版，逐渐加入社交元素。

以上就是这个需求的整体背景，一方面在入口很深且存在感较弱的情况下都还有用户上传图片，说明这个需求是存在的。另一方面也希望能借助相册这个功能做一些社交化的元素，为后续的其他功能做一些铺垫。

调研市面上常见的一些产品模式之后，我发现相册功能主要分为两大类，一类是支持将用户动态流中的图片添加至相册，一类是个人相册与动态流独立，相册为用户单独上传的图片。

前面这种形式冷启动会相对简单一些，典型的产品比如QQ、微博，后面这种形式更多出现在社交产品中，比如陌陌、探探…之前的产品方案是前面一种形式，理由是我们目前有一个圈子，已经有了动态流，可以快速冷启动，后期可以再修改成用户自主上传图片的形式。

我调研了一些现有的产品模式，向技术同事请教了一下实现成本，再结合一些自己的想法，最终得出的结论是采用用户自主上传图片的形式。

因为这种方案更符合我们的目的，技术实现也更容易一些，而且前一种方案最终也会迭代成用户自主上传的形式。然后我就和之前出方案的产品沟(si)通(bi)，此处省略XX字…

明确了大方向之后，结合现有的产品功能，我出了3个方案：

• 方案一是保留背景墙，添加相册模块，整体页面布局大幅调整；

• 方案二是保留背景墙，添加相册模块，页面布局仅小幅调整；

• 方案三是去掉背景墙功能，页面大幅调整…

我个人比较倾向于方案三，最终经过几轮需求评审之后，确定下来的方案也是方案三。

由于用户上传图片的质量没有办法保证，可能是风景照、广告等图片，而我们希望用户上传的是个人照片。所以最开始考虑先定向给到一部分用户上传的权限，引导这部分用户上传自己高质量的照片，作为示范效应。后来由于实现成本太高，被否决了…

你以为到此为止方案就完了嘛…这只是用户端，也就是App上的产品方案。用户上传的图片没有办法保证质量，也没有办法保证是否符合规范，所以此处应该有审核后台。

人工审核难免会有一些漏审或者会有延迟，所以此处还应该有举报机制，以及对应的处理后台…我们目前的做法是机器识别+人工审核，先通过图像识别的算法进行判断和分类，之后再由人工进行复查。

凡是涉及到用户自主发送的内容，比如动态、留言、评论等，都绕不开审核这道门槛，不然平台会承担很大的风险。

关于审核的处理，一般有两种形式，一种是先审后发，一种是先发后审。前者是指先审核，之后内容才会发送成功，后者指的是先发送成功，之后再由相关人员来处理。

关于发送内容违规的处理，一般也有两种形式，一种是禁止发送，一种是发送仅自己可见。

可以看到一个功能模块很多时候没有我们想象的那么简单…以留言为例，留言是否需要审核，审核的量有多大，后期带来的运营成本会有多高…这些隐形需求和后续的运营成本都是我们需要考虑的。

此外还有一些新用户的引导方案，最开始是浮层+气泡引导的形式，后来因为目前App内没有浮层这种形式，加上其他业务线的产品总监认为这种引导方式过强，所以最后改为toast引导的形式了。

以上就是相册这个需求整体的方案，包括App端的方案、审核后台、举报后台，以及新功能上线之后的相关功能说明、引导方案…

确定下来产品方案之后，后续就是设计稿的设计，然而我面临着两个比较尴尬的局面：

• 一个是两个月之前个人页刚改版，版本上线没太久就要改，设计肯定不太愿意改；

• 另外一个是我的思路和之前产品的思路完全不同，而之前的设计方案已经做好了…

我也很绝望啊，还能怎么办呢，跪设计呗…

设计上的难点相对少一些，主要需要解决这几个问题：

• 微动效；

• 缺省设计；

• 图片的展现形式；

• 图片质量较差时的应对方案。

现有产品是没有社交基因的，很多用户根本都没有上传过头像，这部分用户也很可能根本不会使用相册功能，而这个用户基数会很大…所以需要单独给这种类型的用户一个默认界面，避免出现用户未上传图片整体UI就很丑的情况。

相册方案初步考虑是最大支持上传8张图片，这就涉及到展示效果的处理，比如1张的时候怎么展示，2张的时候怎么展示，3张的时候怎么展示，4张的时候怎么展示…

最后一个问题也是我们最担心的，设计稿选用的图片是质量较高的图片，而真实用户会上传一堆什么照片，我们是无法知道的，如果都是个人文字广告或者二维码，想想也是头大…

所以设计方案需要保证即使在这种最极端的情况下，整体的UI看起来也还是能接受的。

这个环节对产品而言，主要就是沟通和项目跟进，需要结合具体团队成员的特点来跟进，比如是否靠谱，以往的需求完成质量，Bug数量等…

这个时候不懂技术的产品的弊端就显现出来了，一方面不了解技术实现的难度，另一方面不清楚实现所需要的时间，一般我都是拉个外援帮助一同解决这些问题。

环境一般会分为三个，开发环境、测试环境、生产环境(也叫做正式环境)，有的公司可能会有一个预发布环境，介于测试环境和生产环境之间，配置与生产环境完全一样。

我们公司目前有三个环境，所以偶尔也会出现测试和正式环境配置不太一样的情况，最终可能的结果就是一些功能在测试环境是正常的，而在正式环境上可能就有些问题…所以，正式发布前需要多测一下。

整个项目最终是如期完成了，踩了不少坑，有些坑只有自己掉进去才知道，即使别人告诉了你，或者即使自己之前就知道这里会坑，也很有可能会掉进去，爬出来之后才会印象深刻。

踩的第一个坑是数据迁移的问题，之前是有背景墙这个功能的，约2%的用户上传过图片。现在这个功能下线了，那这部分用户的数据怎么处理。

最开始是打算不处理的，后来出于用户体验的考虑，还是决定处理一下。采取的方案是在上线之前进行一次数据迁移，将用户最近上传的一张背景图迁移过来，作为相册的第二张。

踩的第二个坑是图片加载的问题，一个是图片本身的大小不同，加载速度不同步，一个是个人资料页的图片和文字区域加载速度不同步，图片区域未加载出来时，屏幕中会有一个空白区域，还有一个问题是这些图片来源于两个不同的接口，图像清晰度不一致。

后来采取的方案是，图片先统一用默认的样式图占位，加载出来之后再替换。将不同接口的数据合并成一个页面来加载，数据都加载出来之后再一并展现，这样就不会出现文字区域加载出来，而图片区域为空的情况了。

踩的第三个坑是项目管理上的坑，当时审核和举报后台是交给另外一个团队去做，中间他们的产品经理推诿了很久，浪费了不少时间，而且对方的进度和给到的时间节点完全对应不上。

最终采用的解决方案是一日多催+必要的时候请求上司支援，最终总算是赶在公测当天把后台都上了正式环境。

最后一个坑是测试环境和正式环境配置不同导致的，图像审核服务在测试环境是正常的，而在正式环境上有些异常，还好发现的比较早，排查之后解决了这个问题。

因为这个案例是刚上线的一个真实案例，一些资料，比如原型、设计稿和文档等，不太方便公开，所以就没有配图说明，见谅见谅。

最后说一下另外两点考虑吧，分别是功能规划和用户分类。

功能模块可以分为新增、优化和删除，此处特指新增。新增一个功能时，可能需要考虑这几点，功能的前向兼容性、同向关联性和后向延展性。

以相册功能为例，之前是有背景墙这个功能的，如何兼容之前版本的功能和数据，没有更新的用户怎么处理，能否查看，能否操作…

同向关联性指的是和现有的哪些功能可以产生联动效应，比如之前的产品方案里相册是和动态相关联的，动态中的图片自动能进入到相册中，这就是可关联的功能点。

后向延展性指的是产品后期的一些规划，比如相册功能会基于目前方案进行一些迭代，比如可能增加上传图片的数量、加入背景墙、支持挂件等。

这些后期的功能规划能让技术在设计架构的时候也提前规划架构上的延展性，进而满足产品功能延展的需要…

用户可以分为3类，分别是新手用户、中间用户和专家用户，产品方案在设计的时候也需要针对这3类用户做一些适当的处理。

以相册功能为例，新手用户对应的就是那些可能根本不会上传图片的用户，缺省状态和新手引导就是为他们设计的。

专家用户对应的是会上传多张图片或者自主装扮的用户，目前满足他们的需求，后期可以考虑支持大于8张图片的上传，以及自定义背景墙、挂件等…

中间用户是个用户基数相对较大的群体，大多数的功能也都是为他们设计的，需重点关注…

以上，就是本文的主要内容，欢迎斧正、指点、拍砖…