一、前言及背景
作为产品，成为接盘侠是很正常的一件事，但是怎么快速，有效，看清楚整个盘子了解清楚盘子情况，明确浅水区和深水区，这个就很考验产品的能力。
这里分享三次接盘的经验，其中2次是自己，一次是看别人，总结起来就是下面几句：
1、通过日常优化
2、从下而上的重构
3、从上而下的分析
二、两次的经过及做法
1、通过日常优化
1.1、项目背景：
当时我负责一整个系统，系统有非常多历史遗留问题，然后安排了个产品专员专门去处理这种BUG或者修复历史数据。
在看到这些BUG或者修复工作里面，发现其实很多是以前人做事不严谨或者设计缺陷导致，而刚好那产品专员是刚入职的，是最初级的，所以安排他做这个事情，希望通过维护系统了解相关业务，最终慢慢接手工作。
这种接盘不像完全接功能或者接系统，是从优化小逻辑小缺陷开始，最终慢慢熟悉工作或者系统的一个过程。
1.2、当时做法：
A、让产品专员将问题进行分类，是BUG、设计缺陷、优化需求：因为业务部门是不会分这些分类，只会有问题或者有想法，就提出来。需要分门别类去处理。BUG就BUG维护，设计缺陷要看严重程度来判断是否需要快速修复。优化需求则丢需求池等待排期。
B、让产品专员对问题的分析并提供短、长期解决方案：目的是想锻炼他对业务的了解及设计方案的考虑，不清楚根源、不了解业务，是没法分析透彻问题，彻底解决问题。
1.3、总结：
A、苦力活：这种苦力活最辛苦，但是最能了解业务细节，而且通过优化、修复过程里面，不断健壮整个系统，事情虽小但是影响却大。
B、适合新手、新入职人员，同时可以锻炼下自己的业务理解、方案设计能力。这种活总得有人干，但是如果为了做而做，就像当时开发的做法，只是简单掩盖掉问题，没有从根源上解决问题，结果同样问题频繁出现，耗费更多精力。有个比较高大上的目的去干活，相对来说会有动力点。
2、从下而上的重构
2.1、项目背景：
系统已经运转了十几年，然后需要从业务、从架构层面重构整个系统，在不影响影响原有业务的前提下，逐个将功能模块重构、解耦掉。
一般初级的产品，能够独立负责业务的产品，都是从这里入手工作，接盘难度并不大。从下而上，是从子功能接盘逐步到整个系统接盘。
2.2、当时做法：
A、划定子功能模块的边界，开始收集原功能设计、逻辑文档、用户的使用意见
B、重构子功能的业务，剥离代码重新开发，将功能变成子服务
C、新旧功能过渡：业务系统迁移、接入到新服务里面，关闭旧功能
D、维护新功能，开始下个子功能重构工作，通过一个个子功能得到重构，可以对整个系统进行比较深入的接盘
2.3、总结：
A、深度接盘：深度了解该功能业务细节，团队接手后会比较容易维护
B、分批重构、过渡，对业务影响会比较低
C、只能看到局部的功能，看不到整体架构情况
D、关键是过渡方案，对新旧系统数据同步的问题
3、从上而下的分析
3.1、项目背景：
背景是一次性接手一个完整陌生的系统，里面包含多个模块，并且不断有新的业务、新的需求需要处理。
既要清楚现有模块之间的关系，多个业务部门对系统的意见，同时还要处理历史遗留的问题（神坑），还要处理新业务的开发。
一般到了中高层产品，都需要经历这种接手别人的大盘子，刚接手的时候，如果方法不对，会陷入在日常维护里面，然后需要很久时间，才能逐步接盘并开展自己的工作规划。
3.2、当时做法：
A、梳理整个系统的大概业务流程、信息架构、服务部门或者用户群体等；
B、分析每个子功能的使用情况、反馈情况、用户满意度等信息；
C、自身对功能的未来发展判断、功能对公司或者部门的价值判断，明确现有系统的缺失；
D、建立需求池、划分模块，有针对性优化系统（虽然这些是很常规，但是很多团队，没有很明确的需求池及模块划分，有活就干。这种就是工作习惯的问题）
3.3、总结：
A、关键是要明确核心功能、非核心功能及功能价值、用户群体之间的关系。资源是有限的，系统哪里都需要资源，同样的资源用在不同的地方，会产生不同的价值，为什么用在这里，为什么不用在那里，每个人心里面需要有个判断标准，而这个分析就是提供这个判断依据。
C、从顶层架构来看待系统的完善程度，是要做新功能？做什么方向的新功能？还是升级优化为主？升级优化什么功能点？有了比较宏观的视觉，对整个产品的未来规划也会更加清晰。
三、总结
其实接盘这事，肯定可以接下来，而且肯定可以做好。只是在接盘的过程里面，如何接得好，更有高效，更有价值去完成一件事情，这个就比较难。
归根到底，就是对于“信息的收集”与“价值的判断”。作为产品人员，是把控产品方向的主导人，怎么将有限的资源创造最大的价值？
网友评论