2004年08月20日

今天,wayne将Oracle 展BOM方式的一些问题分享出来,

其实,在1个月前做SKD时,我就发现这个问题,但未作Share,

难道最近我的Share意识淡薄了 ?!

 

PS.

 

Wayne’s Mail:

 

根據MDM CR PES中去執行這條SQL語句有問題,原因在於START WITH放的位置,他的位置先後執行出來展BOM的結果會不一致(錯誤會比正確的多展一些無關的BOM),所以以後在寫這樣的SQL語句中請小心,大家可以比較一下以下正確與錯誤執行的結果,錯誤的會莫名多出55.G0001.001這一階,他在此BOM中沒有任何母階;
 

Develop BOM

SELECT LEVEL, bprod, bchld, bqreq

  FROM mbm where bdeff<= 20040101 and bddis>=20040101 

CONNECT BY PRIOR bchld = bprod

START WITH bprod = ‘99.F0027.001′ and bdeff<= 20040101 and bddis>=20040101

 ORDER BY 1, 2, 3, 4
 
 
Error SQL Statement:
 SELECT distinct LEVEL, bprod, bchld, bqreq
  FROM mbm
  WHERE bid = ‘BM’
  AND bmwhs = ‘TG’
  AND bdeff <= 20040820
  AND bddis >= 20040820
  CONNECT BY PRIOR bchld = bprod
  START WITH bprod = ‘99.G0021.003′
  AND bid = ‘BM’
  AND bmwhs = ‘TG’
  AND bdeff <= 20040820
  AND bddis >= 20040820
  ORDER BY LEVEL, bprod, bchld
 
Right SQL Statement:
 SELECT distinct LEVEL, bprod, bchld, bqreq
  FROM mbm
  WHERE bid = ‘BM’
  AND bmwhs = ‘TG’
  AND bdeff <= 20040820
  AND bddis >= 20040820
  CONNECT BY PRIOR bchld = bprod
  AND bid = ‘BM’
  AND bmwhs = ‘TG’
  AND bdeff <= 20040820
  AND bddis >= 20040820
  START WITH bprod = ‘99.G0021.003′
  ORDER BY LEVEL, bprod, bchld
 
my liu:
Oracle的标准写法如下,Start With在Connect By前
      Start  WITH  condition
—->————————- > CONNECT  BY  condition

今天,wayne将Oracle 展BOM方式的一些问题分享出来,

其实,在1个月前做SKD时,我就发现这个问题,但未作Share,

难道最近我的Share意识淡薄了 ?!

 

PS.

 

Wayne’s Mail:

 

根據MDM CR PES中去執行這條SQL語句有問題,原因在於START WITH放的位置,他的位置先後執行出來展BOM的結果會不一致(錯誤會比正確的多展一些無關的BOM),所以以後在寫這樣的SQL語句中請小心,大家可以比較一下以下正確與錯誤執行的結果,錯誤的會莫名多出55.G0001.001這一階,他在此BOM中沒有任何母階;
 

Develop BOM

SELECT LEVEL, bprod, bchld, bqreq

  FROM mbm where bdeff<= 20040101 and bddis>=20040101 

CONNECT BY PRIOR bchld = bprod

START WITH bprod = ‘99.F0027.001′ and bdeff<= 20040101 and bddis>=20040101

 ORDER BY 1, 2, 3, 4
 
 
Error SQL Statement:
 SELECT distinct LEVEL, bprod, bchld, bqreq
  FROM mbm
  WHERE bid = ‘BM’
  AND bmwhs = ‘TG’
  AND bdeff <= 20040820
  AND bddis >= 20040820
  CONNECT BY PRIOR bchld = bprod
  START WITH bprod = ‘99.G0021.003′
  AND bid = ‘BM’
  AND bmwhs = ‘TG’
  AND bdeff <= 20040820
  AND bddis >= 20040820
  ORDER BY LEVEL, bprod, bchld
 
Right SQL Statement:
 SELECT distinct LEVEL, bprod, bchld, bqreq
  FROM mbm
  WHERE bid = ‘BM’
  AND bmwhs = ‘TG’
  AND bdeff <= 20040820
  AND bddis >= 20040820
  CONNECT BY PRIOR bchld = bprod
  AND bid = ‘BM’
  AND bmwhs = ‘TG’
  AND bdeff <= 20040820
  AND bddis >= 20040820
  START WITH bprod = ‘99.G0021.003′
  ORDER BY LEVEL, bprod, bchld

