dan 的个人资料学习的空间照片日志列表 工具 帮助

dan

尚未添加列表。
4月4日

梯子山之行随感

  今天是愚人节,对这愚蠢的节日一向很反感,没有任何意义,只是一味的靠耍人找乐,手机上也偶尔收到一幽默短信,简单一笑置之。愚人节对我没有什么影响,也没有什么值得记忆的深刻愚人事件发生,但是这个日子还是让我进入2007年的春天有了个释放情怀,拥抱大自然的难忘的机会。
  因为这天我和一些伙伴去了济南南部山区--梯子山。
他们几个都已反复去梯子山n次了,路已经熟悉的不能再熟悉了,而我每次都是擦肩而过,不是出差就是有其他事情错过去游玩。其实,当初我不是一个喜欢到处玩的人,因为踢球对我来说才有着无比的吸引力,自从认识了老婆,一个不能称之为真正驴友的驴友,才算是真正融入了大自然,感受大自然的清新和静谧了。
  周日一早6点我就起来了,虽然周六踢了一早上足球,浑身酸痛,但还是早早的起来,老婆还是习惯性的懒睡一会。简单的洗漱、收拾一下东西就出发了,一向总是迟到的我们居然是第一个早到的,等了半小时左右人员到齐。
  说是人员,其实就只有我们六人,三对夫妇。
  65路车向来人多拥挤,周末就更不用说。人少好控制,六人轻松挤上车,坐就不要想了,能有个地方站就是万幸。
  一个半小时的路程到达西营,15元租一面的,轻松到达梯子山下一村庄。
  梯子山海拔估为993米,从山下看还是仰起脖子眯着眼,当天雾大,看不到山顶,对我初次来者说,还是深不可测。当然本人是不会被此小山吓倒,还是很相信自己的体能的。
  上山了。。。
  山谷、山脊、山顶,到处传来强人的喊山声,像对梯子山的挑战,阵阵呐喊,足以振奋人心,没有理由退却和害怕。
  根据以往的经验,登山开始,是体力耗费最大的时候,此时身体和生理机能都没有舒展开,是对人的考验最残酷的时刻,爬了没几十米,汗水,可以说是虚汗,便浸透了衣服。看着老婆,累得脸儿红润有加,汗珠滚滴,虽然心疼,但也不能对她说什么,不然乱了她的方寸,影响登山的士气,慢慢调整吧,还是很相信老婆的体能的,毕竟近两千米的泰山后山她也能轻松翻越,只是偶尔给她拍一照片来鼓励她一下。
  登山路,其实根本就不是路,是前者踏出来的一痕迹,没有一合适的踏足点,全靠身体的平衡来调节登山的节奏和路线,山壁很陡峭,足以有75度的倾斜(后遇一强人所说),山越陡峭,我们的身体倾斜弯躬就越低,全身就像贴附着山路上一样往上慢慢蠕动。
  六人互相吆喝,互相鼓励着攀登,看出脸上汗水映衬的累态,没有一个人说累,更没有一个人想放弃。
  右手遮阳,抬头看山,“还有多高?”,但是每次的回答都是“快到山顶了”,也许这是一个非常合适而且非常乐观的回答,明知还有一段距离,但是‘快到山顶’还是给自己足够的信心和力量。
  爬了200米左右,体能已经不是那么重要了,此时的爬山者已经不再依靠体力,而是完全依靠自己的意志力,机械的抬起自己的左腿、右腿,汗水也不再有开始那么多,累了,寻找有利地形,就地而坐,稍息片刻。
  转身看望山下,才发现经过的村庄已经变成了售楼中心的小区模型了,一览无余,偶尔传来经过村庄看到一栓着黑狗的无奈的鸣叫,像是控诉残暴的主人打乱了这个大自然的和谐。对面山腰,蠕蠕而动的身影隐形可见,大吼几声,算是对对面知己的友好招呼,也算是互相鼓励一番。
  爬、继续爬。。。
  此时的我们已经不再感觉累,路型变得愈是复杂,而且也愈陡峭,开始手足并用,路上的断石经过无数英雄的次次踩踏已是相当牢固,不用担心滑坡或者人足踏空。
  转弯、拨开松树枝,排除障碍,大家的攀爬已经很是娴熟,互相提醒路况,当心脚下,本是对体能和技能要求很高的登山活动,让我们诠释的成为一休闲娱乐。
  偶遇。。。。
  我们登山途中,见一老兄在一有利地形,算是一片空草地,躺在草坪上,翘着二郎腿,户外遮阳帽盖在脸上休憩,嘴里哼着小曲,很是享受这大自然的滋润,此君算真是把登山的乐趣解释的淋漓尽致了。
  经过大家近两个小时的战斗,终于到达山头。
  站在山顶,身开双臂,面向阳光,紧闭双眼,享受阳光和山风的的沐浴和洗涤。此时的我们可以把所有生活的不快、工作的不顺完全的抛向脑后、山下,什么也不去想,尽情感受站在山顶上那种居高临下,身居大自然,陶醉于大自然的惬意,释放自己郁闷、疲惫、不堪各种矛盾折磨的情怀。
  睁开眼,身边多出的两位算是让自己又重新认识了人的意志和力量。一对夫妇居然从后面赶上我们,看到男的,不仅让我佩服折叹,此君有1.9米的身高,100多KG的体重,特别醒目而且就是让我佩服的就是此君腆着的将军肚,残酷一点形容就是一个水桶,感到他运动裤的松紧带能撑托起他这变形的肚子,真是不可思议,但是就是这么个不可思议,轻松的登上这近1000米的高山。
  登上山顶,算是任务完成一半,找地腐败,补充能量。
  拿出准备丰盛午餐,大家尽情享受,水果、牛肉、鸡蛋、烧饼、已是美味可口。
  腐败结束,天南地北忽侃一番,鼓足干劲,力争上游,继续出发,寻找下山出路。山顶上没有什么障碍,清晰的蜿蜒小路足以让我们恢复精力,尽情享受山风拂面。
  走不多时,遇到一长龙队伍,看队形应该是一有组织有纪律的驴友团,里面不仅有30好几的妈妈级的女士,而且还有两个不到10岁的小女孩,看到他们爬上来,居然还是那么轻松惬意。大自然的魅力,真是无穷啊。互相问候,互相鼓励一番,回去路线不一,便分开。
  我们走向山谷,经过一滩乱石坡,对我们来说这就是路,硬是扫除一切障碍,下到谷底。
  谷底居然有了碎石路,有了路,便有出口,顺着路走吧。
  此时的季节,干旱少雨,据他们说,多雨季节来此地,到处是溪水潺潺,积水成洼,看来,我此次来只能遗憾山水不能融为一体。
  到一平地,可以说是平台,上面立着不知是唐朝的诗人还是宋朝的词人三尊塑像,也许这是近处水涟峪景点的一观景台吧,在此处拍照、模仿秀,摄影师们疯狂了一把。
  继续出发。。。
  女人就是女人,路两边冒出青草,便说是山韭菜,可是闻起来怎么有种蒜的清香,便躬身拔起来,回去炒个鸡蛋就又能省上几毛钱,看着老婆那么辛苦的摘,于心不忍,上前帮忙,顷刻间,一片绿油油的韭菜还是蒜苗便只剩下弱细的摇曳了,大自然就这样慢慢的被破坏,人还真是坏啊。
  不知不觉进入收费景点,应该是水涟峪吧,当前算是淡季,而且正在整修,也没有什么游人在此休闲,往日泉水,缺少雨水也失去了精彩的溪水长流的壮观景象。水库也在整修,也许此景色便会失去大自然的固有魅力。人工造景,不知是破坏大自然还是给大自然做嫁衣。
  出来水涟峪,便是返城了,整个登山驴行在身体疲劳、心情愉畅中结束了。
  事业、爱情都可以造就生活,但是缺少大自然的滋润,生活就不会如此的精彩。
