分享

IT项目管理杂谈(1)

 william8888 2010-06-22

IT项目管理杂谈(1)

(2010-06-07 18:23:29)
标签:

项目管理

it

分类:随笔文章
风险

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

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

产品

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

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

WBS分解

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

  • 通过分解进行问题的分析,实现大问题向小问题,大目标向小目标的转化。
  • 通过分解体现高内聚,松耦合的组件化思想。最大限度的考虑复用,更好的响应变更。
  • 通过分解将串行工作转化为并行工作,减少等待时间,让团队成员有事可做。
  • 通过分解将大版本拆分为迭代版本,实现最快速的首版本交付。

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

团队

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

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

量化

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

量化的基础是数据,强调数据的基础是关注数据,而关注数据的重点则是可视化

    本站是提供个人知识管理的网络存储空间,所有内容均由用户发布,不代表本站观点。请注意甄别内容中的联系方式、诱导购买等信息,谨防诈骗。如发现有害或侵权内容,请点击一键举报。
    转藏 分享 献花(0

    0条评论

    发表

    请遵守用户 评论公约

    类似文章 更多