【IT168 分析评论】

    软件行业从20世纪60年代开始操作系统的研发，到20世纪90年代中期行业快速发展。从原有的作坊式开发到目前团队协作完成，从早期的技术力量竞争到现有的项目成本控制竞争，从面向结构到面向对象再到面向服务架构，项目管理被提到一定的高度，如何有效的经营项目来降低风险、控制成本，确保项目进度流畅，在有效的时间内保质、保量的完成验收。成为不少项目管理人士的追求目标。结合个人项目管理实践，本人有几点管理注意事项与大家一起分享。

    开发模型确定

    一个项目的好坏，开发模型优良是项目成功重要保障，有了好的开发模型我们可以很好的控制项目进度、降低风险。所以我们在项目开始前首先需要确定项目的开发模型。这里我们建议采用迭代式的开发模型。我们知道原有早期传统的开发模型是一个文档驱动的流程，它将整个软件开发过程划分为顺序相接的几个阶段，每个阶段都必需完成全部规定的任务后才能够进入下一个阶段。项目开始首先完成系统需求规格说明书，之后才能够进入概要设计阶段，编码则在系统设计完成之后进行。这就意味着只有当所有的系统模块全部开发完成之后，我们才进行系统集成，对于一个由很多个模块组的复杂系统来说，这是一个非常艰巨而漫长的工作，且存在着潜在的风险。

    如：需求或者设计中的错误无法在项目早期发现，只有在系统交付客户之后才能发现原先对于需求的理解是错误的，系统设计的错误也只有在测试阶段才能被发现。

    对于项目风险的控制能力较弱，往往项目风险只能随着项目结束才能逐步降低，同时也只有经过系统测试之后，才能确定设计是否能够真正满足系统需求。

    软件项目常常延期完成或开发费用超出预算项目开发进度往往会被意外发生的问题所打乱，需要进行返工或其他一些额外的开发周期，造成项目延期或费用超支。

    项目管理人员专注于文档的完成和审核来估计项目的进展情况所以项目经理对于项目状态的估计往往是不准确的，当他回答系统已完成了80%的开发任务时，剩下20%的开发任务实际上消耗的是整个项目80%的开发资源。

    在传统的瀑布模型中，早期是无法发现，需求和设计中的问题，只有当系统第一次集成后，这些设计缺陷才会在测试中暴露出来，需求缺陷则需要等到系统与用户见面后，方可暴露。从而导致一系列的返工：重新设计、编码、测试，进而导致项目的延期和开发成本的上升。

    为了解决传统软件开发流程中的问题，我们建议采用迭代化的开发方法来取代瀑布模型。在瀑布模型中，我们要完成的是整个软件系统开发这个大目标。在迭代化的方法中，我们将整个项目的开发目标划分成为一些更易于完成和达到的阶段性小目标，这些小目标都有一个明确的阶段性评估标准。迭代就是为了完成一定的阶段性目标而所从事的一系列开发活动，在每个迭代开始前都要根据项目当前的状态和所要达到的阶段性目标制定迭代计划，整个迭代过程包含了需求调研、软件设计、软件实现、版本集成、软件测试、软件发布和产品交付等各种类型的开发活动，迭代完成之后需要对迭代完成的结果进行评估，并以此为依据来制定下一次迭代的目标。

    开发计划制定

    确定好项目的开发模型，一整套配套可行的项目开发计划是开发过程中进度控制的标准，同样是用户、公司管理层了解项目进展的依据。通常项目管理人员、需求人员和用户根据用户原始需求（可以是项目方案书或者是建议书），一起定义整个项目过程中的项目迭代过程个数以及每个迭代过程的开发目标和范围。