3月22日

一个经典的ERP教程(转)

家 中 请 客
 一天中午,丈夫在外给家里打电话:“亲爱的老婆,晚上我想带几个同事回家吃饭可以吗?”(订货意向)
  妻子:“当然可以,来几个人,几点来,想吃什么菜?”
  丈夫:“6个人,我们7点左右回来,准备些酒 烤鸭 番茄炒蛋 凉菜蛋花汤。。。。。。,你看可以吗?”(商务沟通)
  妻子:“没问题,我会准备好的,”(订单确认)
  妻子记录下需要做的菜单(MPS计划),具体要准备的菜:鸭 酒 番茄鸡蛋作油。。。。。。(BOM物料清单),发现需要:1只鸭,5瓶酒,4个番茄,。。。。。。(BOM展开),炒蛋需要6个鸡蛋,蛋花汤需要4个鸡蛋(共用物料)。
  打开冰箱一看(库房),只剩下2个鸡蛋(缺料)。
  来到自由市场,妻子:“请问鸡蛋怎么卖?”(采购询价)
  小贩:“1个1元,半打5元,1打9.5元。”
  妻子:“我只需要8个,但这次买1打。”(经济批量采购)
  妻子:“这有一个坏的,换一个。”(验收、退料、换料)
  回到家中,准备洗菜 切菜炒菜。。。。。。(工艺路线),厨房中有燃气灶、微波炉、电饭堡。。。。。。(工作中心)。妻子发现拔鸭毛最费时间(瓶颈工序,关键工艺路线),用微波炉自己做烤鸭可能就来不及(产能不足),于是决定在楼下的餐厅里买现成的(产品委外)。
 下午4点,电话铃又响:“妈妈,晚上几个同学想来家里吃饭,你帮准备一下。” (紧急订单)
  “好的,儿子,你们想吃什么,爸爸晚上也有客人,你愿意和他们一起吃吗?”
  “菜你看着办吧,但一定要有番茄炒鸡蛋。我们不和大人一起吃,6:30左右回来。”(呵呵,不能并单处理)
  “好的,肯定让你们满意。”(订单确认)
  鸡蛋又不够了,打电话叫小贩送来。(紧急采购)
  6:30,一切准备就绪,可烤鸭还没送来,急忙打电话询问:“我是李太太,怎么订的烤鸭还没送来。”(采购委外单跟催)
  “不好意思,送货的人已经走了,可能是堵车吧,马上就会到的。”
