广告位
首页 资讯 工具型产品经理的思考(产品经理应该掌握的技能和工具)

工具型产品经理的思考(产品经理应该掌握的技能和工具)

用友原本有一条产品线,叫YonBuilder,它可以助推BIP 商业创新平台的完善,起到低代码前置和展示的作用。去年用友并购了API Cloud,也表明了用友想做低代码的决心。不过…

用友原本有一条产品线,叫YonBuilder,它可以助推BIP 商业创新平台的完善,起到低代码前置和展示的作用。去年用友并购了API Cloud,也表明了用友想做低代码的决心。不过Gartner的分析师更倾向于将低代码说为轻量代码。 相信大家都听过MADP和LCDP,这两个平台之间有什么关联?从过往Gartner的一个报告来看,左侧MADP象限里涵盖了一些公司,如Microsoft PowerAPP等,因此这些今天听说过的低代码开发平台公司,他们也有可能同时存在于移动应用开发平台的象限之中。 右侧即我们常见的低代码中台。二者紧密相连,假如你是一个低代码cover平台,那你也会是一个移动云开发平台。 因此我们会发现,当我们访问Microsoft网站时,对方除了说明自己是低代码平台之外,还会说自己是移动应用开发平台。 此外,低代码有没有标准?可能现下大家相对直观的感受便是,基本上所有软件公司都会说自己为低代码、甚至无代码公司。但其实低代码有自己的相关技术标准。从Salesforce代码开发平台来做分析。它主要由三个板块组成:
  1. aPaaS;
  2. MADP lightning;
  3. 最终展示时的移动生态。
综上,低代码平台需要涵盖三种能力,即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相似的分配标准。 因此低代码有这样几个特点:
  • 少量代码:降低重复性工作;
  • 快速试错:提升效率;
  • 图形化:让业务团队能参与进来。
其一,进入行业较久的互联网朋友们可能听过一些DNS系统;在当时,有些系统可以以无代码的方式拖拽式生成一个手机网站,以及适用于各种场景的、基于论坛和新闻展示为模式的建站系统。 但是无代码并不具备核心竞争力。与之相对,低代码的基础标准是这样的:涵盖了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年我选择辍学创业。在我做产品经理的时间里,我觉得最核心的,便是有自己的坚持,从综合的、商业的角度锻炼自己的想法。想法始终是产品领域最核心的、自我历练的基础之一。
本文来自网络,不代表千度号立场。转载请注明出处: https://www.taibaowl.com/19393.html
广告位
上一篇
下一篇

作者: 395045033

为您推荐

发表评论

您的电子邮箱地址不会被公开。 必填项已用*标注

联系我们

联系我们

在线咨询: QQ交谈

邮箱: 395045033@qq.com

工作时间:周一至周五,9:00-18:30,节假日休息
返回顶部