【IT168 技术文章】

　　随着对工作的熟悉，开始感知项目管理，感受到自己的工作是受约束的，在和一个小团队一起工作。模糊认识到项目管理要界定需 求，再设定分解子目标，最后通过一系列规范、要求来约束项目成员保证任务的达成。但是，对项目管理的接触是局部的，并不清楚项目为什么是n个人，为什么要 在t之前完成，讨厌的文档工作和评审为什么要进行，项目结束了总结和奖金有什么关系。

　　后来，真正进入项目才开始了项目管理体验、参与和实施之旅。

　　首先，熟悉什么项目管理?

　　可以说项目是每个企业赖以存在的单元，同时项目的形式是多种多样的，它直接与每个公司的项目组织结构相关。刚开始，我们每个初触项目的人并不清楚什么是标准的项目管理模式，会认为自己所面对的模式就是理所应当的。

　　我参与的第一个正式项目，是公司准备上市的一款新产品，我是其中的一名普通的研发人员。当时，公司指认了一个项目经理，然后从硬件、软件、测试、质量管理 等相关部门调集人力资源就可谓稀里糊涂运作起来了。一开始，整个项目没有明确的项目任务书和系统需求(所谓没有明确是指一些具体的软件规格并没有确切落 地，功能需求没有严格定义，这也给后续结项埋下巨大隐患)。回过头来，我才认识到这里面缺少了上一篇提及的那张项目管理图中的需求开发与管理环节。可以 说，这个环节在成本符合预算的情况下，做得越多越好、下的功夫越大越好，因为它是项目的根本--范围。实践证明，后来的项目过程但凡那些将功能模块需求详 细整理、认真评审、较好控制的模块都基本没有发生什么偏差。那些，或是因为没有认真或者没有足够能力分析需求、控制变更的模块，都成为了项目的短板。比较 可笑的是，这些模块的开发难度都不大，但都是用户必需的，这几个模块严重影响了进度，也严重损失了真个项目的奖金盘子。所谓，“坏了一锅汤”，当时很是生 气，其实那些是公司项目管理不够成熟的必然，大家一起积累经验教训了。

　　随之，项目的计划是在大领导安排了这个任务之后，由相关部门经理依据经验制定，项目经理更多是将讨论的东西落到纸面上。同时，可以说任务规模的估计是站在 都是成手的角度估计，项目计划并没有在团队内部认真的沟通、确认(确认很重要，是项目团队成员对自己承担工作的承诺。其实，到后来一些功能开发出现了延 迟，大多员工推卸责任说计划不是我确认的，没有考虑某某风险)。

　　由于是公司很重视的一个新产品，公司内部的动员、宣传做的比较好，因此即便是有很多现在看来还没有明确的情况下，项目便在大家的一腔热情下开始。我也是这 样。我先是负责某一功能模块的需求整理，于是我系统整理标准协议资料、又参考了一些同行相关产品的手册，搞出来一份洋洋洒洒的需求文档。然后满怀着热情提 交，等待确认开展后续工作。这个时候，忽然接到QA的通知，因为文档不符合模板、邮件发布未上载服务器不符合规范，如同浇了一盆水，小小抵赖一通(搞技术 的通常比较好面子，希望被认可，但事实上，QA的这种要求对研发人员非常有帮助，养成良好习惯能帮我们减少很多不必要的弯路。模板能帮助大家系统思考，避 免遗漏思考;受控更多是一个安全措施，后来一个同事电脑坏了因为没有及时上载，工作等白做，后悔不已)。

　　后续的工作更让大家士气低落，因为项目管理松散、没有明确的配置和过程管理计划，我这份需求的评审经过简单的评审就进入了设计开发阶段，也没有进行需求跟 踪矩阵处理。设计开发过程，我们发现一些需求很难实现、也没有明确是否必须，在和部门负责人确认之后就跳过去，没有进行正规的变更处理。结果，到了测试阶 段提出了不少需求上列出但没有开发的小问题，为此大家打了好半天仗。更头痛的是，在项目结束的时候产品经理对项目提出了更大的质疑，一些他认为必要的功能 规格没有完成，项目组提出“当初怎么没有在规格上写清楚”。总结其中的问题，经验是：变更一定要严格执行，也需要提前确认好变更委员会的成员。这里面，首 先可以方便需求的跟踪，避免漏测试;其次，这是一个很好的沟通渠道，使得大家在信息上一致、更早发现问题。

