【AICon】AI 基础设施、LLM运维、大模型训练与推理,一场会议,全方位涵盖! >>> 了解详情
写点什么

教主:做第一个吃螃蟹的人

  • 2019-09-22
  • 本文字数:3714 字

    阅读完需:约 12 分钟

教主:做第一个吃螃蟹的人

“VR 看房、VR 讲房、VR 带看是贝壳找房上 VR 系三大核心功能。到 2018 年底,我们将实现全国 30 多个城市、70 万套二手和租房房源、3500 个新房楼盘的 VR 呈现,这将是 VR 三维重建技术在中国不动产领域的首次大规模应用。”

——鸟哥


4 月 27 日,贝壳找房如视事业部的 VR 看房揭开了神秘的面纱。惠新宸(鸟哥)介绍了贝壳如视团队自主研发的 VR 看房,这是国内首次在不动产领域大规模应用三维实景和虚拟现实技术。


正因为是首次,产品的扩展性及不确定性给了研发团队更多自由想象的空间,同时也带来很多从未遇过的问题。于是,我们找到了负责将 VR 看房呈现到大家眼前的“教主”:杨永林。



在 VR 看房项目中,我主要做的是工程部分,将硬件团队和算法团队的产出变成一套业务流程将结果展示给用户。你可以理解为肉眼能看到的东西,比如,标签、标尺、展示优化以及在各个客户端 app 上传播……这些都是我们做的。


我们的 VR 看房是什么?

VR 看房是通过 VR(Virtual Reality 虚拟现实)技术让客户看到房子的户型和内部细节,实现不受时间、空间等条件限制的看房。


以前市面上的线上看房产品,仅有一套房子的全景图,并不能称之为真正的 VR 看房。我们的 VR 看房不但能看房,还有 VR 讲房和 VR 带看,让用户拥有沉浸式、互动性、实时性的 VR 看房体验。

1 沉浸式

VR 看房的虚拟现实技术让用户可以从房间中的一个点慢慢移动到另一个点,实现多角度看房,给用户带来身临其境的看房感受。再配上专业经纪人的 VR 讲房,让用户通过影像形式了解房源。

2 互动性、实时性

用户与经纪人能够实时互动。VR 带看结合客户端的 IM 即时通讯产品,使用户与经纪人能够在虚拟房间中同时移动,看到相同的房源画面;通过语音的方式,经纪人也能及时解答客户的各种疑问。

一套 VR 看房如何产出?

教主团队需要服务 7 个业务方,包括二手房、新房、租赁、旅居、海外、德佑、百川,每个业务方具体的操作流程不一样,目前业务量最大的是二手房。那么以二手房为例,一套二手房的 VR 看房是如何实现的呢?

1 经纪人 LINK 下单

一套房源录入到后台后,经纪人(一般为房源维护人)会在 LINK 中预约实勘。

2 摄影师拍摄

每一个区域都有对应的实勘摄影师,如果是拍摄 VR 的摄影师,他就会根据 VR 看房拍摄的标准流程,使用自主研发的扫描设备对房源进行扫描拍摄并将数据上传至相应的服务器上。

3 原素材优化处理生成模型

在基础三维数据上做半自动标注,比如,匹配上户型图、添加户型分析信息、做截图操作提供图片传播资料等。这部分在数据量起来以后,结合机器学习会完成全自动化。

4 添加标注

在基础三维数据上做半自动标注,比如,匹配上户型图、添加户型分析信息、做截图操作提供图片传播资料等。这部分数据量起来以后,结合机器学习会完全自动化。

5 人工审核

一套 VR 看房处理完成后会先进行展示,如果用户有问题反馈或者审核团队发现问题,就可以要求驳回展示。

6 功能添加

在 VR 看房场景中打上经纪人的标签、添加讲房及带看等功能。


教主回忆道:“2018 年 2 月 28 日 VR 看房功能上线,3 月 15 日正式开始拍摄,3 月已经覆盖了成都 10%的房源,到 4 月底一共拍摄了一万多套房源。”


未知是最大的困难

在整个 VR 看房技术研发的过程中,教主团队遇到了太多的难题,但“未知”才是最大的困难。


“很多开发者的常态是在一个已有的、成型的业务基础上进行改进和创新,有可参考的产品。但 VR 看房没有任何可以参考的先例,很多功能我们不知道有没有人实现过。在这个过程中出现过什么问题、会出现什么问题都是未知的,只有开发到了那个节点才发现还有这样一个问题。这是我们做这件事的时候比较困难的,但也正因为这些未知,才有这些人乐意去做这件事,乐意去解决未知的问题。”对于 VR 看房的难点教主这样说道。

