什么时候用？
- 需求一开始就定下来、途中不会变的工作。
- 需要审批和文档、每个阶段都得留痕的项目。
- 顺序本身很重要的工作：设计没完成就不能开始生产。
操作步骤
- 1在上方写下项目名称，点「开始」。
- 2六个阶段自上而下排开。只有打开的阶段能加条目，后面的阶段带着锁的标记。
- 3这个阶段做完后，点方框下面的「完成此阶段」按钮。
- 4确认之后下一个阶段打开；已完成的阶段会打上勾，里面的条目不能再改。
- 5一个项目里可以放多个瀑布项目。
键盘快捷键（桌面端）
把写好的条目加进该阶段Enter
撤销（也能撤回已完成的阶段）Ctrl+Z
重做Ctrl+Y
小提示
- 没有重新打开阶段的按钮；如果误点完成，唯一的退路就是撤销。
- 关闭之前先确认这个阶段真的做完了——关闭时文字也会一并锁住。
- 如果需求会在途中变动，瀑布会把你卡死；那时用 WBS 或 PDCA 更顺手。
示例
示例：向银行交付一个报表模块
范围由合同锁定，交付日期确定，每个阶段结束时都要拿到客户的书面确认。这类工作就是按阶段依次往前走。
需求
- 列出报表类型
- 写下权限规则
- 取得客户确认
设计
- 数据模型
- 界面草图
- 约定性能上限
开发
- 报表引擎
- 权限控制
- 导出功能
测试与交付
- 内部测试
- 客户验收测试
- 上线
- 用户培训
瀑布模型的长处和短处在这里同时露了出来：范围一开始就定死，所以进度好衡量；可一旦开发途中需求变了，整个计划就要往回倒。
常见问题
什么是瀑布模型？
把项目切成前后相接的阶段、上一阶段没结束就不开始下一阶段的做法：需求、设计、开发、测试、交付。名字来自水沿着台阶往下落的样子。
该用瀑布还是敏捷？
范围事先清楚、也不太会变动的，瀑布的管理负担更小，建筑工程、受监管的业务、固定总价的交付都合适。范围要边做边清楚的，瀑布会很贵，敏捷方法更合身。
可以回到上一个阶段吗？
可以，但要付代价，模型本来也不是为此设计的。如果经常往回走，说明范围一开始就不够清楚；那时真正该问的是：当初选瀑布对不对。
阶段之间发生什么？
每个阶段都以一份交付物和一次确认收尾，确认应当是书面的。瀑布提供的全部保障，都建立在双方在同一时刻承认某个阶段已经关闭之上。
免费吗？
免费。Klarsti 目前免费且没有广告，用瀑布方式管项目不需要账号。