从一次开发联调的问题复盘,理解「规则即自由」

1,168 阅读9分钟

最近与后端开发过程中遇到一个特别难受的问题。自已复盘了一下。也慢慢有了对于「规则即自由」的一些想法和思考。

事件

背景

在我与后端合作开发过程中,首先我会定义好数据结构并评论在需求文档的下方,后端按照我定义好的数据结构来返回Response。

过程

我正常定义好结构后评论并@他,在站会上同步了这件事,并且让他看了我mock之后的效果图。但联调时并没有按照我给的结构来,导致联调不能正常进行。但由于他又有高优先的任务要去做,因为我就给他犯的错买单了。

结果

主要有以下几点使我烦扰:

  • 嵌套结构转换大,字段名不一致,好的代码不应该有这种大量转换数据结构的代码
  • 修改公共组件字段,特殊兼容处理较多,代码可维护性大大降低
  • 带着怨气去做这件事,使得我的心情很糟糕,这一点远比前面两点更重要,因为情绪带来的负面价值是不可估量的。当然话说回来,其实也是自己没能处理好自己的情绪,怪不得别人。

产生原因

我推测有以下几点

  • 可能由于他的上个任务delay了,导致这个需求时间紧,没有去看结构
  • 看了但是没细看,以为就是某个之前的其他结构
  • 看了但是觉得这个A结构太复杂,然后使用了B结构没同步给我

思考

苦难不能使人成长,苦难后的反思与行动才能

如何改进

那么我就想怎么才能避免下次出现这种类似的问题呢,答案是规则与约束

每个项目都有SOP,既然现有的通用SOP不能满足要求,那么就建立有业务属性或个人属性的SOP。于是我在follow通用SOP的前提下,与后端沟通一致后并落实成「前后端开发合作规约」【简易版SOP】。为什么是规约呢,我是这么想的,其实这是带有业务属性或个人属性的内部SOP,可能不被其他人认同,因此也不会去涉及定责背锅等问题,只是谁没遵守规约,谁去改的问题。这就是我想要解决的问题。

具体内容就是我定义好结构,后端double check之后需要有一个「确认」的行为,不管是回复评论还是IM回复,需要有一个留底来证明是他确认过的就OK。

重新认识流程规则与约束

「人少的公司」可以理解为小的初创企业几百个人那种,或是微信事业部初期那种,人少开会少执行力快。办事快,流程简单,扁平化管理,没有繁琐的流程管理机制。

之前的认知是在大点的厂最让人诟病的是流程复杂,往往一件小事各种审批使得办事效率低下。而「人少的公司」那种流程简单扁平化是多么高效。

经历过这件事之后,我重新思考了我leader给我说过的一句话「流程是一个让所有人都能达到最大舒适度的一个东西」。这次我终于有点理解这句话了,如果没有流程管理,那么偌大的公司将没办法运作,每个人都遵守这一套规则去执行才能更加高效的去工作。当然规则是大家都认可的并且是经过实践检验并且不断优化改变的,显然现有的很多厂子没有这么做,也许国外做的也不好,我猜的。当我从0开始踩过坑之后才明白好的流程机制的重要性。我也逐步去尝试从0开始运用「规则」这个东西来使得工作更加舒适,使得规则发挥应有的价值,当大家都遵守一个相对满意的「规则」之后,其实这是更大意义上的「自由」。

多想一点!之前为什么没有意识到规则的重要性?

原因很简单,其实这和学习某些技术也很类似,当你连CSS都不会写的时候我给你讲持续集成的重要性,当然无法理解。就好像我连驾照都没有的时候,你给我讲特斯拉哪款车的座位更舒服。我只能记在脑子里哪款车座位舒服,但我丝毫没有感觉到它的舒服。因此认识一个事物的历史,了解他要解决的问题,有机会亲身去尝试或推导出这个事物存在的原因,才能更好的认识并学习这个事物。这其实就是为什么九年义务课本的里面的新概念的第一课总是讲历史。第一课的内容其实也侧面印证了一个哲学问题「发展就是解决矛盾」。