1 找到核心价值

教主说:“面对整个行业里没有做过的产品,做第一个吃螃蟹的人,只能自己想办法把这些事情做得靠谱,做得有价值。”


在产品层面,团队没有可借鉴的产品,当时思考的主要是产品的功能是否有价值。VR 看房能给业务带来什么?是否是解决了痛点?能否实现多赢?然后思考的是这些价值体现在哪?如何表达?切入点有哪些?从哪个点切入是多方容易接受的?所以,最终产品看起来像是虚拟一个线下的看房场景,但思考的过程是价值导向的。


教主分析说:“首先,我们生成了房源的三维模型和全景图,并在看房场景中打上了标签,增加经纪人的头像、联系方式等。后来我们想到,既然有了对房源全量信息展示的空间,房间任何一个角度的画面都有,那么就可以介绍这个房子,于是有了声音与画面同步的 VR 讲房。经纪人跟用户之间经常需要互动,不止经纪人自己说,还希望能得到用户的反馈,用户能提问经纪人能回答,基于这样的考虑,我们想能否让用户和经纪人同时看一套房,所有就有了 VR 带看。”

2 实战积累 合理预判

在 VR 看房产品的研发中,对细节的把握和对效果的检测比较重要。


首先,要知道所有的产品细节是否能实现。因为功能之间是紧密联系的,如果有一个功能点无法实现,整个技术方案就要修改。


其次,产品功能是否能达到预期的效果。由于没有先例,教主团队甚至没有任何可参考的先验数据,而数据有问题时,无法得知具体是哪个因素引起的,这时就考验团队的经验与能力了。


要掌控以上两点,要求工程师们有过硬的实战经验,对产品整体规划进行合理的预判。教主认为面对未知要做的第一步就是把经验部分固化:“拆解整个项目,把自身经验验证过的部分固化下来,变成常量,减少其带来的不确定性。比如,我们用的架构方案都是自身最熟悉最拿手的,以此来减少问题。”

3 拥抱变化 快速迭代

“变”是教主一直以来在架构设计上的原则,他曾说过:“可变化的代码才是有生命力的代码,在架构设计上我也会趋向于让项目的代码可以一点一点的变化演进,而不是一言不合就重构。”


架构设计要能“变”,开发中遇到问题也要能“变”。教主说:“因为未知太多,所以要多做预案,做最坏打算。实际上我们的产品有最基础的功能版本,会思考如果某些不确定点出现问题,怎么降级产品功能。对于项目关键点我们会尝试各种手段攻破,尽量不修改主开发路线。当然定方案前的调研也是少不了的,做到起码心里有八分谱。”


  • VR 讲房录音


做 VR 讲房时,教主团队原本想在网页里做录音,但是发现苹果机型无法使用网页访问麦克风,最后改成客户端提供 API(应用程序编程接口)。这时就需要快速的修改方案,从不依赖客户端发版变成了依赖客户端发版。


  • VR 讲房录屏


在设计 VR 讲房录屏时,最开始参考了游戏上的录屏功能:一局游戏可以通过录屏的方式保存下来,后期随时播放。VR 讲房和游戏录屏看起来很像,但实际开发中却发现了问题。游戏版本往往是经过很多内测,产品非常完备后才对外发布的,一个版本可能会使用几年。比如 CS,版本升级后操作有变化,之前的录屏可能就无法播放了。


“这对于游戏来说可能不是大问题,但是对于我们的产品却是致命的。”教主分析道:“我们的业务是需要持续升级迭代的,VR 讲房不是一个快照,不应该是一个包袱,不能一次升级后所有的 VR 讲房都不能使用了。应该在满足需求的情况下,不影响产品整体升级,并且还具备一定的扩展性。”


  • VR 带看


规划 VR 带看之初,团队想的很简单,只要建立一个虚拟空间,经纪人与用户进入就可以进行互动。在实际开发中遇到特别麻烦的问题:怎么确保经纪人与用户进入的是同一个房间?比如,经纪人从 IM 给用户发起了领秀新硅谷一套房源的 VR 带看,进入虚拟房间后发现用户没有进入,于是又给用户发了一条链接,此时就有了两条链接。如果经纪人进了第一个链接的虚拟房间,用户进了第二个链接的虚拟房间,那么他们永远都不可能进入同一个虚拟房间。


为了解决这个问题,教主团队迅速转变思路,将虚拟的带看房间与房源、经纪人、用户的 ID 绑定,只要进入这个房间,双方就能建立连接。



