软件开发项目管理计划的8大问题分析 2010-07-17 清华领导力培训 推动创新网

项目管理计划是其它各子计划制定的依据和基础，它从整体上指导项目工作的有序进行。项目经理必须运用项目整合管理技巧，因为需要来自项目管理知识领域方方面面的信息。本文就软件开发项目实践中，关于计划主要有以下一些常见问题展开论述。

项目管理计划是项目的主计划或称为总体计划，它确定了执行、监控和结束项目的方式和方法，包括项目需要执行的过程、项目生命周期、里程碑和阶段划分等全局性内容。项目管理计划是其它各子计划制定的依据和基础，它从整体上指导项目工作的有序进行。

在软件开发项目实践中，关于计划主要有以下一些常见问题 1、制订计划时没有进行充分的沟通

项目经理制订计划时没有和项目主要成员和主要项目干系人共同讨论协商，达成共识；或者最终计划没有发布到所有相关的项目干系人，取得他们的认同、理解，最重要的是对计划中共同责任、目标和各自责任、目标的承诺；由此而造成的后果是项目管理计划缺乏项目组成员的支持，没有成为项目组成员的共识，没有使每个项目组成员努力实现在项目管理计划中所作的承诺。因此项目经理制订计划时首先要分清或确定主要项目成员和主要项目干系人，然后与他们进行充分的沟通协商，使项目管理计划是一个大家都认同的，形成共识的有效文件。

一种更为严重的情况是遗漏了重要的项目干系人。在制定计划时没有考虑到所有项目干系人，特别是那些对于项目的成败有重要影响的项目干系人，在制定计划时要和他们进行充分沟通取得对项目进度、资源、验收标准等计划的共识和保证。

2、对编写计划的过程在思想意识上重视不够

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

3、项目任务分工或进度计划表的颗粒度太大

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

4、对总体计划、阶段计划的作用认识不足

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

5、遗漏重要的假设或约束条件

如一些政府机关的管理信息系统软件开发项目隐含的需求是必须遵守一系列的国家和行业标准，但由于没有考虑到这些要求，致使项目管理计划失败，开发出某些功能、性能或数据不符合国家和行业标准的软件，造成返工。所以应当尽可能地将将任何设想和约束编入文档。做项目管理计划时应该尽可能地把假设条件和约束条件考虑清楚，这些假设和约束可以是乐观的、悲观的或者是最可能的估计。例如，可以假设能够及时获得应用程序服务器的新发行版，或可以得到熟悉项目正在采用的技术和技巧的开发人员；还可以假设，项目能在一些约束下工作，如影响计划的强制截止期限或资源限制等等。应该把这些假设和约束条件编入计划文档中，在项目的实施过程中，当项目管理计划需要细化和调整时，就应该考虑到

这些约束条件，而不是以一种“无限资源”的方式做计划。一般来说，假设、约束和风险的区别是假设、约束是一些比较明显、明确、已经发生或肯定会发生的情况，而风险这是不一定会发生的，具有不确定性。

6、项目管理计划没有突出重点

软件开发涉及到方方面面的工作，有些是主要的，有些是次要的，项目管理计划应当反映有价值的工作任务、环境条件。项目管理计划不能写成一个大杂烩，也不能写成一个包罗万象的百科全书。在项目管理计划中要简洁精确地反映对项目有价值的事情、任务和活动，避免罗嗦。项目管理的理论方法、成功的项目管理经验都是在实施项目时应该参考的。但是，每个项目是特殊的，具有“唯一性”的，一次需要为每个项目做专门的计划，选择适合的项目，适合的团队的方式和方法。

7、忽视次要工作任务对项目的影响

软件开发项目管理计划不仅要安排需求分析、概要设计、必要时的详细设计、系统实施和测试与维护等实际的重要工作，而且还应该安排项目中的支持性辅助活动，这些支持性辅助活动虽然不能成为关键活动，但是它们却对项目的进展又作重大的影响。这些辅助活动包括体系结构定义、文档评审后文档编写的返工甚至是需求调研的返工，测试之后的编码返工、系统交付、与软件复用相关的活动、项目组内沟通交流、休假和法定假日、培训和教育、团队成员的生活（如饮食、住宿、交通等）、项目规划、人员管理等管理活动、会议和回复电子邮件，等等。做项目管理计划时应当尽可能完整地列出这些影响项目的活动，或者按照固定的模板进行计划的制订，免得遗漏必要的计划内容。有时候，小的疏忽会带来大的问题，次要矛盾会成为或引发主要矛盾。例如，加班安排不当，会引起员工的厌倦甚至离职，造成软件项目的人力资源问题，从而影响项目的进度，甚至导致项目失败。

8、工作任务的分解不便于人员分工