门铃响了,“李太太,这是您要的烤鸭。请在单上签一个字。”(验收、入库、转应付帐款)
  6:45,女儿的电话:“妈妈,我想现在带几个朋友回家吃饭可以吗?”(呵呵,又是紧急订购意向,要求现货)
  “不行呀,女儿,今天妈妈已经需要准备两桌饭了,时间实在是来不及,真的非常抱歉,下次早点说,一定给你们准备好。”(哈哈,这就是ERP的使用局限,要有稳定的外部环境,要有一个起码的提前期)
 送走了所有客人,疲惫的妻子坐在沙发上对丈夫说:“亲爱的,现在咱们家请客的频率非常高,应该要买些厨房用品了(设备采购),最好能再雇个小保姆(连人力资源系统也有接口了)。”
  丈夫:“家里你做主,需要什么你就去办吧。”(通过审核)
 妻子:“还有,最近家里花销太大,用你的私房钱来补贴一下,好吗?”(哈哈,最后就是应收货款的催要)
  现在还有人不理解ERP吗?记住,每一个合格的家庭主妇都是生产厂长的有力竞争者!!!!
9月13日

如何和身边的同事、朋友相处

君子之交淡若水,小人之交甘若醴
要有度,保持距离,不能太近,避免开过于亲昵或者过火的玩笑
多关心别人,同事遇到困难要热心主动的提供帮助,
工作之外,午餐、晚餐吃饭时经常一起吃,也可以增进感情
一起活动,经常参加大家都喜欢的集体活动,比如打球、打牌、卡拉OK等
最重要一点,互相尊重,
不打探别人隐私,不背后说别人坏话,
多赞赏别人,用心欣赏别人,赞扬要有度
8月11日

需求分析为何困难!

