How to estimate project

      需求分析的过程 需求分析阶段的工作,可以分为四个方面:

1. 问题识别,
2. 分析与综合,
3. 制订规格说明,
4. 评审.

　　问题识别:就是从系统角度来理解软件,确定对所开发系统的综合要求,并提出这些需求的实现条件,以及需求应该达到的标准.这些需求包括：

• 　　功能需求(做什么),
• 性能需求(要达到什么指标),
• 环境需求(如机型,操作系统等),
• 可靠性需求(不发生故障的概率）,
• 安全保密需求,
• 用户界面需求,
• 资源使用需求(软件运行是所需的内存,CPU等),
• 软件成本消耗与开发进度需求,

预先估计以后系统可能达到的目标. 分析与综合:逐步细化所有的软件功能,找出系统各元素间的联系,接口特性和设计上的限制,分析他们是否满足需求,剔除不合理部分,增加需要部分.最后,综合成系统的解决方案,给出要开发的系统的详细逻辑模型(做什么的模型). 制订规格说明书:即编制文档,描述需求的文档称为软件需求规格说明书.请注意,需求分析阶段的成果是需求规格说明书(好象软考曾经考过这个问题),向下一阶段提交. 评审:对功能的正确性,完整性和清晰性,以及其它需求给予评价.评审通过才可进行下一阶段的工作,否则重新进行需求分析　　

　　进行估算最精确的方法通常是建立一个将工作分解开的结构。可以把功能分解为一级，二级，甚至更多级，这就需要在一个很高的层面描述工作，然后将该工作分解成更小的部分，直到每项活动都能够被估算在80小时以内完成。（或假如项目比较小的话，就是40个小时。），这样的话可以方便的在一周的工作总结中进行全方面的估计。这通常也需要花费很多时间和精力。但是，假如您很好地了解了这项工作，而且假如您能够确定所需要的工作都已包括进了您的工作分解结构里，那么您就常常取得获得一个精确的估算。

　　尽管任何的项目都是唯一的，但是有些项目同其他的项目很相象。使用以前的经验这一技巧，您能够找一找以前完成的类似项目，然后根据那个项目实际所需要的工作量来估算您当前的工作。这是个估算工作量的好方法，因为他允许您使用以前的经验。但是，他需要您以前有一个类似的项目，而且您必须具备对那个项目实际工作量的准确计算

　　即使您以前没有进行过这样的项目，其他人可能经历过。找一找内部或外部的专家，看看他们是否能够用其以往的经验来指导您进行估算。例如，假如您必须部署一项新技术，您能够找一个研究分析师，请他来帮助您估算所需工作量的水平。

　　项目管理分九个知识领域，分别是成本管理、质量管理、时间管理、范围管理、人力资源管理、沟通管理、风险管理、采购管理和整体管理。

　　一个项目经理有多少时间是用来做沟通的工作的？应该不少于75%的时间是用来沟通的，所以项目管理将项目沟通管理单独列了出来

　　下面讲几个名词，如果你掌握了，一和人讲项目管理你就抛出来，一定没有人敢小看你。他们是WBS、甘特图、基准（BASELINE）、项目干系人和关键路径

• 　　WBS是WORK BREAKDOWN STRUCTRE ，工作分解结构 WBS的定义还是很麻烦的，PM要召开团队进行讨论，向成员提供与项目相关的所有详细资料，并把WBS树分解到二层三层。然后要花上一段时间让成员 进行头脑风暴式（BRAINING STORM）思考，制订工作产出和相应人员的职责，记录每一个工作包的完成标准。比如我们要结婚了，怎么来分解呢无非是办酒席，拍结婚照，，等等，这个在论坛上曾有人做了详细的分解，大家都可以找到。我们说为什么WBS重要，而且大部分项目管理的咨询都是针对WBS的咨询因为WBS做好了，以后工作就有了参考物，你就知道在不同的阶段你应该干什么，完成到什么进度。其实WBS的划分是没有规则的，主要的考虑角度是方便你做各类的统计工作，为管理服务。同样的一个项目其管理的侧重点不同，WBS结构的划分也可能是完全不同的。衡量划分好坏的标准应该是看其是否满足你管理的需要。
• 甘特图也叫横道图等，很多名称，我们说它是甘特在第一次世界大战时开始使用，它就是在WBS的基础上将WBS形象化老控制进度
• 对于基准，我象举个例子。我们在没有结婚之前，你脚踩几只船？我们说法律允许但道德不允许，但你可以脚踩N只船：）但当有一天你和你的朋友进了一个小黑屋子，然后带了两个盖章的本本的时候，你还可以脚踩N只船吗？我们说此时就不允许了，因为你过了一个基准线（BASELINE）如果你还想脚踩N只船就需要重新回小黑屋子再盖两个章就可以了。那我们的项目要越轨怎么办，也就是项目变更？我们说对这样的项目变更会影响各要素比如时间，成本，质量等我们应该统一由项目管理办公室来进行控制，如果你要变更基准，必须要进行严格的限制。在客户提出变更请求时，要建立变更申请登记表和变更申请 表，并让客户签字。有时候一些不是非常关键的模块PM也不至于一点不讲情面，该卖面子的时候还是要卖，尤其是当着对方领导的面，千万要 卖面子，但是也别卖的太干脆，不要让他们得到的太容易。 PM在变更管理中需要做的是分析变更请求，评估变更可能带来的风险和修改基准文件。如果一个项目进行过程中，比如现在的点心的3G项目，你发现如果再多花一点时间就可以编写出对以后非常有用处的程序，但这个程序不在本项目范围之内，你要不要做？对，我们说不能做，你可以重新起一个项目来做，但不能在这个项目里做，这样会是我们的项目成本超出，风险增加，而且和其他的项目缺少比对性和参照的价值。
• 有个有名的增量开发的名声。只用20%的功能先满足你80%的需求，其他的功能我可以开发升级的版本
• 项目干系人是什么东东，谁给我举一个例子？对，包括项目人员的老婆孩子，正确我们说有的项目需要的时间很紧张，如果你的项目成功了，但项目的程序员们都成了光棍，那项目还是非常失败，至少不是丧心病狂的PM这么想。合理解决项目干系人的冲突是个很累的问题，其中还包括你的只能经理们，你的董事长，你的客户，等等，等等，有的说没用？好，如果你的项目进展不下去，你该怎么办？对，开会，把你的高层找一个坐到会议室，不用他说话，只让他暧昧的看着大家，大家一定会想，这个家伙一定和领导有关系，我们还是好好的做这个项目，下一个项目再给他使拌子吧：）所以为了不累死好好分析一下你的项目干系人吧我们上次讲了一些基础的知识，包括什么是项目管理，项目管理包括什么？