维格陈霈霖:技术管理三宗罪,如何打造「完美的」高效协作数据库

烈酒焚心 提交于 2020-12-16 20:02:04

2020 年全球技术领导力峰会在厦门召开,vika 维格表创始人陈霈霖应邀出席,分享了创业路上的经验以及曾担任大型独角兽企业 CTO 的行业观察,全面剖析企业技术管理层面的痛点,从「技术管理三宗罪」切入,提出了全新的「维格思维」。

以下为《技术管理三宗罪:如何打造「完美的」高效协作工具》主题演讲分享。

陈霈霖:vika 维格表创始人,前喜茶 CTO 兼数字营销负责人,主导设计喜茶 GO 小程序从 0 到 2000 万增长、电商、会员体系,前金山软件架构师,开源框架 KSFramework 创始人(Github 1000stars、仙剑 4 等手游使用),现创办的 vika 维格表在半年内获得 IDG 资本等 3 家机构投资。

技术管理想要敏捷落地,先发现问题

我们先一起来看看旧报纸。

第一份报纸是一个广告,里面有三个电脑品牌:Commodore、Atari、Apple,前面两个大家可能都没听过,Apple 应该都比较熟悉。这份报纸广告说的是:你购买这个电脑能省更多的钱。第二份报纸则是苹果公司的广告。

两张报纸拥有同一个主题:帮 VisiCalc 软件打广告。

现在看来很奇怪吧?电脑硬件公司帮软件打广告。

但在 1980 年,消费者买电脑的唯一用途是这款叫 VisiCalc 的电子表格软件。当时的个人电脑,还被大众戏称为「铁盒子(THE BOX)」。

乔布斯曾经承认:没有电子表格软件就没有苹果公司。这是 80 年代的真实写照。

1983 年,另一个杀手级表格软件叫 Lotus1-2-3,帮助 IBM 统治个人计算机硬件市场,才有了我们说的 IBM PC( IBM 兼容机)。后来一个叫比尔盖茨的人做了一款叫 Windows 的图形界面插件——我刚好是 Windows 很早期的用户 ,这样一款名叫 Windows Interface Manager 的插件是 Windows 的最早形态,后面微软基于这一 GUI 图形技术做了一个全新的软件——Excel。「Excel」这个英文单词中文意思,是「超越」。

微软现任 CEO 纳德拉也曾公开承认,Excel 是微软有史以来最伟大的产品。

为什么我们要了解这些信息呢?

很多人都没有意识到,电子表格已经 40 年了。

但是!

今天很大一部分的技术管理者还在为 Excel 打工

包括项目协作、软件开发、配置管理等等。

为什么?

让我们细数技术管理的三宗罪。

技术管理第一宗罪:伪项目协作

如何去做管理、做敏捷,是每一个技术管理者的日常思考题,得出的结论通常是:我们需要项目管理工具。

以项目管理工具为例,这里就分成了几个流派:

第一种,喜欢简约的看板,每天「拖(动)」一下,就掌控了项目进度。

第二种,喜欢简单又能与代码开发整合的。相信不少人做技术管理时曾经历过:要求设计、市场、运营、行政等学习 Git 命令、使用 Gitlab,认为这样才能和代码整合,实现最高效率。我本人也曾这么做过。

第三种,喜欢专业型的工具。专业的团队要用高大上的项目管理平台。不会用?是你们水平不行。

还有一个「终极流派」,通常是项目经理层面——这群人最爱的都是 Excel 表。他们普遍认为,单元格的「拖拽感」,实现对进度表的自由调整,灵活度较高。

虽然项目管理工具拥有这么多「流派」,但不变的主题是:「完美的」项目管理工具,只是「奢华的梦想」。

现在我们经常谈及「数字化」、「产业互联网化」,大家都想要数据整合、要中台、要打通。

但讽刺的是,现实是大部分技术团队内部都是分裂的「数据孤岛」,也就是说,每天喊着帮别人「数据孤岛」的一群人,自己每天内部也是一堆「数据孤岛」

在项目管理的模式上,由于组织不同、业务流程不同、组织者习惯不同等因素,造成「数据孤岛」,数据难以有效协作,这是第一宗罪。