有几种原因使需求分析变得困难:(1)客户说不清楚需求;(2)需求自身经常变动;(3)分析人员或客户理解有误。

4.3.1 客户说不清楚需求
有些客户对需求只有朦胧的感觉,当然说不清楚具体的需求。例如全国各地的很多政府机构在搞网络建设,这些单位的领导和办公人员大多不清楚计算机网络有什么用,反而要软件系统分析人员替他们设想需求。这类工程的需求是如此的主观,以致产生很多贪污腐败现象。
有些客户心里非常清楚想要什么,但却说不明白。读者可能很不以为然。就举日常生活的事例吧,比如说买鞋子。我们非常了解自已的脚,但没法说清楚脚的大小和形状。只能拿鞋子去试,试穿时感觉到舒服才会买鞋(居然也有神通广大的售货员,看一眼客户的手,就知道应该穿什么样的鞋)。
如果客户本身就懂软件开发,能把需求说得清清楚楚,这样的需求分析将会非常轻松、愉快。如果客户全不懂软件,但信任软件开发方,这事也好办。分析人员可以引导客户,先阐述常规的需求,再由客户否定不需要的,最终确定客户真正的需求。最怕的就是“不懂装懂”或者“半懂充内行”的客户,他们会提出不切实际的需求。如果这些客户甚至觉得自己是上帝的爸爸,那么沟通和协商都会很困难。

4.3.2 需求自身经常变动
唐僧曾说:“妖要是有了仁慈之心,就不再是妖,是人妖。”(《大话西游之大圣娶亲》)
连妖都会变心,别说人了。所以喜新厌旧乃人之常情,世界也因此变得多姿多彩。
软件的需求会变化吗?
答:据历史记载,没有一个软件的需求改动少于三次。唯一只改动需求两次的客户是个死人。这个可怜的家伙还是在运送第三次需求的路上被车子撞死的。[Cline 1995]
让我们先接受“需求会变动”这个事实吧,免得在需求变动时惊慌失措。明白“需求会变动”这个道理后,在进行需求分析时就要留点神:
(1)尽可能地分析清楚哪些是稳定的需求,哪些是易变的需求。以便在进行系统设计时,将软件的核心建筑在稳定的需求上,否则将会吃尽苦头。
(2)在合同中一定要说清楚“做什么”和“不做什么”。如果合同含含糊糊,日后扯皮的事情就多。要防止象韩复渠那样,在别人请他喝酒吃饭时他什么都点头(人家就更加献殷勤),吃完了他就宣布刚才答应的事都不算数,便扬长而去。

4.3.3 分析人员或客户理解有误
有个外星人间谍潜伏到地球刺探情报,它给上司写了一份报告:“主宰地球的是车。它们喝汽油,靠四个轮子滚动前进。嗓门极大,在夜里双眼能射出强光。……有趣的是,车里住着一种叫作‘人’的寄生虫,这些寄生虫完全控制了车。”
软件系统分析人员不可能都是全才。客户表达的需求,不同的分析人员可能有不同的理解。如果分析人员理解错了,可能会导致开发人员白干活,吃力不讨好。我读中学时候最怕写作文逃题,如果逃题了,不管作文写得多长,总是零分。所以分析人员写好需求说明书后,要请客户方的各个代表验证。如果问题很复杂,双方都不太明白,就有必要请开发人员快速构造软件的原型,双方再次论证需求说明书是否正确。
由于客户大多不懂软件,他们可能觉得软件是万能的,会提出一些无法实现的需求。有时客户还会把软件系统分析人员的建议或答复给想歪了。
有一个软件人员滔滔不绝地向客户讲解在“信息高速公路上做广告”的种种好处,客户听得津津有味。最后,心动的客户对软件人员说:“好得很,就让我们马上行动起来吧。请您决定广告牌的尺寸和放在哪条高速公路上,我立即派人去做。”
为什么软件系统分析员的工资要比普通程序员高?就是因为需求分析困难嘛。

8月1日

[引]信息化建设的项目管理

