软件过程：博客3

从提问到自答：一次软件工程课程的回顾与反思

（本文是对我在学期初所写博客的回顾与回应。第一次博客链接：https://blog.csdn.net/qq_42966458?spm=1000.2115.3001.10640）

一、回看学期初的提问：我现在能回答它们了吗？

学期初，我在博客中围绕教育反馈、团队管理、绩效、创新、安全感、结对编程以及 AI 与 PM 的关系提出了一系列问题。当时这些问题更多来自直觉与有限经验；而经过大半个学期的课程实践、项目推进、讨论与观察，其中一些问题已经逐渐有了自己的答案，另一些则变得更加复杂，但也更具体了。

下面，我尝试逐一回应当初的提问。

二、对《构建之法》中几个核心问题的再回答

2.1 关于17.5 其实还是人的问题

当初的问题：

做事能力强/弱的差异，本质是否其实是想不想做事？

现在的回答：
我依然认同这个判断，但补充一点：

想不想做事往往不是个人意愿，而是环境设计的结果。

在本学期的项目实践中，我观察到：

• 当任务目标清晰、反馈及时、努力能被看见时，大多数人都会想做事；
• 当目标模糊、评价不透明、投入与结果脱钩时，不想做事会成为理性选择。

因此，人的问题并不是靠激励口号解决的，而是靠任务拆解方式、反馈机制和责任边界来塑造的。老师在课程中不断强调过程可视化、阶段反馈，本质上正是在解决这个问题。

2.2 关于长期价值 vs 短期交付的绩效冲突

当初的困惑：
长期主义是否会削弱短期执行力？长期价值又该如何量化？

现在的理解：
我逐渐意识到，真正的问题不是长期 or 短期，而是评价粒度是否匹配时间尺度。

• 短期任务：可以量化交付、进度、质量
• 长期任务：不该强行量化成果，而应量化行为与投入

例如：

• 是否形成可复用模块
• 是否沉淀文档、接口、测试
• 是否降低了后续维护成本

这学期中，老师通过阶段评审、过程记录、展示与讲解等方式，实际上是在用可观察行为替代不可量化成果来评价长期价值。这让我意识到：

长期价值并非无法评价，而是不能用短期 KPI 去评价。

2.3 关于创新的安全感是否会削弱动力

当初的问题：
安全感是否会导致保守？

现在的回答：
安全感不是没有压力，而是失败不等于被否定。

本学期让我印象深刻的一点是：

• 在讨论、展示、答辩中，错误被当作分析对象，而不是扣分理由
• 这反而让人更愿意尝试结构性改进，而不是只做稳妥但平庸的方案

2.4 关于结对编程是否浪费效率

当初的困惑：
两个人做一件事，会不会得不偿失？

现在的认识：
结对编程不是为了快，而是为了降低返工成本。

虽然我没有在课程中完整经历高强度结对编程，但在 API 驱动编程与讨论式协作中，我已经体会到类似价值：

• 设计阶段多一次讨论，往往能避免后期大改
• 思路在说出来的过程中被迫结构化

我现在认为：

结对编程的价值不在代码速度，而在决策质量和知识扩散。

2.5 关于 AI 时代 PM 的价值问题

当初的问题：
当 AI 能理解语义、模拟用户，PM 的人文洞察是否会被取代？

现在的新判断：
我认为 PM 的角色不会消失，但会发生结构性转变：

AI 可以生成方案，但选择哪些方案是“值得生成的，仍然是人的责任。

三、对本学期教学方法的整体评价

学期初，老师介绍了 NCL 理想教学环境（以学生为中心、实践驱动、持续反馈）。当学期趋近结束，我认为本课程在以下方面高度接近这一理想：

1. 公开博客 + 千帆竞发图

• 强制外化思考过程
• 让学习轨迹可见，而非只看结果
• 但对部分同学来说，心理压力偏大，需要更明确的评价指引

2. API 驱动的结对编程

• 强调接口思维而非实现细节
• 非常贴近真实工程实践
• 对基础薄弱的同学挑战较大，但学习曲线陡峭

3. PQ 问答与 UX 现场测试

• 将软件好不好用拉回真实用户体验
• 非常符合软件工程本质
• 希望能有更多时间做深度复盘

4. 学生自行组队 + Alpha 后强制人员变动

• 非常真实地模拟了工程环境中的不确定性
• 有助于打破熟人舒适区
• 对沟通能力提升明显，但情绪成本较高

5. 业界专家讲课 + Demo

• 拉近课堂知识与真实工程的距离
• Demo 比理论更有说服力

6. 天使投资式项目评选

• 让价值而非完成度成为评判标准
• 强烈强化了产品与市场意识

五、结语

回到学期初，我提出了很多问题；
到学期末，我并没有得到所有答案，但我已经学会如何提出更好的问题。

这或许正是这门课程对我最大的价值。