房产类项目总结——户型图库

数据分析如何避免沦为形式?15天在线学习get一套可落地的数据分析方法,了解一下 >>

本文根据作者的房产类项目经验,结合项目中的户型图/房型图模块部分,总结了制定户型图库的三个基础方法。

在房产网站(贝壳、安居客、房多多等)查看房源时,会发现每个小区都有一个户型图/房型图模块展示小区的户型。

在做房源管理系统时,要考虑每个小区都有相似户型的房源,这些房源的户型图可以共用一套,如果建立户型图库,集中管理这些图片,那很多房源的户型图无需重新上传,直接从图库中选用,这样做既解决了户型图重复绘制、效率低下问题,也解决了户型图管理混乱的问题。

系统问题及优化策略

接手项目时,户型图在本地电脑管理,房源用到某户型图时,只能在电脑上翻找,然后上传到房源上(如下图)。

按照常规策略方法进行评估,对户型图库项目做如下分析。

1. 发现问题:

  • ①本地电脑管理户型图,不能共享,查找困难,存在丢失的风险。
  • ②户型图在房源上上传,以独立数据存在,系统不能校重,导致户型图重复。
  • ③不能有效复用户型图。

2. 定义理想态:建立易于管理的标准户型图库,且房源容易调取。

3. 提出解决思路:

  • ①建立户型图库模块,集中管理户型图。
  • ②新增、修改房源,增加“选择户型图”功能,直接调用户型图库。

4. 资源支持:

  • ①已经上传的户型图导入户型图库表中。
  • ②户型图缺失的户型、朝向、面积等数据从关联小区上取值,补足数据。
  • ③历史重复数据的处理:需要处理房源和户型图库两部分数据,这个需要业务配合处理。

1.0版本的迭代

由于要记录房源上户型图专员的绩效,所以在1.0版本仅增加了户型图库的概念,上传户型图依然在房源上:

  1. 房源上保留上传户型图功能,房源上传的户型图进入户型图库,户型图继承当前房源的小区、户型、面积、朝向等信息。
  2. 房源上增加“选择户型图”功能,直接调用户型图库。

问题:

  1. 户型图库模块没有独立出来,依赖于房源管理,信息输入不灵活。
  2. 不能修改、删除户型图。
  3. 不能标识户型图是自有、他有类型。

1.1版本的迭代

和业务沟通,户型图专员的绩效不应该放至房源上,可以通过户型图库的新增量去计算他们的绩效,所以在1.1版本解除了户型图库对房源的依赖:

  1. 独立户型图库模块,可以新增、修改、删除户型图。
  2. 房源上去掉“上传户型图”,仅保留“选择户型图”功能。
  3. 新增户型图,反向关联小区,户型、面积、朝向等信息可灵活配置。

总结

1. 模块松耦合

所谓“耦合”,指将两个模块像链子一样连接在一起,存在依赖关系,若其中一个模块要动,势必引起另一个模块要改。在架构模块的时候,尽量做到松耦合架构,以降低整体复杂性和依赖性。

见下图:

1.0版本,上传户型图放至房源管理模块,导致房源管理和户型图库纠缠在一起,调整户型图功能,需要动房源新增、修改模块。

1.1版本房源管理和户型图库相对独立,只是数据层面有交互。

2. 穷尽业务场景,尽可能找到所有异常分支

异常分支越详尽,解决方案会更优,做B端产品,要尽可能分解业务场景,覆盖所有可能的异常分支。

本案例中,列举所有与户型图库有关系的用户,并用5w3h分析,重点关注当前场景是否为高频场景,是否契合目前的需求。其中一种情况,户型图专员在房源上新增户型图,可以记录绩效他的绩效,通过分析,知道这个是历史原因造成的,不利于模块之间的松耦合。

另外,计算绩效,完全可以从户型图库切入,所以我们果断舍弃这种场景,并提供了更便捷的解决方案。

3. 做数据字典,能配置的数据尽量做成字典

数据字典(data dictionary)是对数据对象或者项目描述的集合,数据字典可以集中管理数据,相同的数据维护一份,系统内统一调用。数据字典的特点是配置灵活,调取方便。户型图库也属于数据字典,有了户型图库,相同户型的房源可以统一调用同一张户型图,无需重复上传;另外户型图的信息在户型图库中完成配置,可以同步至全局。

除了这种图片字典外,我们还会遇到字段数据字典,例如户型、朝向、建筑类型、房证年限等等(见下图)。

户型图库作为楼盘字典的一部分,起至关重要的作用。本文从实践出发,运用策略分析的通用方法论拆解项目,并总结了松耦合、穷尽场景、做数据字典3种通用方法,做B端产品这三种方法非常普遍,几乎贯穿整个系统,请谨记!

#专栏作家#

柒柒,人人都是产品经理专栏作家,后台、移动端产品经理,《用户至上-用户研究方法与实践》译者

本文原创发布于人人都是产品经理。未经许可,禁止转载

题图来自Unsplash,基于CC0协议

给作者打赏,鼓励TA抓紧创作!
2人打赏
评论
欢迎留言讨论~!