项目计划定制：项目计划划分与产品项目推进的有机结合

第一章：导语
第二章：需求采集部分的一些要点
第三章：项目中一些需要明确的内容
第四章：关于成本管理部分

第一章：导语

那么什么叫项目，项目计划和项目管理？

项目管理简称为PM，是project management的缩写，直译就是项目管理方法。其国际标准化验证为PMP。其中考核内容以时间管理，资料管理，进度管理等管理学科为主，产品及需求了解为辅助进行。

整体上根据生存周期的阶段共分“需求”“可行性”“规划”“设计”“建造”“测试”“移交”七个部分，交互进行；但从项目管理角度我们简单分割为“关键概念确认”“启动项目准备”“规划”“执行”“监督”“结束项目”六个大范围进行管理。当然这其中也包含一定的细节，这里我们会慢慢的在今后的培训中和大家交流整理

那么回到正题，我们今天主要说的是项目计划的制作方法，其最主要的方式方法事实上并不是从我们制定项目计划开始的，而在这之前我们就必须进行多方面的准备，可以说追溯起来，一切的起源在产品的需求采集阶段就已经开始了

项目计划主要包含如下一些信息：

约定并通过双方同意的内容
信息源的粗细度划分
明确的内容分割
验收标准的明确性
约定并通过双方同意的内容

项目中“约定并通过双方同意的内容”主要包括在《项目规章》或《项目章程》中进行界定或明确。例如是否符合国家法律，是否涉及国外行业等都是用以划分内容，和内容边界具体说明，这里便不做重点描述

信息源的粗细度划分

信息源的出席度划分事实上就属于比较重要的范畴，因为这里的产出会直接关系到整个项目的走向，计划的制定，重点部分的明确甚至是测试及验收阶段都有着至关重要的作用。今天，我分享的内容也主要是针对这以一个方面

第二章：需求采集部分的一些要点

一、需要先明确我们要做的是什么？

当产品经理采集完成用户的需求之后，我们并不是就可以认为已经完成了，然后按照这个进行原型图的设计了。事实上在这里我们缺失了最重要的一个环节，而缺失的原因实际上很简单，这部分工作对产品来说并没有任何的意义，反而会增加工作，而对于之后的项目工作来说却至关重要，这就是——需求粗细度划分确认。

二、如何管理需求粗细度划分—-产品经理的工作要素

简单来说，对收集上来的需求，按照权利（需求方要求），价值（技术侧重）的评估级别进行对应的分割和明确，一般我们利用二线四项图来进行明确的区分和判断。

举个例子方便大家思考：

我们需要做一个PIAZZ，那么我们需要如下材料：

餐桌，苏打水，煤气/电炉子，烤箱，火，披萨面团，番茄酱，配菜，奶酪

然后我们的需求方进行排序：

披萨面团
奶酪
配菜
烤箱
番茄酱
其他（利益引导）

我方“厨子”要求：

披萨面团
奶酪
烤箱
煤气/电炉
番茄酱
其他（开发需求引导或可行性引导）

那么我们可以得到如下图形

我们不难看出，双方都关注的部分是披萨面团，奶酪，然后还有各自重视的部分，因此区分完成后，我们可以根据对应的需求方面拟定此方向的运作及具体内容的安排

那么一定有人要问，为什么我们需要这部分的资料呢，因为这有了这部分资料之后我们才能够明确我们的项目到底是个什么类型的产品，按照各自不同来说在行业里面我们一般将其分为ON-PREMISES,IAAS，PAAS和SAAS以及整合型IPAAS类型产品

好吧我们依旧用上面的例子告诉大家具体的区别，使用不同的类型，会有不一样的思路和解决方法。

IaaS: Infrastructure-as-a-Service(基础设施即服务)

有了IaaS，你可以将硬件外包到别的地方去。IaaS公司会提供场外服务器，存储和网络硬件，你可以租用。节省了维护成本和办公场地，公司可以在任何时候利用这些硬件来运行其应用。

一些大的IaaS公司包括Amazon, Microsoft, VMWare, Rackspace和Red Hat.不过这些公司又都有自己的专长，比如Amazon和微软给你提供的不只是IaaS，他们还会将其计算能力出租给你来host你的网站。

PaaS: Platform-as-a-Service(平台即服务)

第二层就是所谓的PaaS，某些时候也叫做中间件。你公司所有的开发都可以在这一层进行，节省了时间和资源。

PaaS公司在网上提供各种开发和分发应用的解决方案，比如虚拟服务器和操作系统。这节省了你在硬件上的费用，也让分散的工作室之间的合作变得更加容易。网页应用管理，应用设计，应用虚拟主机，存储，安全以及应用开发协作工具等。

