工具型产品经理的思考

3 评论 15186 浏览 34 收藏 23 分钟

2021年11月6日 – 11月7日,人人都是产品经理举办的【2021产品经理大会•深圳站】完美落幕。用友网络助理总裁@刘鑫 为我们带来了精彩的分享,他分享的主题是《工具型产品经理的思考》。添加大会小助手豆豆(微信号:13265455310),回复暗号【031】,获取本场嘉宾分享视频回放,观看完整演讲。

大家上午好,简单介绍一下个人经历。目前我就职于用友,另一个身份是APICloud 的创始人,这是一款移动应用开发平台,也是云上交易平台。

今天我所分享的核心主题是低代码。这个词近来大家也听说得较多,为何低代码近两年这么火?它跟企业的关注点、落脚点有紧密联系。可以相信的是,低代码起码还会再火三年,因为到今天为止,低代码在国内仍没有一个有效的、真实的逻辑。

今天我便会从一款低代码产品设计工具的诞生,来分析整个产品的设计思路。

用友有一条产品线,叫YonBuilder,它可以助推BIP 商业创新平台的完善,起到低代码前置和展示的作用。今年用友并购了APICloud,也表明了用友想做低代码的决心。不过Gartner的分析师更倾向于将低代码说为轻量代码。

相信大家都听过MADP和LCDP,这两个平台之间有什么关联?从过往Gartner的一个报告来看,左侧MADP象限里涵盖了一些公司,如Microsoft PowerAPP等,因此这些今天听说过的低代码开发平台公司,他们也有可能同时存在于移动应用开发平台的象限之中。

右侧即我们常见的低代码中台。二者紧密相连,假如你是一个低代码开发平台,那你也会是一个移动应用开发平台。

因此我们会发现,当我们访问Mendix或OutSystems网站时,对方除了说明自己是低代码平台之外,还会说自己是移动应用开发平台。

此外,低代码有没有标准?可能现下大家相对直观的感受便是,基本上所有软件公司都会说自己为低代码、甚至无代码公司。但其实低代码有自己的相关技术标准。从Salesforce代码开发平台来做分析。它主要由三个板块组成:

  1. aPaaS heroku;
  2. MADP lightning;
  3. Marketplace AppExchange。

综上,低代码平台需要涵盖三种能力,即aPaaS能力——底层云端服务器的能力、前端偏重移动开发平台的能力。而在以工作流的方式操纵了底层的aPaaS能力以及表层的MADP之后,便形成了最终的低代码生态,或者是应用开发市场。

这三个方面涵盖之后,可以起到什么作用?

一、MADP/LCDP都是为了RAD

低代码本身需具有图形化、可视化、流程化的操作能力,主要应用于移动端产品。

企业需求正在逐渐变化,从最开始IaaS需求转变为PaaS需求,再过渡到RAD,即快速应用开发平台。不少企业近几年选择上云,会发现一个直接问题,即将企业的IT系统从内网移到外网、或者移到云上,似乎并不能解决核心问题。

而中台的本质即PaaS,到今天不少企业也发现:上了云、上了IaaS,中台也做了,但是核心问题仍旧没有解决。这就要求我们发现企业所想解决的问题本质为何:即不管利用中台或其他基础的云,产品一定要将满足所有业务需求应用开发出来。

再倒推来看,企业上中台或上云,核心目的即将最终应用开发出来,这也是近几年低代码这么火的原因。

因此关于RAD:无论IaaS或者PaaS,无论上云或者使用中台,都是过程而不是最终的结果。

而关于APP,各种应用(Web 小程序 移动应用 HTML5)才是最终承载业务的抓手。

现在企业数字化、智能化中最重要的矛盾存在于业务部门各种小的、甚至不太看得上的需求之中,IT部门在实现时,依旧周期长、成本高、问题大。

因此低代码未来一定会面向应用本身。近几年这么火,是因为它可以解决企业核心的、看似最平常的应用问题。

二、Low Code

那么低代码是不是只能做小的、轻型的应用?

这个问题其实对从业者来说打击性很大,因为人们可能会说低代码平台本身即低价值的,它只能做小程序、小应用。

好像的确是这么回事儿。

首先,低代码的主要能力涵盖的是小型应用,这里面有其自身的逻辑。

2015年,Gartner曾经有过这样一个分析象限,其中,应用场景分为三类。

其一,基础设施型应用。这类应用其实施周期、生命周期都相对较长,企业内部的实施周期大概为七年左右;与此同时,它在企业内部的存活周期可能会超过12年,变化相对较小。典型代表为ERP。

其二,差异化设施应用。这类应用的实施周期大致1-2年,存活时间大致1-3年,这类应用的典型代表为CRM。

其三,创新型应用。这类应用生命周期短,规划周期和实施周期不能超过6个月。该应用在企业内部的生命周期大致在一年之内;同时要求快速交付。这类应用适用于持续集成、以及敏捷开发等场景。

第三类应用就是我们今天所说的小应用、小程序。

