📄 一句话概括
10 个常见问题里，技术只能解决 5 个——需求、协作、进度、验收这 5 个只能靠流程；技术解决【做得对】，流程解决【做对的事】。
📝 本节和前面几节的关系
第十讲讲完设计（技术），这一章换赛道：开发流程。先说明为什么技术不够。
一、实测：一半问题技术解不了
技术能解 5 个：代码写错、性能不够、结构混乱、测试不足、接口不合理。 技术解不了 5 个：需求一周改三次、没人知道该做什么、交付总延期、两个组对不上、验收时说不是这个。 后 5 个全都不是【写代码】的问题，它们属于【怎么把事做成】。
二、两个层面不能互相替代
技术解决【做得对】：代码正确、性能好、结构清楚。 流程解决【做对的事】：需求清楚、分工明确、进度可见。 技术再强，做错的东西也还是错的——这是本章的起点。
三、为什么这一章要放在最后
因为流程的效果依赖技术底子：代码改不动的人，谈敏捷只会更乱。 11.14 会说清这层依赖：敏捷源于面向对象。 所以顺序是：结构 → 设计 → 流程，倒过来学容易变成喊口号。
四、动手 Demo：仅靠技术和技术窍门，软件开发并不会成功
列 10 个项目常见问题，逐个判断技术能不能解决。 数一数两边的数量。
items = [("这段代码写错了", "技术能解"), ("性能不够", "技术能解"),
("结构混乱", "技术能解"), ("测试覆盖不足", "技术能解"),
("接口设计不合理", "技术能解"),
("需求一周改三次", "技术解不了"),
("没人知道该做什么", "技术解不了"),
("交付总延期", "技术解不了"),
("两个组各做一半对不上", "技术解不了"),
("验收时说不是要的这个", "技术解不了")]
tech = sum(1 for a, b in items if b == "技术能解")
print(len(items), tech, len(items) - tech) # 10 5 5
实跑输出：
--------------------------------------------------------------------
仅靠技术和技术窍门，软件开发并不会成功
--------------------------------------------------------------------
一个项目里，光靠技术能解决的有几件？实测 10 个常见问题：
问题 能不能靠技术解决
------------------------------------------
这段代码写错了 技术能解
性能不够 技术能解
结构混乱 技术能解
测试覆盖不足 技术能解
接口设计不合理 技术能解
需求一周改三次 技术解不了
没人知道该做什么 技术解不了
交付总延期 技术解不了
两个组各做一半对不上 技术解不了
验收时说不是要的这个 技术解不了
常见问题 10 个
技术能解决的 5 个
技术解决不了的 5 个
**实测一半是技术，一半不是**——后一半（需求、协作、进度、验收）**只能靠流程。**
**这就是软件开发为什么需要【开发流程】**：技术解决【做得对】，流程解决【做对的事】。
**所以第 11 章讲的是流程，不是编程。**
实测：10 个问题里 5 个技术能解、5 个技术解不了。 解不了的那 5 个（需求、协作、进度、验收）才是项目失败的常见原因。 所以这一章讲流程，而不是讲更多的编程技巧。
30 秒实验
- 把你上一个项目的问题列出来，按技术／流程两类分一分。
- 找出一个你想用技术解决、其实该用流程解决的问题。
常见误区
- 以为技术强就够了。技术解决做得对，流程解决做对的事。
- 以为流程能救技术。代码改不动，流程再好也跑不起来。
自测三问（点开对答案）
1. 实测比例如何？ —— 10 个问题里技术能解 5 个，解不了 5 个。 2. 技术与流程各管什么？ —— 技术管做得对（正确、性能、结构），流程管做对的事（需求、分工、进度）。 3. 为什么流程这章放在最后？ —— 流程效果依赖技术底子；敏捷本身源于面向对象，结构不行谈敏捷只会更乱。- ☐ 11.2 系统地汇总了作业步骤和成果的开发流程
相关笔记
- 设计的目标范围很广 — 技术的边界
- 系统地汇总了作业步骤和成果的开发流程 — 流程是什么
- 敏捷开发源于面向对象 — 两层的依赖关系
- 🧩 面向对象是怎样工作的 · 索引