一些大的PaaS提供者有Google App Engine,Microsoft Azure，Force.com,Heroku，Engine Yard。最近兴起的公司有AppFog,Mendix和Standing Cloud.

SaaS: Software-as-a-Service(软件即服务)

第三层也就是所谓SaaS。这一层是和你的生活每天接触的一层，大多是通过网页浏览器来接入。任何一个远程服务器上的应用都可以通过网络来运行，就是SaaS了。

你消费的服务完全是从网页如Netflix,MOG,Google Apps,Box.net,Dropbox或者苹果的iCloud那里进入这些分类。尽管这些网页服务是用作商务和娱乐或者两者都有，但这也算是云技术的一部分。

一些用作商务的SaaS应用包括Citrix的Go To Meeting，Cisco的WebEx，Salesforce的CRM，ADP，Workday和SuccessFactors。

也就是说，不同的产品的类型会直接影响我们在产品设计及项目裁剪的明确方向和界限，因此，在项目计划中起到了至关重要的作用。

人话就是：你要去旅游，你坐车去旅游，你和你的小伙伴坐车去旅游，在这3句话里面，你去旅游才是核心的部分。那么就要优先完成核心部分，项目计划粗细度，还有侧重的确认方法。

第三章：项目中一些需要明确的内容

如何规划进度，如何使用以上信息进行操作，这里将进行详细描述

步骤1.区分需求严重性

我们一般通过使用二纵四项图标对需求及内容的优先级及投入重点，具体样式及使用方法如下：

通过合理的拆分和裁剪，可以更好的优化项目优先顺序，更好的提供界定参考，规划方案。

用人话来说，就是需求分主次还有ROI，而这个双方的立场不一致，需要沟通确认，而核心需求和功能基本上是大家认可的，在项目预备中，确认了核心需求和功能，是可以先做一些框架性的部署。

步骤2.通过评估标准进行输出界定里程碑，活动及活动关系

进度管理计划是项目管理计划的重要组成部分。它描述了管理进度的过程的流程，包括如下指标：

将用于制定进度模型的进度方法和工具
准确度（这将包括项目进展）
计量单位（小时、天、周）
控制临界值，例如当机遇浮动或者缓冲而采取的预防措施或纠正措施预案及可行性
度量方法。例如进度偏差（SV）界限或进度绩效指数（SPI）
制定网络图的指南
资源的可用性和持续时间估算的估算方法
进度状态报告的频率和格式

通过以上指标进行界定，可以进行工作分解结构（Work Breakdown Structure，即WBS）

利用分解或滚动式规划进行分解，最终可以产出如下资料：

活动清单（任务列表）
活动属性（任务完成要求）
里程碑清单（界定小实现周期）

活动清单包括：范围基准

范围基准包含：

项目范围说明书（项目章程内已经制定）
WBS包
WBS词典

活动属性包括明确的WBS属性及额外信息

活动属性包括：

活动标识符或编码（WBS编码）
活动名称（WBS任务名）
活动描述（WBS任务描述，及完成条件描述）
紧前或紧后活动（前置WBS任务，引发WBS任务关联）
逻辑关系（WBS隶属关系）
提前量或滞后量（WBS评估完成进度）
强制日期（WBS强制完成日期）
制约因素
假设条件（触发条件）
所需要的资源和技术水平
履行地理位置（履行人或组织）
投入类型（投入资源模式或力度）

里程碑清单：作为每一个生存周期阶段的开始和结束、关键可囧付成果的完成、通过某个标杆对照或测试，或者获得正式签字同意验收。

每一次里程碑的界定，都要再次界定当前阶段活动的需求、风险、成本和其它项目管理计划中需要更新的部分，具体参考《活动属性》表

活动属性表如下：

步骤3.利用以上信息，明确项目内里程之间的关联关系

一般通过网络图进行调整：

网络图内的区域概念：

区域描述

绿色区域：当前模块内任务执行的顺序（A~G）
蓝色区域：某些任务需要的附加条件或紧前活动（F）
红色区域：紧后任务配合产出

整个流程完成了当前里程碑的研发进度计划及发展方向

关于其中的一些字符的介绍

FS-2d:在活动A完成和活动C的开始之间有2天的提前量
+2d:在活动的完成和活动D的开始之间有2天的滞后
SS：E和F之间有开始——开始（SS，即同步开始）关系
FF：G和H之间有完成——完成（FF，即同步完成）关系

其它没有标注的关系都是完成——开始（FS）关系

步骤4.项目活动周期时间估算

大多数发起人和客户倾向于激进的估算，它们希望项目更快更好的完成。但是如果你的估算古语激进，你将在开始的时候就落后于计划，并很难赶上。更激进的估算，在整个项目进度运转的过程中都有很高的风险，因此预算也会无法衡量，造成整个项目的不可控和不可评估状态的出现

