关于灵活配置字段的学习与思考

4 评论 2902 浏览 18 收藏 17 分钟

编辑导语:无论使用什么产品,文字信息对于用户来说都是至关重要的,它可以大大提升用户的使用感和好感。在本篇文章中,作者从自定义字段的定义、配置字段为什么会节省时间、灵活配置的核心目的以及配置字段功能的缺陷这四个方面,为我们展开了详细地说明。

我们使用手机浏览APP、公众号、小程序的某个产品时,我们会读取产品中的文字信息。读文字内容前,我们通常会看下内容旁边的字段名称提示。

这是因为字段是产品中与用户交互的重要能力,是承载业务信息的载体,它能够让用户获取和传输信息,字段名称提示了用户这个字段内容里会包含哪种类型方向的信息。

最近我体验了第三方PaaS平台,发现他们前台页面显示的字段是在后台配置出来的,可以设置出符合我们公司业务个性化对字段的需求。而公司自研的系统一般少有后台配置字段的功能,通常是通过提字段需求,技术工程师编写代码完成的。

我们在采购第三方平台时,会留意系统是否可以自定义搭建我们想要的业务流程,是否可以根据我们公司业务对字段需求配置出自定义字段,需要采购有字段配置功能,支持需求字段配置的系统。

今天我们就来聊聊,体验了PaaS平台配置字段的功能和流程后的一些思考。

一、什么是自定义字段?

自定义字段是根据业务需求自定义的个性化字段,在自定义字段的过程中,定义字段名称的工作并不是业务方独自完成的,而是需要产品经理和业务方进行充分的沟通和调研字段名称是使用正式官方的,还是使用方便大家理解的,共同设计出来。

举个例子:医疗服务业务中涉及到医生记录用户的“身高“、”体重”、“体质数BMI”、“血压”等关于身体健康情况类的信息,就是属于自定义的个性化字段。

配置同学会根据公司业务方提出的这类字段需求,在后台中添加的字段、设置类型、属性和逻辑规则,并在运行维护阶段根据公司业务的需求对字段进行修改和删除。

  • 字段的类型:字段设置类型,是为了方便数据的插入,数据的类型有种,比如整型、浮点型、文本、文本域、日期、时间、单选、多选等等,定义了什么样的字段的类型,会使字段内容以什么形式进行存储,才能让用户保存的数据正确。
  • 字段的属性:为字段选择不同的字段类型,会联动出不同的属性设置。字段属性一般有“允许保留X位小数“、”必填”、”选填”、“默认值”、“唯一值”、“单位”、“自动计算”等等,设置了字段属性,会对用户保存的内容进行属性校验,数据正确才会存储成功。

对于配置自定义字段来说,“配置”是一种功能形式,是另一种让字段在前台页面显示和隐藏的方法。

运维同学在配置字段页面,根据业务对字段的需求,手动在后台录入字段名称、属性和规则,无需研发同学写代码,就可以快速实现原始开发方法中的数据库建模。

运维同学将配置好的字段保存后,前台页面就会根据后台的配置内容即刻进行展现,用户输入的字段值,也会根据后台配置的规则进行校验,配置字段会节省业务方等待字段上线的时间。

二、为什么配置字段会节省时间?

当公司没有后台配置字段的功能时,是需要技术通过编写代码上线字段的。产品和业务方对字段的规则沟通梳理后,会将这些字段规则记录到字段需求表中,字段需求表展现样式如下:

关于灵活配置字段的学习与思考

字段需求从调研到上线的完整流程如下图所示:

关于灵活配置字段的学习与思考

从流程我们看出,研发会对字段进行评审,校验产品经理对字段本身的需求和设计的逻辑是否正确,会对字段进行二次把关。

实际技术通过编写代码上线字段对于研发来说并不难处理,但是研发一般会将字段需求和功能需求合并在一起开发,统一进行迭代上线,字段上线的时间不会按照业务方希望的随时提出随时上线使用。

而后台如果有配置字段功能,产品经理梳理完字段需求表格后,就可以发给运维同学配置字段了。运维同学完成后台配置字段的流程点击保存,业务方就可以即时在前台页面中看到并使用需求字段了。

后台新增字段的配置流程一般为:

  1. 选择模块:选择新增字段在哪个模块;
  2. 创建字段:填写字段信息;
  3. 判断字段是否有依赖性:有依赖性的字段进行依赖性设置;
  4. 进行查重规则设置;
  5. 点击保存。

在后台配置字段,一般一个字段30秒左右的时间就可以完成配置流程。