序言
目前,电子政务、企业管理信息化等已成为信息化建设的热点。这些以业务、数据流程信息化为主的建设项目相当复杂。有数据表明,这类信息化建设项目在国内外成功的比例都不是很高。正因如此,
项目管理引起这个行业人士的普遍关注。同样,也有数据表明,西方国家的一些企业采用项目管理后,项目成功的比例有显著提高。
作者根据十多年项目管理实践经验,以及研究、培训和咨询的知识积累写就这篇文章,相信对信息化工程项目的建设者会有帮助。
本文涉及信息化建设项目管理的内容包括:项目经过的阶段;项目的计划、实施和控制;开发商对项目的管理;用户对项目的管理;项目的组织问题等。
一、信息化建设的几个阶段
信息化建设项目按时序划分,一般经过可行性研究、系统分析、系统设计、
开发和测试、安装调试、运行维护6个阶段。
1、可行性研究阶段
可行性研究阶段段的主要任务是:识别需求,对项目产品进行描述,确定分阶段实施的进度,从业务、技术、经济效益等方面进行可行性研究,形成可行性报告。
2、系统分析阶段
系统分析阶段的任务是:对现行系统进行详细调查,分析业务流程,分析数据与数据流程,分析功能与数据之间的关系。指出现行系统存在的问题和不足之处,确立新系统的基本目标和逻辑功能要求,最后提出分析处理方式和新系统的逻辑模型。这个阶段也称为逻辑设计阶段。逻辑设计解决系统“做什么”的问题。因此,这个阶段是整个系统建设的关键阶段。
系统分析阶段的工作成果为“系统说明书”,这是系统建设的必备文件。系统说明书既要准确又要通俗易懂,用户根据系统说明书可以了解未来系统的功能,判断是不是他们所要求的系统。
“系统说明书”一经通过,就是系统设计的依据,也是将来评价和验收系统的依据。
3、系统设计阶段
系统分析阶段的任务概括地讲,已解决了系统“做什么”的问题,系统设计阶段要回答的问题则是系统“怎么做”。也就是说,根据系统说明书所规定的功能要求,考虑实际情况,具体设计实现逻辑模型的技术方案,即新系统的物理模型。这个阶段也称为物理设计阶段。这个阶段又可分成总体设计和详细设计两个阶段。
这个阶段的技术文档为“系统设计说明书”
4、开发和测试阶段
开发和测试阶段是按物理设计方案付诸系统实现的具体工作,包括开发与调试程序,采购硬件。
这个阶段的工作量很大。在这个阶段,开发工作要重视文档的建设,测试工作需要写出测试分析报告,包括功能“测试分析报告”和“系统测试分析报告”。
5、安装调试阶段
本阶段的工作包括:硬件设备与软件平台的安装调试,用户培训,数据文件转换,系统调试与转换等。
安装调试阶段实现现有系统被新系统所替换,需要用户许多部门的参与或配合。为了使系统顺利转换,必须精心安排,合理组织,统筹调度和协调。
6、运行维护阶段
系统投入运行后,需要进行经常性维护和评价,记录系统运行的情况,根据一定的程序对系统进行必要的修改,评价系统的工作质量和经济效益。
上述6个阶段,构成信息化建设项目的全(整个)生命周期。
根据美国项目管理知识体系指南(PMBOK)的定义:项目生命周期开始于项目启动(例如签订承包合同),结束于项目收尾(例如按合同验收)。因此,信息化建设项目生命周期包括系统分析、系统设计、开发和测试、安装调试这4个阶段。参见下图。


本文第二部分内容——项目计划、实施和控制,是基于项目生命周期来考虑的。由于项目管理其实是一种方法论,因此可行性研究阶段的工作也可以按本文第二部分介绍的方法来处理。

