观察到的过度沟通的现象

讨论

今天进行了一次组内的代码CR。在这个过程中，我意识到了“我认为的”的过度沟通现象的存在。

起因是我们在讨论一个校验、二次提醒的交互。

产品prd描述的是，点击按钮，判断是否符合校验，如果不符合，弹窗提示；如果符合，二次提醒是否确定操作。

因为这个功能点实现比较简单，而且重点的点都满足了，比如校验提醒、二次确认。所以我也没想过其他交互形式，直接就做了，后端也愿意提供两个接口做这个功能。

但是组内其他成员认为我应该找产品沟通一下交互，要不要换成”点击按钮，弹出二次确认框，点击确认的时候，调用一个接口做校验+逻辑操作“。

我认为这个是一个没有必要的沟通，因为这个交互最重要的其实就是满足两点：校验提醒+二次确认提醒”。现在产品给的交互已经满足了，而且对我个人来讲，我其实比较“随意”，我更喜欢有难度的挑战，而不是把精力消耗在小细节上。

继续往前思考一步。我意识到了两个矛盾点：

先说第一点，我很清楚自己，我很喜欢做有难度、需要思考的事情。比如研究pdf分页方案、微前端课题，在做这些事情的时候，我很容易就进入心流的状态，内心很享受，一点也不会受到外界的干扰，甚至睡觉的时候还在思考。

我还有一个特点，我更关注大体流程，比如对业务的理解，太细节了我反倒是听不进去的，因为听进去了也会很快忘掉，去了解他反倒会成为干扰信息。对于代码风格和设计，我也觉得很随意。因为很多代码风格，我觉得是某个人喜欢的风格；还有设计模式，公司业务复杂度没到需要严格遵守某种设计模式的程度。

但是后面这些点看起来似乎和团队内部文化有冲突。这些虽然没有严格成文的规范，但是组内有人提出了“自己更喜欢、更倾向”的改进方案，我不照做的话，显然“不利他”，没有方便他。

这是第一个矛盾。

第二个矛盾。上面提到对交互沟通，我之所以觉得没有必要找产品聊，我想了想，其实还有一个原因，就是每次找产品问问题，产品回复很慢，而且产品在这个项目中很忙，研发有很多逻辑需要找他确认，他同时也要和业务方上下游沟通，所以这点细节交互，对他来说优先级非常低。这时候找他对我的沟通体验也不好。

在研发过程中，前端工作量占比低的原因，很明显能感觉到”不重要“的感觉。前端已经处在”统一提效“的阶段，基建不断升级优化，给开发者更好使用，各种规范不断往细节里扣，就是希望统一，用相同的模式开发，方便其他人快速接手，像产品描述的交互，可能就和以前的交互不一样，他们想用熟悉的交互。

这是组内前端目前的发展现状。但是后端和产品那边呢，产品方案在开发过程中一直修正，所以产品对业务完善度可以说得上不够；后端的研发工作耗时长，很多基建缺失，还有业务逻辑相比前端，确实更复杂。所以可以看出来，产品和后端团队的发展比前端更缓慢，内部还存在很多问题。

我在乎他们的内部问题吗？我想和他们一同成长，帮助他们一起解决，打造一个完美的团队吗？

我不想，我的兴趣点不在这。

如果有人站在“正确”的角度提议我要这么做，我该怎么办呢？

我觉得我还是坚持自己的想法，应该做自己想做的事情。