《项目管理修炼之道》阅读笔记（1）

学了七八年的软件工程，始终却一直停留在写代码的层面，即使到现在可以带领几个人的小团队，但是项目管理方面的经验还是非常少，经常都是面向功能编程，用户需要什么功能就加什么功能，最后下来很多的项目无法如期交付，虽然我作为开发人员无需承担这个风险和责任，但是也深刻意识到软件项目的项目管理过程是非常重要、必不可少的。

这一段时间，一边忙着公司项目，一边备考今年的系统架构师考试，心血来潮下载了一些项目管理的书籍，看了一部分之后收获颇丰，推荐其中一本《项目管理修炼之道》。相信其实很多人都看过，对于我这种在项目管理上吃过亏的人来讲，简直有一种醍醐灌顶的感觉，于是记录一些心得下来，免得白看了。

一、项目驱动因素

一个项目是否能够成功启动，首先要和客户或者投资人确定项目的关键驱动因素，如果他们不愿意确定，这一责任就落在了项目经理头上了。有时候，发布时间会成为项目的关键驱动因素，如果项目没有在规定时间内发布，项目会毫无价值。有时候，项目的稳定性、健全性会成为关键驱动因素，尤其是对于一些政府项目，需要功能完备，BUG少。等等这些，都是要在项目启动之前就确定下来，同时这些也是风险控制的一个重要因素。通常可以使用一些问题来引导客户确定关键因素：

• 项目怎样才算成功
• 为什么想得到这样的结果
• 这个系统需要解决什么问题
• 这个系统会造成什么样的问题

等等。

二、编写项目章程

我在指导团队开发项目的时候，更多的是自己先明确所有功能需求，并且独立完成任务分配和人员的调度。然而这样并没有取得很好的效果，开发的组员很难理解这个功能为什么要这样做，那个功能有什么用等等。文章关于这部分的阐述观点是很明确的，项目启动时需要制定项目章程，如果团队成员不是很庞大，最好是由团队一起参与章程的讨论和编写，并形成草案，再由高层管理和客户审核，让他们了解项目整个过程，建立大概的概念。

文中提及项目章程的模板，其实很简单，而且越简单越好，只要足够让项目启动

• 远景
• 需求
• 目标
• 成功标准
• ROI估算

远景描述一个项目的价值所在，是整个团队乃至上层管理、客户之间达成的一个共识，需求可以不需要精确，根据采用的生命周期不同，更多的时候，需求就是“我们在x月x日可以发布某某版本，需要这个酷炫碉堡的功能”。目标并不等同于需求，因为项目的交付不是落实到目标上，所谓目标更多是项目性能和缺陷方面的要求，比如通过某某测试，缺陷数达到多少等等。成功的标准不单单指项目是否成功交付，关键在于最初客户的定义，比如我们开发的某个功能和同行相比更具优势，在我看来，成功的标准就是项目最后作为一个产品是否实现了其市场价值，说白了就是有没有赚钱。ROI（投资回报率），文中对这一项只有简短的一句话，但是我觉得作为公司的管理层会比较感兴趣，作为项目的可行性分析的一个初步判断。

三、开发项目规划

废话不多说，直接上文中的模板

• 产品意图
• 历史记录（管理某产品的后续版本）
• 发布条件
• 目标
• 项目组织
• 日程总览
• 人员配备
• 建议日程
• 风险列表

我想，如果我在之前已经看过这篇文章的话，会少走很多弯路，文中整章分述了上诉列表的含义，有一段我觉得有必要原文摘抄下来

“小心过早细化日程

要反复修订项目日程，随着项目进程补充细节，以获得更多信息。如果过早向出资人（客户）提供了非常详细的日程，他们会认为项目中几乎没有风险。他们会注意到项目的结束日期，并以此作为项目真正的结束日期。”

项目管理很大程度上是风险管理，如果项目经理无法自己确定风险，可以组织团队成员和测试经理进行头脑风暴，将影响因子大的风险一一列出，并论证其是否能够规避。在项目开发的过程中，需要不断的跟进、更新风险列表。

（本人乃是项目管理中的小白级别，可能会有很多看法比较局限，欢迎斧正，关于此书的电子版，百度很容易找到的）