软件项目管理计划问题分析[1]

　　有人说“做项目计划，如同给一个待出生的婴儿写传记那样困难。如果允许项目结束后再写计划，那就轻松多了，并且可以 100% 地准确”。确实是这样，为什么项目的计划这么难呢？

　　在软件开发项目实践中，关于计划主要有以下一些常见问题

　　1、项目目标不够清晰明确
     
　　这实际上在软件开发项目中是一个普遍的现象。缺乏详细的工作目标以便在项目结束时验证是否取得了预期的成果。对于软件开发项目而言，在进度、任务范围、质量、成本等项目目标中，进度是最容易清晰明确的，也是用户最为关心的。不管是献礼工程或一把手工程，进度都是项目目标诸多方面中最先制定的，并且能够很快在招标文件或合同中订下来。当然，这种进度的合理性未必是经得起考验的。而统计数字事实说明，大部分的软件开发项目的进度是不合理的。无论是急于求成的客户还是缺乏软件开发经验和软件工程知识的项目经理都存在对进度过于乐观的问题，其原因较多是因为他们对项目范围的认识是在一种比较粗的颗粒度基础之上。大多数的软件开发项目在开始阶段可能存在项目范围不够清晰的问题，需要经过需求调研之后才可以清晰。质量目标是最不容易清晰和明确的，这主要是因为软件系统的质量量化比较难。由于质量目标的不确定性，它在进度、成本、范围等目标的压力之下就很容易被忽视。这似乎说明了，质量目标是这些目标中最不重要的一个，最有可能被牺牲的一个。成本目标可能用户方面不太关心，确实软件开发组织最为关心的，软件开发的成本主要是人力资源的成本，其他的设备基础设施都是可以重复使用的。所以，在进度、任务范围、质量明确以后，人力资源的成本就可以经过经验等方式估算出来。

　　2、对编写计划的过程在思想意识上重视不够
     
　　实际上是对项目计划的重要性认识还不够充分，虽然大家都知道知道“作计划”很重要，是项目成功的关键，但又认为计划就是写文档，也许是因为一些人善于写程序但不善于写文档，所以有些项目经理会认为写文档是一种走形式，或对繁琐的文档有一种排斥心理。其实不能把计划当成仅仅是写一个计划文档的问题，而是要通过编写计划文档的过程，理清项目目标、项目范围、项目所需资源、制定合理的项目进度、制定完成项目所需的各种约定（沟通、变更）、制定应对风险的有效对策。对于这一问题的解决，首先应当提高项目经理的计划意识，采用项目计划制定相关各种知识、技术、工具，加强对开发计划、阶段计划的有效性进行事前事后的评估与评审工作。

　　3、制订计划时没有进行充分的沟通 
  
　　项目经理制订计划时没有和项目主要成员和主要项目干系人共同讨论协商，达成共识；或者最终计划没有发布到所有相关的项目干系人，取得他们的认同、理解，最重要的是对计划中共同责任、目标和各自责任、目标的承诺；由此而造成的后果是项目计划缺乏项目组成员的支持，没有成为项目组成员的共识，没有使每个项目组成员努力实现在项目计划中所作的承诺。因此项目经理制订计划时首先要分清或确定主要项目成员和主要项目干系人，然后与他们进行充分的沟通协商，使项目计划是一个大家都认同的，形成共识的有效文件。
     
　　一种更为严重的情况是遗漏了重要的项目干系人。在制定计划时没有考虑到所有项目干系人，特别是那些对于项目的成败有重要影响的项目干系人，在制定计划时要和他们进行充分沟通取得对项目进度、资源、验收标准等计划的共识和保证。

　　4、对总体计划、阶段计划的作用认识不足
     
