专栏名称: 人人都是产品经理
产品经理不再是一个单纯的职位,而是一种思维方式,这种思维是所有互联网人必备的,做互联网的人不能不懂产品,关注产品,改变生活。
目录
相关文章推荐
三节课  ·  用AI,普通人完全能大胆做电商! ·  4 天前  
产品犬舍  ·  纯银的产品专栏打折 last day, ... ·  4 天前  
三节课  ·  《三节课独家·9周年学习手册》免费领 ·  1 周前  
91产品  ·  20个小红书官方给的工具 ·  5 天前  
51好读  ›  专栏  ›  人人都是产品经理

新增字段时需要考虑哪些问题?快来对照自查一下吧

人人都是产品经理  · 公众号  · 产品  · 2024-11-03 10:00

正文

在B端产品的工作中,字段调整是家常便饭的事儿了。那么,如果我们在设计的时候就考虑这些情况,需要注意哪些问题呢?作者总结了13个要点,可以对照一下。


———— / BEGIN / ————

B端产品经常会由于业务的变动,需要频繁调整。尤其是添加新字段,更是家常便饭。

很多产品认为这个需求非常简单,甚至有的公司由于效率问题,直接跟技术打声招呼,连需求都不建,这样往往会导致二次返工,影响业务的正常开展。

其实如果对下面这些问题做到熟悉,最好是遇到新加字段时,下意识会考虑这些问题,那么也可以同时兼顾效率和质量,让自己尽快进入产品的工作模式中。

一起来看一下吧:

1、写清字段名称,使用符号高亮显示;

如果有必要写需求的话,字段名称一定要单独用一个符号【新增字段A】或者用标色标清楚,比如需要【添加颜色】字段,如果我们直接写作“XX功能主单需要添加颜色字段”,那么技术就有可能误解为要添加的字段是【颜色】。

一个小小的加符号的习惯,就可以避免和技术由于多次沟通浪费时间,以及后续的返工。需求文档必须清晰无异议。

2、是否必填;

需要从业务角度判断该字段是否要设置为必填。必填分为两种,一种是强制必填,一种是建议必填。

强制必填就是说,保存单据时字段为空,系统将不允许保存,这个需要连带着说明保存时该字段的校验逻辑。

举个例子:比如某单据会根据类型的不同设置不同的审批流,如果用户不填类型就会导致单据找不到对应审批流程,就需要将该类型字段设为强制必填。

另一种建议必填,会在前端页面的设计上跟其他强制必填字段一样的加粗或标红,来引导用户心理上去填写;或者在保存时提示,该字段没有填写,请问是否允许保存,提示用户并且让用户来选择。

比如借款单需要选择前置业务单据时,有的借款单就是直接借款没有对应的具体业务单据,在保存时需要提醒用户是否为空保存。

3、字段的数据类型(例如,文本、整数、浮点数、日期、布尔值等),如果是选项需要把所有选项列出,需要写明是否有空选项

这一项涉及到技术的表设计,需要考虑这个新增字段具体需要哪种类型的数据,尽可能考虑到后续业务的发展方向,会对该字段产生什么影响。

比如当前只有整数,后续可能会有浮点数,那么在一开始就建议技术使用浮点数来存储。

4、字段内容的长度

这项与上一项都涉及技术的表设计,如果是文本字段的话,需要预估字段的长度。

实际业务当中经常会发生,备注功能的长度不够,保存时报错,需要请技术二次扩展长度。

如果是自动抓取的字段,长时间业务都没有发现长度不够,而数据又不能二次抓取的情况下,就会导致相当长一段时间的文本字段丢失部分内容,失去了信息本身的意义,给公司造成经济损失。

5、字段参与的校验逻辑,校验放在保存时还是审核时,校验的触发逻辑,点击不同按钮时的逻辑

新增字段参与的逻辑校验是重中之重。在描述时一定要从已有功能出发,来讲解没有的功能。

并且点击不同按钮的时候的逻辑要按步骤写清楚,对每一步的提示和弹窗,如果有的话也应该尽量详尽。

