从鹅厂大佬身上学技术

May 10 2024

2018下半年我加入鹅厂，2019年调岗到现在的组，一直跟着鹅厂11级大佬做事，为了提升自己能力，我开始学习大佬的做事方式，我发现大佬的能力往往体现在他的思维的层次上，简单的说就是解决某个问题的时候，我当时可能只看到第2层，但是大佬已经想到第4层上去了，这期间我也找大佬聊过天，也有一些收获，在这里通过一些具体的事例来分析一下大佬的技术能力。

重复琐碎的工作

我所在的项目是一个公共的平台项目，对外提供api对接服务，不可避免的就一直有些OnCall的工作，在项目初期，也是各种app对接的高峰期，我每天的工作时间基本上都被各种咨询，各种问题所占用，文档也写了，各种FAQ也说明了。但是由于平台本身模型的复杂性，问题总是在重复。考核周期一盘点，发现实际产出相比以往有所降低，复盘我处理这些OnCall工作的方式：

• 写文档，持续更新文档
• 写FAQ，持续整理并更新

那么问题出现在哪里呢，从大佬开始参与项目开始，这些OnCall的事项成了项目重点需要解决的问题，大佬首先要求我学习业界优秀的开源项目文档写作方式，整理平台项目文档的最佳实践。我在阅读了相关文档，以及文档写作经验后，找到了平台项目写文档的最佳实践：

• QuickStart：这部分内容写一个简短的demo来为读者提供一个快速启动的导览
• HowTo：以用户的角度他可能碰到的一些问题的场景来说明如何进行
• Explanation：一些约定的名词概念，为什么要这么做的说明
• Reference：最后是一些关联的文档，api的docs，性能测试报告，FAQ等等

在基于以上文档结构重新整理的文档后，用户反馈接入流程清晰了很多，不同需求的用户都能在QuickStart的基础上结合HowTo来实现自己的需求。

针对用户的各种疑难问题，大佬要求我除了整理FAQ以外还要分析FAQ中的一些问题是否能通过自动化来解决，是否能让用户自行通过工具解决，在分析了一些共性的问题后，我找了2个可以实现工具的点：

• 针对接口逻辑难以调试的点，在用户调用接口的入口点增加debug开关，在api的执行逻辑中如果开启debug，就一路收集相关信息，直接把调试信息返回给用户，使得用户可以自行调试
• 针对又一些需要手动修改数据的操作，整理相关操作，写个一个简单的助手app，使得用户能自助处理问题

通过以上措施，原本的OnCall工作所占用的时间减少了60%，那么是不是就完美了呢，大佬说不是，大佬要求我想一想为什么总是会有这么多的咨询量，是不是项目本身的设计的模型就是有问题，就算没有问题，有没有什么方式能让用户减少咨询。

然后我开始重新复盘项目的功能。咨询量大的根因在于项目本身需求的复杂度，用户对接的时候是有很高的理解成本的，造成了咨询量很大，但是需求的复杂度暂时是没有办法降低的，只能和产品同学一起想办法，最后我推动产品一起做了一个可视化接入的app，帮助用户组在可视化接入流程中理解接入流程，生成数据。虽然这个app不能覆盖100%的场景，但是对于70%以上的简单需求足以覆盖。

到这里OnCall的工作终于不再占用我太多的时间了，让我们来总结下我当时的思维层次:

• 第一层：用户问什么解决什么
• 第二层：总结文档，FAQ避免重复回答

大佬的思维层次：

• 第三层：抽象工具来解决问题
• 第四层：识别业务本身的问题，推动业务改进

能想到第几层实际就体现了技术能力哪里，技术能力是一种以解决某种问题为目标的思路、方法与执行手段，其本质就是解决问题的能力。在编程领域，就是对遇到的业务问题进行抽象、提炼以及逻辑的构建，通过研发工具以提升解决问题的效能，减低人工低效的重复工作。

抽象复杂的工作

随着业务的发展，我们的项目对接的app也越来越多，我们是一个公共平台，需求的推进往往以通用需求为主，但是对接的app有各种各样，需求各不相同，导致用户虽然对接了，但是很多特有的需求又要自己实现，为了满足这类用户的诉求，我开始专项访谈抱怨的用户，了解他们的需求，针对性的解决。

但是大佬提示我，有一些用户虽然没有抱怨，不代表没有需求，应该做一个问卷广泛收集意见，安排专人处理。

进一步要从收集的意见中提炼需求，提炼价值，从架构与产品的角度寻找原因，拆解任务，制定实施计划。

到这里是不是完了呢，大佬说其实更应该从组织架构，从年度目标上从收益最大化的角度，从培养团队的角度全局思考这些收集的意见，综合考量。当然这里就比较高层次了，需要更多的思考。

总结下这里工作的思考层次：

• 第一层：有什么问题解决什么问题
• 第二层：广泛收集，专人跟进解决问题
• 第三层：抽象业务需求，改进产品与架构
• 第四层：从业务发展，个人发展，组织发展的角度思考业务演进的方向

我们需要从业务发展与自我发展与组织发展的角度来思考如何处理各种复杂抽象的工作，避免只知道接需求，成为一个项目经理，只知道通过任务来跟踪进度。

关键决策

在与大佬的合作过程中我一直有一个疑问，就是项目推进的过程中，有一些关键的决策是怎么确定的，比如在某个时间点大佬要求我们必须重新整理代码层次，抽象新的代码编码规范，但是这个事情其实短期来看并不会看到有收益，可能从老板的角度来看这都不算产出。在一次聊天中，我提出了我的疑问，大佬从3个角度帮我解了惑：

1. 有所坚持：有一些原则自己必须坚持，比如对代码的架构，代码的整洁
2. 长期主义：项目可能会长时间的在自己手里维护，所以需要看远一点，否则坑的还是自己
3. 向上汇报：要让leader知道你在做什么以及这么做的必要性，获取leader的支持

在与大佬合作的这几年中，通过观察大佬的工作方式，我学到了很多。编程能力是程序员的核心基础能力，但是只是能力的一部份，我们还要提高我们的思维层次，提高效率，增加产出。软技能也很重要，表达能力，沟通能力，项目管理能力都是程序员需要关注的技能点。