博客园 · 丿似锦
架构师的成长
根据随笔《架构师的成长》整理的演示文稿 · 本地 HTML，零依赖
导言
做管理时，什么最重要？
- 核心能力不是技术多强，而是把技术价值翻译成业务价值。
- 以及在混乱中快速建立秩序的能力。
一、角色定位
从技术专家到团队领导者
最大的坑是还在写代码里出不来。转变：从「我来解决技术问题」→「我来让团队能解决技术问题」。
- 40% 对外沟通（产品、业务、上级）
- 30% 技术方向（架构、评审、方案）
- 20% 团队建设（招人、带人、流程）
- 10% 写代码（保持手感，勿成瓶颈）
二、与产品和业务沟通
说人话，别说技术话
原则：翻译成业务语言——钱、时间、风险、用户体验。
| 避免 | 更好 |
|---|---|
| 要用 Redis 做缓存层 | 可以做到秒开，用户不用等 |
| 需要重构微服务架构 | 现在加功能要改 3 个系统，重构后只改 1 个，上线快一倍 |
| 技术债太多 | 每做一个需求要多花约 30% 时间处理历史问题 |
二（续）
主动参与 · 建立信任
- 产品规划阶段就介入，带着技术视角给建议，别等 PRD 来了再估工期。
- 定期和业务方做技术简报：讲趋势与风险，不讲细节堆砌。
- 用数据说话：稳定性、性能瓶颈、哪些改动影响最大。
说「不」时给替代方案：「按目前方案三周做不完；若砍掉 X 先上核心流程，一周可交付，X 下期补上。」别只说不行，给路径。
三、接手新项目 · 7 天速通
Day 1–4：是什么、为什么
- Day 1–2 · 是什么：本地先跑起来；看 README、架构图；画出数据流（请求从哪进、经哪些模块、存哪里）。
- Day 3–4 · 为什么：问前任/核心开发当初为何这样设计；看近 3 个月故障与 PR；改最多、bug 最多的模块即核心与痛点。
不要试图理解所有代码——理解业务流程与数据流就够了。代码是实现，业务才是本质。
三（续）
Day 5–7：怎么样、交付
- Day 5–6 · 怎么样：核心链路 QPS、延迟、错误率；依赖与第三方；部署、监控告警、回滚机制。
- Day 7 · 输出：一页架构图；核心模块清单 + 负责人；Top 3 风险 + Top 3 优化机会；与团队、产品对齐一次。
四、融入团队
前两周：少说多听
1v1 比开会有用十倍。入团队第一周，找每人单独聊 30 分钟，问三个问题：
- 你现在最忙的是什么？
- 团队你觉得做得好的是什么？
- 如果你能改一件事，你想改什么？
四（续）
找到三个人
| 角色 | 作用 |
|---|---|
| 信息枢纽 | 消息最灵通（未必技术最强），帮你看清团队真实状态 |
| 意见领袖 | 说话大家会听；搞定他，团队就搞定一半 |
| 最强执行者 | 活干得最好但可能不善表达，是核心产出保障 |
四（续）
不要急着证明自己
新人忌讳：上来就说「我以前在 XX 公司是这么做的」。
正确姿势：「我看到咱们现在是这样做的，能给我讲讲当时为什么选这个方案吗？」先理解，再建议。尊重历史决策，即使你觉得有问题。
五、协调配合
别用权力，用价值
- 给面子、给舞台：「这块你最熟，方案你来主导，我给你打下手。」
- 帮他解决他解决不了的问题：争取资源、挡需求、为新技术背书。
- 私下认可，公开表扬——周会一次点名认可，胜过十次私下夸。
- 初来乍到少动核心地盘；新需求增量上证明价值，老系统慢慢过渡。
五（续）
树立威信
- 不挑最老的，挑一件确实有问题、大家也有同感的事。
- 就事论事，不人身攻击；先私下沟通，避免公开处刑。
六、快速进入管理岗 · 向上
让老板看到管理潜力
- 主动承担「没人管的事」：跨团队协调、技术评审、oncall 排班等灰色地带。
- 带小项目做到闭环：从 2–3 人的小需求开始，按时交付、过程透明、结果可衡量。
- 定期同步、管理预期：周报写思考与判断；主动报风险，别等老板来问。
六（续）· 向下
积累团队影响力
- 做团队的「乘法者」：文档、分享、规范；帮新人、帮老开发解难。
- 建立技术品牌：内部分享、博客；关键决策上有观点、有论证。
反直觉：你越能被替代，越容易升职。若你走了活没人接、系统就崩，反而难被提拔。