IV. 产品的需求、系统分析、设计training.mypm.net
项目管理论坛
总的而言，软件开发主要分为六个阶段：需求分析阶段、概要设计阶段、详细设计阶段、编码阶段、测试阶段、安装及维护阶段。开发软件就如八股文一样：总体规划、项目立项、需求分析、系统分析、系统设计、编码实现、项目测试、文档制作（八股文：破题、承题、起讲、入手、起股、中股、后股、束股），一切都按部就班。同理，信息系统集成项目管理一般的过程分为：需求分析、项目调研、方案论证、实施方案、具体实施、测试、验收、售后服务。同时项目管理按管理的方式可以分为售前、售中和售后。 项目管理者联盟
pmp.mypm.net
在国内，做的项目越多，就越容易产生这样的感觉：项目感觉总是做不完，就像一个“无底洞”。用户总是有新的需求要项目开发方来做，就像用户在“漫天要价”，而开发方在“就地还钱”。 实际上，这里涉及到一个“范围管理”的概念。项目中哪些该做，哪些不该做，做到什么程度，都是由“范围管理”来决定的。“范围管理”的相关知识，可以参考项目管理知识体系指南、项目管理九大知识体系的相关内容。这里只说说两点，核心需求和需求的变更。 项目管理论坛
项目管理者联盟
一般说来，需求对用户来说，可以分为核心需求和辅助需求。对于中国贪心的用户来说，功能从来不嫌多的。核心需求就是用户使用本软件是，一定会使用的功能，没有这些功能，会影响用户的忠诚度。辅助功能，就是用户可用可不用的功能。有了这些功能，用户更喜欢，没有这些功能，用户不会太在意，或者是可以容忍。同样一个软件，不同的用户，核心需求和辅助需求是不一样的。在一个项目产品中我们应该知道对方需要什么，自己要做什么，这是项目成功的基础所在。training.mypm.net
club.mypm.net
对于产品，因为用户是不确定的，确定哪些需求是核心需求，哪些是辅助需求，则比较难。但是如果定位合理，对定位的用户范围的特征分析得准确，则不是什么太难得事。但无论是产品还是项目，都必须考虑以下三点：1、对于用户提出的每个需求都要知道“为什么”，并判断用户提出的需求是否有充足的理由，并考虑由此而引申出来的问题，触类旁通，举一反三；2、对于用户提出的每个需求都要知道“为什么”，并判断用户提出的需求是否有充足的理由；3、分析由用户需求衍生出的隐含需求，并识别用户没有明确提出来的隐含需求（有可能是实现用户需求的前提条件），这一点往往容易忽略掉，经常因为对隐含需求考虑得不够充分而引起需求变更。blog.mypm.net
blog.mypm.net
需求确立后，重要的是规范化，文档化，可参考常用的需求建模的方法如数据流图（DFD）、实体关系图（ERD）和用例图（Use Case）三种方式。 项目管理者联盟
项目管理者联盟
需求的变更是不可避免的，如何以可控的方式管理软件的需求，对于项目的顺利进行有着重要的意义。现在，重要的不是限制需求的变更，而是让用户、销售、开发都明白，不管是哪种情况下变更，只要是造成变更的一方，都要背负相应的责任。这就需要一个明确的约束机制。在制定制度时，大家都可以参议，提意见。但只要制度确定了，就必须恪守这个制度，是制度管人，而不是领导管人。也只有这样，才不至于开发处于遥遥无期的状态，而到最后则草草收兵。blog.mypm.net
项目管理者联盟
本人认为，需求的确定可以分为三个阶段则比较合适，这样划分也涉及到计划、成本的管理，可参考后面的相关内容。项目管理者联盟
www.mypm.net
一、 项目初期，用户、销售、开发三者，应根据WBS方法确定整个项目的整体需求，即最起码要确定WBS中最顶层的父作业，如需求一，需求二．．．．．． 并尽可能详细地确定需求地具体划分，如需求一.1，需求一.2，需求二.1，需求二.1.（1）．．．．．．对于开发周期比较长的项目，则可以确定每个需求开发开始的大概时间，周期比较段的项目，则只需确定整个项目的开始时间即可。对没有确定的需求，则要明确在开发前一个相应的时间，必须在确定的时间之前来落实详细的需求。对已确定的需求则明确在开发前的一个具体时间内可以修改的内容，主要是框架性的需求。项目管理者联盟
www.mypm.net
二、 项目开发前，核实项目的所有需求，应当包括详细的需求，并明确告知用户以后只能修改细节上需求，主要是操作上的需求。如果在以后要修改框架性的需求，必须受到一定的约束，所产生的成本必须为要变更的一方负责。如是因为开发的原因造成的，则增加成本纳入到项目的成本中；如因销售工程师因销售压力而盲目对用户作承诺的功能，则相应成本必须纳入销售成本中；确定落实需求后，进行项目的开发阶段。项目管理者联盟
项目管理者联盟
三、 项目开发完成后，提交给用户试用。用户使用后，用户明确要修改的内容，主要范围是操作上，细节的实现是否与需求一致，是否与用户真正需要的一致。如要对框架性的需要修改，则必须按先前的约束条件进行。确定修改内容后，向用户明确，以后的修改内容都只能局限于当前提出的修改范围，当然，程序出错除外。开发进行修改，用户使用，将修改范围进一步缩少。一次或多次迭代后，项目完成。 PgMp.mypm.net
blog.mypm.net
V. 工作量的估算及评价项目经理博客
项目管理者联盟
项目管理最大的难度，就是每一模块的工作量、开发时间的确定，这也是项目实施的主要风险，最难预测、控制的风险。项目管理者联盟文章
training.mypm.net
比较常用的估算方法有：估计项目交付日期的方法有很多，如基于经验的估计、基于模型的估计等。一种简便易行的估计方法是采用Wideband Delphi估计方法，此方法可以降低不同人员所作估计的偏差。基于模型的估计方法则包括KLOC、FPA以及COCOMOⅡ等模型。在这里主要引用新的估算方法，以供参考。项目管理者联盟
blog.mypm.net
如果，公司有着类似项目实施的丰富经验，则工作量、开发时间的确定则会更切实际。项目管理者联盟
首先，提取公司内部数据，统计出类似模块的工作量（M公）、开发时间（S公）。如果，公司没有这方面的经验，那如何办呢？不做这一步？！对，没办法，没时间时也可以放弃这一步。有时间，有精力时，可以通过了解社会对类似模块的工作量、开发时间的平均值再结合本公司的情况进行假设模块的工作量、开发时间。项目管理者联盟
项目管理者联盟
其次，项目开发成员对这一模块的工作量、时间的估算。这一步是最耗时，这是很多公司都没有去做的，包括国内一些知名的软件公司。软件开发，不是工厂中的流水线生产，可以对产品的生产过程中每一个过程，每一个步骤，进行严格的控制和限制。在开发过程中，由于开发人员不同的学历背景、知识水平、经历、开发经验、对模块的理解程度、思维方式、编程习惯等因素，对同样的模块，所需求的工作量，开发时间是有很大区别的。因此，需要每个开发成员对相关模块了解熟悉后，进行估计，再根据不同的系数，通过不同的公式进行转换后确定每一个模块的工作量、开发时间。项目管理者联盟
项目管理者联盟
 公式为：M＝M（公）*X1+M(项)*X2;项目经理圈子
  S＝S（公）*X1+S(项)*X2;项目管理者联盟
  M(项)＝M（开1）*Y1+M(开2)*Y2+…+ M(开n)*Y.n;项目管理者联盟
  S(项)＝S（开1）*Y1+S(开2)*Y2+…+ S(开n)*Y.n;项目管理者联盟