字段量不多的情况下,一般当天就可以完成配置,供业务方使用。并不会像研发写代码一样,需要在测试环境发布后,测试流程完成再在生产环境上发布,配置字段节省了测试环节的时间。

三、灵活配置的核心目的

灵活配置的核心目的就是为了供业务方随时提出需求,及时支持,及时使用。灵活配置及时支持的对象:是业务中各种各样的业务场景及运营需求,通过字段和功能的配置的方式及时支持需求。

1. 为什么业务场景需要及时支持?

一项业务对于销售人员来说是有时效性的,销售人员要及时向甲方提供他们需要的资料、及时向内部反馈甲方交付的资料,内部审批流程完成后再及时通知甲方,最后完成签单、付款、服务整个业务流程闭环。

在上述的业务流程中,每一个业务场景和需求产品经理都需要设计线上产品化方案及时支持业务,帮助业务顺利开展和进行。在流程不断完善变更的过程中,只有迅速响应,才能让客户对等待的时间无感知,中间的过程不因为变更而中断,影响业务的正常进行。

因为及时支持业务场景就是为了帮助销售盈利,帮助公司做好服务内容,帮助客户体验流畅的产品服务。

2. 哪些特征的业务场景需要及时使用?

我的理解是非成型的初期业务会使用第三方平台,通过及时配置功能和字段的方式满足业务流程需求和场景需求。因为非成型的初期业务还没有固定的SOP,很多节点的规则和内容都会随着业务的发展而丰富起来。

在初期阶段,使用一个成熟的第三方系统能够通过配置及时的更新支持不断变化的业务规则和业务流程,满足业务方在系统中跑完全流程,不会因为业务的变化而经常陷入等待系统迭代的被动中。

SaaS/PaaS平台的租户大多数来自各行各业,对字段的需求多种多样、随着业务的迭代,对字段需求也会跟着业务随时发生改变,快速的支持增加/修改/删除个性化字段快速供业务使用是促使租户付费的核心。

四、配置字段功能的缺陷

后台配置字段的功能拥有业务方青睐的优势,同时它也存在着不可忽视的劣势:配置功能开发成本高、配置字段风险大。

1. 后台拥有配置字段的功能,会造成开发成本高

后台配置字段并不是仅仅做一个“功能”,因为系统的目的是为了将各个业务线的数据打通,所以后台配置的字段会牵涉到“业务”。后台如果需要配置字段,就需要有下面的能力支持:

  • 表单列表:不同业务流程节点会抽象出来不同的字段,这些字段会组成一张表单。运维同学根据用户提出的字段需求确定所在哪个业务节点,再确定字段将在哪个表单中显示;
  • 创建新表单功能:如果当前抽象出的字段,属于新的业务流程节点抽象出来的字段,没有匹配上的对应表单,就需要有创建新表单的能力,能够容纳新的业务流程节点;
  • 添加自定义字段配置功能:将字段名称、属性和规则根据业务规则进行填写;
  • 字段依赖性配置功能:将两个字段值之间的逻辑关系进行配置,比如不同的省市对应不同的医院,将不同的省市下对应点的不同的医院一一配置后,用户在前台中选择某一个省市后,带出来的医院数据就是这个省市下的医院数据了;
  • 页面布局功能:通过字段顺序的调整、常用和必填的确定,决定了新建页面和详情页面的布局。这部分提供了前台页面可视化的配置能力,通过拖拽组件、编辑展示页面中内容进行布局;
  • 字段的校验规则:通过校验规则设定,以保证前台用户录入的数据符合录入规范和要求;
  • 字段的查重规则:为了防止数据内容有重复项,保持数据唯一性,设置查重规则后,可以避免字段重复。

上述的7项能力为配置功能中配置字段和配置表单的核心能力,系统的灵活程度决定了配置的流程和规则的复杂度,从上述配置功能需要支持的能力中我们可以看出,相对于技术通过代码实现字段需求来说,后台增加配置功能的开发成本更高。

2. 后台拥有配置字段的功能,也会带来高风险

与研发写代码相比,配置字段的高风险主要体现在“字段名称更替”、“字段的禁用与删除”、“字段数量有上限”3个方面:

1)更替字段名称

由于字段名称可在后台操作修改,拥有配置权限的用户可以随时变更字段名称,很可能修改字段名称前,团队并未对字段的定义达成一致的共识,导致修改或改错了字段名称后,业务用户由于不理解字段名称的意义,填错或担心填错而不敢填入内容。