技术管理第二宗罪:无尽增删改查

2017 年,我到喜茶后进行了一次调研。那时候「数字化」不像今天这么流行,「新零售」的概念也没有出现。但当时这个问题很困扰我:数字化究竟是什么?

经过观察,我发现传统公司里几乎每一个人日常使用工具都是 Excel。譬如,一万多人的人力资源管理、几千种物料的供应链管理、加上门店管理、门店员工管理、市场活动等等,都在依赖 Excel。

这是我 2017 年所看到的真实情况。当时我去参加了一次演讲,放了一张公式:企业数字化指数等于总人员减去重度操作 Excel 的人

当场有很多人拍了照,还分享在朋友圈中,以上这张照片,是我从他们朋友圈找来的,我才发现:这是绝大多数企业不可言喻的痛

我当时就有了一个今天看起来很粗浅但却很务实的认知——所谓的数字化转型,就是「干掉 Excel」,在执行上,把所有的 Excel 打掉,变成一个个基于网页的系统,让所有的员工、不同的部门可以在上面一起协同工作。

以这个思路回到执行层面。

你会看到市面上这么多的小程序,但小程序的背后是什么呢?

是各种「表格」,是基于各种「表格」的管理系统。

你们肯定都用过这类的系统后台,比如:商品管理,内容管理,订单管理,产品管理,门店管理,学生管理等等。

为了运营这一个后台,我的研发团队中有 100 人在做这件事。在版本更新时,各种各样的表在满天飞,我觉得「哇,大家好忙啊」,但是在忙什么呢。

都在忙着数据库的增删改查 (CRUD),很多做过 IT 系统的人都有过这种不太友好的经历。

最让我沮丧的是,两年后适配的业务系统已经很多了,但几乎所有的业务部门都会提一个功能需求:导入 Excel

我们不是做了后台吗?为什么还要导入 Excel?真实的反馈是:所有的IT系统,跟 Excel 的「拖拽感」无法比拟。

因此,在做了数十个管理系统后,我发现:

程序员面临的最大问题是:你以为在写软件,但其实你只是在「加载数据库」。软件分为前端和后端,100 人的团队里可能做前端小程序的只有 2 个人,剩下的 98 个人都在做后台。大部分的工时被消耗在后台的数据产品以及业务逻辑上,也就是后端——他们都一直在增删改查。

他们一直在试图用 Excel 的灵活来「弥补」Excel 无法做到的数据结构化,这就是「导入Excel」的功能。

这是第二宗罪。

技术管理第三宗罪:配置管理黑盒化

随着公司规模和团队规模的发展,你的项目比开始变大,业务的需求开始变多。

配置管理黑盒化,什么意思呢?

随着产品迭代、业务部门用户增长,各种各样新的需求开始出现,比如价格修改、界面调整等等。

技术管理者通常认为,现在需要做的是:一个抽象化可配置的系统。

但执行上「可配置」来不及了,最快速的解决办法就是:脚本化的配置管理。比如 YAML、XML 等。

这种配置解决方式在许多行业存在,以游戏行业为例:

1 个网络游戏有上千张 Excel 表,游戏策划的工作都是用 Excel 表进行配置。我自己以前就做过 4 个不同的表格配置工具,妄想加快策划配置的效率。 有些时候,来不及做配置表了,就对策划说:这个表设计得很复杂了,要不直接写 LUA 脚本吧。 结果,很多游戏策划的都是会写代码的产品经理。

再比如运维领域,运维的同学知道,当运维开始,需要各种各样的机器、全国各地需要运维时,就需要一个团队来做 CMDB 系统,或者做一个测试用例系统,再加上前端、后端测试——这些的本质还是不同的表格。

而没有实现结构化、可视化的配置管理,配置管理对于普通人来说,是不可正常操作的,正是技术管理的「第三宗罪」。

伪项目协作流、无尽「增删改查」、配置管理黑盒化,三宗罪听起来是三件事情,但它本质都是一个事情:都在尝试将本地的表格数据结构化、在线化,实现协作。

我们为此投入巨大的成本,效果却不甚理想,问题出在哪?我们来抽丝剥茧,分析一下:

