资深项目管理专家谈IT项目管理中的关键点

本文由“光环国际”—中国项目管理PMP培训上市企业转载

1、产品

产品的的最终实现要通过多个迭代的项目版本进行。当时做产品还是做项目是必须要回答的问题，项目是阶段目标，而产品才是终极目标。关注产品才可能形成市场和客户导向。因此在做项目过程中随时都应该融入产品意识。

而什么是产品意识产品意识首先是一种客户意识，要认识到做项目最终仍然是形成产品，而产品的最终作用仍然是使用并为客户带来价值;其次是团队意识，要意识到团队力量才能够最终形成产品，虽然个人只负责了产品的很小一个零件，但是实现过程中仍然要从产品的角度去考虑和设计;最后才是产品的设计意识，要意识到产品设计是一个较为独立的活动和流程，产品设计是从用户的角度来看产品而不是从内部实现机制上来分析产品，这是产品设计之基本。

2、风险文章

我们意识到有风险，但是风险还是转化为问题了。所以有风险意识还不行，还必须将风险转化为行动。对于风险必须关注两个问题，第一是关键的风险是否已经识别出来第二是对于风险的应对是否有效最害怕的是关键风险没有被识别出来，最遗憾的是虽然识别了关键风险，但是风险仍然转化为了问题。

一开始可能你并不清楚风险应对是否有效，所以必须去关注和跟踪风险应对的情况。关羽大意失荆州，虽然有修建烽火台的风险应对，但是风险仍然转化为了问题，所以只能说是一种遗憾的事情。

3、WBS分解

为什么要分解分解是我们面对大型事物或问题的一种思维和解决问题方式，通过分解逐步理清楚问题，通过分而治之逐个解决。这是我们谈分解的总体思路，再细化下分解的原因。

通过分解进行问题的分析，实现大问题向小问题，大目标向小目标的转化。

通过分解体现高内聚，松耦合的组件化思想。最大限度的考虑复用，更好的响应变更。

通过分解将串行工作转化为并行工作，减少等待时间，让团队成员有事可做。

通过分解将大版本拆分为迭代版本，实现最快速的首版本交付。

要知道分解和集成都会增加额外的工作量，如果不是为了上述目的，就应该尽量减少不必要的分解。前面两点是从技术上和问题解决层面来考虑分解的目的，而后面两点则是从项目管理和计划上来考虑分解的目的。在分解的过程中两者必须要兼顾。

4、团队

团队和分解密切相关，没有计划和分解就谈不上团队和执行。而团队是项目目标真正的执行者，对于团队的考虑就是通过分解让相关人员都能够很好的胜任各自的工作。所以要做好项目管理，先了解团队成员知识和技能是必须的。如果对团队成员都不足够了解，就很难更好的进行工作和任务的安排，如果多技术不了解，又很难从技术层面去考虑分解工作。

团队的高效和核心竞争力体现在哪里首先要意识到团队的高效的基础仍然是个人的高效，但是个人的高效并不代表团队一定高效。如果个人的高效都是在为团队最终的目标服务，有很强的目标意识才可能带来团队的高效。团队高效一方面是分解后并行工作中的高效性和按期完成，减少等待和空闲;一方面是集成过程中的顺畅性和高效沟通。

5、量化

很多工作如预研究等确实很难计划或量化，但是这并不代表我们不应该形成以数据说话的意识。任何事物都不是一开始就能够量化的，但是走的路多了，见识多了自然就慢慢由定性转化为了定量。定性是大方向，而定量则是精细化;定性是全凭经验，而定量则是经验+逻辑;定性是宏观把握，而定量则是精细化控制。量化的基础是数据，强调数据的基础是关注数据，而关注数据的重点则是可视化。

6、计划

计划本身就是对项目的预测，如果等所有的事情都明确了再来做计划，那么可能你始终都无法去做计划，当你期待的东西明确后你又发现了新的不明确的东西。因此计划本身就是基于假设下的某种确定性，再简单点说就是如果人员，团队，环境和技术怎么样了项目团队应该可以完成哪些事情。而假设即是风险，所以计划是基于风险的一种对事物发展趋势的预测。

当你面对一个大的不明确的事物的时候，首要工作仍然是分解，只有通过分解才能够把确定的东西和不确定的东西分离出来。对于确定性的事物可以先行，对于不确定性的可以考虑风险应对和替代方案。当我们面临一个关键技术没有解决的时候，我们往往第一反应是无法做计划，但是我们需要的却是基于假设和风险的计划。比如：文章

假设关键技术A能够在一周内预研成功和解决，项目应该在6周左右时间完成。如果关键技术在一周内无法解决，我们需要启动替代方案2，当采用替代方案2时候项目在8周左右时间能够完成。这种陈述方式本身就是计划，并且可以看到如果这样描述让我们会根据高度关注风险和不确定性。

7、范围

我不得不再回顾下教科书的内容，计划是渐进明细的，而范围是一开始就确定的。计划可以渐进明细，但是范围不能蔓延。但是实际的情况往往确实就是项目范围在蔓延，范围完全不变动基本很困难，所以项目管理者根据应该关注范围受控这个概念，范围可能会发生变化，但是一定要受控。

范围通用涉及到两个方面的内容，一个是产品范围，如果产品范围发生变化必然会增加项目范围，所以首先要控制产品范围和用户需求。其次是项目范围，当产品范围没有变化的时候，由于我们采用的过程管理策略同样影响到项目范围。即时产品范围和项目范围都没有变化，如果我们采用的技术实现方案不同，仍然会影响到工作量，而工作量直接影响到进度目标。​​​​