后话

后话1

为什么前后端都不想以下两种情况发生呢?

  1. 需求变更
  2. 数据结构变更

原因说白点有以下几点:

  • 改需求相当于之前所做的所有付出基本白费,并且这些「付出」很大程度上其实并没有多少价值,不管是对于整个产品的价值输出还是对于自己的提升来说。总结:浪费生命的事情谁都不想做,做这种事情还不如我去玩几局游戏,至少游戏在某些条件下能让我放松,让我更好的投身于其他事情。
  • 增加沟通成本,程序员工作至少一半时间是在IM,IM正在虐杀生命。

如果是一个健康的迭代,以上两点「变更」是比较少的发生,如果发生一定是某一个环节出了问题。不管谁是始作俑者,以上两种情况下产生的「变更消息」通过「产品迭代合作链」一定会透传很多次,在小的项目可能看不出来,在大的项目如果没有好的流程管理机制,简直是爆炸。就算有好的流程管理机制和工具去制约,消息透传的次数也是指数级别上升的。这还不考虑

  1. 与工具去交互的成本。
  2. 「变更消息」未被确认,或即使被确认了但没有被执行而产生的不符合预期的结果甚至更糟的结果,或「变更消息」的理解偏差。

如果考虑以上两点,可想而知「增加沟通成本」这件事是多么恐怖。

打个比方,如果出现了变更,会发生什么?

首先所有人要知道并准确理解这个变更意味着什么,消息同步x。然后讨论谁来改和改动成本(小的变更可以忽略这一步,但大的变更可能需要开发提供几张解决方案并与产品开会讨论决定执行哪种方案),影响的scope,改动过程中可能会遇到问题「变更导致的新问题和与之前是否兼容的问题,指需求层面不是代码层面」,遇到问题如何处理,再来一次「变更问题处理」沟通,消息同步y。OK一切确定了,变更处理,改动结束,消息同步z相关人员,回归测试。因此一次变更导致的沟通成本一下子就提了上来,并且如果消息同步不到位有可能引起某一环节的问题。如果变更小或者涉及的人员不多的话,可能会很简单,但如果你一旦遇到这种复杂点的流程,真的就要爆炸了,耽误很多时间才搞定一件事,这还是冒着出锅的风险。

因此当我leader问我这个变更到底让我花了多少时间去改代码,我说10分钟,但付出的代价远不止10分钟这么简单。因为沟通的时间有大概有40+分钟去完成上面的复杂流程,并且还要在当前手里的事情和这个紧急变更之间去切换,这样算下来,这个变更导致的「总体成本」计算为半天一点都不过分,因为一个人一天也就大概专注四个小时在编程,其他都是在IM、切换工作上下文状态等事情上。这仅仅是「执行变更」的人的成本,如果加上整个「产品迭代合作链」所有人,那真是资源的极大浪费。

后话2

我leader给我说,不应该给别人犯的错买单,我这么做了主要考虑是以下几点

  • 后端很强势,虽然是他的错,但我不想撕破脸
  • 不要脸的怕不要命的,没有最强势的人,只有更强势的人。我还在寻找一个从容的状态,这种从容的状态是指「什么场景下强势,什么场景下可商量」。
  • 自信心不足,对别人提出更高要求的同时,其实也是对自己提出了更高的要求。毕竟参与合作的人的level基本差别不大,如果很大,那么合作的舒适度一定会降低,舒适度降低到无法承受的地步,合作必然不能继续下去。

后话3

改一个传参可能需要30s,但是由于后端说的话前后矛盾,我要去和他争辩「为什么说话前后矛盾」这个问题需要20分钟。但我认为这20分钟的意义远大于那30s,因此我选择了后者,但现在看来,我还是太年轻了。纯属吐槽。

以上仅限于我个人的想法,不针对某个人,只是自己的一些观察和思考。

最近知乎上也看到类似的文章,希望可以给大家一点启发和思考。 zhuanlan.zhihu.com/p/68435690

End ~