核心问题
为什么 PM 学工程，首先要尊重“阅读代码”这件事？
真实场景
PM 以为工程师的主要工作是写新功能。但很多时候，工程师一天都在读旧代码：查接口、看权限、追数据来源、确认一个字段到底在哪里被改过。
这不是低效，这是软件工程的真实日常。
常见误区
坏判断是：
这个功能看起来很简单，为什么改这么久？
看起来简单的需求，可能牵动旧系统里很多不明显的依赖。
工程视角
读代码是在回答这些问题：
- 这个业务规则现在写在哪里？
- 有没有别的入口也会走这段逻辑？
- 改这个字段会影响哪些报表？
- 有没有历史兼容逻辑？
- 有没有看不见的下游依赖？
写代码之前，工程师必须先理解系统。
PM 可以怎么做
PM 可以把“理解成本”纳入排期，而不是只估开发动作：
- 这个模块是否熟悉？
- 是否需要读历史代码？
- 是否缺少文档？
- 是否涉及多个系统？
- 是否需要找老同事确认背景？
Atlas Action
下次估时前，主动问一句：
这个需求的主要成本是在写代码，还是在读懂现有系统？
小结
软件工程不是在空白纸上写新功能，而是在已有系统上继续生长。
PM 理解读代码的成本，就更能理解工程排期为什么不是“看页面大小”。