在确定了系统构架之前应该考虑在编写文档的同时是否有些其他基础性的工作可以先做，如是否在需求分析的同时进行部分的系统概要设计；是否可以先进性技术预研，环境架构搭建、后台数据库框架搭建、软件系统框架搭建等等。迭代法使得在上一阶段的部分任务完成后，下一阶段的对应工作就可以投入进行。在确定了系统构架之前之后工作任务的分解都要考虑模块编码独立性、开发编码工作的负载均衡、编码进度安排优化、预防人员流动（如生病、其他更紧急的任务、离职等）对开发的影响一个好的项目管理计划同时应有助于减少项目组的压力和紧张，提高软件开发效率。

为了创建并整合一个很好的项目管理计划，项目经理必须运用项目整合管理技巧，因为需要来自项目管理知识领域方方面面的信息。与项目团队以及其他的干系人一起工作来创建项目管理计划将帮助项目经理指导项目的执行并理解整个项目。

第二篇：软件开发项目管理之我见

导读：项目失败只有一个原因：就是项目经理不合格。

不注重code人员,其实这是一个严重的错误。

问题不应该依赖由测试人员来发现，而应该由开发人员来发现。

软件的质量应该由程序员来保证的，而不是测试人员。

不要说项目的失败是因为新需求引起的,一个没有新增需求和风险的项目是不存在的。

代码阶段还有一个重要的工作就是做code review代码公开评审。

注意：这儿讲的项目失败与成功，是从开发的角度来讲的，运营是否成功不在讨论之列。

软件开发项目管理之我见

陈仁奇 chendiy @ sohu.com

一、开发管理

项目为什么会失败？为什么发布日期会一拖再拖？

项目失败只有一个原因：就是项目经理不合格。除非这个项目经理在项目开始阶段就已经提出来了这个项目会失败，或者是完全属于项目之外不可抗拒的原因导致失败。

看到这儿项目经理也许不服，您请继续?

新增需求的原因导致失败？客户会让你新增100个需求而要你二天交货吗？必然是分析设计阶段没有充分考虑好可扩展性和新增需求导致现在不可控制而失败的!

程序员人力不足导致？人都没有到位，怎么会失败，多少人做多少人的事，多少人做多少人的计划，不会有失败。 程序员技能不够？项目经理是如何面试的？怎么在项目失败了才发现是程序员技能不够？有问题早提出来嘛。 测试人员没有做好？少来了，测试人员只是加了一道保障证明。程序很多流程都通过不了，程序还属于开发调试阶段，与测试人员有什么关系？

我在国内参加个大大小小好些项目，有日本外包，华为外包的，公司自主研发的。发现有这样一个概念很多项目经理都没有搞清楚：什么叫开发阶段？我认为开发阶段最多只能包括单元测试这一部分。综合测试绝对不能属于开发阶段

了，也就是说不能到了最后验货阶段还有程序流程走不通，程序随便正常操作都会失败。程序随便正常操作都出现好多bug属于开发还没有完成，绝对还没有过单元测试阶段，离综合测试和验货阶段还早着呢。说明白点，还属于代码code阶段。

不懂程序设计的项目经理，往往不注重code开发人员,其实这是一个严重的错误。软件的质量来源于什么？由谁来保证？有的项目经理说是由测试人员来保证，就算测试人员的测试用例写得很详细，把需求中的每一个功能点都测试到了，那最后就没有问题了吗？当然不是，很多逻辑上的东西要程序员来保证不出问题的，而测试人员只是起一个验证的作用，问题不应该由测试人员来发现，而应该由开发人员来发现。也就是说，我们尽量不要让测试人员来发现问题。如果第一次测试有至少25%以上的用例通不过，那说明质量监控出了问题。这样的版本根本就不应该拿出来进行测试。由此分析，软件的质量是由程序员来保证的，而不是测试人员。

细细说来!

一个项目的成败与否，与项目的各个阶段皆有关系：需求都不清楚，开发起来

肯定是南辕北辙；分析设计不够好，会让编写的难以维护，随着新增需求的增多，

会导致整个系统混乱不可控制；编码不好，整个系统不稳定是必然的，Bug也是抓不尽的；测试不做好，系统是没有保证的，少了哪个环节都不行。

项目管理，我认为重点主要放在 项目计划(plan)，进度监控(progress control)，质量监控(quality control)，风险预测(exposure rating)这四个方面。不要说项目的失败是因为新需求引起的,一个没有新增需求和风险的项目是不存在的，承认这一点之后,我们就不会有很多怨言了。

以下从上面提到的几方面进行详述：

项目计划：没有项目计划，那失败还有什么话好说？大家都知道凡事预则立，不预则废。项目计划一定要包括这几方面的内容：各阶段里程碑时间点，各个里程碑的输出结果，风险预测，意外应对。计划一定要提前于交货时间计划，风险意外是否留下时间和应对处理方案？

进度监控：对每个阶段把握好，每个阶段要完成的任务一定要完成，如果完不成，是什么原因导致的？我们的应对策略是什么？我们要信任别人，但是不要忘记锁门。同样的，别人说完成了，你不能就认为别人完成了，要看到结果才能证明完成了。有的项目经理说，我也进度监控啦，他说完成了就完成了，谁想到没有完成？到底是程序员不诚实还是项目没有管理好？你没有锁好门，能怨别人偷你东西吗？还有一种情况就是不懂如何锁门――根本就不知道这一阶段的输出结果是什么？当然进度监控就是一句空话了。

