IV. 产品的需求、系统分析、设计

  总的而言，软件开发主要分为六个阶段：需求分析阶段、概要设计阶段、详细设计阶段、编码阶段、测试阶段、安装及维护阶段。开发软件就如八股文一样：总体规划、项目立项、需求分析、系统分析、系统设计、编码实现、项目测试、文档制作（八股文：破题、承题、起讲、入手、起股、中股、后股、束股），一切都按部就班。同理，信息系统集成项目管理一般的过程分为：需求分析、项目调研、方案论证、实施方案、具体实施、测试、验收、售后服务。同时项目管理按管理的方式可以分为售前、售中和售后。 

  在国内，做的项目越多，就越容易产生这样的感觉：项目感觉总是做不完，就像一个“无底洞”。用户总是有新的需求要项目开发方来做，就像用户在“漫天要价”，而开发方在“就地还钱”。 实际上，这里涉及到一个“范围管理”的概念。项目中哪些该做，哪些不该做，做到什么程度，都是由“范围管理”来决定的。“范围管理”的相关知识，可以参考项目管理知识体系指南、项目管理九大知识体系的相关内容。这里只说说两点，核心需求和需求的变更。 

  一般说来，需求对用户来说，可以分为核心需求和辅助需求。对于中国贪心的用户来说，功能从来不嫌多的。核心需求就是用户使用本软件是，一定会使用的功能，没有这些功能，会影响用户的忠诚度。辅助功能，就是用户可用可不用的功能。有了这些功能，用户更喜欢，没有这些功能，用户不会太在意，或者是可以容忍。同样一个软件，不同的用户，核心需求和辅助需求是不一样的。在一个项目产品中我们应该知道对方需要什么，自己要做什么，这是项目成功的基础所在。

  对于产品，因为用户是不确定的，确定哪些需求是核心需求，哪些是辅助需求，则比较难。但是如果定位合理，对定位的用户范围的特征分析得准确，则不是什么太难得事。但无论是产品还是项目，都必须考虑以下三点：1、对于用户提出的每个需求都要知道“为什么”，并判断用户提出的需求是否有充足的理由，并考虑由此而引申出来的问题，触类旁通，举一反三；2、对于用户提出的每个需求都要知道“为什么”，并判断用户提出的需求是否有充足的理由；3、分析由用户需求衍生出的隐含需求，并识别用户没有明确提出来的隐含需求（有可能是实现用户需求的前提条件），这一点往往容易忽略掉，经常因为对隐含需求考虑得不够充分而引起需求变更。

  需求确立后，重要的是规范化，文档化，可参考常用的需求建模的方法如数据流图（DFD）、实体关系图（ERD）和用例图（Use Case）三种方式。 

  需求的变更是不可避免的，如何以可控的方式管理软件的需求，对于项目的顺利进行有着重要的意义。现在，重要的不是限制需求的变更，而是让用户、销售、开发都明白，不管是哪种情况下变更，只要是造成变更的一方，都要背负相应的责任。这就需要一个明确的约束机制。在制定制度时，大家都可以参议，提意见。但只要制度确定了，就必须恪守这个制度，是制度管人，而不是领导管人。也只有这样，才不至于开发处于遥遥无期的状态，而到最后则草草收兵。

  本人认为，需求的确定可以分为三个阶段则比较合适，这样划分也涉及到计划、成本的管理，可参考后面的相关内容。

   一、 项目初期，用户、销售、开发三者，应根据WBS方法确定整个项目的整体需求，即最起码要确定WBS中最顶层的父作业，如需求一，需求二．．．．．． 并尽可能详细地确定需求地具体划分，如需求一.1，需求一.2，需求二.1，需求二.1.（1）．．．．．．对于开发周期比较长的项目，则可以确定每个需求开发开始的大概时间，周期比较段的项目，则只需确定整个项目的开始时间即可。对没有确定的需求，则要明确在开发前一个相应的时间，必须在确定的时间之前来落实详细的需求。对已确定的需求则明确在开发前的一个具体时间内可以修改的内容，主要是框架性的需求。

  二、项目开发前，核实项目的所有需求，应当包括详细的需求，并明确告知用户以后只能修改细节上需求，主要是操作上的需求。如果在以后要修改框架性的需求，必须受到一定的约束，所产生的成本必须为要变更的一方负责。如是因为开发的原因造成的，则增加成本纳入到项目的成本中；如因销售工程师因销售压力而盲目对用户作承诺的功能，则相应成本必须纳入销售成本中；确定落实需求后，进行项目的开发阶段。

  三、项目开发完成后，提交给用户试用。用户使用后，用户明确要修改的内容，主要范围是操作上，细节的实现是否与需求一致，是否与用户真正需要的一致。如要对框架性的需要修改，则必须按先前的约束条件进行。确定修改内容后，向用户明确，以后的修改内容都只能局限于当前提出的修改范围，当然，程序出错除外。开发进行修改，用户使用，将修改范围进一步缩少。一次或多次迭代后，项目完成。
 
  V. 工作量的估算及评价

  项目管理最大的难度，就是每一模块的工作量、开发时间的确定，这也是项目实施的主要风险，最难预测、控制的风险。
  比较常用的估算方法有：估计项目交付日期的方法有很多，如基于经验的估计、基于模型的估计等。一种简便易行的估计方法是采用Wideband Delphi估计方法，此方法可以降低不同人员所作估计的偏差。基于模型的估计方法则包括KLOC、FPA以及COCOMOⅡ等模型。在这里主要引用新的估算方法，以供参考。

  如果，公司有着类似项目实施的丰富经验，则工作量、开发时间的确定则会更切实际。

