一、需求管理

　　对于任何类型的软件项目，需求阶段都是最重要的阶段，需求管理是整个软件项目管理的重中之重。需求管理通常包括两个大方面的问题：需求收集分析与需求变更管理。

　　首先，对于需求收集与分析，核心风险来自于需求不明确。由于客户和软件开发团队的背景不同，对同一问题的理解自然存在差异。这些差异如果不能在需求的最初阶段尽量弥合，那么必然导致需求增加与需求更改。因此，在需求分析阶段，要求需求分析人员具有丰富的客户沟通经验，必须多花一些时间，充分了解用户的目标与工作过程，站在客户立场上，设身处地考虑问题，帮助用户将模糊的需求清晰化，将简略的需求明细化、完善化，将混乱的需求逻辑化、条理化。

　　其次，任何项目都无法承受频繁的需求变更与需求增加。因此，除了在需求收集阶段需要尽可能将需求细化外，还需要在适当阶段尽量冻结需求。公司的销售人员往往倾向于接受用户模糊的要求，并暗示用户“什么都好商量”。这往往给项目后期甚至项目完成后又频繁更改需求，甚至导致项目严重拖延、开支严重超出预算埋下祸根。因此，在需求细化的后期阶段，必须“拉下脸来”，就需求冻结和后期需求增加的费用支付方式和客户达成共识。

　　二、关注项目设计的灵活性

　　对于中小型项目，在设计过程中，必须关注设计的灵活性。在实际的项目中，即使在需求阶段花再多的经历，也没法完全避免开发阶段的需求变更。因此，在架构设计中，尽可能采用灵活的设计就至关重要。对于项目设计人员，可以借鉴RUP(Rational Unified Process)中基于组建的体系结构思想，利用基于独立的、可替换的、模块化组件的体系结构管理复杂性，提高重用率，构建有弹性的、能适应变化的、易于理解的、有助于重用的体系结构。

　　三、开发进度管理

　　开发进度管理，主要需要关注如下几个方面：

　　1. 任务分配、人力资源分配、时间分配要和工程进度协调;

　　2. 任务分解要合理，并且尽量并行化;

　　3. 对项目进度控制要尽量细致，并且在实际执行过程中审查要严格;

　　4. 针对项目中不容易控制的部分，譬如技术难点、来自于客户的时间拖延要做好充分的准备;

　　5. 要为测试、缺陷修正和预期的需求变更预留足够的时间;

　　如有必要，还应采用适当的协同进度管理工具。

　　四、开发团队管理

　　对于开发团队管理，要做到分工明确、因人施用。根据水平的高低，合理分配工作量。并且关注团队内部的交流沟通结构，避免“互相等”和“误解”。尽量让每个人的工作量饱和化。在项目开始以后，要尽可能保持团队稳定，避免人员变更给团队带来的协作混乱。

　　五、配置管理和SQA

　　软件配置管理(SCM)的主要作用是标识、控制、和状态统计。

　　这些功能的意图是维护和跟踪功能、配置、产品、产品基线、需求规约和其他文档的变更，软件版本的描述;跟踪变更申请，问题报告和解决记录，提供配置控件委员会(CCB)会议纪要等。

　　软件开发之后的变更需要从多个侧面加以注意:

　　1. 任何返工都是有代价的

　　2. 将资源用于返工则无法开展新项目 项目管理者联盟，项目管理问题。

　　3. 如果变更不能精确的标识和控制，那么软件的版本就会因为未知和没有记录的修改而无法跟踪

　　4. 如果变更没有考虑到所有的副作用，那么对于一个变更所引起的连锁反应的跟踪是非常费时间的

　　5. 变更次数的增加会使系统面目全非

　　当项目经常变更时候，SQA是非常重要的。SQA应该进行Pareto分析和趋势分析以确定引起变更的根本原因。SQA同时要保证系统的影响是可跟踪、可测试和可验证的。SQA的一个主要目标是在开发的早期发现问题，避免其进入下游开发中。

　　六、文档管理

　　对于小型项目，首先，必须有文档要求，否则后期的修改、维护、升级都会变得异常困难;其次，对文档的要求应该“适度”，即够用即可。一切以便于后续工作为目标，不做过于繁琐的要求，不应把大量精力投入进过于繁琐的文档编写。此外，还应注意文档的版本控制，保证文档和代码的一致性。