具体才是阶梯:新增字段时需要考虑哪些问题?快来对照自查一下吧

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

B端产品经常会由于业务的变动，需要频繁调整。尤其是添加新字段，更是家常便饭。很多产品认为这个需求非常简单，甚至有的公司由于效率问题，直接跟技术打声招呼，连需求都不建，这样往往会导致二次返工，影响业务的正常开展。

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

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

如果有必要写需求的话，字段名称一定要单独用一个符号【新增字段A】或者用标色标清楚，比如需要【添加颜色】字段，如果我们直接写作“XX功能主单需要添加颜色字段”，那么技术就有可能误解为要添加的字段是【颜色】。一个小小的加符号的习惯，就可以避免和技术由于多次沟通浪费时间，以及后续的返工。需求文档必须清晰无异议。

2、是否必填；

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

强制必填就是说，保存单据时字段为空，系统将不允许保存，这个需要连带着说明保存时该字段的校验逻辑。举个例子，比如某单据会根据类型的不同设置不同的审批流，如果用户不填类型就会导致单据找不到对应审批流程，就需要将该类型字段设为强制必填。

另一种建议必填，会在前端页面的设计上跟其他强制必填字段一样的加粗或标红，来引导用户心理上去填写；或者在保存时提示，该字段没有填写，请问是否允许保存，提示用户并且让用户来选择。比如借款单需要选择前置业务单据时，有的借款单就是直接借款没有对应的具体业务单据，在保存时需要提醒用户是否为空保存。

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

这一项涉及到技术的表设计，需要考虑这个新增字段具体需要哪种类型的数据，尽可能考虑到后续业务的发展方向，会对该字段产生什么影响。比如当前只有整数，后续可能会有浮点数，那么在一开始就建议技术使用浮点数来存储。

4、字段内容的长度

这项与上一项都涉及技术的表设计，如果是文本字段的话，需要预估字段的长度。实际业务当中经常会发生，备注功能的长度不够，保存时报错，需要请技术二次扩展长度。如果是自动抓取的字段，长时间业务都没有发现长度不够，而数据又不能二次抓取的情况下，就会导致相当长一段时间的文本字段丢失部分内容，失去了信息本身的意义，给公司造成经济损失。

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

新增字段参与的逻辑校验是重中之重。在描述时一定要从已有功能出发，来讲解没有的功能。并且点击不同按钮的时候的逻辑要按步骤写清楚，对每一步的提示和弹窗，如果有的话也应该尽量详尽。涉及到校验的新增字段就不仅仅是一个简单的增加字段的功能了，而是一个涉及复杂业务逻辑的相对复杂功能，需要使用一般的需求文档描述的逻辑。这里有时间可以给大家分享一下，一般的需求文档描述，应该注意哪些要点才更能简洁优雅地表达。

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

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

7、考虑历史数据的处理

新增一个字段，历史单据已经存下来了，但是历史数据并没有这个字段。需要跟业务沟通，历史数据的该字段应该如何赋值。简单一些的可以统一赋值，需要在需求里写明并且在上线前让技术从数据库统一操作。但是如果历史数据需要人工判定，就需要提前请技术将历史数据需要参与人工判定的字段导出，再让业务分发下去进行判定，要注意业务人工判定时，需要使用规则的数据进行标记，方便下一步的技术统一赋值。还需要考虑历史数据赋值和上线时间的先后问题。

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

有的功能比如生产相关单据，由于涉及成本等机密信息，有些类型的单据不可以让有页面权限的用户看到，以免泄密。需求沟通时一定要与用户确认，如果有该功能权限的用户很广泛，而这个新增字段或者页面有一些敏感数据，是否要进行特殊的权限设计。如果有权限需求的话，要根据系统后台的权限功能，找到适合本功能的权限设计方式，既能减少本次开发量，又能在实现用户需求的基础上，在后续的权限维护与配置上也方便的方法。

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

新增字段有时是系统默认赋值，那么就不需要出现在新增修改页，只需要出现在详情页即可。如果是涉及数据统计的字段，那么就要加在报表中。如果字段更重要的话，可能会需要根据字段给报表增加一个新的维度。涉及报表的改动可能会较大，具体实施时可以考虑先实现增加字段需求，报表需求作为二期功能进行排期开发。

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

列表页的显示如果是数字要跟其他格式一样，保证导出的数据是规整的、可被分析的。并且如果需要核对数据的话，一定要增加汇总值。这些看似不起眼的地方，实际生产中经常会忘记，所以需要强化这种思维方式，才会变成更加进阶的产品经理。

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

有些新增字段与其他字段有关联性，比如【是否取用特殊折扣】与【特殊折扣】是对生的两个字段，是否取用选择是的时候，才会显示特殊折扣用于填写，选择否则不需要显示这个特殊折扣，否则会产生歧义，更或者导致系统bug。这些动态显示和交互说明需要在需求文档里描述清楚，以免和技术产生误解。

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

这项描述的是本字段和其他功能之间的关联，如果涉及到这种关联，需要详细描写他们之间的关系。不光要写本字段是否会影响其他功能，也要写其他功能是否会影响本字段，这种关系要双向考虑。

13、需要写明提示信息。

如果该字段产生了上述的一些复杂逻辑，从业务使用的角度，需要添加提示信息来帮助业务录单。包括我们自己，时间长了也会忘记这个字段有什么特殊逻辑，所以提示信息要应加尽加，千万不要过于自信觉得这个逻辑简单就不用加了。要为以后的自己和业务做出设计上的冗余，避免后续的运维工作。

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

本文由 @不纯 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash，基于CC0协议

该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。