该帖子同步发自：(wcabt的博客  访问该博客)

　　一、研究项目管理的意义

　　项目管理是一个范围比较大的课题。由于快速的市场变化，大量的创新工作，当前企业中越来越多的工作都可归为项目管理的范畴。这样，一方面企业如果能够认识和掌握项目管理的一般规律和技能，无疑会极大提升企业应对市场竞争和变化的能力;另一方面，由于项目管理几乎无所不包，因此泛泛谈项目管理，其价值不大，企业应当对其关键价值链上的项目活动的组织、流程、技术予以深入研究，形成成功模式。

　　二、项目的特点

　　1) 时效性。企业之所以发动项目，是希望在短时间内集中资源快速完成任务。

　　2) 创新性。项目工作往往涉及到新的技术，新的方法，新的环境，无前例可循。

　　3) 协调性。项目工作往往涉及多个方面，项目人员往往来自多个层面，多个部门。可谓以"乌合之众"应对"八路神仙"，协调难度很大。

　　4) 结果性。项目都会有既定的目标。但是对达成目标程度的评价却仁者见仁，智者见智。项目经理往往费力不讨好，不可能取悦于所有的人。

　　三、项目失败的主要原因

　　以上4点决定了项目管理的难度、不确定性和高风险。项目失败的案例比比皆是，失败的原因主要有：

　　1) 战略失误，立项就搞错了。对市场和技术前景判断失误，项目作了一半，发现环境已发生变化，该项目已没有价值，或有了更好的替代方案。

　　2) 项目组织结构不合理，责权不明确。

　　3) 需求分析不准确。

　　4) 重大技术障碍。重大的技术创新是困难，应单独立项;常规性的项目应当尽可能采用成熟技术。

　　5) 资源冲突。同时进行多个项目，顾此失彼。

　　6) 盲目乐观，计划与控制不力，工期拖延。对工期估计过于乐观，缺乏缓冲。

　　本文重点针对前4个问题予以深入讨论。

　　四、项目立项与规划

　　研究项目管理，首先要思考的问题是：项目从哪里来，或者说，项目的来源有哪些?一般来说，项目的主要来源有：市场或客户的需求;技术攻关、跟踪或创新的需求;产品完善或配套的需求;领导或员工的 "灵机一动"等。 这些原始的需求仅仅是一些粗糙的、混乱的项目构想，如果在这混乱的时候，就仓促启动项目，那么这样的项目十有八九会失败。这些混乱的项目构想必须通过一个严格的立项过程来进行梳理和评估，明确项目的目标和范围，识别项目之间的依赖关系，分清轻重缓急，形成结构化的项目清单，在些基础上进行的项目才有可能成功。

　　因此，立项过程非常重要，它直接决定了一个企业项目管理水平的高低、有的企业的项目立项是事后反应式，只能被动地应付企业内外部需求，对出现的问题采取救火式的解决办法。而有些企业的项目立项是前瞻式的，能够主动地预测需求，并抓住需求和引导需求，对可能出现的问题和风险能够提前预防。这种前瞻性的思考能使企业避免随意的、临时的、盲目的上一些没有业务价值的项目，而忽视了那些真正能够提升企业核心竞争力的项目。

　　项目立项应当仔细考虑如下问题：

　　• 项目的总体目标是什么?

　　• 用户需求是什么?

　　• 可以利用哪些现有的东西?

　　• 费用的极限是多少?

　　• 项目持续时间是多少，什么时候开始获利?

　　• 存在的风险是什么?

　　五、项目运作的组织结构和职位角色

　　支撑项目良性运作的组织结构的基本原则："三权分立，各司其职，相互制衡"。

　　1) 人大：立法及法律解释，定期修改;

　　2) 国务院：按法律要求，具体做事情;

　　3) 检察院：保证依法办事，纠偏纠错。

　　以软件开发项目为例，按CMM的要求，正规的软件开发组织应包括以下角色：

　　1. 软件工程过程组，相当于"人大"。其主要作用是建立质量管理体系，如：流程、模板、 检查表、标准、指导书等;这些东西建立起来后，软件工程过程组主要负责质量管理体系的完善与改进工作，定期召集会议，讨论制度流程的改进。老子说："治大国若烹小鲜"，煎小鱼儿，必须经常翻，不翻就煎糊了;但也不能翻得太勤，翻得太勤就会破环小鱼儿的形状。制度流程也是一样，不应该变动太频繁，让员工不知所措;但也不能永远"以不变应万变"。

　　2. 软件开发项目组，包括：项目经理、项目成员、质量控制专员、项目秘书等，负责具体的软件开发。

