项目过程管理（七）排期和立项_项目排期

术语解释

• 里程碑（时间）：重要的时间节点，例如提测、发布。来自英文milestone。
• 风险点：任何可能造成项目延期的事项
• 立项：经过核心和高优先级的全体需求评审后，由项目经理收集各职能的工- 作量、风险、所需资源评估，协商得出里程碑时间，发出邮件。
• 每轮提测叫t1、t2、t3，t = test
• 每轮提测内提交的修改，叫patch。
• 合起来看：第2轮提测打的第3个tag，叫t2p3
• 全功能提测：所有在本版本要上线的需求都做完了，也可以让UI提前验收

项目排期

排期目标：

• 每个需求的职能依赖关系以及时间表。比如前端依赖UI和后端，被依赖者什么时候做完。
• 分几轮提测，每轮的时间点，提测内容。“核心”和“高”优先级的需求，都可形成一轮提测。
• 发布时间
• 风险点

里程碑时间安排示例：

• t1：11.2。需求A、B。UI在11.1 前给出，后端接口在11.1 前准备完毕
• t2（全功能）：11.5。
• t3：11.7。
• 发布：11.8

可能的风险点：

• 参与人员业务不熟
• 长假的前后，工作效率低
• 人员请假
• 第三方服务或政策因素

另外，如果要管理得细致点，每个人的工作计划都应该详细列出来。但这样是挺浪费时间的，早已不流行了。更好的做法是对团队成员做一定的培训后，项目过程让大家自由发挥，管理者只关注结果即可。

版本管理

完整版本号格式：x.y.z.c，例如2.1.3.456。前三位x.y.z合起来叫version或version name，第4位叫build code或version code。非app项目可以没有第4位。说明：

1. 有新需求，第2位+1，第3位归0
2. 大改版或年度版本，第1位+1，第2、3位归0
3. bug修复或小改动，需要发patch版，第3位+1
4. 第4位每次提测（非发布）都+1，永不重置。这是最简单的区分每次提测包的手段，可方便测试做回归检验。

立项邮件

收件人：项目组img群
标题：【立项通知】xxx（项目）y.y.y（版本）。例如 【立项通知】微信3.2.4
1
2

正文示例：

Dear All，

本期项目共有5个核心和高优先级需求，3个中低优先级需求。有12个人参与实际工作。
具体请看 需求总表【http://...】。

项目周期：10月4日-10月18日，共10个工作日

里程碑：
t1：10月12日（周三）。提测需求A、B。UI在10.10前给出，后端接口在10.11前准备完毕
t2：10月13日（周四）
t3（全功能）：10月18日（周二）
发布：10月20日（周四）

风险点：
1.新同学加入实现需求A，业务不熟，可能会延长解bug时间
2.需求B需要技术预研，预留时间未必准确。请 @xxx 随时汇报进度
3.第三方合作商xxx在月中要进行数据迁移，影响我们对接

日程表如下：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

（日程表图用Excel做的，项目管理系统一般会自动生成）

本系列文章的目录：https://hursing.blog.csdn.net/article/details/88025790