质量监控：也应该是分阶段进行的，每一个阶段的质量监控内容有所不同。

需求分析阶段的质量监控就是完整而又正确的理解用户需求，需求是否清楚可懂，写用例的测试人员是否明白需求？

分析设计阶段的质量监控就是设计是否完全满足需求？这个设计方案是否满足以后新功能的扩展？以及是否有考虑到新功能的意外和设备环境，运行平台的变化？

编码阶段的质量监控就是变量命名是否规范？代码是否可读？是否有详细的注释？是否有重复代码？要知道重复代码是必然会造成系统不稳定，bug成群的。可变部分的代码和不可变部分的代码是否分离。要知道上面讲的每一部分如果没有做好，都会导致后期的产品出现大量问题。代码阶段还有一个重要的工作就是做code review代码公开评审，你自己发现不了的问题别人也许就看得见。

单元测试阶段的质量监控任务就是单元测试代码是否测试通过？代码覆盖是否完全？单元测试报告提交情况如何？单元测试用例有没有做好？

综合测试阶段质量监控任务当然就是看用例是否完全？是否全部真正执行？测试报告有没有写好？

回归测试当然得看以前测试的Bug是否还在，如果还在，当然是无条件打回去重新开发。

测试阶段最主要的监控就是看用例是否真正执行，是否有安全性测试？破坏性测试？异常测试，压力测试？

项目管理表：

以上的每个阶段最好完成了才进行下一阶段，否则会造成混乱出现问题的。想并行进行节约时间反而浪费了时间！

二、公司产品管理

是不是一定要每个阶段完成了才能够进行到下一阶段呢？其实项目细分还可以分为“项目”和“产品”，当然，一个项目可能包含多个产品，一个产品分为多个项目。在这儿，产品好比的是一本书，项目好比是其中的一个章节（文章）！当然了，写书的人远远没有写文章的人多，上面讲的是项目的管理细节问题，下面再谈到产品的开发。

其实一个公司在开发一个产品时，由于产品的复杂性，功能太多而不确定性，如果每一个阶段都能够分析清楚再开始做下一步，这个产品的开发可能变得没有意义。所以在大多数公司开发产品的时候，都是先按照确定的需求来，当要增加新功能往往要等到下一个版本。想要一次就做到大而全是不现实的，因为人总是在进步的。

谈到产品，要保证产品质量，就到谈到公司的软件开发相关方面的制度。我认为一个公司的在开发方面的制度以下这个几个方面是非常重要的。

1、编码规范

编码规范是相当重要的，一个好的编码规范可以做到零注释！既然可以做到零注释，那我们再加上注释，不就是锦上添花双保险？维护人不更是轻松了很多？

无论你采用什么语言(C、C++、Java、.net、php、vb.net等)，建议采用Java命名规范，千万不要采用匈牙利命名法。在如今普遍使用智能IDE的情况下，如今已经公认的最优秀命名规范为前者，后者已经被无数次证明为垃圾！建议变量所有单词为全拼，毕竟东方人的英文水平天生不如以英文为母语的国家。Cfg也许都知道是“配置”的意思，但config来得更明显。当然都有特例（在极少的情况下用需要采用匈牙利命名法和单个字母的变量）,值得说明的是，千万不要禁用goto语句，在意外失败的情况下goto again是相当不错的手法。

2、公用类库

一个公司一定要有自己的公用类库，而且还要有一个兼职管理员！因为我们在开发的过程中会发现，往往在开周期超过一个月的软件项目中，至少会有50%的工作是重复的！也就是以前或者以后会碰到！真正变量的东西是很少的，大部分的时候都是以前碰到过类似的开发过程。把变化的和不变的代码分开，在公司层上应用就是公用类库。

我以前服务过的公司，还几乎没有见到过有自己公用类库的公司。

采用公用类库的好处至少可以提高二倍的工作效率，运用得好，随着公用类库的积累，提高10倍的工作效率都是比较容易的事情。我编程的时候，有时候如果不采用公用类库，可能至少需要1个星期以上时间才能够搞定的工作，采用公用类库后，可能只需要几分钟。而且不需要测试，更稳定，更健壮！

公司平时可以把贡献的公用类库数量作为考核标准之一。

3、公用框架（公司框架Framework）

一个公司的业务可能局限在一个行业，而市场上的开发framework是针对各行业都适合的，那针对某个公司的行业，就一定还有优化的地方，建立适合自己公司的简化的开发框架，保守估计可以提高30%以上的开发效率。国内的No.1华为就有自己的开发框架！

尽信书则不如无书，同样，尽信我不如我！任何规则都不是绝对的，先学习规则，然后再活用规则！ 欢迎各位同学就此论点进行讨论，发表你的任何观点(赞同,反对)，我的联系邮件: chendiy@sohu.com