每一模块，每项功能完成后，对小于原定工作量或成本的，可以直接以原工作量和成本作为考核的依据。对于超出原定工作量或成本的，必须组织相关人员进行成本、工作量的评估。主要的操作方法为，组织3到5人的评估小组，小组成员尽可能是在开发时对要评估模块相当熟悉的成员。小组成员利用一定的时间了解评估模块的代码，功能特点，模块实现思路，难点，简单的单元测试等，然后小组的成员假设是成员本人来开发评估模块，需要用的成本、工作量并转换为开发人员相应级别的工作量、成本，最后综合小组成员的估计的工作量、成本和开发人员开发时所耗费的成本、工作量进行加权平均，得出最后的成本、工作量，并以此作为考核的依据。 项目管理者联盟
项目管理者联盟
VI. 计划的编排项目管理者联盟
bbs.mypm.net
有人这样形容计划的，“计划，计划，纸上画画，墙上挂挂，计划不如变化，计划不顶领导一个电话。！”。根据美国Hackett公司的一项调查发现，只有37%的信息化项目在计划时间内完成，只有42%的信息化项目在预算内完成。计划很容易成为空话，特别是在软件工程中，影响计划的因素太多，计划就形同虚设了！但是，项目管理方法的主体就是项目计划、计划优化方法,其目的就是综合各种因素，制定合理的计划，并通过计划的实施，使其规范化，从而提高项目的效益，提高人员效率，降低项目的成本。项目管理者联盟
项目管理者联盟
围绕着项目计划方法，可以把项目管理方法分为四个发展阶段：Gannt图阶段、确定性网络计划技术阶段，如关键路径法CPM（Critical Path Method）等、概率型网络计划技术阶段，如计划评审技术PERT (Program Evaluation and Review Technique)和多因素随机网络计划技术阶段，如考虑资金因素的PERT/COST，考虑活动风险的图评审技术  GERT(Graphics Evaluation and Review Technology)和风险评审技术VERT(Venture Evaluation and Review Technology)，以及多种资源（资金、人力等）约束下的网络优化等等。无论项目管理发展到哪一阶段，本人认为计划要合理，合乎以后项目实施的实际情况，以下三点是前提：项目管理者联盟
项目管理者联盟
一、 对计划的态度问题。如果计划只是为了让上面的头头看看，放在墙上挂挂。那基本上这些计划也就是没什么意义的计划，不说也罢。这些计划不是小数。笔者曾经看过这样的计划，某位同事出差在外面两周，但在最新的计划中，还有本周必须在公司完成的开发任务。这种计划，一经编排就意味着无法完成，或者要进行变更。还有，笔者亲身经历的，在收到的计划中（是8月15号制定的），已安排笔者在8月15号前的一个星期完成某一项工作。本人是在8月15号后才知道要完成这项工作的，自然就无法按时完成拉。这样的例子还有很多，不胜枚举。 项目经理圈子
PgMp.mypm.net
二、 对计划的编排要做到有粗有细。传统的计划编制是这样的：首先对项目进行估算，粗算出项目的总体进度。然后进行精化：确定概要设计阶段、详细设计阶段、编码阶段、测试阶段、安装及维护阶段等阶段的具体要求、完成时间、投入人力物力，并确定几个关键阶段。这些关键阶段的要求进度必须在指定日期之前完成。最后充分考虑影响项目计划的因素，并做出相应的措施，做出项目进度表，列出在每个阶段的难点要点，要注意的问题。，并将需要分析阶段的内容和项目计划、进度表整理成文档，分发到相关人员手上。PgMp.mypm.net
pmp.mypm.net