👉 为什么千万项目管理工具不敌一个 Excel?

刚刚有讲过,对于项目管理工具:有人喜欢看板的,有人喜欢专业的,喜欢需求测试一体化,有人喜欢跟代码提交绑定在一起,但是更多的人到了后期一般都会用复杂的 Excel,用自由单元格进行拼凑,像项目经理。

典型的是非技术背景的项目经理,他们就很难用得起偏研发的项目管理工具,因为所有的这类软件结构都是固化的,维度不可变,无法灵活地做连接。Excel 则是人人都会用的,并且表格式「拖拽感」让人轻松。

👉 为什么会有无尽的「增删改查」?

这就要提到计算机软件的形成。大家每天都会接触不同的软件,但几乎所有的软件离不开下面这个图。

首先,你需要一个关系型数据库(如 MySQL、Oracle),接着找到一位后端程序员,用不同的语言来读取数据。他们通过辛苦的工作生成了 API。再找一位前端工程师,做出客户端,再接入 API。从我的经历来说,大部分的软件都是这种运作结构。

我们都知道工程师、程序员的工作量都在「增删改查」、生成 API 上,那么更本质的问题是什么?

关系型数据库,不能「直接编辑」和「拥有 API 能力」,所以我们需要用大量不同的语言跟框架去满足这些需求。

👉 为什么配置管理黑盒化 ?

随着业务的发展,各种各样的需求被提出,这里就存在两套思维模式:

第一种是「工程师思维」,工程师需要什么,他会想:哦,你的需求要严谨、要结构化,我们可能要基于数据库或者一个稳健的工具来做。工程师的选择,一般是用脚本语言做配置管理、或自己做一个配置管理系统。

但是前面的业务部门并不这么想,这就是第二种「业务部门思维」。他们需要的就是简单地「拖拽」一下,或大喊一声「啊,哥帮我改一下」,就完成一次配置管理的改动。所以对他们来说,为了实现业务变动的配置,你让我学 YAML、学 LUA 啊,是什么鬼!能不能做个工具直接搞定?

这两种截然不同的思维方式,就是「配置管理黑盒化」重要表现。

那么,在了解并适当分析了问题后,如何解决这些问题呢?

我们来做个简单地回顾,项目管理、「增删改查」、配置管理这些痛点,可以推导出所有数字软件的三大原则

原则一,绝大部分的软件「底座」是关系型数据库。可以说,没有数据库就没有软件,编程语言都是建立在数据库的基础之上。

原则二,绝大部分用户对软件的需求是电子表格式的「拖拽感」,无论什么高大上软件,用户只想要简单的「拖拽」操作感,所有行业建立了众多IT系统后,业务部门还是需要——「导入 Excel」功能,并不是你的系统功能不强大,而是你不能帮助他们更好更有效地去执行。

原则三,绝大部分工程师每天忙碌于对接 API,后端工程师负责生成 API、前端工程师负责接 API,这是他们的日常。

那么问题来了,有没有办法让 Database+Excel+API 结合呢?

有,那就是 vika 维格表

这样一款产品,势必对软件的开发模式产生深远影响,那么,现阶段我们(vika维格表研发团队)是如何用 vika 维格表来做产研协同管理的呢?

如何用 vika 维格表做产研协同?

需要明确的是,vika 维格表是一个新的思维方式,在关系型数据库的基础上,产生的「关系型电子表格」,保留了关系型数据库的本质属性,加入了 Excel 式的「拖拽感」,简单好上手。

那么基于 vika 维格表,我们是如何开展工作呢?

首先,就是充分发挥 vika 维格表作为「关系型电子表格」的优势,去做各种各样的情报收集,沉淀成「需求池」。

我们知道,产品需求在成为真正的需求之前,是经历过很多讨论和挣扎的。由于 vika 维格表的可定制化,我们与通常的项目管理的「需求池」不同,可以根据需要将需求划分成3个不同的阶段,分别是浪选、海选、正选。

第一个阶段叫:浪选(反馈与吐槽)

来自微信的吐槽可以被迅速记录,需求的详细描述、 是否有人响应与有人吐槽,是否是我们关心的内容等等,这些都可以通过维格表定制化搭建实现记录。

