关于增删改查串的思考

0 评论 1472 浏览 0 收藏 9 分钟

在设计方法论中,又一个口诀叫“增删改查”,不同公司有着不同的版本和说法。这篇文章,我们看看作者分享的“增删改查串”,有哪些不一样。

系统多种多样,产品千变万化,都离不开最原始的行为,就像人性各异,归根结底都是由分子组成,当然还能再细化什么原子、夸克等更小单位。关于技术层面当然最终是由代码组成,代码又有各种方法、对象、属性等组成,这都是在我们除开发人员外肉眼不可见的地方运作,如果从我们肉眼可见的视角去看,这一切都离不开增删改查串这五个动作。

我们对于增删改查这四个动作很熟悉,因为我们知道事物能量是不会凭空产生的,是需要触发的,我们每一个增删改查后的结果是一个静态的页面,单纯的几个孤零零的页面是不能称作一个系统的,需要有东西串连起来,因此我们在这边加了一个串的动作。

这一套动作下来有点像apaas平台了,涵盖了数据、表单、流程三个层面,这套动作还包含apaas缺少的内容,我们下面一一来分析这套动作。

01 增

这是数据和业务的诞生地,一切业务的开始,那么数据从哪里来呢?我想从3个方向来:

1、手动直接添加产生

这就需要用到表单功能了,页面中包含哪些字段,填写的规范等,配置好后,拥有操作权限的角色就可以进行手动新增了。如:新建一个客户,新建一个请假等各种协同办公类的表单申请功能。

2、系统内流程操作触发产生

这里面除了涉及到表单功能,还涉及了流程引擎的功能,是通过系统内其他表单页面操作,引发的关联性动作。如:申请一个表单,会在审批人那边出现一个待审批的数据。

3、系统外数据传递

这个通常用api接口进行数据的传递,有实时触发传递(这个是数据提供方给数据需求方传递,是需要数据需求方出接口的),有定时来取(这个是数据需求方主动到数据提供方来取,是需要数据提供方出接口的)。如:SCRM从微信取客户的操作轨迹。

02 删

这个动作的来源其实和增的一样,只是这边的删除需要注意的是包含3种形式:

1、物理删除

这个动作是非常危险的,相当于直接删库,相当于彻底删除,有可能彻底无法回复,需要谨慎,一般情况下都会采用第2种方法。

2、逻辑删除

与物理删除相对应,我们从肉眼中是已经删除了,但实际上是没有删除,相当于电脑桌面上回收站中的文件,虽然在你的正式文件夹中已经没有这个文件了,但是你还可以在回收站中找到并且还原,这种方式是常用的,比较安全。

3、撤销与禁用

我们说删除并非一定是把东西删掉,也许是不让其运作,就像机器一样,我们可以让它停下来,不一定要破坏掉它,撤销常出现在表单申请,禁用经常在一些规则配置中使用。

03 改

正因为不确定性,因此我们所有的行为和抉择都是可变的,而加上改的操作后就不只是对原来数据修改那么简单了,这里面涉及到的逻辑流程可能全部要重来,因此修改的权限也是要谨慎发放,要控制好在什么阶段可修改,谁可修改,不然容易把系统搞崩。对于流程较短的可以这么操作,而对于流程较长的则不能操作。

比如电商已经下单了并且物流已经发放了,这个时候再去修改邮寄信息将会很麻烦,多数是等送到了拒收,返回或者自己签收后再次邮寄,很少中途通过系统去修改,要变更也是线下联系快递员进行变更。

04 查

这块就与数据相关了,可能没有什么流程性的操作,但却是当前比较重要的内容,因为这里涉及数据、报表,甚至数字化,不仅仅是列表页面的查询参数。

现在市面上大谈阔谈数字化转型,可想而知,数据背后的能量有多大,那么作为数据的查的功能,也是相当的重要了,怎么查出有效的数据,怎么查出真实的数据,数据的统计,视图层面要花些功夫。

比如各种数据公司做BI的,其实都是通过查的操作把数据按照模型给展示出来。

05 串

这个是我们新加上的伙伴,现在不是单打独斗的时代了,是合作双赢的时代,任何一个公司都不会把所有系统和功能全自己做一遍,不说没有这么多人和财,实在是没必要,外面有这么多又便宜又好用的系统和功能,为什么不集成进来呢?因此串这个动作是有两层含义的,上面增删改其实已经包含其中了一点。

1、内部流程串起来

一个系统顺利运转,少不了各个节点的通力合作,短流程如表单申请,长流程如电商购物、招聘等,都需要不同功能模块之间相互数据传输,串的是流程(人和事),更是数据和业务。

2、外部功能集成

现代企业都想要封装复用已有的功能,降本增效,那么就会有很多高度标准化的功能做成插件或者封装成接口对外提供,大型软件集团都会有自己的开放平台,把自己的能力往外辐射。

比如支付、短信、外呼等都可以直接从外界获取相应功能集成到自己的系统中,像电商就包含了支付、物流、定位等外部开放功能。

正因为这个串,才让aPaaS平台更加完整,我们感觉低代码/无代码平台会替代现有的人力代码系统,只能说大部分,apaas还是有边界的,而且必须有边界,我们只能无限接近全智能,如果完全没有代码依靠了,那么这个apaas平台将包含世界上所有的业务场景,这也不太显示,只能无限接近。

06 最后的才是最重要的

我们讲了这么多所谓的凝练的本质功能,也只是理论,只是有了工具的材料,如何去运用这些材料拼装成产品,如何用产品去服务客户才是重中之重,因此,熟悉业务才是成功的钥匙,如果加上理论方法论就会如虎添翼,业务为王,理论为辅,才能让产品站得住脚。

离开了业务,离开了用户,如无腿之物,寸步难行。产品人,投身于你的业务中去吧,找你的客户去吧,在那里才有金矿。

本文由 @诗忆录 原创发布于人人都是产品经理,未经许可,禁止转载

题图来自 Unsplash,基于 CC0 协议

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

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
海报
评论
评论请登录
  1. 目前还没评论,等你发挥!