2004年08月19日
關於風險管理,<與熊共舞>是一本很不錯的書。
 
前段時間,看到一個關於IT治理的開放標準,COBIT(Control Objectives for Information and related Technology,信息及相关技术的控制目标),
這是一個非常適合IT項目審計的標準,
與PMBOK類似,它將項目分成4各領域,34個過程,
對於對每一個過程,都進行了細分,並進行成熟度認證。
 
我們目前的項目管理,缺乏一些有效劃分與控制,也缺乏對項目的有效評介,
當然,我們的理論也根據很弱。
 
上封Mail中關於”代码同行评审”(我們的CodeReview)與”對项目进展定期檢查”,都是一些比較好的措施,
我們平常也有作,只是在執行力度上需要加強,執行方式上需要摸索與總結。

一、项目风险发生的根源

 极少听见有项目主管说他的项目没有任何风险而一切尽在掌握。对于一个项目来讲,风险的出现非常常见,把所有风险都拒之门外几乎没有可能,你几乎没有可能完美的解决“工期”、“资源”、“质量”三者的天生的冲突,这些导致项目不可能完全在规定的时间内、按规定的预算由规定的人员完成。这是因为项目计划和预算本质上只是一种预测,在执行过程中与实际情况肯定会有差异,这些预测和实际情况的差异性,就为项目各种各样的风险埋下了伏笔。经过一些项目实践,我总结出项目风险产生的原因主要有以下几条。

1. 项目计划中对风险管理没有引起足够的重视,导致风险发生以后手足无措。

2. 轻视前期需求工作,导致项目实际产品与客户预期的差别较大。

3. 项目过程中过渡轻视文档管理,导致风险发生以后要么无据可依(通常指需求发生变更以后,发现当初需求文档不完善),要么后继无人(通常是一些设计类文档,在人员发生变动的时候,其它人看不懂文档,无法接手工作)。

4. 轻视质量控制,导致主管得到的信息与实际差距较大,不能清晰的及时判断出真正的风险是否已经发生。在项目运作过程中,如果只靠员工的报告来掌握项目进展是不够的。事实上,员工都愿意报喜不报忧,在项目初期就出现的问题苗头,如果不能传递上来,将在后续阶段造成大更大的纰漏。缺乏质量控制机制,也就是缺乏有效的“监督”人员来制约,是造成这种情况的主要原因。

5. 轻视架构和概要设计。一般项目时间紧、资源有限,这样一些项目管理者在缺乏对系统架构和其它技术方面的设计缺乏有效的论证的前提下,就凭借着经验匆匆启动项目,很可能导致以后一旦因为客户需求变化等因素对整个系统的架构产生影响,导致系统大量的修改。以前就我曾经经历过这种事情,简直让人崩溃。

6. 缺乏积极的应对风险的措施。实际上,项目发生风险非常正常,很多风险甚至可以预料是肯定会发生的,一旦比较大的风险发生,会直接对项目组每个成员产生一些负面影响,此时很多项目管理者不能以积极的态度应对,而是自乱了阵脚,很可能导致项目计划频繁变更,项目节奏感被打乱并且逐渐开始失控。

二、解决措施

 任何问题,如果找到了真正原因,其实已经向解决问题迈进了一大步。针对以上风险发生的原因,我们可以采取以下一些策略来降低风险带来的损失甚至规避大多数风险。

在项目计划中重视风险的评估

很多项目主管在项目启动的时候认为既然团队已经建立好了,项目计划已经制定好了,就可以憧憬着项目成功了。其实没有任何两个项目是一模一样的,任何项目都会有风险的。在项目初期认真做好风险的评估,并且能让你的项目干系人(尤其是项目主管的掌控项目资源的负责人)清楚这些风险,那么一旦风险发生,也可以更加从容不迫的应对,并且有理由更好的协调资源,不至于让大家不知所措。

要重视需求工作