二、项目计划、实施和控制
1、整体计划
整体计划的核心内容包括:范围计划、时间计划、成本计划和组织计划。
1)范围计划
项目范围由工作分解结构(WBS)界定。工作分解是一种以结果为导向的分析方法,用于分析项目所涉及的工作。工作分解结构中所包含的全部工作构成了项目的整个范围。工作分解结构是项目管理的一个非常基础性文件,因为它是计划和管理项目进度、成本和变更的基础。项目管理专家认为,没有包含在WBS中的工作是不应该做的。
信息系统建设项目的工作分解结构,第一层通常是由前面所述的项目生命周期的4个阶段组成,第二层则包括每个阶段需要完成的可交付成果,第三层包括第二层可交付成果进一步分解的结果——所有细化的可交付成果,…。
工作分解结构层次的多少,以便于管理为划分标准。相同的项目,不同的人会做出不同的工作分解结构来。工作分解结构最底层的可交付成果叫做工作包。
2)时间计划
时间计划是确定工作分解结构中每个可交付成果的开始和结束时间。时间计划通常用表格或甘特图、里程碑图来表示。网络计划技术中的关键路径分析、并行工程等技术方法,可用来优化时间计划安排。由于有项目管理软件的支持,生成时间计划图表,以及用网络计划技术优化时间安排都变得十分地容易。
3)成本计划
① 制订资源计划
资源计划确定了为完成项目中各活动所需要的资源(人、设备、材料)。WBS
是项目资源计划最基本的输入。
② 成本估算
成本估算是利用WBS、资源需求、资源单价、活动历时估计等成本要素,通过有关算法与工具(项目管理软件或电子表格)算出完成项目所需各种资源的成本估计值。
③ 成本预算
成本预算是为了确定测量项目实际绩效的基准计划,而把整个成本估算分配到由WBS确定的各工作包上去。成本预算和成本估算通常是同步进行的。
④ 成本基准计划
成本基准计划是一种按时间分段的预算,可以用来测量和监控项目成本的绩效。按时段把估算的成本叠加起来即可求得成本基准计划。
4)组织计划
组织计划是,利用责任矩阵确定WBS中各工作项的责任单位;利用组织图确定报告关系。但是,组织计划结果的具体形式受企事业单位的组织结构制约。(关于项目的组织问题,在本文第五部分解析)。
2、项目实施
项目实施总是一个阶段接一个阶段地进行的,前一个阶段的结果为下一阶段提供输入。信息化建设项目中,第一阶段的结果“系统说明书”,为第二阶段系统设计提供输入;第二阶段的结果“系统设计说明书”,为第三阶段的开发工作提供输入…。
每个阶段实施工作也都要首先做个计划,这个计划是为完成WBS工作包而采取的行动计划,包括:基于各项活动的基准进度计划,角色、职责分配计划。类似于前面讲到的组织计划,角色、职责分配也利用了责任矩阵这种方法,只不过在这里是把职责分配到个人。
项目子产品、产品实际上产生于项目实施过程中。
3、项目控制
项目控制包括绩效控制和变更控制
1)绩效控制
绩效控制目的是使工作结果与计划保持一致。
上面讲到,项目子产品、产品产生于项目实施过程,因此在这个过程中必须持续测量相对于项目基准计划的绩效,以便将实际绩效和基准计划进行比较,并以此为基础采取相应的纠正措施。
测量绩效的方法主要有两种,一是挣值测量,一是进度跟踪。而且,这两种方法通常是结合起来使用。
① 挣值测量
挣值测量在西方国家是测量绩效最常用的方法。它综合了范围、成本和进度测量,帮助项目管理队伍评价项目绩效。挣值测量涉及三个关键值:
l 计划值(PV):在规定时间内花费的获得批准的成本预算部分
l 实际成本(AC):在规定时间内完成工作发生的实际成本
l 挣值(EV):在规定时间内实际完成工作的价值
不难看出上述三个关键值是三个关于时间的函数。由于函数曲线呈S形状,所以通常称之为S曲线图。
这三个值提供了评价工作绩效的测量尺度。包括
l 进度偏差(SV):SV=EV-PV
l 成本偏差(CV):CV=EV-AC
l 进度绩效指数(SPI):SPI=EV/PV
l 成本绩效指数(CPI):CPI=EV/AC
② 进度跟踪
进度跟踪是输入实际工作进度,然后与基准进度计划比较,找出各项活动进
度上存在的偏差。利用项目管理软件进行进度跟踪极为方便、有效。
有了绩效测量结果,接着便是对偏差原因进行分析,进而根据分析结果决定纠正措施。纠正措施没有什么新东西,都是平时习以为常的一些方法,比如对进度偏差有赶工、快速跟进(有些书上叫做并行工程)等措施。理论著作上对这些方法的外延问题讲得很多,原因是在采取这些措施时,要考虑可能带来的许多问题,但这些都不是本文所要描述的内容了。
2)变更控制
变更控制的目的是维护绩效测量基准的完整性。也就是说对基准计划的变更予以控制。
基准计划变更包括:范围基准计划变更,时间基准计划变更和成本基准计划变更。一般说来,只有项目范围变更才会影响测量基准。但是,在某些情况下,进度延误或成本偏差非常严重,需要“重新确定基准计划”才能提供
测量进度或成本执行情况的切合实际的数据。
基准计划变更是很慎重的事,应该:
l 建立正式的变更程序
l 由变更控制领导小组负责批准或否决变更申请
l 定义正式文档变更的步骤
前面已经讲了,一般情况下只有范围变更才会影响测量基准。而在信息化建
设这样的高科技项目中,范围变更往往是因技术(功能、性能)要求的变化而起。项目管理中讲到的配置管理,讲的是项目过程中的技术管理问题。
配置管理内容包括:
l 识别工作项或系统的物理特征和功能特征
l 控制这些特征的任何变更
l 记录和报告这些变更
l 审计这些工作项和系统以证实其与需求相一致。
进行配置管理的目的是,项目过程中任何技术上的变更都要在范围变更中反
映出来,并要得到有关各方的一致认可。
三、开发商对项目的管理
无疑,开发商是信息化建设项目中的主角。对项目计划、实施和控制方面的工作,开发商都需要重视。
计划方面
信息化建设项目往往带有较多的创新成份和不确定性,项目成果在出来之前,并不确切知道它会是什么样子。因此,用户的需求和任务目标在整体计划中都不容易表述得十分具体,特别是对要实现的功能的规定往往有相当程度的灵活余地。
由于这些原因,整体计划中的工作范围、完成各项工作(由WBS定义)所需的时间和费用都较难以准确估计,所以整体计划工作必定是一个反复修改的过程。实际工作中,人们往往因为“计划赶不上变化”而不愿做计划或只做一个大致的计划。专家认为,项目管理的首要任务是计划!计划!还是计划!先哲说:“凡事预则立,不预则废”。因此,尽管信息化建设项目中存在诸多变数,但细致的整体计划工作是必须要做的。

