IT项目管理的九个要素
▲ 点击蓝色“早晨” 关注
国内最短小最精悍的早晨平台
1、产品
产品的的最终实现要通过多个迭代的项目版本进行。当时做产品还是做项目是必须要回答的问题，项目是阶段目标，而产品才是终极目标。关注产品才可能形成市场和客户导向。因此在做项目过程中随时都应该融入产品意识?
而什么是产品意识?产品意识首先是一种客户意识，要认识到做项目最终仍然是形成产品，而产品的最终作用仍然是使用并为客户带来价值;其次是团队意识，要意识到团队力量才能够最终形成产品，虽然个人只负责了产品的很小一个零件，但是实现过程中仍然要从产品的角度去考虑和设计;最后才是产品的设计意识，要意识到产品设计是一个较为独立的活动和流程，产品设计是从用户的角度来看产品而不是从内部实现机制上来分析产品，这是产品设计之基本。
2、风险
我们意识到有风险，但是风险还是转化为问题了。所以有风险意识还不行，还必须将风险转化为行动。对于风险必须关注两个问题，第一是关键的风险是否已经识别出来?第二是对于风险的应对是否有效?最害怕的是关键风险没有被识别出来，最遗憾的是虽然识别了关键风险，但是风险仍然转化为了问题。
一开始可能你并不清楚风险应对是否有效，所以必须去关注和跟踪风险应对的情况。关羽大意失荆州，虽然有修建烽火台的风险应对，但是风险仍然转化为了问题，所以只能说是一种遗憾的事情。
3、WBS分解
为什么要分解?分解是我们面对大型事物或问题的一种思维和解决问题方式，通过分解逐步理清楚问题，通过分而治之逐个解决。这是我们谈分解的总体思路，再细化下分解的原因。
通过分解进行问题的分析，实现大问题向小问题，大目标向小目标的转化。通过分解体现高内聚，松耦合的组件化思想。最大限度的考虑复用，更好的响应变更。通过分解将串行工作转化为并行工作，减少等待时间，让团队成员有事可做。通过分解将大版本拆分为迭代版本，实现最快速的首版本交付。
要知道分解和集成都会增加额外的工作量，如果不是为了上述目的，就应该尽量减少不必要的分解。前面两点是从技术上和问题解决层面来考虑分解的目的，而后面两点则是从项目管理和计划上来考虑分解的目的。在分解的过程中两者必须要兼顾。
4、团队
团队和分解密切相关，没有计划和分解就谈不上团队和执行。而团队是项目目标真正的执行者，对于团队的考虑就是通过分解让相关人员都能够很好的胜任各自的工作。所以要做好项目管理，先了解团队成员知识和技能是必须的。如果对团队成员都不足够了解，就很难更好的进行工作和任务的安排，如果多技术不了解，又很难从技术层面去考虑分解工作。项团队的高效和核心竞争力体现在哪里?首先要意识到团队的高效的基础仍然是个人的高效，但是个人的高效并不代表团队一定高效。如果个人的高效都是在为团队最终的目标服务，有很强的目标意识才可能带来团队的高效。团队高效一方面是分解后并行工作中的高效性和按期完成，减少等待和空闲;一方面是集成过程中的顺畅性和高效沟通。
5、量化
很多工作如预研究等确实很难计划或量化，但是这并不代表我们不应该形成以数据说话的意识。任何事物都不是一开始就能够量化的，但是走的路多了，见识多了自然就慢慢由定性转化为了定量。定性是大方向，而定量则是精细化;定性是全凭经验，而定量则是经验+逻辑;定性是宏观把握，而定量则是精细化控制。量化的基础是数据，强调数据的基础是关注数据，而关注数据的重点则是可视化。
6、范围
我不得不再回顾下教科书的内容，计划是渐进明细的，而范围是一开始就确定的。计划可以渐进明细，但是范围不能蔓延。但是实际的情况往往确实就是项目范围在蔓延，范围完全不变动基本很困难，所以项目管理者根据应该关注范围受控这个概念，范围可能会发生变化，但是一定要受控。
范围通用涉及到两个方面的内容，一个是产品范围，如果产品范围发生变化必然会增加项目范围，所以首先要控制产品范围和用户需求。其次是项目范围，当产品范围没有变化的时候，由于我们采用的过程管理策略同样影响到项目范围。即时产品范围和项目范围都没有变化，如果我们采用的技术实现方案不同，仍然会影响到工作量，而工作量直接影响到进度目标。
我们无法控制范围完全不变化，那就转变思路，尽量让范围的变化尽早的被识别出来并解决掉。即使是资深的需求分析师也无法保证完全能够通过需求规格说明书和原型覆盖用户的所有需求，因此唯一的方法就是短周期迭代，尽早的交付首版本，尽早的获取用户的范围变更信息。
7、计划
计划本身就是对项目的预测，如果等所有的事情都明确了再来做计划，那么可能你始终都无法去做计划，当你期待的东西明确后你又发现了新的不明确的东西。因此计划本身就是基于假设下的某种确定性，再简单点说就是如果人员，团队，环境和技术怎么样了?项目团队应该可以完成哪些事情。而假设即是风险，所以计划是基于风险的一种对事物发展趋势的预测。
当你面对一个大的不明确的事物的时候，首要工作仍然是分解，只有通过分解才能够把确定的东西和不确定的东西分离出来。对于确定性的事物可以先行，对于不确定性的可以考虑风险应对和替代方案。当我们面临一个关键技术没有解决的时候，我们往往第一反映是无法做计划，但是我们需要的却是基于假设和风险的计划。比如：
假设关键技术A能够在一周内预研成功和解决，项目应该在6周左右时间完成。如果关键技术在一周内无法解决，我们需要启动替代方案2，当采用替代方案2时候项目在8周左右时间能够完成。这种陈述方式本身就是计划，并且可以看到如果这样描述让我们会根据高度关注风险和不确定性。
8、平衡
平衡是我们在项目管理中谈的比较多的一个词，平衡也是项目经理的一个重要能力。但是平衡仍然是相对的，很多时候我们谈平衡是项目目标驱动的，但是更应该谈平衡是用户满意驱动的。一个项目延期交付2个月，投入增加了30%是否就一定不成功呢?显然不是，因为在这段时间可能是用户驱动增加了一个关键需求和功能，而且也增加了投资，及时晚交付仍然可能是用户满意。
平衡不能牺牲质量，因为质量的一个衡量本身就是用户满意，要意识到其余都可以变化而质量不能变化。很多时候项目失败的原因就是去降低质量，导致了钱也花了，项目也延期了，最后仍然是用户无法满意。
9、进度
很多时候我们是知道进度会延期，但是却无能为力。由于导致进度延期的原因，涉及到的人，团队环境等因素太多了，导致我们无法快速的作出相应的应对决策。那好吧，还是抓紧时间赶进度吧，连沟通都免了，而最后结果往往确是进度恶化。如果我们只是发现问题，而不去解决问题，那发现问题本身也就没有了意义。进度都知道要延期了，还需要开会浪费时间吗?答案往往是暂停并集体思考和决策比贸然前进更加重要。
从软件开发生命周期来说，软件开发包括了需求，设计，编码，测试等诸多过程。前面需求，设计，编码都没有延期为何测试延期这么多呢?测试应该来背这个责任吗?要知道测试的时间长短首先是跟前面各个阶段的工件质量相关，其次才是和测试人员本身的效率相关。进度延期的根源往往是前面各个阶段不切实际的进度，我们采用可视化项目管理和增量迭代，冒烟测试和每日构建都是为了让前面阶段的进度尽早的可视化。
本文来源于网络，仅做传播和普及知识之用，如有侵权请告知删除。