　　其他的功能模块问题也不少，主要是进度延迟的比较严重。后来才知道，项目还少了项目管理图中的milestone阶段评审环节。这个环节可以让领导、项目 经理、项目成员对前一阶段工作的工作成果给与审核(下阶段准入条件)，总结成功经验，分析风险问题。使得各相关人了解项目的现状，以及是否需要给与特殊支持。

　　同时，因为项目经理是协调型角色，没有足够的power，使得过程中各部门各自为政，一些上下层软件接口、硬件联调问题定位等事情迟迟不能落实。项目经理 做的工作，更像一个汇报员，把各组实际情况整理出来通报给大家与大领导。事实上，通报给大家，相信没人为最终工作去负责推动;通报给大领导，大领导日理万 机、又认为有项目经理和部门经理推动，哪里会真正管理。更重要的问题是他在项目管理手段上不够成熟，即便没有power，但抓住人这个主观因素多沟通，利 用个人影响力来保障团队的有效开展，同时保障固定不变的项目例会制度，专题评审与汇报制度，相信一定会收效很多。当时的我还只是沉浸在项目存在的各种冲突 中，频于奔命完成任务，感受到项目很不顺利，并不知道哪里出了问题(真正的问题是当时还没有明确的项目管理制度，更合理的项目管理组织结构，没有明确的授 权，立项阶段的不正规导致了项目从开始注定这样的结局)

　　当然，项目最终还是上市了，但周期延迟了半年多，整个项目组被各种问题、长期的紧张折磨得疲惫不堪。项目经理也因为项目延迟太多和个人原因离开了公司，去了朗讯。我个人与项目经理的关系还不错，第一听说pmp(戏说拍马屁)也是从他那里得知，到现在大家还有联系。

　　下面是项目结束时项目做的总结提纲，从中可以看到管理的雏形。

　　1. 概述 3
　　2. 项目总结 3
　　2.1 项目计划完成情况： 3
　　2.1.1 硬件模块(以调试完成为准) 3
　　2.1.2 软件模块(以代码提交为准) 3
　　2.1.3 测试(以测试报告提交) 3
　　2.1.4 项目变更情况 4

　　2.1.5 项目费用统计 5
　　2.1.6 人员工时统计 6
　　2.2 问题及解决情况 6
　　2.2.1 各次测试问题统计 6
　　2.2.2 硬件遗留问题和解决方案 7
　　2.2.3 软件遗留问题和解决方案 7
　　2.3 BOM成本估算 8
　　2.4 剩余工作及计划 8
　　2.4.1 硬件 8
　　2.4.2 软件 9
　　2.4.3 测试 9
　　2.4.4 转生产工作 9
　　2.5 COST Down的预计工作 9
　　3. 项目工作分析： 10

　　其次，从部分项目管理銎?-子任务计划安排与监控

　　后来，我开始负责一个小组的工作，在项目中开始接触WBS和自任务计划分解，尝试了DELPHI估算等方法。开始时，很多理念还不是很清楚，通过收集学习 项目管理的相关材料，多与项目经理沟通等方式，自己逐步熟悉起项目管理的内容。于是，从点走向了面。自己期待的项目经理角色正慢慢走来!

　　回想当初个人的项目管理入门学习基本是零星积累的，很不系统。我前段收集的《项目运作的一般流程》对入门同学很有指导作用，当初如果有这么个文章能少走很多弯路。

　　反过头来再看，it行业项目管理入门学习这两本书，理论上很受用的：一是国际项目管理协会(PMI)研制的“项目管理知识体系”(PMBOK)，二是美国 卡内基梅隆大学软件工程研究所(CMU/SEI)研制的“软件能力成熟度模型”(CMM/CMMI)。然后，在实践中锻炼，总结适合自己的经验。