涉及到校验的新增字段就不仅仅是一个简单的增加字段的功能了,而是一个涉及复杂业务逻辑的相对复杂功能,需要使用一般的需求文档描述的逻辑。

6、考虑未来业务的发展,使程序更有扩展性,或者便于配置。

如果新增字段是选项的话,要考虑这个选项是否是根据业务变化会随时新增的。

如果是的话,就要考虑是否可以增加一个配置功能,让业务可以及时配置及时使用,而不用每次等业务有变化之后,再走流程找技术去加,这样更加便捷高效,程序的易用性也更强。

7、考虑历史数据的处理

新增一个字段,历史单据已经存下来了,但是历史数据并没有这个字段。需要跟业务沟通,历史数据的该字段应该如何赋值。简单一些的可以统一赋值,需要在需求里写明并且在上线前让技术从数据库统一操作。

但是如果历史数据需要人工判定,就需要提前请技术将历史数据需要参与人工判定的字段导出,再让业务分发下去进行判定,要注意业务人工判定时,需要使用规则的数据进行标记,方便下一步的技术统一赋值。

还需要考虑历史数据赋值和上线时间的先后问题。

8、考虑是否按类型设置用户权限

有的功能比如生产相关单据,由于涉及成本等机密信息,有些类型的单据不可以让有页面权限的用户看到,以免泄密。

需求沟通时一定要与用户确认,如果有该功能权限的用户很广泛,而这个新增字段或者页面有一些敏感数据,是否要进行特殊的权限设计。

如果有权限需求的话,要根据系统后台的权限功能,找到适合本功能的权限设计方式,既能减少本次开发量,又能在实现用户需求的基础上,在后续的权限维护与配置上也方便的方法。

9、考虑字段是否加在详情页、新增页、修改页、列表页、报表中。

新增字段有时是系统默认赋值,那么就不需要出现在新增修改页,只需要出现在详情页即可。

果是涉及数据统计的字段,那么就要加在报表中。

如果字段更重要的话,可能会需要根据字段给报表增加一个新的维度。

涉及报表的改动可能会较大,具体实施时可以考虑先实现增加字段需求,报表需求作为二期功能进行排期开发。

10、列表(包括列表页和明细中的列表)新加字段时,考虑数据格式要求(如日期格式、数字的精度要求等),是否汇总值。

列表页的显示如果是数字要跟其他格式一样,保证导出的数据是规整的、可被分析的。并且如果需要核对数据的话,一定要增加汇总值。

这些看似不起眼的地方,实际生产中经常会忘记,所以需要强化这种思维方式,才会变成更加进阶的产品经理。

11、交互说明,如动态显示,在某些状态下显示或不显示。

有些新增字段与其他字段有关联性,比如【是否取用特殊折扣】与【特殊折扣】是对生的两个字段,是否取用选择是的时候,才会显示特殊折扣用于填写,选择否则不需要显示这个特殊折扣,否则会产生歧义,更或者导致系统bug。

这些动态显示和交互说明需要在需求文档里描述清楚,以免和技术产生误解。

12、字段与其他功能的关联性,与其他表的外键关联,或者一对一、一对多的逻辑关系。

这项描述的是本字段和其他功能之间的关联,如果涉及到这种关联,需要详细描写他们之间的关系。

不光要写本字段是否会影响其他功能,也要写其他功能是否会影响本字段,这种关系要双向考虑。

13、需要写明提示信息。

如果该字段产生了上述的一些复杂逻辑,从业务使用的角度,需要添加提示信息来帮助业务录单。

包括我们自己,时间长了也会忘记这个字段有什么特殊逻辑,所以提示信息要应加尽加,千万不要过于自信觉得这个逻辑简单就不用加了。要为以后的自己和业务做出设计上的冗余,避免后续的运维工作。

以上是我在B端供应链产品工作三年总结出的方法论,纯纯的干货呦~如果文章有不尽不实的地方,欢迎小伙伴们在评论区与我互动讨论,期待互相交流沟通,让我们都成为更优秀的产品经理!

———— / E N D / ————

作者:不纯

品牌推广| 内容撰写|广告投放|培训合作

请在公众号后台回复  作