最近闲下来，除了学习之外，就是不停地各种瞎想，顺便自己在大厂这些的一些经历简单汇总成几句话。

---

1. 不要你以为，要按对方以为实现

前几年的时候：产品提了需求，我写代码时灵光一闪，觉得”这样实现更好”，然后默默改了。结果被QA当成Bug提过来了。

任何未经对齐的灵光一闪，都是给自己挖坑。不是你的模块，别替产品做决定。

2. 级别越高，屏幕上越看不到 IDE

留心观察你的主管或项目主 R。他们的屏幕大部分时间都是聊天对话框，不是五彩斑斓的 IDE。

这不是他们不写代码了。而是到了某个阶段，你的价值从”写代码”变成了”让代码被写出来”。沟通、对齐、决策——这些才是真正影响项目走向的东西。

3. 代码写完，只是开始

很多人觉得代码写完就完事了。

后面还有测试、效果验收、功能迭代、以及某天突然炸出来的线上问题。

4. 好好写技术方案

大部分程序员不喜欢写文档。我也不喜欢。

但花 1 小时写清楚设计决策、选型理由、风险点，能省后面 10 小时的扯皮。这事我吃过亏才知道。

5. 重构的两个真相

别轻易重构，尤其是业务迭代期。没有人要求时别手痒——重构的最佳窗口是每个季度初，需求少的时候。

但想扔掉历史包袱，除了重构没有别的路。

所以策略就一句话：时机对了果断干，时机不对就忍住。 区别在于你有没有周期性留出技术债偿还时间。

6. 项目失败，90% 是沟通问题

大厂多年，项目延期、暂停、临时下线各种情况都遇见过。

除了政策不可抗力，基本全是这类事——要么运营觉得可行研发觉得不行，要么产品改需求没同步到位，要么管理失控没人说。

技术问题都有解法。沟通问题没有银弹。

唯一的解：多说、早说、频繁说。别等到”下周上线”才问进度。每周同步一次，哪怕就十分钟。

7. 用方法论做事

方法论不是拿来装逼的。它是大量事实验证过的做事工具。

程序员习惯用工具解决代码问题，却经常忘了用工具解决做事问题——PDCA、复盘模板、目标拆解。善用这些，比多会一个框架更值。

8. 汇报进度比汇报结果更重要

我以前也这样：想在做出完美结果后再同步。但现实是——周期性汇报进度，让各方感觉项目在推进、风险可控，远比一个突然的”做好了”要重要。

管理预期，本身就是工作的一部分。

9. 向上管理预期

你的领导不需要惊喜。更不需要惊吓。

接手任何任务，第一件事就是对好预期：花多长时间、产出什么、风险在哪。

10. 30岁左右多去布局自己

公司的残酷在于一个人处在组织中需要被表明价值。所以总有贬值的时候。提前给自己去设想下一步总是没有坏处的。

---

10 年下来，我发现一件事：

技术决定你的起点，但沟通、预期管理、方法论决定你的终点。