程序员只懂技术能行吗？
为什么说技术人员“说”和“写”总得擅长一个？
你以为的“关注结果”是真的结果吗？
从一线工程师跃升团队管理者一共分几步？
在不断变化的职场环境中，技术人如何保持竞争力并实现自我增值，是摆在每个人面前的挑战。无论是一线工程师还是技术管理者，如何在组织中有效合作并赋能他人，构建一个高效且成功的团队，都是我们需要深入思考的问题。
小红书音视频架构部负责人陈靖，结合自己近十年的互联网技术团队管理经验，分享了他对技术人在代码之外如何持续成长的见解。希望能帮助你在职场中找到定位，并通过个人成长推动团队和组织的共同进步。
陈靖，本科毕业于中山大学，硕士毕业于北京大学和卡内基梅隆大学，出版《深入理解视频编解码技术》、《现代 C++ 软件架构：方法与实践》等多本技术专著。2019年，他参与创建深圳市人工智能产业协会，该产业协会是中国第一个人工智能和产业界结合的协会。在加入小红书之前，他曾任 51Talk 首席音视频科学家、Google（美国）视频算法工程师、华为中研视频组工程师，具有丰富的工业界敏捷开发和算法研究的实践经验，对如何实现项目成功有独特的见解。
本文整理自陈靖在「 Top 100 全球软件案例研究峰会 」上的分享，以下为分享实录。
大家好，感谢大家今天的到来。我今天分享的这个主题是「不止会写代码，工程师的自我迭代——如何与组织一起成长」。
本次分享主要分为两个部分，一部分是对于每个技术人的分享，另一部分是对团队 leader。
一、技术人的“三重成功”
首先，关于成功的定义，高考状元的成功和行业领袖在职场上的成功有什么不一样？
高考的成功，是个人的成功，是在有限的解空间里去取得一个最好的成绩；而行业领袖需要做的是增量，本质是创新、创造，是一个无限解空间。从这个角度去看，我们可以定义三种不同的成功。
第一种是自我成功，高考状元怎么取得成功，本质上就是自己做好自己的事，就可以取得成功。
第二种是合作成功，职场上更倾向于这种，需要和其他人一起去完成一个复杂的任务。
第三种是赋能成功，这种成功主要适用于职场领袖，赋能成功其实也是合作成功的一种，因为 leader 和他的团队本质上也是一种合作关系；跟合作成功不同的地方在于你在这段合作的关系里面做功相对偏少，更多的是去主导你的合作对象做更多的事情，让他们能有更好的表现。
本次分享主要介绍我们如何在职场中做到合作成功和赋能成功。作为工程师应该怎样迭代自己，才能更好地和别人合作？如果你走上管理岗位，怎样才能更好地赋能别人？
1.1 合作成功：小 T 字型人才
想做好合作一件事情，可能需要一个小 T 字型人才。那么小 T 字型人才是什么样的呢？
T 字型下面的一竖代表深度，本质上是看个人对自己技术掌握的深度。以我自己举例，我是音视频象限的，当然也是音视频加架构这个象限的。那我就会在编解码、传输，分布式计算等领域有一些学习了解。怎么样才叫有深度呢？主要有以下两个方面：
- 系统性：什么叫系统性？系统性就是不断获取相关知识，你对这个领域方方面面都比较了解。
- 深刻理解：深刻理解就是你利用所学过的知识去取得项目的成功。所谓“纸上得来终觉浅”，我们需要真正落地一些事情，才会对这个事情有非常深刻的理解。
T 字型上面的一横代表广度，本质是知识面的扩展。从我的角度来讲，如果我是一个 T 字型人才的话，那我就会去了解云原生、数据库等。可能相对自己的技术栈来说，了解得不是很深入，但是也一定要去了解。要成为一个小 T 字型人才，如果想要在广度上有所突破，可以从以下三个方面入手：
- 关键概念：当你去了解其他专业方向的事情的时候，首先需要掌握这个方向的专业概念，当别人说一个名词的时候，你要知道他在说的是什么。
- 语言体系：高效的语言体系是很赋能工作效率的。那为什么我们会觉得团队中突然来了一个人讲一些我们听不懂的术语会有问题呢？这是因为这个组织还没有适应那样的一个语言系统。关键是在一个组织里，大部分人是否听得懂。
- 交互界面：当大家在跟自己的上下游合作时，都在去寻求自己在什么维度上能够跟对方合作，对方在什么维度上能跟自己合作。前面提到了语言体系和关键概念，那当你能理解对方在说什么，对方也能理解你在说什么，双方就非常容易能达成一个交互的界面。
以上三个方面的核心是“ 知彼解己 ”，即我要了解对方，也要让对方了解自己。
1.2 赋能成功：大 T 字型人才
如果未来你想要成为一个能带团队的领导，那就需要成为能更好地赋能别人的大 T 字型人才。一名合格的大 T 字型人才需要具备的特质主要分为技术和技术之外。
大 T 字型人才的一竖代表技术，技术在这里就更加泛化，你需要比小 T 字型人才了解更多的东西。因为有可能和你打交道的并不都是技术团队，可能还有像产品、运营等团队。
特别想强调一点：人其实很难被别人改变，但人可以自己改变自己，自我迭代。这也是我为什么想做这个分享，抛砖引玉地告诉大家：你其实可以自我改变，不断迭代，我们一起探讨从哪几个方面如何能更有效地迭代自己。
除了深度之外，大 T 字型人才的广度要怎么拓展？主要分为以下两个方面：
- “术” ：表达能力、写作能力、逻辑能力
最基本的是表达、写作、逻辑能力，更深入些的是理性、逻辑、修养、企图心、自我控制力。
“术”，就是方法。“ 作为一个技术人员，无论未来有没有成长到管理岗位上，说和写总归要擅长一个。”
“说”是一种更加敏捷高效的方式，达成共识，快速推进；“写”是更深刻持续的方式，跨时间周期地影响他人。这两者，总归要有一个方式让你被你的同事理解，在职场上促成合作，完成事情。如果你未来想做一个团队管理者，想要更好地合作或者赋能，本质上来讲这两个东西都需要掌握。
- “道” ： 问题驱动、关注结果
关于“道”，首先一点是问题驱动。
西方有句谚语叫做：“必要性是发明之母” 。每个人所认为的必要性都是不同的，你认为必要，别人不见得认为必要，这就是关键所在，也是分歧出现的地方。
所以在公司、在组织内部是需要 battle 的， battle 是达成共识的一个必要手段。探讨必要性，一定要主动积极。如果不主动积极， battle 则不会发生，那必要性也不会成为共识，那你做的东西就不是问题驱动的。
另外一点是关注结果。
那么问题来了：你所关注的结果，它本质上到底是过程还是结果？
以通知开会为例，如果 leader 让你去通知开会，你会去做哪些事呢？大多数人都会去关注这几个点：开会的时间、地点、人物，但这样是一个结果还是过程呢？很多人可能会觉得这样好像就已经是一个结果了，但其实还不够，我们还可以关注以下几点：
- 这个会议主题到底是什么？
- 这个会的优先级高不高？优先级如果很高，为了防止议程冲突，我们需要提前提醒参会人参加会议。
- 这个会议需要大家做什么准备吗？比如会议文档的阅读与交互。
通知开会，其实应该更多关注它的过程。在这个过程中可以看到主动积极的重要性。
对于“道”的层面，无论是“问题驱动”还是“关注结果”，都绕不开“以终为始”。问题驱动是以终为始，因为问题的解决本身是终点；关注结果也是“以终为始”，开会一例中，大家会想为什么开会是一个过程，开会最终的目的是什么，想到这个问题就可以回到以终为始。
二、管理者的“战略艺术”
2.1 作为管理者的“三会一懂”
作为管理者要掌握“三会一懂”，会定目标、会开会、会复盘，懂取舍。
合格的管理者定目标时会抓住五个要素——具体、可衡量、可接受、结果导向、时间限制。
2.会开会
会议可以分成两种，一种是例会，开例会时应该坚持五有、五不、四框架原则，最重要的一点是不追求深入细节；另一种是主题会，开主题会的关键是确定谁参加、谁决策、谁记录、谁执行，切忌把不相关的人引入进来，浪费团队和个人时间。
3.会复盘
复盘涉及三种形式：
小事及时复盘——不必拘泥于形式，及时解决问题。
大事阶段复盘——大事以周为维度、双周为维度，或者月为维度做阶段性复盘。
完事全面复盘——项目最终完结之后做全面的复盘。
4.懂取舍
取舍本质上就是战略，战略即取舍。战就是取，是重点进攻的方向，略就是舍，就是该回避的方向。一个人有没有战略眼光、战略思维，是他能不能做 leader 的关键点。因为在做项目的时候，无法既要、又要、还要，此时就需要取舍，所以战略本质上就等于取舍。
那战略是什么呢？战略不是关于未来做什么，而是“现在做什么”的“未来性”。也就是说我们需要考虑：现在所做的对未来会有什么样的影响？如果现在有些地方做得不好，未来那个事情可能就不用做了。讨论战略，很容易变得很“虚”，所以一直要很务实地去说明我们现在做什么，以及现在做的这个事情在未来会引发什么样的变化，这样才是一个战略。
2.2 管理者的视角 WWH
我把一个团队的人员结构划分成了三类，从下到上分别是 Engineer 、Team Leader 、 Director ，每一类人所关注的重点与看事情的角度都会有所不同。
Engineer 这一层，更关注的是 How —— 该怎么做。
涉及到产品的设计开发与部署、后续测评与改进，工程师需要考虑的是：工作中该如何避坑，如何实验，如何工程化，如何迭代 。
Team Leader 这一层更多关注 What ，即判断哪一个选择更好。
从概念、流程、架构、关系入手，我们可以思考：这个技术有什么特点或者关键点？存在类似的技术吗？区别是什么？这个技术的缺点是什么？这个技术的收益和代价是什么？以及目前这个技术的成熟度如何，行业的应用情况怎么样？
Director 层更关注的是 Why ——为什么做，真的需要做吗？
从业务角度深挖 why 层面，可以用 “5 WHY” 方法帮助你提出问题，反复提出为什么，找到根本原因。
- 为什么要做？(解决什么问题)
- 不做行不行？(问题大不大)
- 以后再做行不行？(问题紧迫吗）
- 其他人有参考价值吗？（问题是普遍存在的吗）
2.3 往管理者的方向迭代
如果想要向管理者的角色迭代，则需要根据不同角色的需求，对 WWH 进行不同的权重区分：
高级工程师需要深入了解技术的 what 和 how，但也不能忽视技术决策的 why；资深专家则需要在技术决策的 why 层面有更深入的理解，同时也要涉猎 what 和 how 层面的技术知识；而团队管理者则需要更多关注战略方向。
本质上一个职场人应该对每个层面都有一定了解，关键区别在于比例与重心的不同。
三、AIGC时代，技术人应该焦虑吗？
本次大会主题与 AIGC 密切相关，那么在 AIGC 时代，我们要以一个什么样的心态去迭代自己？我们应该焦虑吗？
AIGC 特别强大，对我们的开发模式产生了一定的改变与影响，但它现在本质上还是作为一个工具为人使用，是服务于人的，它特别擅长把结构化/形式化的东西做特别好。
有一种 AIGC 赋能开发的开发模式，叫做水母式，其特点是头大，多触角。这种模式的意思是：作为开发者，我们需要把更多的精力和时间投入到头部——识别问题、定义问题和产品设计等；AIGC 就像水母的触角一样，可以分支帮助我们做选型、写代码、测试等工作。
而工具对社会、对个人的冲击是不同的。对社会的冲击，我们不必太过担心，因为它只是将掌握某些知识的特权下放给更多的人，使更多人参与到这个行业中来。AIGC 加速了这个过程，降低门槛，让更多人进入到这个行业。
“悲观让人类存活，乐观让人类发展。”悲观确实可以让你更好地保护自己，人类其实能发展到今天，悲观起了很大的作用；但是人之所以能够发展，还是因为乐观。
最后，我想祝愿每一个技术人心态年轻，心智成熟、乐观积极，心中有丘壑，梦中有星辰大海。谢谢大家。
