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

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

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

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

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

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

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

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

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

　　同时，因为项目经理是协调型角色，没有足够的power，使得过程中各部门各自为政，一些上下层软件接口、硬件联调问题定位等事情迟迟不能落实。项目经理 做的工作，更像一个汇报员，把各组实际情况

[1] [2] 下一页