　　3. 质量保证人员，相当于"检察院"。其工作主要保证制度流程的顺利执行，一个质量保证人员监控几个项目组了。质量保证人员不仅是事后检查，还必须强化事前和事中控制。质量保证人员要主动协助项目经理以及项目组成员理解这些流程、模板、规范，譬如写代码前，质量保证人员可以给项目组介绍编程规范，写文档前，介绍文档的标准、模板等。质量保证人员保证公司的质量体系在项目组内得以实施，每个阶段结束后，都要对该阶段的进行质量以及流程执行情况的总结，监控项目按照质量计划(质量计划是项目经理制定的)执行。质量保证人员还要通过项目组成员搜集数据，分析数据,给出分析报告，等等。

　　六、需求分析

　　需求分析贯穿项目始终，在项目过程中会不断产生新的需求，也会不停地发生需求变更。需求分析是项目管理的重点和关键，需求分析常见的问题有：

　　1. 需求膨胀。希望一次解决所有的问题，项目范围不断扩大，"把海水煮沸"，最终导致项目失控，偏离原来的项目目标。

　　2. 需求曲解

　　a) 需求镀金。对用户需求进行了包装和拔高，"用户需要的是一辆自行车，而不是宝马"。

　　b) 选择性地过滤用户的需求，"对一个拿着榔头的4岁小孩来说，满世界都是钉子"，需求分析人员可能因为自己的价值观而片面分析问题。

　　3. 需求分析人员过早给出解决方案，失去了寻找更好解决方案的机会。

　　需求分析的"5C"和"5T"原则

　　1. Correct(正确)：表述的内容一和包含的信息应该是准确无误的。

　　2. Clear(清晰)：言简意赅，意思明确，无需别人绞尽脑汁这个需求到底是要表达什么意思，措辞不可含糊不清，模棱两可，更不能让人感觉话里有话，引起岐义。

　　a) 易引起岐义的需求表述句式通常是否定式，而不是肯定式。

　　b) 不要隐含假设 -- 所有假设都应表述清晰。

　　c) 对所有需求要进行优先级排序。一些需求会比另一些重要，如果需求分析人员已有了这样的判断，就应该也传递给别人。

　　3. Complete (完备)：每条需求都应完整无缺，避免漏缺或不必要的重复。

　　4. Consistent (前后一致)： 需求应能与上下文保持一致。需求应包含关键字或标识符，如"应"代表必要的需求，"将"代表导向性需求，而且全文保持这一种优先级定义原则。

　　5. Changeable(可变更)：对单个需求的更改不会对其他项造成过多影响。

　　6. Traceable(可追溯)：所有需求的来源都要明确，应可追溯到其他相关文档。

　　7. Tenable(合理)：所表述的需求必须是可实现的和可操作的。 能否在项目预算范围内，利用有限的资源，按时实施这些需求?一条需求是否与其他需求有冲突?是不是正当需求? 需求实际上都应是必要的。也许需求用"将"来描述更好一些，也就是指，导向性或非基本功能。某个需求是否只是一般描述，与系统功能没有什么关系?某个需求是否超出系统控制范围，或根本不是需求? 对每个需求，是不是都能找到用途或用户?有没有存在的理由?

　　8. Testable (可测试)：确定每一条需求都可以通过某种方法去测试其是否能实现。是否已量化?容错性和误差范围是否说明?能不能想到一个合理的方法去测试它? 这个需求的结果是否可见?

　　9. Tool (工具性)：需求管理的工具化。

　　10. Terminology(项目术语表)： 创建并维护项目或公司的词汇表。只要一个行话，或一个单词、或一个缩略语在项目中表示他们通常意义之外的意思，就应该把他们纳入词汇表。词汇表应列为需求文档的一项或作为需求文档的参考项目。

　　七、项目人员

　　1) 项目经理。项目经理是稀缺资源，不是所有的人都能成为项目经理。挑选有成功经历的人做项目经理，有的人总能把项目引向成功的彼岸，大部分人却总是在中途触礁。

　　2) 项目成员。应当能够独当一面，项目组如果大部分都是"学习者"，往往很难成功。"挑选那些最忙的人，而不是闲着没事的人。"

　　八、项目管理的一些经验

　　• 有明确定义的目标，有清晰定义的阶段、承诺及基线目标

　　• 采用一个有正式的开发评审点的流程 (管理决策及减少风险)

　　• 在项目刚开始时就有跨部门团队制定计划

　　a) 确定清晰的团队目标

　　b) 在项目整个周期中在一起工作

　　c) 团队被授权做决策

　　• 在项目的整个生命周期中根据用户需求来制定、执行和调整项目计划

　　• 通过预算控制来管理项目

　　• 在产品/技术目标、计划及成本方面保持均衡

　　• 团队成员的角色及职责是明确定义的

　　• 有一个唯一的对项目的最终结果负责的项目负责人

　　• 质量, 获利能力, 用户满意度/市场接受程度

　　• 将项目管理视为一种正式的职业及层次较高的工作

　　• 将技术开发与产品开发分离

　　• 采用一个集成的系统来处理所有项目的信息