接上篇 没人教的项目管理方法之（明白该干什么） 二、项目章程如何写（上）
五、项目假设
就字面意思来解释，就是必需满足这些假设的条件，项目才可能按计划开展任务，这里的假设大家不要写得过多，而要集中关键假设上，这个需要结束上篇文章提到的项目约束来讲：
为了大家不用翻上篇文章，我把描述粘过来
值得注意的是，项目的约束需要进行优先级别的排序。也就是说一个项目中，这些约束不要在同一个优先级上全部满足，根据我的经验，一个项目也就是一个高优先级的关键约束，另外加上两到三个的次要约束条件即可满足项目成功的所有必需条件，另外的约束条件应该作为锦上添花的约束进行罗列，完成了当然好，不完成也影响不了项目的总体验收。
因此，影响高优先级及次要优先级的假设条件才是你需要关注的：
譬如：工期作为高优先级约束。有些项目有近乎苛刻的工期要求，这时首要保证的假设无外乎如下：
Ø 人力资源（包括开发方和客户方，大部分项目经理在做假设时只估算了开发方，其实客户如果业务繁忙，没法配合你的需求调研、版本审核、业务指导等也会影响工期，如果有第三方，那么还要包括第三方）
Ø 设备资源（计算机设备、网络设备、其它硬件设备、办公条件等）
Ø 资金资源（人力成本、加班经费、风险准备金（这个要估足）、交通误餐等）
Ø 知识储备（预估项目中可能遇到的知识难点，可以通过培训、外聘专家、外包等解决）
Ø 根据项目实景分析（采用鱼骨图，SWOT等工具）会遇到的项目延期问题，譬如客户没一个懂需求分析重要性的，那就要安排相应的需求分析知识培训给客户
项目假设是可以补充的，应该说项目假设有点类似于风险分析，但项目假设是着重于关键约束实现的必要条件，而不是应对方案。
六、项目管理方法论
项目管理方法论就不过多阐述了，如果你的企业有一个完整的项目生命周期管理，那么这里其实就是选择相应的生命周期，如果需要适当裁剪的，要把裁剪后的周期详细说明。
瀑布、敏捷、RUP等这些都是生命周期的呈现形式，根据不同的企业特点，会对这些方法进行相应的改动以适应开发过程。
七、项目的可交付成果
这个很清晰，一般来说第1、2项是客户要求的，第3项需另外约定
1、软件各个版本
2、各个里程碑提交物（文档、阶段交付产品）
3、项目过程中生产的其它附属提交物（通用类库或组件、附属开发产品（譬如一个小型OA））等
八、概要进度
这一项很多项目经理很反感，确实我也很不愿意预估，因为项目开始的时候很多条件都不是很明确，那些WBS在这个阶段是没法弄的，没办法预估，而项目章程非要来这么一项，怎么办呢。
我提供一些思路给大家
1、凭经验预测，这是最不靠谱的，建议不到山穷水尽的时候不要用，因为你一旦对企业承诺了，实现不了就全是你的责任了。
2、短暂启动评估法
老外也叫这个“哈德逊湾式启动”，方式源自17世纪加拿大的哈德逊湾航运公司，这家公司的商船在启航后，会在距离港口几英里的地方做短暂停留几天，这样确保如果忘记装载了一些必须的给养和装备，可以回到港口再补充。
运用到项目管理中，可以让项目小组先尝试在项目的实际环境中先开展完成某些功能和工作，具体说来譬如一组测试驱动的代码或是某一组功能的思维导图，这个时间要尽量短，一般不要超过三天，如果你不好选择开展哪些工作，那么你可以选择手头上可以在4小时内完成的工作，完成之后，项目组一起来分析这些工作。如果还是不知道，那么请看下面的办法
3、短期迭代
和上面不一样，这个估算是以一组功能或工作完成后，团队成员来一起分析整个项目的工期，譬如说大家一起把需求分析中所需的功能点整理出来后，或是以某一组功能完成为前提，来进行工期的整体评估，这个时间最好在一周内。
4、团队头脑风暴
按任务从上至下进行分解，大家各抒己见，用加权平均来分析具体工期。这个做法的误差很大，而且要求项目组成员的经验足够丰富，否则不宜采用。
九、参考里程碑提交物
这个就举例说明了，大家看看下面的表格就一目了然了
| 序号 | 工作里程碑 | 前置任务 | 参考提交物 |
| 1 | 项目立项 | 《项目章程》 | |
| 2 | 需求分析 | 1 | 《需求分析说明书》 |
| 3 | 编码实现 | 2 | 《任务分配表》《测试计划》 |
| 4 | 测试 | 3 | 《用例测试》《bug报告》 |
| 5 | 部署 | 4 | 《管理员手册》《操作员手册》《数据字典》《验收报告》 |
| 6 | 维护 | 5 | 《维护计划》《灾难恢复手册》 |
*黑体的文件需客户签字认可
好了，项目章程基本上说完了，欢迎大家拍砖