——这是我的第 157 篇原创文章——

学习 B 端产品，就看「司马特小分队」

1月14日，钉钉召开6.0发布会，又引热了低代码和零代码。
根据Gartner的数据，到2024年，65%的应用程序开发将是低代码。到2023年，超过50％的大中型企业将采用低代码应用程序平台（LCAP）作为其战略应用平台之一。
在人人可做软件的将来，产品经理还有一席之地吗？ 

01

什么是低代码？

低代码的起源，还得从上个世纪八十年代说起。1980年，IBM的快速应用程序开发工具（RAD）被冠以新的名称——低代码，由此，低代码的概念首次面向大众。低代码是英文“Low Code”的翻译，当然，此“Low”非彼“Low”，它意指一种快速开发的方式，使用最少的代码、以最快的速度来交付应用程序。
低代码是一种软件开发模式，简单“拖、拉、拽”即可快速搭建软件，就像用Axure画完原型，添加下链接就是一个软件了。低代码的形式是“可视化编程”，核心是“复用”。像中台一样，提高复用率是低代码的关键。
且不想会不会被客户淘汰，产品经理听着就很激动，再也不用和开发撕逼了，我想怎么设计就怎么来，不对了纠错成本也很小。
现实真是如此吗？ 

02

低代码的现状

就目前来说，低代码平台可以搭建表单、流程类的简单软件，但是复杂的B端业务，还是要靠码农码出来。
低代码不是无代码，在拖完可视化界面后，还是要简单编程的，比如用python 写上数据流转逻辑，那么产品经理使用时还需具备简单的编程能力。
低代码的优点很明显：
  • 通过配置即可满足一批新增或变更需求，直接避免了低价值代码开发时间，开发效率提升10倍并不夸张。
  • 通过配置无法完全满足的需求，虽然仍有开发工作量，但由于可以复用平台能力，也节省了相当一部分开发工作量。
  • 由于平台能力复用，会大大缩短端到端交付时长，如测试时长、集成发布时长等。 
但低代码的缺点也显而易见： 
  • 低代码平台本身是一个开发框架，能在平台上造出什么很大程度依赖于框架本身的能力。
  • 虽然很多低代码平台标榜自身灵活性强、解决企业个性化需求，但其前提是在框架能力范围内。如果个性化需求刚好不在框架能力范围内，二次开发实现成本、时间都不容小觑。若企业所选的低代码平台刚好又不够开放，对平台支持和升级的强依赖性会让企业有苦难言。 

03

低代码会取代产品经理吗？

低代码已然是一个不可逆转的趋势。在担忧是否会取代产品经理前，或许程序员更应该担忧。
我们来梳理下产品经理在软件开发中的主要职责：

  1. 挖掘客户需求

  2. 设计产品

  3. 验收产品
假设不需要产品经理，那么上述工作都由客户来完成，就我们实际的经验来看，可能吗？
很难！或许在若干年后，由娃娃编程抓起，是可以实现的。
很多产品经理说，觉得自己就是个工具人，没有价值，客户说要什么功能，我们就做什么。但是如果真让客户自己来设计软件，90%以上跑不起来。
产品经理的基本功并非一日而成，B端来说3-5年才能夯实基础，做到设计功能时没有细节遗漏，能贯穿各模块，能辨识出功能潜在的坑。 
一方面软件的运转和生活思维是有很大差异的，客户不一定知道转化成软件后，应该要怎么实现。就是那种一看就会，一做就废。另一方面功能的完整闭环、异常情况的考虑，着实是需要强思维逻辑的。
B端产品经理，既懂软件实现，又懂行业业务。假如我是企业主，我不会让行政、管理去做这件事，专业的事情还是要专业的人来做，我宁愿购买一套低代码平台，花钱找产品经理来帮我搭建系统。届时，我们还真能从乙方变成甲方爸爸。
假设低代码平台发展到成熟的阶段，一切皆可编，对程序员的需求就少很多了，但是要求会高，这就意味着能力一般的被淘汰，或可以转为产品经理一样的角色。
END
我们在星球成立了“B 端产品经理之家”，汇集了 230+ 来自教育、医疗、电商等行业的小伙伴,每天都有各种产品话题讨论，也有行业专家答疑解惑。
更是有多位小伙伴，通过我们的「系列课程」和「改简历」，成功拿到心仪的offer。
每天不用 1 块钱，得到的是可见的成长。

回复「星球」了解更多服务

声明：本站所有文章，如无特殊说明或标注，均为本站原创发布。任何个人或组织，在未征得本站同意时，禁止复制、盗用、采集、发布本站内容到任何网站、书籍等各类媒体平台。如若本站内容侵犯了原著者的合法权益，可联系我们进行处理。