波仔
💻 第十二章 SE负责监管计算机系统的构建
📄 一句话概括

SE 的功夫大半不在写码——需求访谈、方案设计、进度协调、文档提案才是主业，编程只是地基之一而非门槛。

📝 本节和前面几节的关系

上一节认识了监管者的跨度，本节澄清最常见的误解：SE 究竟要不要是编程高手？

一、SE 的一天在做什么

典型工时分布：需求访谈与设计评审占大头，进度协调与文档提案次之，技术调研垫底； 真正【亲自写程序】的时间可能接近零——写码外包给程序员团队执行； SE 的产出物是方案、估时、架构图、会议纪要，不是代码。

二、为什么不懂技术也当不了

说【不必会写】不等于【不必会看】：程序员报【这功能要两周】，SE 得判断是实情还是虚报； 技术判断力来自编程素养——数据结构、算法、系统原理（前三章的功底正是用在这里）； 所以正解是：不必担任过，但必须看得懂——评估能力比动手速度重要。

三、对自学者的启示

想入行 IT 但担心【写码天赋】，SE 路线提供了另一扇门：懂原理、善沟通、会管理一样有位置； 反过来，想走技术路线的程序员，补上 SE 的需求与沟通功夫，才能长成架构师； 【⚠️ 2026 现状】这条经验在 AI 辅助编程时代更真：写码门槛在降，【判断该写什么】的价值在升。

四、动手 Demo：SE 的时间都去哪了

把一名典型 SE 的工作时间按类摊开，合计后看【亲自写程序】的占比。

work = [("需求访谈", 25), ("设计评审", 30),
        ("进度协调", 20), ("文档提案", 15),
        ("技术调研", 10), ("亲自写码", 0)]
print("合计:", sum(p for _, p in work), "%")

实跑输出：

--------------------------------------------------------------------
SE 未必担任过程序员
--------------------------------------------------------------------

很多人以为 SE = 高级程序员, 其实 SE 的功夫大半不在写码。
把一名典型 SE 的工作时间摊开看看:

  工作内容           时间占比
  ----------------------------
  需求访谈与整理     25%
  设计与评审         30%
  进度与团队协调     20%
  文档与提案         15%
  技术调研验证       10%
  亲自写程序         0%

    合计 100% —— 而写代码的占比是 0%。

会编程当然加分——能评估程序员的估时是否靠谱、技术上做不做得到;
但 SE 的核心竞争力是【听懂客户、拆解问题、管好过程】, 编程只是地基之一。
所以说: SE 未必担任过程序员——没写过千行大程序也能当, 关键看综合能力。

合计 100%，写码占比 0——监管者管的是【写什么、何时写、谁写】，不是【怎么写】。 技术调研的 10% 用来保持判断力——对应上一条【不必担任过，但必须看得懂】。

30 秒实验

  1. 把 SE 的六类工作按【对客户／对团队／对自己】分成三组。
  2. 说说程序员转 SE 需要补哪两样能力，SE 转程序员又缺什么。

常见误区

  1. 以为 SE 是职级更高的程序员——两者是分工不同的岗位，不是上下级。
  2. 以为不写码就能不懂技术——没有技术判断力，估时评审全是瞎拍。
自测三问（点开对答案） 1. SE 的主业是哪几类？ —— 需求访谈、方案设计、进度协调、文档提案。 2. 【不必担任过程序员】的完整含义？ —— 不必亲自写，但必须看得懂、判断得了。 3. SE 的产出物是什么？ —— 方案、估时、架构图、提案——不是代码。

相关笔记