实施方面
项目实施过程中,项目管理队伍必须协调、管理存在于项目中的各种技术和组织接口(界面)。对于信息化建设项目,在系统设计与开发、测试阶段,对各种技术接口的管理极为重要。而在系统分析与安装调试阶段,协调组织界面是项目管理队伍的重点工作。
实施过程中,项目队伍成员必须按计划做事!
比较我们与西方人做事的习惯不难发现,西方人总是按文档(当然首推计划)规定去做事,而我们做事主观随意性较大。应该学习和接受西方人的做事习惯!
控制方面
挣值测量作为一种项目监控工具在我国使用得不多。主要原因是我们的项目
管理者粗放式管理惯了,不习惯于做较精细的管理工作。当然,在信息化建设这类高科技项目的管理工作中,对工作量完成百分比做比较准确的估计(这是使用挣值测量法的前提)有些困难,也是人们不愿使用这种工具的一个原因。但笔者的体会是:对工作量完成情况做个百分比估计,比不做要好;对于类似项目第二次做时,对许多工作完成情况的估计还是有较好的置信度的。
变更控制可能是信息化建设项目中最需要但又是最困难的事。范围无止境的蔓延常常是让开发商苦不堪言。控制范围蔓延涉及到许多方面的因素,这里不一一讨论了。