　　项目经理认为计划不如变化快，项目中也有很多不确定的因素，做计划是走过场，因此制定总体计划时比较随意，不少事情没有仔细考虑，或者是有一种等一下再说的想法；阶段计划因工作忙等理由经常拖延，造成计划与控制管理脱节，无法进行有效的进度控制管理。那些号称“所见即所得”的OA，边做、边提需求、边改、边完善的“四边形”的所谓“快速”软件开发也可能竟然是本企业周期延续最长的项目，因为无休无止的需求变更而永无止境。从项目的计划阶段来看，因为边做、边提需求、边改、边完善，所以他们首先就对计划没有信心，基本上计划对他们来说只是应付，久而久之，对计划方面的锻炼意识不如其他项目，甚至养成不容易改掉的习惯。

　　5、任务和职责划分不够清晰或有遗漏
     
　　目标、任务的分解不够清晰、工作有遗漏，没有确定项目组成员职责的差别，如程序员的职责都笼统地写成“编码”。其主要原因是一些新任的项目经理是由程序员提拔起来的，不太熟悉软件工程各阶段工作职责中某些具体工作的分配，无法按任务分清每个人的责任。如应该分清楚需求人员该做什么、设计人员该做什么、编码人员该做什么、测试人员该做什么。责任似乎很容易分清，但大家却经常听到“这是需求的事”、“这是设计的事”这样的争论，严重的造成项目组内部的纠纷扯皮。就是因为这些新的项目经理对一项具体工作，如界面设计、数据规格等应该由需求分析人员来做，还是设计人员来做分不清楚，还有就是做到什么程度算概要设计，什么程度算详细设计，职责上也要搞清楚。建议新上任的项目经理应该多学习软件工程的相关知识。

　　6、项目任务分工或进度计划表的颗粒度太大
     
　　常见的现象有对任务持续时间进行不切实际的估计；或未考虑到任务的相互依赖关系而造成遗漏工作。其主要原因是软件工程的分析与设计经验的不足，无法细化系统需求，并从需求推导出设计，根据设计去分配任务。根据细化的需求也可以分配任务，但是由于需求中的功能点和设计中的模块往往不是一一对应的，如一个需求功能点需要一系列的模块来实现，多个需求功能点也可以共用同一组模块加上不同的设置参数来实现。所以根据设计来确定程序代码阶段的任务分配比较合理。需求是整个项目的基础、需求的清晰颗粒度对后面的工作及工作计划的准确性至关重要。项目计划的准确度是以一开始以需求（包括设计层需求）为基础得出的工作结构分解的完整性、清晰性为基础的。如果没有这个基础，项目计划就不可能做得很准确。在无法准确制定项目计划的情况下，对其风险要足够重视，并制定出具体可行的对策。如果对整体的需求或工作结构分解无法一次完整的清晰，就应当把它先分解为几个大块，分块进行，已经清晰的先制定本块（阶段）计划，下一环节的工作也可以开始（分块）进行。再项目开始阶段往往还没有得到详细的需求成果，因此根据项目计划渐进明晰的特点，在需求调研分析阶段过后，需求成果清晰是，应当及时细化项目计划，在概要设计完成时，要更进一步地细化后面编码测试阶段的详细计划。

　　7、与上一种情况相反的是计划表的颗粒度太细
     
　　就是说软件开发的工作虽然可以被划分为若干阶段，但是这些阶段不应该是整齐划一的。虽然每个环节阶段成果是下一环节阶段成果的基础，但即使在阶段成果通过评审之后下一环节对上一环节也应当随时进行检查验证，上一环节根据下一环节的验证检查情况进行调整。在上一环节没有得出可以供下一环节开展工作的基本成果时，下一阶段的投入可能是浪费时间。“按任务分清每个人的责任”并不是说上一环节的人员在初次完成本环节后交给下一环节就了事了，而应该继续与下一环节的人员共同作战、相互影响、不断进行同步完善,及时地解释和调整上一阶段的成果。如果上一阶段与下一阶段的负责人是同一个人，就没有这方面的问题，但是在实际工作汇报时要考虑到在某个阶段可能进行着前一个阶段或后一个阶段的工作。

微信扫一扫实时了解行业动态

微信扫一扫分享本文给好友