软件项目开发全流程 · 第 1 课 · 软件项目的生命周期全景

1、先讲三个"翻车"的故事

故事一：三个月的"小需求"。
老板说："就加个导出 Excel 的功能，很简单吧？"
开发说："简单，一周搞定。"
结果三周后，发现导出要权限、要大数据量分页、要兼容三种旧模板、还要审计日志……最后做了两个月，还漏了"导出后不能重复下载"这条，被业务方投诉。
问题不在技术，在于没人先把"想要什么"问清楚。

故事二：最勤奋的团队做出了没人用的东西。
一个五人团队闷头写了四个月，代码优雅、测试齐全、CI 绿灯，上线后发现：目标用户根本不用网页版，他们只在手机上点两下。团队交付了一个"正确但没人要"的产品。
问题不在执行，在于立项阶段没验证"值不值得做、给谁做"。

故事三：上线即巅峰。
产品上线第一天流量暴涨，老板很开心。第二周开始偶尔报错，第三个月没人敢改代码——因为改一行崩一片，没有测试、没有文档、原作者已经离职。
问题不在上线，在于交付之后没人想过"怎么养"。

这三个故事，分别对应软件项目里最贵的三类失败：需求没对齐、方向没验证、生命周期没规划。这门课要讲的，就是怎么系统性地避免它们。

2、软件不是"写完就完了"

很多人对软件开发的想象是一条直线：

有想法 → 写代码 → 测试一下 → 上线 → 完事

真实世界是一条闭环：

有想法 → 立项 → 需求 → 设计 → 开发 → 测试 → 发布 → 运维 → 维护 → …… → 下线
          ↑                                    │
          └────────── 反馈 / 修改 ──────────────┘

这条从"想法诞生"到"系统退役"的完整链路，就是软件生命周期（Software Development Life Cycle，简称 SDLC）。

记住一句话：写代码只是生命周期里的一小段，项目真正的成本大头在它前面（想清楚）和它后面（养得住）。

3、六大阶段全景图

把生命周期切成六段，每段回答一个核心问题：

┌─────────────────────────────────────────────────────────────┐
│  第一阶段 · 立项与规划      "为什么做？值不值得做？"          │
│  第二阶段 · 需求与设计      "到底做成什么样？"               │
│  第三阶段 · 开发与团队协作  "怎么高效地做出来？"             │
│  第四阶段 · 测试与质量      "怎么证明它是对的？"             │
│  第五阶段 · 交付与运维      "怎么安全地交出去并稳住？"        │
│  第六阶段 · 维护与退役      "怎么养、怎么改、怎么体面下线？"  │
└─────────────────────────────────────────────────────────────┘

本系列 33 课，就是沿着这六个阶段一路走到底：

• 第一阶段（第 1~5 课）：立项与规划
• 第二阶段（第 6~11 课）：需求与设计
• 第三阶段（第 12~18 课）：开发与团队协作
• 第四阶段（第 19~23 课）：测试与质量
• 第五阶段（第 24~28 课）：交付与运维
• 第六阶段（第 29~33 课）：维护与退役

4、每个阶段到底在干嘛

注意最后一列的"角色"——同一个在小团队里可能一个人全包。阶段不是"岗位"，是"活动"。哪怕你一个人做一个副业项目，这六类活动一件都少不了，只是名字换成了"你自己"。

5、谁在参与：干系人不是只有用户

一个项目的参与者远不止"开发"和"用户"。常见的有：

• 发起人（Sponsor）：出钱、拍板、扛结果的人。项目失去发起人支持，基本就结束了。
• 产品经理 / 业务方：定义"要什么"，代表用户和商业价值。
• 项目经理：管范围、进度、风险、沟通，让事情不失控。
• 架构师 / 技术负责人：定技术方向，保证系统"能长大"。
• 开发工程师：实现。
• 测试工程师：独立视角验证。
• 运维 / SRE：保证线上稳、可观测、可恢复。
• 最终用户：真正用的人，也是最终裁判。
• 合规 / 法务 / 安全：数据、许可证、隐私这些"隐形红线"的把关人。

第 3 课会专门讲怎么把这些人的诉求、权力和影响力画成一张干系人地图。

6、为什么"跳过规划"最后都要还债

新手最爱说："流程太慢，直接开干！"他们没错——小项目适当简化是合理的。但"跳过"和"简化"是两回事：

这些"代价"有个统一名字：技术债（第 30 课细讲）。它像信用卡——今天刷得爽，账单迟早来，还带利息。

正确姿态不是"要么全流程、要么裸奔"，而是"按项目风险，选择流程的轻重"。 一个人写脚本，可以只保留"想清楚 + 测一下"；一个十人团队做支付系统，六阶段一个都不能省。

7、阶段不是瀑布：迭代与并行

特别提醒：上图画成六个方块，不代表必须"第一阶段全部做完才进第二阶段"。

• 瀑布模型：严格按顺序走，适合需求稳定、变更代价高的项目（如航天、部分硬件）。
• 迭代/增量模型：每轮都小步走完"需求→设计→开发→测试"，不断交付可用增量。
• 敏捷：更强调短周期、快速反馈、拥抱变化（第 17 课细讲）。

现代软件项目绝大多数是迭代式的：你会在第 3 周就做一次"迷你立项+需求+开发+测试"，第 5 周再来一轮。这六阶段更像是六种活动，在每一轮里都会出现，只是深浅不同。

所以学这门课时，不要把"阶段"理解成"时间轴上的必经关卡"，而要理解成"随时要问自己的六个问题"。

8、动手实验 🎯

任务：给你身边任意一个软件（微信 / 你公司的系统 / 你写的课设）画一张生命周期图。

1. 找一张纸或新建一个 markdown 文件。
2. 写下它的六个阶段里，你认为各自发生过什么（哪怕是猜的）。
3. 标出你认为最容易出问题的阶段，并写一句理由。

4. 再想一个你自己做过的"小项目"（哪怕只是写个爬虫、做个毕设），对照上表：

   • 你的"立项"是怎么做的？（还是根本没做？）
   • 你的"交付"和"维护"发生了什么？
   • 如果重来一次，你会补哪一个阶段？

把这个练习的结果留着——整个系列学完，你会想用新的眼光再改一遍。

9、今天你带走的三句话

1. 写代码只是生命周期的一小段，项目成本的大头在它前面（想清楚）和后面（养得住）。
2. 六大阶段是六个要问自己的问题，不是六个必须依次通关的关卡；按风险选择流程轻重。
3. 你跳过的每一步，都会以技术债的形式连本带利还回来。

下一课，我们从最前面那个最要命的问题开始：这件事，到底值不值得做？