四、用户对项目的管理
在项目生命周期内,用户对项目的管理主要在进度控制、范围核实、质量把关等方面。由于通常是采用固定总价合同把项目承包给开发商,因此对成本的控制不是用户主要考虑的问题(当然,非固定总价合同情况除外)。而对范围、进度、质量等方面的管理是基于同样的标准的,即是说项目所有的技术和管理文档以及任何变更后的版本,都是开发商和用户达成一致意见后形成的。
在项目生命周期内,用户项目队伍重在参与。在系统分析阶段,没有用户项目队伍的重要参与就不可能产生好的“系统说明书”,也就不可能有好的项目成果。在安装调试阶段,没有用户项目管理队伍的协调、调度,转换工作就可能陷于混乱状态。在系统设计与开发、测试阶段,用户应着眼于未来的运行维护,派技术人员全程参与工作,其必要性有二:一是未来系统运行维护的重要责任,要求技术人员必须深度了解系统的技术情况;一是系统将来必然会不断升级,要求技术人员能够为升级方案做重要贡献。系统维护人员是了解公司业务的技术专家,不可等同于一般维护人员,也不同于一般网管人员,这点应引起用户的重视。
有些情况下,用户可以雇佣项目监理来协助自己完成项目工作。特别是项目启动前的可行性论证阶段,用户对怎样实现信息化或什么样的信息化解决方案对自己是实用的,可能并不很清楚,这时购买项目监理或咨询公司的服务是很有效的。在项目生命周期内的各阶段,从职能上说,项目监理与项目管理是差不多的。
五、项目的组织问题
对于信息化建设项目,多数开发商、用户单位的内部组织都是传统型(职能型)的,即组织的结构是按职能划分的。在这种结构体系里,对项目的组织往往是非正式的(用户方面更是如此)。所谓的项目经理一般也就是部门内部一个领头干活的人。而另一个极端的现象是,当认为某个项目很重要时,就可能由高层人物来负责这个项目。在一些媒体甚至某些高等教育教材中,我们都能看到有这样的说法:信息化很重要,信息化建设工作应该由一把手亲自抓。
对信息化建设的项目管理工作,由一个领头干活的人负责显然不行,但由一把手亲自抓的观点,也非常值得商榷。
本文开头提过,信息建设工作是很复杂的事情。“复杂”体现在两个方面:一是把业务流程、规范、标准等搞清楚,并据此确定要建一个什么样的系统很复杂;一是技术实现上复杂。负责信息化建设的项目经理,应有这两方面的知识与经验。从开发商方面看,该项目经理应有很好的技术背景,同时要熟悉所服务行业的业务情况;从用户方面看,这个项目经理应非常清楚本单位的业务流程,同时对技术有一定的掌握。
一把手是企业战略层面上的管理者,很难要求他管好信息化建设这样具体而复杂的项目。
保证信息化建设项目的顺利进行,应从组织结构上着手。
矩阵型组织(参见下图)是西方国家许多企业采用的一种项目组织类型。

在这种组织结构里,职能部门经理承担职能性职责,项目经理承担项目职责。所谓扁平化管理指的也是这个意思。
从图中不难看出,项目经理需要在全公司内整合资源来完成项目工作。要做到这点,首先应赋予项目经理必要的权力。高层经理应充分认识到,负责=职责+职权。上图显示出,项目经理和职能经理的权力是平行的。要重视信息化项目建设工作,高层管理者在职能经理与项目经理的权力平衡中就应更倾向于项目经理一边。
这里应该强调的是,矩阵型组织是一种现代型组织结构,重视这种组织结构
应用,其意义不仅仅局限在信息化建设过程中,对处在产品或服务转型期的各行业来说,都有重要的现实意义。
结束语
本文阐述了信息化建设中的项目管理。然而,在当今信息化社会里各行业都应重视项目管理。时代的变化已越来越快。产品生命周期短了,一种型号的产品推出后,很快就被功能更强、性能更好的产品所取代;对服务的要求更高了,与时俱进的人性化、个性化服务是不断摆在人们面前的课题。创新已是这个时代出现频度很高的一个关键词。产品创新需要立项,服务创新也是项目。项目的概念已超越了我们对它的传统认识。因此,我们不仅要在信息化建设中重视项目管理工作,还需要在广泛的社会领域中重视项目管理。

 


 

 
没有相册。
没有可用类别。