这是前两年某个项目的项目总结，现在看来也有一定的用处，叙述了一个项目从拍脑袋管理到有序计划管理的过程，同时也解释说明了在项目中我们为什么必须要某些文档，全文如下：

此项目从2012年12月开始至2014年4月结束，项目时间跨度较长，项目组角色齐全，技术难度较高，总体来说为我提供了一个很好的实践平台，丰富了我的阅历，增加了我的经验。

我的项目经理生涯开始于2009年12月，此项目是我经历过最完整的一个项目，同时也是最规范的一个项目。项目中的需求、开发、测试人员都是专业的独立的人员，可以让我能够在此项目中充分的协调资源，按照我所设想的要求构建项目组。

在项目开始时，公司开始讨论是否引进CMMI模型，在项目中期，CMMI模型被完全引进，这也为我指明了一条完整的项目管理道路，使我可以参考成熟的项目管理体系来合理的管理此项目。

最开始，项目计划中只有大的时间节点，而且项目管理的手段单一，甚至缺失，所以最初项目中存在大量严重的问题：

1.   没有将工作划分到最小的颗粒度，预估出的耗费工时出入很大，无法准确的限定项目组成员所耗费的工时，只能盲目相信项目组成员的自主能力和承诺。

2.   没有固定的沟通方式和时间，如果项目组成员的反馈不够及时，很容易造成项目监管失控。很多情况下，沟通不畅，工程师遇到问题或者完成任务，我根本无法知晓。

3.   概要设计覆盖程度不够。国内旧的开发习惯都是编码的同时做设计，虽然在项目开始时我已经有意的摒弃这个习惯，但是化开冰山非一日之功。这就导致重构、返工这种延缓进度的工作出现。

4.   虽然项目开始时，开发部门已经有了一套编码规范，但是真正的实行时，还是遇到了很大的阻力，改变个人习惯是很困难的事情。

万幸的是，项目组的成员具备极强的能力和责任心，而且CMMI模型最终被引进，所以随着项目的进行，我们逐步解决了上述问题：

1.   周计划安排。

a)   最开始周计划非常简陋，在当时确切的说是今日总结加明日计划，先总结今日的工作完成度，再安排明日的工作。在推行之后，的确使我能够准确的知晓当天的工作情况，并且对第二天项目组成员的工作有了预估，可以方便进行调整。但是最大的问题没有解决，那就是我不知道某一个需要耗费数天的工作在何时能够完成，我将自主权最大程度的交给了工程师。

b)   后来CMMI培训时，我发现周报和工作日志搭配使用的方式比较好，我就在项目组内部开始推行。首先使用周报总结上周的工作情况，然后分配下周的工作，尽量保证工作的颗粒度达到最小，同时所有的项目组成员必须完成所分配的任务，并且每天需要将任务的完成情况以工作日志的方式提交。这就初步解决了最大的问题，最小颗粒度可以使我相对准确的预估工作完成节点，最大化的控制了项目成员的有效工作时间，同时每天我都可以了解到工作的完成情况，便于我即时发现问题。

c)   再之后，每周周报完成后，会开启周例会，对难以完成的任务着重点出，引起相应人员的重视；承上启下，对上周发生的问题进行分析，避免再犯，对下周的任务做统筹安排，项目组成员明确目标；自由的沟通，任何问题都可以抛出，避免潜在的风险。

2.   WBS任务分解。

在这之后，又遇到了新的问题。虽然近期内的任务可以完全把控，但是无法知晓这两周的任务完成情况和任务安排是否符合整体的需要，我只能知晓上周的情况符合了预期，我却不能知晓，这种预期是否可以满足最终工期的要求。所以我不得不重视WBS任务分解，不过由于在项目后期才开始引入WBS任务分解，所以只在两次迭代内使用过，但是不可否认的是，WBS分解帮助我明确了时间安排、识别了潜在的风险、有序合理的安排工作任务。同时帮助项目组成员了解了项目的生命周期，明确了阶段目标和里程碑节点。总之，整个项目组成员向着一个目标而努力的时候，总是显得有激情，目标也更容易达成。