贝壳的工程师不止有超强的逻辑,还有超强的应变能力和“比心还大”的脑洞。产品开发过程中,针对一个技术点,大家会给出多种解决方案,然后从逻辑上、场景上分析每个方案的优劣,选择一个方案快速去试,如果试出问题就迅速更换方案。每个工程师都有对自己方案的坚持,而“互怼”也成了常态,“怼”出来的解决方案才能更完美的解决问题。


自动标尺、打标签……每一个技术点都会遇到大大小小的问题,教主团队依靠超强的应变能力,打败通往胜利道路上的小怪兽和大 boss,一关一关升级前进。


“目前我们上线了两个版本——基础版本和带看版本。产品上线只是从 0 到 1 的过程,未来还有更多功能需要去实现,很多细节需要去打磨精细。”教主说,“比如经纪人端的优化、摄影师效率的提高、交互细节的优化等,虽然不会有肉眼所见的翻天覆地的变化,但一定会让产品的体验越来越好。”


5 个客户端、7 条业务线、楼盘字典、IM 团队……VR 看房的上线是公司多个团队合作的产物。教主团队要跟很多团队对接,在这个过程中得到了很多帮助,也产生过摩擦,但大家都有统一的目的地,到达让所有的过程都成为美丽的风景。


作者介绍:


杨永林(教主),2015 年底加入链家任链家网前端总架构师,2017 年 11 月调至如视软件工程部参与 VR 看房项目。


本文转载自公众号贝壳产品技术(ID:gh_9afeb423f390)。


原文链接:


https://mp.weixin.qq.com/s/DFF8YFknZzrOA1ulHdTcog


2019-09-22 23:49854

评论

发布
暂无评论
发现更多内容

B端产品经理养成记(2):用户故事

涛哥 数字产品和业务架构

产品经理 需求 产品开发

RocketMQ - 高可用设计

Java收录阁

RocketMQ

Kafka系列9:面试题是否有必要深入了解其背后的原理?我觉得应该刨根究底(上)

z小赵

大数据 kafka 实时计算

ARTS week 2

刘昱

你会写测试用例吗

RocketMQ - 如何实现事务消息

Java收录阁

RocketMQ

draw.io-取代visio的流程图绘制工具

Rice嵌入式开发技术分享

chrome vscode 写文章神器 draw.io

B端产品经理养成记(1):业务场景

涛哥 数字产品和业务架构

产品经理 需求 产品开发

【openlayers】在vue中使用ol

德育处主任

Java html Vue 地图 openlayers

【5月】本月读书学到了什么

Neco.W

创业 读书感悟 阅读量

钢铁侠马斯克之仰望星空

池建强

创业 马斯克 Space X

写博客的那些事

shengjk1

Apache DolphinScheduler新特性与Roadmap路线

代立冬

大数据 数据中台 工作流调度 海豚调度 数据湖调度

John 易筋 ARTS打卡Week 02

John(易筋)

ARTS 打卡计划 ARTS活动 arts

时代在变,产品运营能力很重要

punkboy

程序员 程序人生 产品经理 产品推荐 程序媛

愚蠢写作术(1):怎么让你的标题被读者忽视

史方远

个人成长 写作

工作 vs 生活

shengjk1

如何用CSS选择符(数字开头) 杀死队友

德育处主任

Java html css3 大前端 Web

ARTS Week1

姜海天

转行程序员浅谈进程间的socket通信

WB

Linux 程序员 socket

ARTS打卡第一周5.25-5.31

我笔盒呢

工厂模式(四)泛型工厂之MyBatis Mapper代理

LSJ

Java 设计模式 泛型 工厂注册中心

游戏夜读 | 关于构图的困难

game1night

ARTS week2

紫枫

ARTS 打卡计划

做PO难,难于上青天

刘华Kenneth

敏捷 产品经理 决策 PO

不吹不黑!GitHub 上帮助人们学习编码的 12 个资源,错过血亏...

JackTian

GitHub 学习 开源 程序员 编码

ARTS打卡Week 02

teoking

objective-c LeetCode WebRTC

【ARTS打卡】Week01

Rex

学习

使用Kotlin语言初始化数组

mengxn

数组 kotlin 初始化

MAC OS 下 HomeBrew 使用

耳东@Erdong

macos brew homebrew

Element-UI实战系列:Table+Pagination组件实现已选和全选功能

AR7

Vue 大前端 Element

教主:做第一个吃螃蟹的人_文化 & 方法_杨永林_InfoQ精选文章