一个好的需求是连接业务层面和技术层面两类人,让他们达成一致的目标的关键,对于大型的复杂的项目尤其重要。好的需求可以很好的控制客户需求变更给项目带来的负面影响,(很多项目都是这样,不断的需求变更导致不断的修改,如此反复,最后陷入无法自拔的泥潭),因为客户一旦签字确认以后,这份需求就应该与商业合同一起具备法律效力而对客户进行必要的约束;另外一份清晰的没有二义性的需求可以让开发人员非常清晰自己应该完成什么工作,测试人员很好的编写测试用例,就是这份需求,可以大大降低项目组以后在沟通、修改方面的成本,提高效率和产品质量。

其实大部分人都知道“需求”的重要性,有些人肯定会说:“项目时间和资源有限,怎么可能化那么多精力专门做需求呢?”。这是一种误区,需求并不一定要长篇累犊、事无具悉,但是一定要有需求。具体需求怎么写,应该对整个项目做评估以后制定一个策略。比如因为公司长期从事某方面业务,那么这些就可以写简单点;或者项目时间太紧,那么需求文档的模版可以根据实际情况做一些必要的简化。

不合格的需求,往往会因为当初一时的懒惰而让项目最终付出几倍的惨重代价。需求是项目的一份纲领性文件,是以后项目路线的指挥棒,好的需求一定能清晰的描述出整个项目:包括都要做什么以及这些事情的优先级。比如知道优先级以后,项目的管理者就可以根据重要性、难以程度而因人制宜的分派工作,尤其遇到时间特别紧张的情况下,可以说服客户先上最重要的系统模块而把一些不重要的放在以后逐渐实施,这样把好钢都用在刀刃上,在资源等方面受到很多限制的前提下,尽量做到大家的满意,这也为降低日后的风险打下了坚实的基础。

重视项目文档管理

 让项目主管最痛苦的事情莫过于:当一个重要成员半途离开项目组时,才发现他根本就没有留下任何可用的文档。尤其在IT项目中,人员流动性强,文档就是成员之间交接的重要工具。但是很多主管很容易陷入“重技术实现,轻文档”的误区,他们总是认为项目实施时间紧迫,为了节省时间,可以在项目收尾阶段突击写文档。要是项目周期稍长一点,到了最后,谁还会清清楚楚记得每个实现细节呢?如果下一个项目与此类似,以前的劳动成果还有谁能继承得下来呢?

 当然,现在越来越多的公司已经注意到了管理好文档的重要性,一般可以借助VSSCVSPVCS等工具来很好的对文档进行版本控制,但是有一点要特别引起注意:单单关注文档本身远远不够,还要重视文档的质量!即使是在现在很多管理很规范(比如已经通过了CMM3ISO9000等认证)的公司,“重过程、轻质量”也是一个突出问题。一般在每一份文档入基线以前,都要通过评审、同行评审等方式来对文档进行专门的“轰击”以保证文档的有效性,这些评审小组中如果能包括一些行业、技术方面的专家将经常能达到更好的效果,这些专家完全可以从公司外面聘请。

 有了完善和有效的文档做基础,能降低很多项目过程中的风险。

重视质量过程控制

 很多人通常认为,在的项目组中最重要的是主管和设计开发人员,而认为项目中的质量过程控制没有什么必要。但是在实际项目过程中,单靠研发人员提供的报告来判断项目进程、确认是否有或者将有风险发生远远不够。因为大部分人喜欢报喜不报忧,而且汇报的内容大部分只是他本人主管的认知,也缺乏通盘的考虑。越复杂的项目,越需要量化的管理,必须有一种机制能让管理者真正掌握项目的实际进展情况,最有效的办法就是建立质控部门与实际的研发部门相互制约,监控测试项目实际情况和实际的问题,而不参与项目的具体实施。

作为一个项目管理者,明确这种研发和质控的关系,除了更好的保证项目质量以外,还能客观的反映项目实际情况,通过这些文档来表明每个基线、每个成员的工作量和完成质量,对识别、预测项目风险意义重大,当然,这些措施也大大降低了项目过程中可能的风险发生的概率。


重视架构和概要设计

 IT项目中,编码实施固然重要,但是对于一个比较复杂项目中的项目组来讲,如何让不同角色的研发人员高效协作,将是更加要紧的问题。
 
设计文档,尤其是架构设计就是能够让这些研发资源更加高效协作,降低返工的有效手段。有了这些设计作为指引,研发人员就可以同步工作,共享公用的资源(比如,经过设计分析以后,发现客户业务方面有ABC三个业务模块,但是其实这三个模块中有几乎50%在技术实现上是公用的)。在实际设计的操作过程中,可能有时候项目组内部成员几乎没有一个有经验,那么最好还是聘请一些外部的专家来帮忙,我在实际的项目中,发现这个效果会比较好。

 有了这些有效的纲领性的技术文件,会在实际开发过程中大大降低各种潜在的风险。