那么这几类应用谁来督导、发行?这类应用多为部门发起,所处理的事宜大多也为企业内的“杂事儿”。比如HR计划做一次内部的健康筛查,此时会需要建立这类小应用;比如传统IP覆盖能力产值,这事儿会由IT部门主导。因此可以看到,第三类应用有着典型的不同。

今天的企业为何要上云?前两种应用并不是企业上云的目的,尽管企业内网的ERP、CRM等东西可以挪至外网,但这并不具备任何实际价值,仅是移动搬家时代的体现,可以让场景使用相对丰富而已。但本质上,内网已经可以满足原有需求。

因此大家应有一个直观认识,低代码并非只能做小型应用,云上用户之所以上云,是为了快速开发和迭代,满足业务部门的需求。因此,低代码开发平台主要是为了解决新问题,主要用来做基于移动和云的、业务部门发起的创新型的数字化智能化应用。假如技术人员、IT部门不能很好地满足业务部门的数字化、智能化需求,此时企业便需要借用低代码平台来打造数字化的竞争优势。

另外,低代码的推广不能只讲太多技术说的话,这并不适用于低代码的全球市场环境。

国内低代码公司的从业人员大多讲的和国外不一样,他们借助低代码的概念,讲的是中台。而今天的低代码虽然涵盖了中台的能力,但这并不是它的核心要务。低代码所需解决的,是公民开发者如何参与到企业的IT进程中的问题;真正的赋能公民开发者才是低代码的价值。而如何提升IT部门效率的问题,才是传统PaaS或中台所需解决的。

那什么“不是技术的话”?如outsystems,这是全球低代码领域内的一个标杆公司,单笔融资了上亿美金。可以看到,它所讲的是customer experience,即利用低代码平台可以做出拥有更佳用户体验的应用;operational efficiency,即自身效率的提升,实现系统的现代化;还有digital transformation等等。

因此,低代码并不等于中台,它只是涵盖了中台的能力。更核心的在于它能不能做出更好的、比如和outsystems相似的分配标准。

因此低代码有这样几个特点:

  • 少量代码:降低重复性工作;
  • 快速试错:提升效率;
  • 图形化:让业务团队能参与进来。

其一,进入行业较久的互联网朋友们可能听过一些DISCUZ系统;在当时,有些系统可以以无代码的方式拖拽式生成一个手机网站,以及适用于各种场景的、基于论坛和新闻展示为模式的建站系统。

但是无代码并不具备核心竞争力。与之相对,低代码的基础标准是这样的:涵盖了aPaaS的能力、涵盖MADP,以图形化、可视化、流程化的方式进行组合,驱动底层的PaaS和表层的MADP,最终形成低代码。

因此,低代码不代表无代码,它需要一定的代码工作量,其目的是为了让业务部门参与整个过程,形成完整的组合和有效的低代码应用,实现APP数字业务的创新。而无代码无法满足企业将数字化当成核心竞争力的这一前提。

其二,快速试错,提升效率,即企业可以快速地变化、升级。

其三,图形化,即让业务团队参与进来。低代码平台其实很适合产品经理。以往产品和研发提需求时,如果研发态度不好,可能甚至会告诉产品这个需求无法实现。但是低代码时代来临之后,产品可以帮研发将事情做到七八成,研发只需完成剩下的部分。

而关于低代码开发平台的最终检验标准,有这三个方面:

  1. 能不能开发2C和智能硬件的应用;
  2. 能不能有效连接企业内部和云端的API;
  3. 具不具备三种能力:图形化、MADP、aPaaS。

早期低代码开发平台只能做表单式,但是能否做好2C体验的产品,才是低代码平台的核心价值之一。

今天的低代码开发平台也需要很好的连接能力,毕竟现下企业做应用时,并不要求完善自身内部的所有程序,它可能会用到多家的系统。因此连接能力是必须的,这也是PaaS的能力之一。

而以图形化的方式进行组合,可视化驱动底层的PaaS和表层的MADP,则是衡量一个低代码平台有效性以及真实性的基础标准。

三、企业怎么用?

低代码开发平台给企业IT解决什么问题?给谁用?

Forrester是相比Gartner更早定义低代码的公司。在分析报告里,它提出了低代码的两种定义:

其一,面向企业内传统IT开发团队,给专业研发人员使用的开发平台。

其二,面向业务团队,即非传统IT人员群体使用的开发平台,即公民化开发者。

因此在国外,Low Code 分成两种产品模式,面向不同的群体实现输出。当下在国内,我们很少听到有人专门面向产品经理提供低代码工具,更多的还是第一种,可能通过模型驱动,提供专业的IT数据,但这种工具对我们而言还是太复杂了。

那么,企业到底该怎么用低代码开发平台来做应用?

而我作为产品经理、作为低代码开发平台分析师,我又该如何设定我的产品?

首先,面向经过培训的业务团队,我们给他使用的应该是图形化、可视化的工作台。且要想让这类非专业人员使用低代码,我们可以从普通互联网用户角度出发来进行思考,满足他们的需求。

