曾经我也崇拜沉默寡言的技术型 CTO，直到遇到了能言善道的管理型 CTO

个人经历，不一定对，只是分享下感受，莫喷。

刚毕业时面试某小厂，感觉 CTO 气场很强，我称为 A 君吧，说话铿锵有力，压得我喘不过气来，问得很深入，面完汗都出来了。入职后知道 A 很牛，在社区有点名气，做过不少开源项目，后端们非常尊敬他，有人还是奔着 A 来的。

A 非常内敛，话不多说一向独来独往，团建什么的都是坐一边点点头。技术很强，带着几个后端抗下很高的并发，在小公司孵化不少技术产品，每次项目启动会都能准确地预见问题。项目紧急的时候第一时间带头冲锋，确有大将之风。我也希望成为 A 那样人牛话不多的 geek 。

在我入职一年后，A 另谋高就了，新来的 CTO 称为 B 君吧。他刚来的时候很健谈，每天都跟同事打招呼，有时在路上遇到了，会找你拉拉家常，其实我也不太爱社交，特别是这种上下属的闲聊，不太适应。感觉他平时工作也不写代码，当时我还是比较怀念 A 的。

B 空降三个月后，摸清了公司的底细，本来我们的后端是兼任运维的，B 强烈要求增加专业的运维，运维大哥一来，瞬间解放了随时待命的后端们，还规范了 ci/cd 。招了更多前端，解放部分老前端出来配合后端给内部写工具。要求产品提需求时必须通过技术评审，开会前必须提前一天发会议资料，在评审会上开发打回了非常多不合理的需求。要求开发在写代码前先写文档，互相审阅后才能开工，项目结束后立马做复盘。还经常鼓励我们内部反馈问题、分享新技术，内部的文档平台也拉了产品和运营进来，一起写一起讨论，力排众议让设计部增加 UX 岗和增加 UI 人手。

一开始大家都不适应，我也不喜欢整天开会写文档，觉得 B 瞎搞。一晃眼三年过去了，大家完全熟悉了这套模式，发现好处真的好多：

1.以前生产环境经常有些难以出现的 bug ，日志也没报错，没收到投诉就不管了，B 严格要求后端做好分级日志，前端做好错误监控，结果真查出了很多疑难杂症的原因。
2.B 提出前后端一起审视开发中的效率问题，找出耗时比较多的环节，机械性工作（比如导数据）一律写工具解决，有了我们内部造了不少轮子，不得不说效率大幅提高。
3.产品提需求需要技术评审，提高了技术的话语权，才发现很多需求根本是没必要的，用已有的业务打通一下即可，我们经常跟产品来回拉扯，结果就是双方都更加清晰业务的核心和实现方式了，先准备会议资料再开会，开完会再写文档，真的非常高效。
4.以前的设计根本不考虑前端的实现，而且非常忙，经常是前端等设计稿，B 软磨硬泡设计部大佬增加 UI 后，UI 有了更多时间跟前端坐在一起讨论怎么设计更合理，更方便做，设计稿也按时出了。

后来我升职了，开始跟公司很多不同部门的人打交道，原来才发现很多时候其他部门以前想给我们技术部门提一些小需求，A 要求对方出文档，很多不懂技术的同事就不敢提了，由于 A 平时也很少话说，其他同事基本都是见不到的，所以都不敢提建议，只有重要的业务需求才会让产品提出正式的需求。
B 来到后，大群的气氛明显开始活跃了，其他部门也敢聊敢提一些小需求，才知道其他部门用自家产品也有各种痛点，比如内部有些申请经常同步失败，部分基层员工叫苦连天，以前 A 都说接口没问题的，测试也没复现，也不是什么大事情，就叫他们重启网络算了。后来 B 在闲聊中知道这个情况，特意找了个时间安排技术去跟进，原来才发现真是一个远古 bug ，解决之后其他部门的人真的非常感谢 B ，虽然这都是小事，但我真能感觉公司的人相处更融洽了，我真心佩服能把大家团结到一起的这种人。

xuanbg

2023-02-14 10:24:38 +08:00

每个公司，或者每个部门，都需要先解决生存问题，然后再考虑发展问题。A 技术虽然强，但没有建立规范的研发流程，实际上并没有完全解决生存问题（内部疲于奔命，外部怨气冲天）。B 的到来，才真正解决了研发部门的生存问题。在这个基础上，需求就要从生存变成发展（做更多，做更大）了，如果 B 解决不了发展的问题，可能还会换成 C 。

可能有些人会认为在公司规模小的时候，没有流程效率会更高。当然这种情况是真实存在的。但存在的前提是整个团队都很强，大家都知道做什么事，怎么做是对的才行。如果团队并没有这么厉害，大多数人不懂怎么做是对的的情况下，规范的流程就可以让人知道怎么去做好自己的这个环节。虽然效率不高，但至少能把事做对。所以，我是坚定认为，哪怕最小的规模，哪怕就是几个人的产品 /技术团队，也应该建立完善的产品研发流程。只有这样才能保证产品能够符合真正的需求，产品才能按预定计划和要求上线。