需求从提出到落地会经历多个环节,其中最有意思的阶段是「海选与投票」,产品与研发的人都在一起投票,一堆人同时打开一个网页进行各自的「投票」与「吐槽」。多人共同在线编辑,也不会出错,这是维格表的优势之一。

一个需求从「浪选需求池」进入到了「海选列表」,再加入运营与业务部门的共同投票,通过公式计算「喜欢度」。

这时候就实现了项目管理体系上:业务与研发打通,随时可变成看板模式。

第三阶段叫需求正选列表,这时候就涉及到执行细节和执行人员了。

其实前面还有一个定迭代的部分,时间有限,这里按下不表。

与过去所有项目管理系统不同,我们有着「需求整理」和「海选投票」,基于 vika 维格表的灵活可定制特性,结合自己的需求去定义一个项目管理的流程。

在版本发布后,我们还有个「bug 缺陷」,快速发现、迅速调整,bug 会有固定的版本,可以像卡片一样移动到下一个版本中进行迭代修复。

通过 API 与 IM(钉钉/企业微信)连接后,无论你在移动端或 PC 端提交 bug,都会自动提交给研发人员。

关系型电子表格与 API 结合后能碰撞出什么样的新鲜玩法?我们一直在尝试。

典型案例是,我们可以实现测试用例自动化。

比如,用来做测试用例系统。首先,配好测试的用例,直接去调用 API,通过 API 自动 POST JSON,去测试接口的正确性。

测试用例的本质就是去调用 API,最终出具测试报告。

看这一张表,今天执行怎么样:有没有失败?哦通过率 98%,测试用例数 100。这是我们真实的一个表。

基于整个 API 接口,怎么去尝试一些更多的玩法?

既然 vika 维格表支持 API,同时是个数据库,那么也意味着是个很好的「爬虫」数据库。我们可以直接用 vika 维格表来做「爬虫」——直接把他当成一个「爬虫」数据库,而且是实时协同。

一般你「爬」进来数据库,不能可视化,还需要进行二次处理。但维格表通过 API 一扒,直接实现把数据库实时可视化。

比如,与 iOS 平台上「快捷指令」app 快速整合起来,成为一个场景:用「快捷指令」去扫一个码,查询大数据的 ISBN 号,再通过 API,一行代码都不用写,就实现了一个图书扫描系统。

这就是可视化电子表格其中一个场景。

所以,当我们回头来看整个原则,会有一个全新的思维方式——维格思维。这个全新理念的代表产品就是:vika 维格表,一款支持 API 的关系型智能表格。

相信我,当你深刻理解「维格思维」的真正内涵后,你会对整个计算机行业有全新的认识。

比如,vika 维格表将 Database、Excel、API 整合,这意味着我们很多日常工作都会被轻松解决,不需要每天增删改查、每天导入 Excel。

在完全脱离技术管理应用之外的场景中,vika 维格表也有着异常丰富的应用场景,比如我们有宝妈用户就用来做「带娃攻略」,用 vika 维格表做了一个「科学育儿群之宝宝吃鱼」的数据库,并且分享到社群里。这是可视化数据库的天然优势。

发现了吗?vika 维格表,这样一种支持 API 的关系型电子表格,可以派生出一千多个不同的应用场景,比如:软件开发领域的产品研发管理、里程碑、版本迭代、产品需求、研发任务等等。可自由定制化的属性,比标准化的项目管理流程更加灵活强大。

作为一款新型的电子表格,vika 维格表同样可以用来做 CRM、OKR、VC BP 管理、案件追踪、本土吃喝玩乐、年度旅行计划、设计团队协作等等场景。

vika 维格表是可视化数据库,是一种全新的思维模式,是Database+Excel+API 三位一体的全新思维,是数据库与电子表格结合的全新尝试。

2020 年是「维格思维」的元年,vika 维格表不止于「一种全新的协作工具」,对于技术管理者来说,我们更值得去深思的是:以一种全新的视角去审视软件开发的本质

本文由博客群发一文多发等运营工具平台 OpenWrite 发布

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!