项目实战

这门内容不是“教你做一个具体项目”，而是帮你建立一套能重复使用的项目节奏：从选题、拆解、执行，到展示、复盘和后续迭代。你会发现，很多学生项目不是能力不够，而是缺少一个足够清晰的交付路径，导致做到一半才发现方向散了。

本章目标

学生项目最容易犯的错，是把目标设得太大。真正容易出成果的项目，往往不是“功能最全”的，而是“边界最清楚”的。建议你先把交付目标写成一句话：我要做一个什么，给谁用，解决什么具体问题。

一个最小可用项目定义应该包含这些信息：

这个步骤看起来很简单，但大多数项目失控，都是因为一开始没有把这几个问题写清楚。

有了最小目标之后，下一步不是立刻写代码，而是把需求拆成任务。学生项目里最实用的拆解方式是“按用户路径拆”，而不是按技术模块拆。你可以先列出用户会经历的步骤：

按这个顺序拆出来的任务，通常更容易形成可演示的版本，也更容易在课程展示或作品集里讲清楚。

很多学生的项目其实做出来了，但展示时讲不清楚。为了避免这种情况，建议你在项目进行中就顺手整理一版说明，至少包含这些内容：

这套说明既能用在课程展示，也能用在简历、作品集或实习面试里。比起一个复杂但讲不清的项目，一个简单但表达清晰的成品更有说服力。

课程作业和作品集之间的差距，往往不是功能多少，而是表达方式。如果你希望把一个课程项目放进作品集，至少要做到这些：

很多同学作品集不过关，不是因为项目太简单，而是因为评审官花了两分钟还没看懂这个项目到底是做什么的。

学生项目里常见的几个失控信号其实很早就会出现。如果你遇到以下情况，通常说明需要先停下来整理，而不是继续加功能：

遇到这些情况时，更有效的做法不是继续开发，而是把当前版本整理成一版“最小可交付成果”，然后再决定要不要继续扩展。