对于小公司来说，项目管理就是从0到1的过程，只能摸索着从大的管理模型中抽取出合适的思路，再拼接成最基本的管理模式，才能让轮子先跑起来。
在读《IT项目量化管理》这本书时所学到的一些方法论，通过自己的理解将方法论转成图示来帮助大家快速理解，如果有写的不到位或错误的地方欢迎批评指正。
WBS是项目管理重要的专业术语之一，其基本定义是
以可交付成果为导向对项目要素进行的分组
它归纳和定义了项目的整个工作范围每下降一层代表对项目工作的更详细定义。
按照书上的说法，WBS分解法的一个用法即在“时间轴”上，对交付物进行分解并分期检查，以此方式来完成项目进度管理。
WBS分解法的四个步骤：
- 确定交付物
- 分解交付物
- 确保可交付物成果的准确性
- 细分检查周期
但其实整理下来感觉可以算为2个分解+2个原则，先说两个分解：
1. 确定交付物
可以通过两种方式来确定交付物，以「交付物种类」来划分和以「项目阶段」来划分。
从「交付物种类」来说，如硬件系统（应用服务器、数据服务器）、软件系统（前端应用、数据库应用）、开发与维护文档（操作手册、代码文件）……
从「项目阶段」来说，每一个阶段都会产生交付物，如需求分析阶段（需求文档）、编码和单元测试阶段（功能模块代码）……
个人感觉「以项目阶段来划分」更好理解一些，并且更容易安排到检查周期中去。
2. 分解交付物
每个交付物也是在阶段中由不同的任务组成的，比如需求分析阶段交付的是“项目需求报告”，其中还要由“业务流程图”“功能流程图”“需求文档”等一系列组成。需要在工作时间轴的基础上，对交付物进行细分和进度检查。
就像项目经理说：我们现在该开始写代码了，就只产生了最后的结果，在这其中要以“周”为单位核查项目进度，检查每一项任务的完成情况，所以就需要对交付物进行分解。
两个原则
- 确保可交付物成果的准确性
即确保交付物的「具体」、「可检查」和「客观」。通过这三个属性保证客观上可验证的“任务已完成”。 - 细分检查周期
将工作内容最好 分解到1~2个工作日来检查交付物
一般项目组会以已「周」为单位开会核对项目进度并制定下一周的计划，如果没有按时完成则将未完成项排进下一周的工作日程。从操作系统的角度上来说这也叫作「滚动窗口」
通过以上2个分解+2个原则，可以得出一个基本的分解模式：
项目不同的阶段能得到大致的周期，将其分解成以「周」为单位的交付物后再进行细分。在安排「当前周」的工作时要细化到每个人1~2天的任务周期，即检查这一小段任务是否按时完成。当前周之后的时间适度粗化，就比如当前是第1周，第20周的任务就没有必要细分交付物。
