产品经理岗2020年终工作总结

产品经理岗2020年终工作总结

按照产品经理负责的产品类型来分类的话，移动端和中后台都做过了，而且是前后逻辑相互对应的一整套平台。可以从零独立做出一个基金经理、销售经理、财务运营、投后经理以及C端高净值客户使用的金融产品管理平台，就是2020年以来最骄傲的成绩。而整个搭建过程中出现的所有生产事故、沟通对接问题、产品设计问题都是2020年以来最宝贵的经验。

移动端：APP、H5、微信服务号：

APP的定位是一个为C端客户提供的认购金融产品的工具，底部导航分为三大块：首页、产品、我的。首页的特点，毋庸置疑的一点就是，撑得起台面，起码不会令C端客户望而生畏；其次就是提供了各种快捷入口，比如查看持仓、完成各项认证等等。产品列表则是一个最基础的金融产品销售应该拥有的页面。第三个底部导航“我的”同理，提供持仓金额、持仓产品的多维度查询以及账户设置的功能。

在完成APP期间，有几件印象深刻的事情：

1.UI改版及周年庆活动：这其实是一件没有被明确指示的工作，而最原始的动力是来自于，产品经理作为一个产品的Owner，一个APP的设计与风格就代表着TA的审美及品味。当时很希望可以把APP设计风格做得更加前沿，也希望能抛弃掉金融APP定位的刻板印象，带来一些微交互的创新。所以，重点都放在了视觉动效上，以及用户在点击某个按钮后的反馈。UI和开发同事必然是不认同的，因为任何一点脱离舒适圈的设计与开发都是增多的工作量。沟通是当时最难以推进的工作，经常评审到中间，UI同事就出现不愿意做的负面情绪，并且把负面情绪带到对产品设计的评价上，甚至变成了一种攻击。最有力的说服就是尽量用较完整的低保真甚至高保真动效去打动，或者举世面上相对成功的案例证明它的优势和必要性。这绝对是一个互相进退以及制衡的过程，包括与开发的沟通也是，甚至需要找出类似效果的前端代码去解释这并不是一件很难的事情，是可以完成的事情。当然，共情也是必要的，去体谅工作量，尽量争取开发时间，以及平和的沟通都会起到微小的作用，推动事情的进展。

2.账户体系对接：绝对是一件非常考验逻辑的事情，也是一件一旦出错就会产生严重问题的事情。有多少APP因为在登录注册时出现的问题而流失掉大量的用户。账户体系对接其实算是一件政治任务，一个是出于安全方面考虑，另一个是出于拉新用户考虑。首先要区分登录与注册场景，注册场景的难点在于不同证件类型对应不同的审核机制，登录场景的难点就在于其复杂性。在登录场景下，先区分账密登录和短信验证码登录，而在账密登录下又需要区分手机号与用户名登录的流程差异。在完成账户体系对接需求的过程中，会不断出现流程图中的某个场景缺失，而继续补充场景的过程又会反向影响整套逻辑。后来发现，流程图设计并不能最完美地呈现需求，开发与测试用例评审的过程中尤其明显地出现该问题，因为流程过于复杂，所以评审极易出现疲倦，且不好溯源。如果搭配Excel，将所有的场景列出，通过控制某一个变量不断排列组合的方式，不仅可以减少遗漏的的情况，也可以在出现问题时方便排查。

3.机型、系统版本的兼容及闪退问题：意识到该问题的严重性还是在最近的一次事故中。

4.15晚上有超高净值客户反馈app出现闪退问题。其实之前华为即兴总是存在闪退问题，且每次跟进几乎都还是以重新下载APP，没有找到根本原因就结束了，所以就闪退问题本身一直都没有给予足够重视。因为此次出现问题的是超高净值客户，惊动了很多领导，不同团队的执行层面都被要求查明问题，所以这一次闪退问题的核查执行力非常高。当天晚上排查思路已经比较明确，基本按照以下顺序进行：app版本问题、数据问题、机型问题、ios系统版本问题。但由于客户不能反馈明确的以上信息，导致查询log去明确她使用的app版本、机型、ios系统版本花了一部分时间。查明问题的主要障碍是在生产环境账号缺失，无法模拟完全一致的场景，以及昨晚远程无法使用不同机型测试。第二天上午其实出现了停滞状态，因为无法达到精准复现以及闪退问题本身重视度不高，所以执行力降低。但由于不得不写“公关”邮件跟所有领导同事解释这个问题，我才又变成了推动这件事情的人。在排查最麻烦的机型适配时，为了达到完全的标准变量比照，突然发现所有自认为已升级到最新版本的手机其实都只停留在13.3阶段，而出现问题的是13.4.1。最终在13.4.1版本上完成场景还原时，复现出多次闪退问题。总算解决了。其实在收到苹果的兼容性警告邮件的时候，虽然苹果更新系统以及通知都非常仓促，但还是应该给予足够重视的。

4.分配数据错误问题：这是一次极其严重的生产事故，是在某个周末出现的，接到了业务方

的电话以后，马上就意识到事故严重性，整个人紧张到发抖。当时立刻联系了开发同事进行排查，首先检查的是后台数据是否出错，发现后台数据是准确的，说明整体分配逻辑并没有错误。那就是后台返回前台数据或者是前端展示逻辑上出现问题。最终排查结果是由于后台在接收数据确认状态时，服务器出现超时现象，导致多次返回数据，前端接收数据变成double。事情结束后，也有好好反思该问题。虽然确实属于开发中非常细小的问题，但如果产品层面可以想出方案减少此类事件概率，那产品还是有出现0失误的可能。如果从开发过程中介入，那就是在技术架构评审时，就要及时提出如果服务器出现超时的各项保障机制。其次是测试过程中介入，要求测试尽量多模拟数据流转过程中的异常情况，观察数据准确性。最后是产品设计角度，生产环境中最好可以与C端客户出于同一场景中，第一时间完成数据比对以及信息确认工作，起码可以以最快的速度发现并解决问题。或者可以通过报警短信或是报警邮件的方式，将数据表中关键字段的结果通过文本方式提供。

5.强制更新决策：强制更新一定是尽量避免发生的，如果网络状况不好，用户很可能就无法使用APP了，而且频繁的强制更新意味着需求规划不完善、技术兼容性糟糕。强制更新需要尽早确认，因为这会决定技术开发时是否需要考虑兼容性问题以及测试阶段是否需要进行新老版本回归。

如果没有上述的这些事件，一帆风顺地做完了产品，很多需要考虑周全的细节点很可能就会被忽视了。人无完人，出现一次错误，及时止损、承担责任并且思路清晰地解决问题，防止同样的问题再次出现才是最重要的。每一次错误的复盘，都是意义重大的。

对于H5、微信服务号来说，基本是作为APP功能复刻的轻载体。重要的事项，第一，决定H5、微信服务号上的功能，一定是用户最在意并且需要最快反馈的内容；第二，H5、微信服务号上的设计，可以做得不一样，不仅可以防止视觉疲劳，也可以尽量显得不冗余，利于用户沉淀；第三，APP的重要的文案调整与功能更新需要及时同步H5、微信服务号，防止出现版本差异。一时的轻松，只会剧增后续设计、测试、开发、问题排查的工作量。

逻辑复杂、作为平台核心、中枢的后台管理系统

正常的业务发展而言，线上化进程一定是从后向前，只有后台的完备，才可以使前台呈现做到游刃有余。后台管理系统是从2017年第四季度开始规划的，初衷就是为了让业务人员的