首先，提取公司内部数据，统计出类似模块的工作量（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. 计划的编排

  有人这样形容计划的，“计划，计划，纸上画画，墙上挂挂，计划不如变化，计划不顶领导一个电话。！”。根据美国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号后才知道要完成这项工作的，自然就无法按时完成拉。这样的例子还有很多，不胜枚举。 

  二、对计划的编排要做到有粗有细。

  传统的计划编制是这样的：首先对项目进行估算，粗算出项目的总体进度。然后进行精化：确定概要设计阶段、详细设计阶段、编码阶段、测试阶段、安装及维护阶段等阶段的具体要求、完成时间、投入人力物力，并确定几个关键阶段。这些关键阶段的要求进度必须在指定日期之前完成。最后充分考虑影响项目计划的因素，并做出相应的措施，做出项目进度表，列出在每个阶段的难点要点，要注意的问题。，并将需要分析阶段的内容和项目计划、进度表整理成文档，分发到相关人员手上。

  这样的计划编制，在土木工程等运用项目管理比较成熟的行业时，还算相当成功，但具体运用到软件开发上，很多时候，就会出现变形，走样。例如有些计划，真是很细致，很细致，甚至细分到小时，分钟。这样的计划很难执行，只要外界有变化，或者前面的计划出现误差，则这个计划就完了。有些计划，很粗，很粗，粗到只有时间点，只有大框架，没有具体的内容。在实施时，根本无法知道具体怎样做。这样的计划，一般被称为里程碑式的计划，比较适合领导对计划的检查。

  在国内，软件开发中，计划的制定，比较常用的方法为WBS方法，即将项目工作分解为更小、更易管理的工作包也叫活动或任务，这些小的活动应该是能够保障完成交付产品的可实施的详细任务。首先就是周密地做好范围计划编制；然后以项目进度为依据划分WBS，第一层是大的项目成果框架，每层下面再把工作分解，这种方式的优点是结合进度划分直观，时间感强，评审中容易发现遗漏或多出的部分，也更容易被大多数人理解。其中，这部分内容运用专门的项目管理软件比较适合。Microsoft的项目管理工具Project就可以自动为各个层次的任务编码，国内的项目管理软件中，同望EasyPlan不但具有自动编码功能，还可以在甘特图，单网图，双网图三种视图下快速编制计划图，并可对计划、资源、成本费用的优化，进行跟踪比较，盈余分析等等，是一个不错的软件。 

  但是，WBS方法的前提是，对软件开发所涉及的业务要比较熟悉，有多年的经验；要求涉及人员的流动性小，管理模式要稳定。人对事物的认识是有一个过程的，不同的阶段有不同的认识。因此，对一个计划来说，计划前期尽可能细化每一项工作，越具体越好。对于以往计划执行得比较好得的公司，项目受到外界干扰比较少的项目，前期计划可以细化到日，或半天。对执行得一般的项目，可以细化到两天、三天或一周。对执行得比较差，或者容易受到外界影响的项目，如项目组成员要经常出差，或支援其他项目，或者要中断进行前面项目的维护工作等等，可以细化到旬、半个月，最好不要超过一个月，否则计划失去其本来的意义。对计划后期工作的制定，则可以比较粗些，用以适应前期计划执行情况造成的变化。

  当然，这样的计划，也要避免采取每周制定下周工作计划的逐周项目计划方式，避免“项目失控合法化”。项目计划的Breakdown或曰“粒度”，是一个需要小心把握平衡的问题。越细则控制力度越大（笔者曾见过细到0.25小时/人的），但项目管理的成本越高；反之亦然。以国内目前的状况，个人看法，项目的周期越长，应越粗。项目周期为三到六个月的，可以粗到一周或半个月。周期为一到两年的，则可以粗到一个月，一个季度。无论多大的项目，应该也不要超过半年。 

  三、关键线路的制定。一般来说，先确定关键工作，整个项目的关键线路。然后，确定非关键工作。最后通过甘特图（横道图），网络图（单代号网络图，双代号带逻辑时标的网络图）找出自由时差、总时差，并通过缩短关键线路的工期来对项目进一步优化。在这里，最重要的，关键线路的资源，即关键线路中的关键工作是由哪个开发人员负责。现在的项目管理工作中，存在这样一个误区，整个项目的关键路线通常是由一两个开发精英、骨干、核心来承担。这样存在很大的风险。当开发核心在项目中途离职或者不得不暂停开发工作，如生病，出差等，会造成整个项目延误，而其他开发人员窝工。同时，一个人长期处于高压下工作，当前工作延误了，导致整个项目的延误；下一个工作延误了，又导致整个项目的延误。反正已经连续延误了，就无所谓了，做到哪里就算哪里好了，整个人崩溃了，对开发计划确定的时间就放弃了，从而形成一人加班，全员加班。因此，一个好的计划，出关键线路合理外，还必须时关键线路有多个人员在不同时段进行承担，避免一两个人长期承担整个关键线路，同时，还要预料，还有哪些因素影响，使某些非关键工作会上升为关键工作，成为关键线路，影响整个关键线路。