软件项目管理中的十个误区 阅读笔记

误区1：在项目的需求分析阶段，开发方与客户方在各种的问题的基本轮廓上达成一致即可，具体细节可以在以后填充。因为无论开始时有多么细致，以后对需求的修改几乎是必然的。

。(范围的核实和项目验收都要根据范围基准进行。因此前期的范围说明书和范围的基线至关重要)

笔注：本人实际项目采用敏捷开发模式，特点为可及时对变化的需求做出快速响应，但项目初期仍尽可能的把需求细化，包括前期调研、需求沟通、书写需求分析说明书、产出相应的原型界面文档。同意要划定需求范围，并且把需求尽量做细，对后续沟通和进度控制是大有益处。确实，就算需求再细致，也会有变化，即使以很细的粒度做了前期需求，并产出了原型界面，在开发进程中仍存在需求变更，甚至在用户测试后，也会出现需求变更，但细致的需求，是需求范围的划定、项目排期和后期有效沟通的前提。

误区2：软件项目的需求可以持续不断的改变，而且这些改变可很容易地被实现。

。(不应该称为误区了，现在估计谁都不会认为需求可以持续不断改变)

笔注：需求分析阶段，开发人员应能从实现角度对每个需求点的代价进行有效的预估，对于可能引起巨大变更代价的需求点一定要跟客户方确认清楚，在项目周期中产生的任何需求变更，不应引起项目交付时间的巨大波动。

“在软件版本发布以后，甚至可能要花费60-100倍的代价”，项目开发周期应有效沟通，在约定的规则秩序下进行吧种情况还是应该努力避免。

误区3：软件程序主要由代码组成，因此编码阶段是整个软件项目的最重要的阶段，应该给与大量的时间，并且集中主要的资源。

。(这个跟软件项目的规模密切相关。对于规模小于2万行代码的，或者说采用敏捷或快速开发的，或者说架构已经确定的改进型 项目，编码时间至少要占30%；而对于源代码规模超过50万行的大型软件项目,重点则是在需求和系统设计上面，编码时间一般为10%)

笔注：系统总体和详细设计如果做得细致，书写设计文档的过程，就是代码实现脑内的过程，实际动手的编码工作即可很快完成。目前项目每个功能点都要求产出系统详设文档，对梳理思路、提高效率和后期维护都有意义。

误区4：为了便于代码的维护修改，在系统的详细设计阶段文档工作应该做到写出所有程序的伪码。

。(应该深刻理解源代码就是设计的一些重点观点和思路，因此详细设计输出的代码模型一般是不抛弃的，编码人员可以直接在该代码模型基础上进行编码)

笔注：详设文档应能描述清楚功能点的实现流程、设计思路、代码结构、类图、数据输入输出情况、数据模型、关键算法等。认为如果详设文档能做到满足开发和后期维护，不必要拘泥于形式，花费不必要的时间代价。

(估计很少有人这样认为，所以不应该称为误区)

笔注：项目组内一直在强调开发人员要重视自测、加强自测，甚至要进行组内互测，这个问题是不言而喻的。

。(干系人管理很重要,同时CMMI强调的集成项目管理也说明了这一点)

笔注：嗯，项目管理环节中没有任何孤立的个体，一定是环环相扣、整体相连。

误区7：在开发进度滞后的情况下，可以聘请更多的程序员加入到开发团队中，通过增加人力资源来赶上进度。

(可以辩证的看，组织的成熟度越高，复用越高，该方法才是可能的方法)

笔注：从我们的项目来看，虽然项目的业务领域深度很深，但从项目开发模式和系统的架构设计情况来看，对新手来说应不难融入，之前也有成功的例子，不过当然也要考虑新人自身的学习能力和适应能力非常好的因素。

。(这里跟工种无关，更相关的是效率和产出,但去很难推行)

笔注：如果一个项目经理不仅具备项目团队整体把控能力，同时兼备整个项目技术支撑的能力，这应该是最好情况。如果由于各种原因，实际项目中不是这样的情况，那么项目经理应能尽量做到本分，比如有效的组织团队，在开发和客户方之间进行各种有效沟通，尽量为开发团队扫除障碍，使其专心于开发进程，同时从项目进度大局考虑问题，从待遇和工作实施方面均为技术骨干提供空间，使其在宽松环境中施展能力，成为团队的核心和技术支撑，推动项目顺利进行。关于薪酬问题，这个是水到渠成的问题，对整个项目存在至关重要推动力的成员，作为不可替代或缺的存在，其自身价值是不言而喻，不管他是不是项目经理。

笔注：没错。看到这里有点不耐烦了，一直想着要去做FCFF核心模型的公式配置，不多说了。

笔注：从旁观者角度说，这个真是应该再给力点。核心技术骨干对项目的作用可不是提前几天交付那么简单。然后，以后想做这种问题的当事人呐。