2)字段的禁用与删除

  • 字段的禁用:当字段在后台被设置禁用后,在前台页面中就看不到这个字段了,就像是研发写代码中对字段的逻辑删除。字段禁用后,字段所拥有的数据依然存在。
  • 字段的删除:当字段在后台被设置删除前,字段所拥有的数据需要做处理,“删除数据库里面的数据”或是“迁移该字段的数据到其他某个字段中”,删除字段一般仅限数据要求不高的业务。

当遇到不使用的字段时,一般将该字段在后台“禁用”处理,不做“删除”处理。因为删除字段,会删除字段所包含的数据,如果运维人员并未备份数据,就删除了字段,后业务方如果再发现删除字段下数据的价值,就无法再复原数据。

3)字段数量有上限

后台配置字段数量是有上限的,最多配置多少个字段的数量后台中是有明确要求的,相对于写代码支持的字段数量较少。如果是字段数量庞大的需求,面临的风险就是后台配置字段功能可能无法支持配置全集字段需求。

上述字段配置存在的3种风险,无论哪一种都会直接影响线上用户使用。因为风险的影响,使用户对系统的感知体验不好,造成用户操作系统的心里负担:

字段频繁更替名称让用户不知道如何填写内容;字段的删除可能会导致数据的丢失,让用户不再信赖系统,总想着再保存一份数据;字段数量有上限,让用户总觉得业务中的流程信息有缺失。对系统的使用动力就不会强,系统沉淀的数据不会是用户想沉淀下来的全部内容。对公司业务来说也是一种损失。

五、总结

配置功能优势和缺陷并存,第三方平台大多会设计配置字段的功能,是因为对于第三方平台来说,提高配置字段的效率是核心,设计配置字段功能的优势大于劣势。

而自研系统大多是代码支持字段需求的,很少做字段配置功能,是因为当遇到重要紧急的字段需求时,通过写代码也可以做到即时支持,而开发成本和风险性相对自研系统来说较高,系统的稳定性对于自研系统来说是核心,设计配置字段功能的劣势大于优势。

产品经理在思考是否设计字段配置功能时,需要将优势、劣势、我们为了解决什么问题和核心目标兼顾思考后,再判断功能是否可以做,是否做了有价值。

#专栏作家#

暮暮,公众号:禾暮暮,人人都是产品经理专栏作家。拥有好奇心且极度认真的产品同学。拥有财务理论知识和财务产品经验,目前在医疗健康领域,擅长中台产品设计。

本文原创发布于人人都是产品经理,未经作者许可,禁止转载

题图来自Unsplash,基于CC0协议。

给作者打赏,鼓励TA抓紧创作!
更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 两个问题,可否请教下
    1.灵活配置的字段,是在数据库中新创建列,还是使用已有的字段,用户配置以后再去映射
    ——我看文章中说字段数量有上限的,是因为在数据库中提前需要设置好字段的原因吗,还是业务的控制原因
    2.像SaaS类的平台,字段配置中如果不停创建字段可能会导致表列暴增,感觉上应该是映射已有字段,如果是映射已有字段,不同的用户看到不同的页面展示,这个权限范围是受到账号权限的控制吗,是归到功能权限吗

    回复
    1. 您好,因为我不是第三方系统的产品,我是使用者,所以我问了他们的产品哈,为啥对于自定义添加的对象,字段有限制,他们的意思是说,是从系统性能方面考虑的,本身系统都标准的功能和字段,如果我们添加了大量的自定义的对象,自定义的业务类型,自定义的字段,这些会影响系统的性能,并且如果大部分需求都是通过自定义的方式实现的,说明我们对于需求的实现方式,也可能并不是最佳的方式。总的字段的数量限制,是因为数据库底层表结构的限制。

      关于添加了太多,系统会运行的慢:主要是看字段的类型,比如加了一个文本类型的字段,只要总的字段数量不超出底层数据库表的限制,也不会有太大的影响,但是比如添加的是计算型类型的字段,这种的当客户配置了逻辑规则后, 系统会根据逻辑规则算出来最终的结果,这个会很耗系统资源,所以会很大程度上影响系统的性能。

      (以上感谢风杰)

      第二个问题映射在自建系统一般是根据业务线来判断映射成什么字段。也就是说,根据设置的角色判断的映射

      回复
  2. 关键问题是 表单增加字段事小,但是涉及到的 字段的来源,变动,要怎么设置,感觉实在是没必要

    回复
  3. 可以结合使用人员角色,开发成本合理加这个功能,toB的产品挺常见

    回复