作者：CppExplore 网址：http://www.cppblog.com/CppExplore/
一 项目管理流程
1 项目定义
在有限的时间、有限的人力、有限的资源内，完成即定的功能，并保证项目的质量。
项目具有时效性/资源受限，功能边界明确等特点。
项目失败，并不仅仅是指项目的功能没有完成。超时/超支都算做项目失败。
2 项目管理目标
可重复：项目的成功性可复制。一个项目成功，另一个项目也可以成功。成功不是偶然性。
可管理：项目本身可管理，成功过程可控。
3 项目生命周期
项目具有固有的生命周期规律，项目管理需要遵循该规律，不要过分重视产出（压缩时间），否则影响长期的稳定的产出（同样体现项目管理的可重复、可管理）。
项目生命周期分：需求意向 需求阶段 开发阶段 测试阶段 维护阶段。下图给出一个模拟示例：
其中需求结束、开发结束、版本正式发布（测试结束）均为里程碑。
4 参与项目的角色
参与项目的主要角色有：项目管理人员/需求人员/研发人员/测试人员/配置人员/实施人员。他们分阶段进入项目，分阶段离开项目。下图为人力投入示例：
其中需求来源发生在立项之前，不予考虑，另产品人员需要参加需求文档review，属项目外，不考虑。
项目管理人员需要全程跟踪项目，尤其是立项点、需求文档review、需求结束、设计文档review、设计结束、测试期间以后进入维护期后。
需求人员除需求阶段，还需要参与设计文档review、测试文档review。
开发人员除开发阶段，还需要参与需求文档review，以及测试期间bug修复、维护期保留部分人力。
测试人员除开发阶段，还需要参与需求文档review。
二 项目阶段
1 立项
立项初期，更多的是资源申请、人力安排计划等。尽量减少以后的沟通成本，比如确定项目编号、阶段编号、功能编号、模块名（如果能够确定）、各模板版本号格式、系统部署的软硬件平台等。
2 需求阶段
该阶段是项目最重要的阶段，代表了项目的使命。该阶段的产出需求文档则是项目最重要最核心的一片文档，是设计文档、测试用例以及后期维护的依据。
需求文档的用语应该是明确的、无歧义的。比如 “包含...但不限于这些...”、“这些功能请研发人员灵活掌握”“请参考某某网站/请参照某某项目的样子”都属于不合格的用语。
需求文档整体内容应该是封闭的，不依赖于任何未知的内容，引用的外部文档需要嵌在需求文档中，或者给出文档号，可以在团队的文档库中查询到。为更好的理解需求文档的封闭性，举例说明，比如要实现sip栈， 需求文档应该给出sip协议的介绍以及做到什么程度，研发不需要自己去看rfc文档， 只需要参照需求文档去开发即可。另任何业务上的知识盲点， 需求人员都要给开发人员解决，开发人员在任何时候(需求文档review中或者设计文档中或者开发中)发现业务知识盲点，都可以反馈给需求人员，要求给予支持或解决。
需求文档需要明确定义系统的功能边界、系统的网元划分、各个网元的外部特性。这里给出一个大体的提纲：要实现的功能点、网元划分以及最后的部署方式、每个网元的功能点、复杂网元的内部模块图建议（可选）、网元间通讯接口、各网元间的交互时序图、各个网元如何和其他网元交互完成前面的功能点。
其中各网元的交互时序图需要能涵盖网元间所有的交互，简单的重复的交互也可用文字描述补充；网元间的通讯接口是明确的，每个命令中的字段名、类型、取值范围都需要明确。
其他方面，比如性能要求、其他非功能性要求等，如果外部需求方有明确要求，可写入文档，否则可象征性写一个一定可以满足的值或者省略这部分（性能本身依赖于团队的积累）。
在需求文档review阶段，产品人员可以审核考量是否已经满足了预期的功能；开发人员可以审核考量是否已经明确了自己负责的模块特性，是否不再需要和其他模块的开发人员沟通确认某些接口上的问题；测试人员审核考量是否可以依据此写出测试用例，不需要再向开发人员确认。
最后需求文档defect入库、文档本身入库。
3 开发阶段开发阶段可以细分为设计文档阶段、编码阶段、测试阶段。其中重要的是前期设计和后期的测试阶段。
设计文档中，开发人员要从各个角度向别人展示自己的系统，包括部署图（在网络中的位置）、模块图、数据流向图、
静态类图、交互图、状态图 关键数据结构等，最终需要能体现需求文档要求的功能。
研发测试阶段请参见
测试系列之 c++ server测试全攻略，
其中白盒测试、内存测试、压力测试必做，同时陪测程序需要和源码一并提交在版本管理工具中。完善的log信息和必要的陪测工具是系统质量的保障。开发阶段结束后，源码/二进制包上传、代码行统计、各种文档入库、defect入库。
4 测试阶段
测试人员的测试用例、结果必须文档化。专项测试需要包含以下部分：测试目的、测试方法、测试环境、附测试脚本、测试结果。
测试人员不仅需要测试系统，在实施和维护期间更要回答现场人员的咨询。
测试结束，各种文档入库、defect入库，用户文档产生、版本打标记或者打基线，作为以后开发的基础。
5 实施阶段版本正式发布，基本标志项目结束。实施人员将作为以后现场支持的Level1级，测试人员为Level2级，研发人员为Level3级，属于未实现的功能，转需求人员。
说下bug数量，一般c/c++代码每千行16-20个bug左右，研发和测试阶段按一定比例划分。bug过少，从某个角度可以看作测试力度不够，过多可以看作代码质量较差。任何时候，bug数量都不应当作为绩效考核的标准。
以上阶段中最重要的是需求阶段，其次是研发阶段的测试。
三 追求更好的项目管理流程
从某种程度上说，项目管理是一个团队的习惯。
一个好的项目管理习惯，可以让一个团队的运作如行云流水，又如微风拂面。团队成员各司其责，既是在工作 又何尝不是一种享受。整个项目管理，就象... （就象...最近装修，团购网上的标语：就象）喝茶那样轻松。即便是这个团队从公司脱离，在新的环境里也会保留以前的项目管理制度，从通讯企业里出走的团队很多这种例子。
而一个差的项目管理习惯，则是一个团队的噩梦。所谓的管理，可能流于形式，可能成为项目管理者的令箭牌，可能成为研发人员的催命符。
习惯的力量强大而可怕。不管是好的团队还是差的团队，遇到不符合自己习惯的改变，都会做出一致的决定：抵制。抵制的理由可能不同 ，有的是 我们现在已经运作的很好了，不需要做出改变，有的则是我们没有那个能力去实施这个流程/我们人员有限/我们控制不住。改变后也不见的运作比现在差，改变后也不见得会浪费更多的人力，反而会有序，更节省人力，更利于控制。
养成习惯需要3个前提：知识（知道这么做是好的）、意愿（愿意这样做）、可实施性（有明确的实施方法）。之后加上坚持，一定时间（21天）后就可以形成习惯。
看培养好的项目管理习惯就是这么简单，真的就象喝茶那样轻松。
四 团队技术积累 项目管理理论容易给人以错觉，好象只要有了规范的项目管理流程，就可以保证项目的成功可重复/成功过程可控制。但事实往往并不是这么如意。
项目管理的顺利进行依赖于团队的基础建设：团队人员组成、基础代码库、基础模块库等。没有完备的团队和一定的基础积累，谈不上项目得可重复与可管理性。
成熟的团队中，项目的主角是需求人员、开发人员、测试人员。需求是个迭代的过程，是在已有系统或模块上持续扩充的过程。开发是充实基础库与模块库，在已有基础代码库和基础协议栈之上实现业务的过程。测试是一个测试工具积累的过程。完备的积累是项目成功的可靠保证。
总体来说，项目管理和团队建设相辅相成，共同发展，公司在不同的时期，偏重不同，初期重团队建设，成熟期重项目管理。
五 具体问题具体分析
项目管理流程并非一层不变。针对项目的规模和复杂性，可分大项目、小项目、mini项目。有的项目很小，不需要写需求文档，可能只需要增加一个ChangeRequest，也可能不需要写设计文档。以保证小项目的灵活性和响应及时性。后期的补充正确区分defect和ChangeRequest。需求一定要递交到需求人员，以便其把握整个系统以及后续架构的走向。