全面学习项目估算、计划、计划跟踪知识【完整版】
下面是小编为大家整理的全面学习项目估算、计划、计划跟踪知识【完整版】,供大家参考。
全面学习项目估算、计划、计划跟踪知识
摘要：
{0}
大纲：
1. 从建筑工程说起
2. 估算要估啥？
3. 估算如何做出来？
4. 计划有什么内容？
5. 计划是如何做出来的？
6. 如何跟踪计划？
{1}
正文：
从建筑工程说起
{2}
{3}
1. 从需求到竣工，经历需求、设计、估价、建设等环节，每个环节由不同专业的公司或人员完成。
{4}
{5}
{6}
{7}
软件项目管理可能是最复杂的一种项目管理，因为软件项目具备这样的特点：
1. 需求、设计不明确。
{8}
{9}
{10}
软件项目管理 难归难，但我们还是要去面对的，我们应该如何应对软件项目的估算与计划呢？
估算要估啥？
{11}
对于估算要区分以下几种情况：
1. 甲方对项目的估算
甲方想做某个系统，会根据自己对系统的估计以及自己的预算估计出一个价钱。甲方往往不能准确对项目进行估算，项目的价钱往往是来自预算，而所有甲方都是想在有限的预算内办更多的事情。很多项目需要招标，其实重要目的就是希望找出性价比最高的软件公司。
2. 乙方在投标阶段对项目的估算
作为软件公司，要判断该项目需要多少的成本，然后稍微“ 放大 ” 成本作为投标价，这样 公司才能有利可图。
然则现实情况很残酷：
{12}
2 2 ）很多招标其实甲方都 “ 隐含 ” 一个预算价，如果软件公司的报价超出这个价钱，你就别想中标了。而这个预算价往往会小于软件公司对项目的估算，让你难以决定这项目做还是不做好！
{13}
在我们公司，对于已经产品化的项目，估价比较容易，这其实是一个积累的过程。而对于全新的以前没有多少经验的项目，估价其实也是很难做得很好的，我们往往是由项目经验与技术经验都实力雄厚的总经理来 “ 拍脑袋 ” 拍出来的。所谓 “ 拍脑袋 ” ，其实不代表乱猜，是以雄厚的经验和强大的知识为前提的。
3. 项目组开展项目时对项目的估算
{14}
{15}
项目估算到底要估什么呢？
{16}
人工费：
包括项目组各人的薪金，以及公司运作分摊到项目组各人头上的运作成本。公司运作成本包括非项目组人员的人工、场
地设备费用、水电通讯费用、人员培训招聘费用、人员闲适成本、研究失败时的成本、商务活动的成本等。
{17}
{18}
{19}
{20}
{21}
以上费用最难估计的就是人工费，人工费我们以工作量来考虑，下文开始我们重点讲解项目工作量的估算。
如何估计项目的工作量呢？
{22}
那项目的 “ 所有工 作 ” 包含什么呢？回答这个问题其实就是回答 “ 估算要估啥？ ” 这个问题了。
一般情况下，项目工作包括以下内容：
1. 项目前期工作。
{23}
2. 商务方面的工作。
{24}
3. 需求调研方面的工作。
需求调研是一个 “ 反复 ” 的过程，一般来说能在前期确定 80%已经是很了不起的成绩。
需求调研的工作量一般由三部分组成：前期调研的工作量，后期需求细化的工作量，后期需求变更的工作量。
前期调研的工作包括：项目组内部讨论、确认，与客户讨论、确认需求，编写需求规格说明书及组织评审等工作。
需求细化是指对 之前已确定需求的进一步具体化、优化或轻微调整，如：界面细节的确认、各业务概念的具体化等。需求细化一般是可预见可估计的。需求变更是指对之前已确认需求的 “ 否定 ” ，变更的原因主要有两种情况：一是之前需求调研工作没有能做好，理解错客户的真正意图或者是遗漏重要的需求；二是客户业务情况发生变化，与之前情况已经不同。第一种情况应该尽量避免，而第二种情况一般是难以估计的。需求变更时需重新估算，和客户签订需求变更协议。
{25}
4. 软件设计方面的工作。
不少项目为了 “ 赶 ” 进度，设计文档很少，然则项目真的很简单、不需要仔 细考虑设计的情况是非常少的！
软件设计工作包括：
1 1 ）系统架构设计。
2 2 ）技术方案选择。
3 3 ）关键模块设计。
4 4 ）数据库设计。
5 5 ）用户体验设计。
{26}
另外不要忘记了以下两方面的工作：
{27}
{28}
5. 编码方面的工作。
{29}
{30}
6. 测试方面的工作。
{31}
软件测试一般要经历多轮，我们估算往往只考虑了第一轮，就好象软件只需要测试一回就不用再测试了。而测试环境准备、测试数据准备这些工作也很容易在估算时 “ 忘记 ” 了。
7. 实施方面的工作。
{32}
我们 公司通常的做法是：
{33}
2 2 ）初验后要协助客户让系统正式上线，让客户真正用上这套系统，推动最终验收。
影响终验主要有两个因素，一个是客户在使用系统过程中会提出各式各样的问题，如果在需求范围内应该都予以满足；而另外一个影响因素是客户会因为各种各样的原因推迟使用系统，或者是使用不充分，让项目终验遥遥无期。估算时需要充分考虑这两个影响因素。
8. 维护方面的工作。
{34}
{35}
维护的工作一般有：
1 1 ）用户培训；
2 2 ）协助客户录入资料；
3 3 ）修复被破坏的数据以及数据库；
4 4 ）修改客户或内部 发现的软件缺陷；
5 5 ）代码重构，提高部分程序的性能与可靠性；
6 6 ）修改一些界面文字或显示风格；
7 7 ）回答客户反馈的一些安装与操作疑难问题；
{36}
{37}
9. 项目管理方面的工作。
{38}
项目管理工作量一般占整个项目工作量的 10- - 20% ，项目不明确的东西越多、项目组成员水平越不足、项目组成员之间工作磨合度越不好，管理工作量就越大。
{39}
0 10 配置管理方面的工作。
{40}
{41}
中间产物有：
1 1 ）工程类：需求文档、设计文档、测试方案、代码、数据库脚本、数据库、测试脚本等。
{42}
{43}
最终产物是指最终会交付给客户的东西，一般有：组件、安装程序、数据库、用户手册、管理员手册等。
{44}
11. 质量保证方面的工作。
严格来说，质量保证是靠项目组全体来保证的，这里所说的质量保证是 “ 狭义 ” 的质量保证，是指：要确保项目组按照既定的规定、过程、标准来工作，需按照既定的格式要求产出相应工作产品。
对于以上十一点，实际项目估算中往往出现这样的问题：
{45}
{46}
{47}
4. 项目管理方面的工作量估计不足。
估算如何做出来？
{48}
有很多种估算办法，大致可以分为 两类：
{49}
2. 直接得到工作量。
第一类的常见方法有：功能点法、代码行法，第二类的常见方法有 i Delphi 估算法、微软的由底而上估算法。
{50}
{51}
这个 0 1000 块代表了工作的规模，而生产率就是 0 100 块/ / 日，这样就可以推算出工作量为 0 10 人日。建筑工程可以得到土石方量、混凝土量、钢筋量等代表工作规模的数据，这样就比较容易推算出完成这些工作需要的工作量。
{52}
{53}
{54}
我们的项目大部分是数据库四轮马车的操作（查询、增加、修改、删除），功能点法从比较高的层次对这些工作进行抽象， 有一套严密的规则可以让你将需求分解成一个一个的功能点。代码行法思路也类似，不过分解的结果是代码行而已。但一般来说代码行与软件的实现技术相关度太大，大家会更加偏爱功能点法。
{55}
1. 只适用于数据库四轮马车的操作的项目，高技术含量、创造性高的软件不适用，如游戏软件、计算机负责计算与决策软件等。
{56}
3. 两个方法的规则都很详细，要花大量时间学习和实战才能掌握。
{57}
i Dephi 估算法是比较符合大家实际工作习惯，也是比较容易掌握的估算办法。
i Delphi 法的大致方法如下：
1. 找几名资深专 家，一起对项目进行 WBS ，把项目的工作分解为十几条最多二三十条的工作项。
{58}
{59}
4. 按照上述办法，各专家反复估算几次，一般次数就是 2 2- -4 4次，各专家估计的工作量会越来越趋近，这个时候取全部专家的平均值。
{60}
{61}
微软由底而上的估算方法大致是这样的：对项目各项工作进行分解后（即俗称的 wbs ：
work breakdown structure ，工作分解结构），每个任务落实负责人，由负责人对自己的任务进行估计。这个办法有以下好处：
{62}
{63}
{64}
其实微软这 个方法根本就没有什么特别，所有正常人都可以想到这个方法，但仍然有很多人去追求那些不太靠谱的估算方法。
这个方法还是有这样的一些问题的：
{65}
2. 有人估算过于保守。
{66}
第一个问题是比较常见的，但我们要这样想：估不准也比不估算好，估算偏差哪怕超过 100% ，也比不估算好，至少有个谱。
{67}
第二个问题分两种情况，有些人是确实是过分保守的对自己信心不太足，项目经理可以多多来指导他的工作，看看他具体的进展，让他更加充分地了解任务，更加充分了解自己的能力，增强他的信心，这样他就能持续进步了。而 另外一种情况就比较恶劣，少数人会故意增大时间，这样他平时工作不必全力以赴，可以比较悠闲，甚至可以利用工作时间干私事。如果发现这样的情况，就应该严肃处理了，不要做烂好人，这样的人在团队中存在是对团队的极大伤害。
第三个问题往往是各项目经理心中的痛楚，他们会觉得：实在无奈啊！做项目就是在有限时间有限资源内做不可能完成的任务，在这样的情况下，你就不要跟我扯估算了！
{68}
{69}
{70}
我的经验告诉我，功能点法、代码行法这些方法基本上是不靠谱的，我在实际项目中会综合使用 i Dephi 法和由底而上的估算方法 ，并予以改良，下面介绍一下我的一些心得体会。
{71}
假设某项目是这样的情况：
{72}
{73}
{74}
{75}
你现在要负责这个项目，你会如何做估算呢？
你需要做好两个事情，才能保证项目实际成本控制在预算内。
{76}
{77}
{78}
{79}
{80}
{81}
{82}
{83}
{84}
{85}
{86}
{87}
{88}
{89}
我们公司有一份估算模板，里面汇集了以前的估算经验，列出了所有需要考虑的估算内容以及详细的说明。
我们以前没有估算模板时，估算偏差会达到 50% 以上，总结经验发现偏差的主要原因是估漏！使用估算模板会帮助我们发现遗漏，后来我们的估算偏差基本可以控制在 20% 以内。
前文的 “ 估算要估啥 ” 小节，我列出了项目通常要考虑的各种工作，也列出了容易估漏和估计不足的地方，大家可在此基础上根据自己公司实际情况，修改和扩充这些内容，写出自己公司的估算模板或估算指南。
{90}
将工作分解，直到分解到可以估计工作量的程度，这个可能是最土最有效的方法了。但你可能会问，这样的估算方法，项目之间就无法横向比较了？
项目估算第一目标是用来指导项目工作，如果这个目标都达不到， 那么就不需要考虑项目之间的横向比较了。
{91}
{92}
{93}
{94}
{95}
计划有什么内容？
关于项目计划，我们要先讨论什么是正确的事情，然后再讨论如何做正确的事情，我们先来看看项目计划应该有什么内容？让大家做项目计划，很多人以为用 t Project 做一份开发进度计划就完事了。而项目的开发工作只是占了项目工作的其中一部分而已，跟项目所有相关的工作，我们都需要计划。诸如开发计划、测试计划、培训计划、沟通计划、采购计划等等，这些计划的集合，我们称之为项目计划。
项目计划应该包含以下内容：
1. 项 目背景、目标、概述等。
{96}
3. 风险分析及应对措施。
4. 项目估算。
{97}
6. 项目人员职责。
7. 对项目各项工作的安排，包括但不限于前文介绍的 1 11 种工作，如下：
1 1 ）项目前期工作
2 2 ）商务方面的工作
3 3 ）需求调研方面的工作
4 4 ）软件设计方面的工作
5 5 ）编码方面的工作
6 6 ）测试方面的工作
7 7 ）实施方面的工作
8 8 ）维护方面的工作
9 9 ）项目管理方面的工作
10 ）配置管理方面的工作
11 ）质量保证方面的工作
{98}
9. 采购计划。
{99}
{100}
下图是主计划目 录示例：
下面是进度计划示例：
{101}
{102}
上面讲了很多项目计划的内容，其实我们只是需要想清楚为什么要做计划，你就会知道项目计划应该有什么内容。
项目计划的几个重要目的：
{103}
{104}
{105}
4. 明确项目的各种工作产品。
{106}
计划是如何做出来的？
一、要站在战略的高度。
有时候我会问项目经理这样的问题：
{107}
2. 合同要求在什么时候验收？
{108}
{109}
一般情况下，在项目初期，你应该搞清楚这些战略层面的内容：
{110}
{111}
3. 项目的工期要求。
{112}
{113}
{114}
二、明确计划的 “ 输入 ” 。
要做好计划，你还需要了解清楚以下内容：
{115}
{116}
3. 项目组当前的能力情况。
{117}
以上这些内容，是项目计划的 “ 输入 ” ，良好的输入是优质计划的基本保证。
{118}
估算如果做得好，其实计划就完成大部分了，你需要利用估算来指导计划。为了说明 “ 估算指导计划 ” ，下面我会虚拟一个例子。
某项目估计完工需要 0 1000 人日的工作量，其估算明细如下：
1. 项目管理 0 150 人日。
2. 需求 0 150 人日。
3. 设计 0 150 人日。
4. 编码 0 250 人日
5. 测试 0 100 人日。
6. 实施 0 200 人日。
根据估算，你安排了详细的进度计划，进度计划中的各任务可以分为六类：项目管理、需求、设计、编码、测试、实施。请注意每一类工作量的总和，不能超过对应的估算，你需要用各子估算来控制这六类子任务。
{119}
在具体计划时，往往会发现估算时遗漏考虑的内容，这时很有可能实际计划的总工时会超出估算，或者是某类别的工时超出相应的子估算。这是很正常的事情，项目组对项目的认识是逐步深入的，不太可能在估算时就 100% 考虑周到。遇到这 样的情况，我们通常这样处理：如果仅是某类别工时超出相应的子估算，如果能从别的子...
推荐访问:全面学习项目估算、计划、计划跟踪知识 计划 估算 完整版