从产品角度,快速接盘新系统的一些经验及方法提炼

一、前言及背景

    作为产品,成为接盘侠是很正常的一件事,但是怎么快速,有效,看清楚整个盘子了解清楚盘子情况,明确浅水区和深水区,这个就很考验产品的能力。

    这里分享三次接盘的经验,其中2次是自己,一次是看别人,总结起来就是下面几句:

    1、通过日常优化

    2、从下而上的重构

    3、从上而下的分析

    4、面向市场的产品接盘


二、两次的经过及做法

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、从顶层架构来看待系统的完善程度,是要做新功能?做什么方向的新功能?还是升级优化为主?升级优化什么功能点?有了比较宏观的视觉,对整个产品的未来规划也会更加清晰。


4、面向市场的产品接盘

4.1、项目背景:

       接手一个saas系统,系统之前有人已经做了一段很长时间,我只是负责移动端的设计。

       虽然只是负责某个端,但是作为一个产品需要对市场、全局等有比较清晰的认知,才好进行比较深入的沟通。分析的内容偏重是市场方面,而不是功能结构方面。

4.2、当时做法:



三、总结

    其实接盘这事,肯定可以接下来,而且肯定可以做好。只是在接盘的过程里面,如何接得好,更有高效,更有价值去完成一件事情,这个就比较难。

       归根到底,就是对于“信息的收集”与“价值的判断”。作为产品人员,是把控产品方向的主导人,怎么将有限的资源创造最大的价值?

你可能感兴趣的:(从产品角度,快速接盘新系统的一些经验及方法提炼)