零代码带来的工作和创业机会

技术演进往往会推动企业内部职能与协作关系的变化。新技术会消灭一些岗位，也会创造出很多新岗位。大数据技术兴起，产生了数据分析师岗位，云计算技术发展，带来了对运维工程师的需求。同样，应用平台的出现，会让企业内部出现应用搭建师这样的岗位。只不过，这个岗位需要的是数字技术理解和业务流程知识的综合，而不是单项专业技术。因为应用平台能够替代相当比例的原生定制开发，所以它不可避免地会减少对重复性开发工作的需求，从而减少对一般企业应用开发人员的需求。

 

所需要的技能组合

 

通过应用平台搭建应用显然不需要软件开发能力，但也不意味着任何人都能够用同样的程度掌握。简单的单表应用创建难度类同于建立一个Excel表格，一般的职场人员都不会有难度，但是要结合自己企业业务需求，构筑一个包含多个业务数据对象，多个工作流程的应用还是需要一些特殊技能的。我们通常把这组技能称之为抽象和逻辑能力。

 

抽象能力是指从具体现象出发，抽取出规律和模型。在应用平台使用中，抽象能力有助于从纷繁复杂的人、物、事中识别出正确的对象，并给予合理命名和边界，从各种具体的企业管理流程中识别出工作流的形态，并能够用最简单的结构来表达它。举“个例子来说，在建立和销售过程有关的应用时，需要识别出与人有关的对象包括销售人员，客户联系人，和物有关的对象包括产品，产品价目表等，和事有关的对象包括报价，报价明细，订单，订单明细和销售行动等。这些对象构筑在一起，就能够闭环记录和更新在整个销售流程。

 

逻辑能力则值得一系列和逻辑学有关的知识和经验。在应用构建时，常常需要对属性做细分，那么用户最好能够理解什么叫互斥并穷尽（MECE），在设计工作流的时候，要准确判断分支条件、节点次序，并且要在脑中预想工作流真实运行时的数据形态变化。

 

与其说，抽象和逻辑能力是一种天性，不如说它更多是后天依靠经验来增强的。尤其在软件领域，一种事务的数据和流程架构大多数不是依靠聪明人每次构想出来的，而是产业通过最佳实践积累出来的。应用APaaS的时候，过往各种管理软件的使用经验，包括对那些软件的界面流程记忆，都能够用来帮助更好地使用应用平台搭建自己的应用。简单说，就是看得多了，也就会了。

 

 

零代码相关的岗位

 

企业不至于产生"零代码应用搭建师"这样的专职岗位。如果是，那其实也有悖于零代码平台所推动的"全民开发者"理念。全民开发当然不意味着企业中每个人都要从事应用创建工作，但是它着眼于降低应用搭建的技术门槛，让非技术人员也能够参与到应用设计和搭建过程中来。所以，可以预期的是，在应用平台品类普及以后，企业的业务职能部门和IT部门在岗位设计和工作内容上都会有一些随之而来的变化。

 

（1）业务部门可能自己承揽数字化建设的部分责任

 

其实业务部门一直以来都有自主解决IT问题的诉求。一位承担质量管理的经理当然不愿意内部求人来解决配套的IT问题。一方面因为业务不等人，另一方面，要在内部沟通业务需求和流程本身也是一件特别费神的事情。IT部门通常排满了各种业务系统开发和迭代需求，在决定优先度和实现方式的时候，常常公说公有理，婆说婆有理，很多时候不得不上升到公司管理会议上去争论。

 

在所有业务部门，从销售，营销，采购，到行政，财务，人事，其实都有能力自主通过应用平台来实现自己想要的部门级应用。如果控制每个应用的规模和复杂度，那么大多数应用甚至无需求助IT部门或者外部。因为APaaS产品天生的开放度和灵活度，如果将来需要和其他应用整合到一起使用，也是完全可以办到的。

 

所以，在任何职能部门中，一些善于运用计算机，有比较丰富应用经验的人可能在部门主管的授权下直接动手来解决。有的时候，部门主管甚至可能自己动手。我们在市场实践中，还看到CEO亲自动手的，虽然这有一些过度管理的争议，但实践证明缺乏IT背景的员工是可能掌握这一代应用平台产品的。读者如果仔细读过了本书的主要部分，应该对此有信心。

 

掌握APaaS的应用能力无疑是要投入时间成本的。要建立一个简单的部门应用，实际搭建所需要花费的时间以天计，但是搭建前期的业务分析和平台学习可能要花费更长的时间。实际的经验表明，一位有意愿，有基础能力的职员，可以在2-4周之内掌握基础到中级的应用搭建。这些精力的投入，对于企业和个人来说都是十分划得来的。对企业来说，节省了外包开发或者委托IT部门开发的开支和时间，对个人来说，这是职业能力的极致体