3.   配置管理

a)   最开始我们只是使用TFS对项目的源代码进行了管理，当然这是必须的，否则就谈不上协同开发了。

b)   当我们开始补充文档时，我们又新建了一个文件夹将所有的文档上传了进去，这就导致这个文件夹里面充斥了各种文档，而且命名方式不尽相同。当项目组成员希望查阅某些资料的时候，很难在第一时间找到。

c)   最后我们按照CMMI的要求将文件夹细分，规范所有文档的命名方式，并且分类存放，最终解决了之前所遇到的问题。

d)   在项目中期，该产品已经可以看到雏形，这时我们又遇到了新的问题，每一次发布程序提交给测试后，开发人员继续开发，此时如果测试发现了问题，开发人员很可能无法重现该问题，因为代码已经被更改，甚至与上一次发布时的代码大相径庭。而且测试遇到问题时去查阅需求文档，来寻求印证时，也遇到过“需求文档”被更改，无法印证的情况。为了解决这个问题，在之后每次发布程序时，我们都会生成一个基线，保证将此次发布所有相关的资料全部封存，保持不变。

e)   项目后期，开始优化工作。版本发布的很密集，代码改动也很频繁，随着每一次的代码改动和优化工作的紧张进行，需要对修改的功能进行针对性测试，然后再做回归测试。但是在提交“送测单”时却不能准确识别哪些部分被修改，导致不能对被修改的功能进行针对性测试。所以，我们又建立了《版本代码改动跟踪文档》来解决这个问题，保证能够识别每个版本具体修改了那些文件，甚至于识别具体修改了那些代码段。

4.   系统设计

a)   在项目开始时，我识别了几个技术难点出来，分配到工程师，让他们去做预研，为之后的设计工作打下基础。事实证明，预研工作对系统设计具有指导性的意义。

b)   最开始核心的功能都进行了预研和设计，并且留下了资料，直到项目完成，底层的核心设计也没有被改变，这证明我们所做的设计是成功的，而且为整个项目奠定了基础。

c)   但是同时也发现了一些问题，比如缺少静态图和序列图，所以在编码的同时又做了设计，耗费了工作量；不能限定工程师的编码范围，工程师获取了过大的自由空间，导致很多代码被废弃；在回溯问题时，各函数和模块之间的互相调用，需要重新阅读代码才能再次了解，会耗费大量的无用时间。所以新的项目中，概要设计是必不可少的，而且静态图和序列图必须覆盖整体代码的90%以上，尤其是核心功能。

5.   其它

a)   代码走查被最早的引用到项目工作流程中来，并且发挥了重要的作用。通过代码走查我可以即时纠正开发工程师在编码时所产生的问题，帮助开发工程师养成良好的编码习惯；虽然缺少了静态图和序列图，但是最后程序的架构符合了我的预期要求，就是通过不停的检查、修改、再检查、再修改来实现的；保证了代码质量，限制了低级BUG的数量；最主要的是通过代码走查，使开发工程师的工作可以走在一条正确的轨道上，虽然走的时间有可能会有点长，但是终点最终是正确的，轨道是直的。

b)   在项目中，补充了大量的文档，并且让项目组成员意识到了文档的好处。文档就是我们沟通的记录，是我们达成共识的证明，保证项目组成员的有效沟通最大化，同时避免了项目成员之间矛盾出现的几率。

其实，我最应该感谢的是所有的项目组成员，因为他们突出的能力、极强的责任心、长久的激情才能保证项目能够最终成功，毕竟任何方法、任何约束都是由人去执行的，如果项目组成员的能力、表现不符合项目的要求，就是再强悍的项目经理，也难以保证项目最终达到预期目标。