其二,代码部分应该如何配合这类人员?则应当让业务团队优先处理各种需求,让碎片化的需求规范化(如输出PRD、专业的Axure原型等),进而推动业务向研发团队行进。

举个例子。比如HR部门发起一个诉求,此时需要进行需求梳理,再设计产品原型UI等。在分析完整个流程之后,我们会发现,图中标黄的部分在原本IT能力范围之外,标绿部分则是企业IT人员所擅长的。

因此我们在想,关于前半部分,我们是否能够做出一个工具将其串联起来,并跟后半部分也串联起来,形成一个完整的流程,让每一个小的需求都在规范流程里流走,并形成一定的技术标准。即产品经理最后画出的原型会变成代码,最后IT团队则可以轻松地完成剩余事情。为此,我们划定了右侧部分,将其变为标准化的流程。

而码前便是基于这样的逻辑下诞生的。它可以做什么事呢?

首先,它可以将Idea快速孵化,利用现成的事物实现高度复用,缩减时间周期。比如开发注册页面,此时我们可以挑选模板,这些模板的核心功能并无太大差别,利用模板,我们实现引导页面复用、通用化功能复用等,不仅输出了产品原型,更是完成了低代码的输出。

其二,降本增效;即一个人便可以完成多个人的工作,可能未必专业,但是减少了沟通环节;之后再交付专业人士。

其三,管理便捷,即所有流程都可以被串联起来,在一个平台上实现通用化的流转。

而这能起到什么帮助?

比如,可以帮助业务部门精准地描述企业IT数字化需求,利用模板方式创建引导,进行产品设计,形成高保真的、可实时保存的云端协作原型设计。低代码开发也可以实现前后同步驱动,联动前端开发与后端开发。

以上便是我对产品经理可使用的、低代码工具的设计和思考。

说回一个问题,是不是人人都可以做产品经理呢?就我个人经历而言,这个问题的答案是否定的。

产品经理可以分为两种,其一,会画原型的产品经理;其二,也是大家更为追求的,即可以从战略角度出发、把控整条产品线的产品经理,这类产品经理需要对市场方向等方面有所思考。

而我们做低代码,也是基于整体方向的思考上进行。因此我觉得,产品经理其实跟艺术创作类似,都需要一些天赋。做研发的,可以学习计算机、学习自动化;做UI的,则大多是美术出身;这些角色都是有地方可以进行学习的。但是学校里并没有专门开设一门关于产品经理的课程。

举个例子,为什么微信PC端一定要扫码登录?按我个人理解,使用PC端登录微信的场景相对较多,此时输入用户名、密码进行登录反而更为简单快捷,为何从产品出现伊始,它就要求用户PC端必须扫码登录呢?

可能最开始关于这个产品设想,研发团队并没有太多思考。但今天微信仍在坚持,我觉得,这便是一个产品的逻辑,是产品的坚持和设计。每家产品都有自身的战略思考,不会轻易地被用户调研左右,因为用户需求调研所得的需求很可能都是伪需求。更核心的,还是在于思考。

而码前这个工具可以做什么?当下我们梳理产品需求的时候,大多按页面进行处理;生成这些页面之后,码前支持将所有页面导出为一个个对应的sketch文件。最简单的逻辑在于,这一方式可以防止页面遗漏,这也是对UI工作的一个有效提升。

总结一下,产品经理需要有自己的坚持,这是最核心的道路。产品经理也需要拥有战略思维。

四、最后

2000年我还在上大学,2003年我选择辍学创业。在我做产品经理的时间里,我觉得最核心的,便是有自己的坚持,从综合的、商业的角度锻炼自己的想法。想法始终是产品领域最核心的、自我历练的基础之一。

我个人比较认可英国的撒切尔夫人所说的一段话:

Watch your thougts,they become words;

Watch your words,they become actions;

Watch your actions,they become habits;

Watch your habits,they become character;

Watch your character,for it becomes your distiny.

而作为一个产品经理,我们的想法是所有一切的来源。希望大家都可以成为一个独当一面、涵盖所有能力的产品经理,这其中可能需要一点天赋,大家可以校验一下自己。

相关阅读

大部分成功的商业创新,来自于组合创新——2021产品经理大会·深圳站现场报道

年度行业大会开启巡回

互联网圈年度盛典,听一线实战专家深度分享,与数千位互联网圈同行深度交流,拆解产品、运营实战案例,挖掘行业新机会!

扫描下方二维码添加大会小助手,回复暗号【032】领产品经理&运营人必备工具包,获取全年大会最新资讯!

本文为【2021年产品经理大会·深圳站】现场分享整理内容,由人人都是产品经理运营 @Aine 整理发布。未经许可,禁止转载,谢谢合作

题图来自大会现场

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 有太多产品不懂技术底层,跟技术扯皮倒是厉害的很

    回复
  2. 因为产品不懂代码,换个懂代码的产品就能做的像模像样

    回复
  3. 这篇文章对于门外汉来说,读的有一些吃力了,但是作者写的还是很详细。

    来自云南 回复