采用积极的应对风险的措施

 让人遗憾的是,即便我们做了很多的事情来防止风险的发生,通常还会有风险发生。一旦突如其来的风险发生了,例如:项目组核心成员突然病倒,客户组织结构发生调整或者虽然当初签订了合同确认了需求,但是客户业务调整了,那么我们总不能一意孤行的还是移交给客户一套其实已经无法运转的系统吧。这些风险一旦发生,躲避不是办法,作为一个项目主管来说,更加行之有效的办法是带领整个团队,用积极的心态、科学合理的方法来以最小的代价克服它。当然,这也需要项目组的经验以及项目主管的综合素质来支撑。

 通常处理风险的过程分为三步走:识别  量化 应对。通过风险识别确定哪些风险可能影响项目,并把风险归档作为以后过程财富的很好的积累,把产品、历史信息、其它相关信息作为输入,利用检查表、流程图、面谈等手段,得出风险的来源、征兆等结论;风险量化是指评价风险和它们之间的相互作用,从而评估项目可能结果的大概范围。如果你想启动风险量化过程,那么你需要首先知道这些风险的来源,量化是一项比较复杂的活动,除了采取货币、时间等来衡量以外,最好借助专家的判断。有了比较量化的结果以后,项目主管就能清晰的意识到风险的严重性,从而做出更加贴切的应对措施;有了以上的结果以后,就可以制定风险应对措施来制定应对措施了。

 总之,知道了项目风险的原因和应对措施,对项目的顺利进行有非常重要的意义,很多情况下,能否很好的处理好项目的风险会成为项目成败的关键,这种处理突发风险的能力也成为衡量一个项目主管人员重要指标。

    PMIPMPMPM,这几个英文单词不仅长得挺像,而且都是“项目管理”家族的成员,可实际上它们之间差别还挺大。
   
项目管理现在正热门,但是它有好几个分支,比如PMIPMPMPM。为帮助大家分清这些面貌相似的英文缩写各自的含义,记者专门采访了天津理工学院经济管理学院院长尹贻林教授。
   
PMIProject Management  Institute)是美国项目管理协会的简称,它的成员主要以企业、大学、研究机构的专家为主。现在已经有4万多会员。它卓有成效的贡献是开发了一套项目管理知识体系(PMBOK)。
   
PMBOKProject Management Body of  Knowledge)是项目管理知识体系的缩写。在这个知识体系中,把项目管理划分为9个知识领域,即:范围管理,时间管理,成本管理,质量管理,人力资源管理,沟通管理,采购管理,风险管理和集成管理。现在PMBOK还处于发展完善过程中,目前有1996年版和2000年版两个版本。
   
PMPProject Management  Professional)指项目管理的专业人士,它是由PMI组织认证的。PMI的资格认证制度从1984年开始,目前已经有两万多人通过认证,成为PMPPMI的资格认证虽然有项目管理能力的审查,但更注重于知识的考核,要成为PMP必须参加并通过包括200个问题的考试。项目管理现在已经成为美国的优选职业,根据统计数据,在美国,从事项目管理工作的初级工作人员年薪在4.5-5.5万美元,中级人员在6.5-8.5万美元,高级人员为11-30万美元。美国的大学开始设立项目管理的硕士学位,并有取代MBA专业学位的趋势。我国从2000年开始引进PMP认证,目前PMI授权我国外国专家局负责国内的PMP培训和认证工作。
   
MPMMaster of Project  Management)指项目管理硕士学位。二战后,随着项目管理影响和应用领域的逐渐扩大,西方发达国家的大部分高校都开始开设项目管理课程,并培养项目管理的硕士和博士。在我国,项目管理目前还不是一个独立的学科,还没有项目管理的硕士点和博士点。为了缓解我国当前飞速发展的经济对高级项目管理人才的巨大需求,国务院学位办于200111月正式下文批准加拿大魁北克大学与天津理工学院经济管理学院联合培养  M PM的合作办学项目。天津理工学院成为国内第一个与国外高校联合培养MPM的高等院校。