那么我们应该如何评估项目的活动周期时间甚至是成本，这就成了每个项目管理这必须要掌握的部分

一般来说一个准确的活动周期估算，是需要有稳定的核心团队作为基础，配合相关数据形成可行性预估，其他相关数据材料包括：

季度管理计划
活动清单
活动属性
活动资源需求
资源日历
项目范围说明书
风险登记册
资源分解结构
事业环境因素
组织过程资产

而后通过专家判断，同类对比估算，参数估算，三点估算，群体决策技术，储蓄分析能力进行等方法进行分解后得到我们所需要的数据

这里将着重介绍其中的一种方法：

类比估算法（RERT估算）

类比估算法采用标准化计算方式，简略估算“行业价值”及“期望持续”等标准化基数

公式如下：（最乐观+最可能*4+最悲观）/6

举例：你需要出差去上海，机票是596一张，然后你查询特价时票价为300，紧俏时期价格达到过700，那么可以期待的票价应该介于396~596之间。这里请注意你期待的价值并非最终的实际价值，但是可以依据此类进行倒推甲方的期待价值及项目各个阶段可以接收的时间周期范畴

同样的，在计算项目周期时我们也可以如此计算

例如：一个功能，如果1个人实现，那么需要7天（每天8工时）。如果2个人，需要3天（每天8工时）做完，如果3个人2天可以做完（8工时）

那么计算工时可以使用此为标尺进行计算：

（8*7+8*2*3+8*3*2*4）/6=（56+48+192）/6=49.34工时

可以确定最好的配置时间方案为2人3天完成

步骤5.制定进度计划

依据以上的信息进行规则处理后，我们可以得到如下具体的一些信息：整个项目需要执行的过程和单个节点所需要的时间及周期，于是在这里我们可以初步的制定相关的进度计划，这里我们将继续使用到网络图概念完成

首先我先需要制定任务卡片，卡片样式如下：

其中ES=最早开始日期，EF为最早完成日期；LS为最晚开始日期，LF为最晚结束日期

任务编号与WBS包中的任务编号保持一致，预计时间为之前评估完成时间（具体参照步骤4）

然后我们需要对整个项目网络图（参照步骤3）进行“最早”（期望）条件预估，变形为：

之后我们进行进一步的完善进行“最晚”（底线）条件预估，变形为：

最终产出样式为下图(差异点在于自由浮动，以及总浮动的标记说明）

其中一些名词解释：

浮动：最早（开始-结束）和最晚（开始-结束）之间的数据差异叫做浮动
总浮动：在不延误项目完成日期或违反进度制约因素的前提下，进度活动可以从其最早的开始日期到当前任务状态下可以延误，推迟的底线时间量
自由浮动：在不延误任务今后活动最早开市日期或违反进度制约因素的前提下，某进度活动可以推迟的底线时间量
最早开始日期（ES）：在关键路径中，基于进度网络逻辑、数据日期和进度制约因素，某进度活动未完成部分可能开始的最早时点
最早完成日期（EF）：在关键路径中，基于进度网络逻辑、数据日期和进度制约因素，某进度活动未完成部分可能完成的最早时点
最晚开始日期（LS）：在关键路径中，基于进度网络逻辑、数据日期和进度制约因素，某进度活动未完成部分可能开始的最晚时点
最晚完成日期（LF）：在关键路径中，基于进度网络逻辑、数据日期和进度制约因素，某进度活动未完成部分可能完成的最晚时点

当然在一些必要的条件下，可能需要紧急或者优先保证一部分功能的优先实现，我们一般称这种状态为关键路径状态，通过关键路径发进行表述

即无论发生任何工时或活动变化，必须优先保证当前流程中相关内容的实施和完成

依据以上内容，我们可以完整的对项目的具体内容和时间进行划分，完成划分后借助

Microsoft Project完成项目计划的描述制定，并配套跟进燃尽情况，及下发对应WBS任务包。整体进度依据产出结果对比差值为基准，完成项目进度及成本管理

第四章：关于成本管理部分

事实上之上已经完成了对于项目管理中比较重要的项目计划内容的方法进行了讲解，但是如果在实际的设计过程中我们必然会发现一个比较尴尬的问题，为什么周期只有这么就，而我们的如何可以有效的有依据的方案给我们的领导层或者业务方，让其明确周期的必要性和健全性，这里就必须包含成本管理部分的内容，以此明确人员及项目周期定义的原因

这里面我们需要提到《项目章程》中定义的几个必要的元素，它们分别是：投资回报（ROI），回收期，净挣值（NPV），未来值(FV),内部回报率（IRR）

简单来说，ROI即投资方需要的回报标准，一般我们依旧利用RERT估算，通过对于产品行业价值进行RERT估算，大致确定其软件开发成本及配套价值一般来说