個人檔案网络人生相片部落格清單更多 ![]() | 說明 |
|
5月29日 管理者合格的管理者需要具备强烈的进取精神与敬业精神,没有干劲的人是没有资格进入高层的。这里不仅仅是指个人的进取精神,而是自己所领导群体的进取与敬业精神。 公司发展需要大量的管理者,优秀管理者有三个衡量的标准:一、具有敬业精神,对工作是否认真,改进了,还能改进吗?还能再改进吗?二、具有献身精神,不能斤斤计较。企业的价值评价体系不可能做到绝对公平,献身精神是考核干部的一个很重要因素,一个管理者如果过于斤斤计较,就不能与手下融洽合作,不能将工作做好。没有献身精神的人就不要去做管理。三、具有责任心和使命感,这将决定管理者是否能完全接受企业的文化,担负起企业发展的重担。 企业在选拔管理者的过程中要坚持以下几个原则: 第一、管理者要具备踏实的办事能力、强烈的服务意识与社会责任感,能够不断提高自身的驾驭与管理能力。 作为一个管理者不但要学会做人,也要学会做事,踏踏实实地做事,认认真真地做事。那种只说不做或只会做表面文章的人,只会进行原则管理、从不贴近事件的人,不能得到提拔和重用。华为要求每个管理者都能够亲自动手做具体的事,那些找不到事做又不知如何下手的管理者,就会面临被精简的命运,我们会将没有实践经验的干部调整到科以下的岗位去。在基层没有做好工作的,没有敬业精神的,是得不到提拔的,任何虚报数字、作风浮夸的干部都会被降职、降薪。 在华为,我们要求中高层管理者要具备自我提高的能力,能够很快地适应社会、企业的发展要求。同时,管理者必须充分理解企业的核心价值观,具有自我批判的能力。要关心部下,善于倾听不同的意见,能够和持不同意见的人交朋友,分析这些人的问题,给他们帮助。一是帮助他们改变思想方法,二是帮助他们疏散到不同的岗位,避开和主管领导的正面冲突。对管理者而言,做员工真诚的朋友很重要,这样,员工就能和你说知心话,可以弥补管理者在工作中的缺陷。 第二、管理者要具备领导的艺术和良好的工作作风。团结、沟通是管理工作的永恒主题,任何一个管理者不仅要团结与自己意见一致的人,也要团结那些与自己意见不一致的人,做不到这一点就没有资格做接班人,永远不会得到上级的提拔。在华为,我们强调批评与自我批评的工作作风,从高层一直传递到最基层。在公司内部允许员工对自己的上级,对自己的部下进行批评,否则人人都顾及影响,都做“好人”,企业管理的进步就无从说起。 任何一个管理者都要清清白白做人、认认真真做事,做员工学习的榜样。不仅要严格要求自己,也要严格要求部属。只有一个群体具有高水平,才表明这个管理者的高水平。在华为,我们在高中级干部中贯彻,反对贪污,反对浪费,反对假公济私的原则。 第三、要站在公司的立场上综合地选拔,而不能站在小团体、小帮派的立场上选拔管理者。区别这个人是否具有成为合格管理者的潜质,主要看这个人的基础、素质以及能力,不能论资排辈。同时,要允许持不同意见的人存在。华为实行的是干部对事负责制,而不是对人负责制。对人负责制会滋生一些不良风气,会出现使很多人说假话、封官许愿、坦护问题、以人划线等一系列的毛病。华为对管理者有几条纪律:管理者只能以个人名义表达自己的意见,不允许使用联合签名的方式。管理者个人对问题的看法,只能用电子邮件的方式发给专用邮箱反映,而不允许未经批准擅自把电子邮件发上公告栏。当公司认为意见可以公开时,才可以公开发表。不管是正面意见还是负面意见,未经批准,在华为都是错误的。 第四、管理者必须具有培养超越自己的接班人的意识,具有承受变革的素质,这是企业源源不断发展的动力。没有前人为后人铺路,就没有人才辈出。只有人才辈出,继往开来,才会有事业的兴旺发达。每个管理者都必须开放自己,融入到企业的文化中,具有能上能下的心胸,只有能屈能伸的人,才会有大出息。 企业变革的阻力一般都来自管理层,管理者要以正确的心态面对变革。变革从利益分配的旧平衡逐步走向新的利益分配平衡,这种平衡的循环过程,促使企业核心竞争力提升与效益增长。在这个过程中,管理者的利益可能会受到一些损害,大方丈可能会变成小方丈,原来的庙可能会被拆除,这时,管理者要从企业发展的角度出发,用正确的心态对待。就像华为,正处在一个组织变革的时期,许多高中级干部的职务都会相对发生变动。公司会听取管理层的倾诉,但也要求服从,否则变革无法进行。等变革进入正常秩序,公司才有可能按照干部的意愿及工作岗位的需要,接受他们的调整愿望。 第五、企业对候选的管理者要进行深入的了解与沟通。有些企业选拔管理层,对个人的履历没有做深入的调查,不是很清楚他过去的经历,导致在以后的工作中出现很多意想不到的状况。华为就要求管理者的个人履历加强透明度,他也可以选择放弃对公司的透明度,这样,公司也会放弃选择他做干部的权利。对管理者个人状况的了解有助于解决管理层的腐化问题。 华为还有一个选拔管理者的原则:凡是没有基层管理经验,没有当过工人的,没有当过基层秘书和普通业务员的,一律不能提拔为管理层,哪怕是博士也不行。学历再高,如果没有实践经历,也不可能成为一个合格的管理者。 原理今天发现,已经大半个月没有打理过博客了,实在是很懒惰啊~进入五月以后,工作有所变化,工作的内容由被动的等待变成了完全的主动出击,主动是我之前一直很缺乏的能力,希望现在的工作可以让我成长很多。虽然只是工作了一个星期,但也是让我受益匪浅,明白了不少道理。发现有很多原来其实我们以前就已经知道了,只是没有把他们应用到实际的工作中,如果你对这些理论还不太熟悉,不妨看看下面的总结—— 彼得原理 酒与污水定律 木桶定律 马太效应 零和游戏原理 华盛顿合作规律 手表定理 不值得定律 蘑菇管理 奥卡姆剃刀定律 对不起,时间1、“我很忙,我没时间” 上面是我总结的最核心的三个问题,是每个备考PMP的学员必须要解决的。下面说的是,我从通过考试的同学身上总结的共同的规律,也就是要树立的三个心态,就是备考PMP的“三要”。 能力大多人不会认为自己的能力有问题。但是,困扰人们的问题是:在相关条件差别不大的情况下,为什么有的人能成功,而有的人却不能。 根据本人从业经历的观察与思考所得,无论在内企,还是在外企,凡是成功人士(以下简称他们)的身上都有独特的个人能力和人格魅力,这是旁人所缺乏的。他们的成功决不能简单地归结为机遇好。依我来看,这些能力可概括为: 1、解决问题时的逆向思维能力 面对工作中遇到的新问题,一时又找不到解决方法。而且,上司可能也没有什么锦囊妙计时,他们擅长用逆向思维办法去探索解决问题的途径。他们清楚具体业务执行者比上司更容易找出问题的节点,是人为的,还是客观的;是技术问题,还是管理漏洞。采用逆向思维找寻问题的解决方法,会更容易从问题中解脱出来。 2、考虑问题时的换位思考能力 在考虑解决问题的方案时,常人通常站在自己职责范围立场上尽快妥善处理。而他们却总会自觉地站在公司或老板的立场去考虑解决问题的方案。 3、强于他人的总结能力 他们具备的对问题的分析、归纳、总结能力比常人强。总能找出规律性的东西,并驾驭事物,从而达到事半功倍的效果。人们常说苦干不如巧干。但是如何巧干,不是人人都知道的。否则就不会干同样的事情,常人一天忙到晚都来不及;而他们,却整天很潇洒。 4、简洁的文书编写能力 老板通常都没时间阅读冗长的文书。因此,学会编写简洁的文字报告和编制赏心悦目的表格就显得尤为重要。即便是再复杂的问题,他们也能将其浓缩阐述在一页A4纸上。有必要详细说明的问题,再用附件形式附在报告或表格后面。让老板仅仅浏览一页纸或一张表格便可知道事情的概况。如其对此事感兴趣或认为重要,可以通过阅读附件里的资料来了解详情。 5、信息资料收集能力 他们很在意收集各类信息资料,包括各种政策、报告、计划、方案、统计报表、业务流程、管理制度、考核方法等。尤其重视竞争对手的信息。因为任何成熟的业务流程本身就是很多经验和教训的积累,遇到用时,就可以信手拈来。这在任何教科书上是无法找到的,也不是那个老师能够传授的。 6、解决问题的方案制定能力 遇到问题,他们不会让领导做“问答题”而是做“选择题”。常人遇到问题,首先是向领导汇报、请示解决办法。带着耳朵听领导告知具体操作步骤。这就叫让领导做“问答题”。而他们常带着自己拟定好的多个解决问题方案供领导选择、定夺,这就是常说的给领导出“选择题”。领导显然更喜欢做的是“选择题”。 7、目标调整能力 当个人目标在一个组织里无法实现,且又暂时不能摆脱这一环境时,他们往往会调整短期目标,并且将该目标与公司的发展目标有机地结合起来。这样,大家的观点就容易接近,或取得一致,就会有共同语言,就会干的欢快。反过来,别人也就会乐于接受他们。 8、超强的自我安慰能力 遇到失败、挫折和打击,他们常能自我安慰和解脱。还会迅速总结经验教训,而且坚信情况会发生变化。他们信条是:塞翁失马,安知非福,或上帝在为你关上一扇门的同时,一定会为你打开一扇窗。 9、书面沟通能力 当发现与老板面对面的沟通效果不佳时,他们会采用迂回的办法,如电子邮件,或书面信函、报告的形式尝试沟通一番。因为,书面沟通有时可以达到面对面语言沟通所无法达到的效果。可以较为全面地阐述想要表达的观点、建议和方法。达到让老板听你把话讲完,而不是打断你的讲话,或被其台上的电话打断你的思路。也可方便地让老板选择一个其认为空闲的时候来“聆听”你的“唠叨”。 10、企业文化的适应能力 他们对新组织的企业文化都会有很强的适应能力。换个新企业犹如换个办公地点,照样能如鱼得水般地干得欢畅并被委以重用。 11、岗位变化的承受能力 竞争的加剧,经营风险的加大,企业的成败可在一朝一夕之间发生。对他们来讲,岗位的变化,甚至于饭碗的丢失都无所畏惧。因此,他们承受岗位变化的能力也是常人所无法比拟的。在他们看来,这不仅是个人发展的问题,更是一种生存能力的问题。 12、客观对待忠诚 从他们身上你会发现对组织的忠诚。他们清楚地意识到忠诚并不仅仅有益于组织和老板,最大的受益者是自己,因为,责任感和对组织的忠诚习惯一旦养成,会使他们成为一个值得信赖的人,可以被委以重任的人。他们更清楚投资忠诚得到的回报率其实是很高的。 13、积极寻求培训和实践的机会 他们很看重培训的机会,往往在招聘时就会询问公司是否有提供培训的机会。善于抓住任何培训机会。 一个企业,如果它的薪酬福利暂时没有达到满意的程度,但却有许多培训和实践的机会,他们也会一试。毕竟,有些经验不是用钱所能买回来的。 14、勇于接受份外之事 任何一次锻炼的机会他们都不轻言放弃,而把它看成是难得的锻炼机会。并意识到今天的份外,或许就是明天的份内之事。常看见他们勇于接受别人不愿接受的份外之事,并努力寻求一个圆满的结果。 15、职业精神 他们身上有一种高效、敬业和忠诚的职业精神。主要表现为:思维方式现代化,拥用先进的管理理念并能将其运用于经营实践中。言行举止无私心,在公司的业务活动中从不搀杂个人私心。这样,就敢于直言不讳,敢于纠正其他员工的错误行为,敢于吹毛求疵般地挑剔供应商的质量缺陷。因为,只有无私才能无畏。待人接物规范化,这也是行为职业化的一种要求。有了这种职业精神的人,到任何组织都是受欢迎的,而且,迟早会取得成功。 5月26日 团队 曾几何时,团队成为一个响亮的词语。公司与公司在市场上的搏杀更多的演绎为团队与团队的PK。成功的团队都是一样的,不成功的团队各有各的不幸。如何打造一支强势团队困扰着一位又一位的经理人。下面来介绍一下,强势团队的五个特征: 重组:三部委下发深化电信体制改革通告(转载)
工业和信息化部国家发展和改革委员会财政部 5月25日 业务部门和支撑部门的关系4转型谈何容易,尤其是对于这些技术专家来说,心理是非常难以接受的:做了这么多年的技术,也自知技术的发展非常快,如果不持续跟踪和学习技术,如果中间歇一段时间,恐怕就很难再继续钻研技术了,所以从技术向其他方向转型的感觉就像是自废武功。但是,为了练成嫁衣神功,恐怕这是必须要做的。 在这个时间点进行业务支撑的转型有三个可选择的方向:一个是向业务转型;一个是向管理转型,还有一个就是向“使能者”的方向迈进了。 现在的业务支撑人员向业务转型难度是比较小的,因为省级业务支撑系统已经做到了省级集中,所以在业务支撑部门可以看到全部的企业运营数据和应用,和绝大多数的业务人员相比,支撑部门的人员有机会更全面地接触业务,这是企业里其他部门难以触及的资源和机会,所以如果支撑的人员向业务转是比较可行的;而且支撑人员的思维比较理性和逻辑化,再加上丰富的经验,往往是业务部门非常欢迎的对象。但是和真正的业务人员相比,支撑的人员往往思维比较僵化,考虑问题顾及较多,这样易丧失机会;还有一点很重要,就是IT人员做业务时,一定要理解为什么要关注短线,关注近期能达到的目标,而且自己也要这么去做,否则就无法适应业务部门的节奏和氛围了。 相对于向业务转型,在支撑部门内部也不是所有的人都能做到的,因为毕竟有的人与业务之间还有一定距离,尤其是那些纯搞技术的人,要他们脱离开现有的工作去分析和理解业务,恐怕还是需要一定的时间的。对于他们来说,其实向管理转型也是个不错的选择。这次工作会议上,上海公司在进行经验介绍的时候就强调,他们不是在做研发,而是做研发管理。拥有较强技术背景的技术人员,如何进一步提升自己的管理能力,从“自己做”到“指挥、指导别人做”,无论是对个人还是团队,都是非常重要的一步。 中国移动业务支撑部门向管理转型也是发展的必由之路。之前分析过,计费业务中心时代,支撑部门是业务部门的附属生产中心,主要工作是满足业务部门提出的需求,执行业务部门制定的策略;另一方面,也要遵从省公司的各个职能部门的管理。所以说,这个时候计费业务中心没有管理权和岗位是正常的。但是现在,支撑部门的定位发生了很大的变化,业务支撑系统部既有生产职能,也同时拥有了对自己专业进行职能管理的权力,内部管理类似于事业部制,这就要求业务支撑部门自己对自己的专业提出管理的制度、办法,并安排人员执行这些制度,这就是我们所强调的管理职能。那么谁来行使这些管理职能呢?恐怕主要工作还是要依靠部门自身人员,尤其是技术人员的转型。 最后一点,所谓向使能者的方向转型和过渡,是强调业务支撑人员要站在企业的高度和广度,在对企业发展战略、市场环境以及技术能力等进行全面分析的基础上,超前性地拟定企业业务发展的可能的方向,并依据这些方向制定业务支撑自身的发展战略以及中长期的演进和发展目标,超前地进行系统方面的建设和储备。 大家这么一看,就觉得做“使能者”太难了,似乎要做很多不应该业务支撑部门做的事情,但是,这也是不得已的办法,因为企业里必须要有这样的一个部门。那别的部门能承担这个职责么?首先看业务部门。现在业务部门受到很大的现实压力,因此他们在策划和提出需求的时候,大都以短线为主,主要的工作都是在围绕KPI开展的,对远期的工作指导性较弱。其次看企业的发展战略部门,虽然站得很高,但是他们的工作与具体的业务和生产运营还有一定距离,因此制定的战略规划往往落地程度和可操作性较差。而从支撑部门的角度来看,IT系统的建设是需要一定周期的,从系统规划、设计、建设,以及从系统上线到稳定运行,都需要时间,如果系统的规划不适度超前,超前地储备业务支撑能力,恐怕当业务部门的短期需求出现时,建构在传统框架上的系统,或者缺失业务支撑能力的系统是很难快速、健康地满足要求的。 要做到“使能者”,必须要具备很强的能力,包括规划能力,对业务的熟悉与了解,对企业战略和市场环境的理解,对技术的把握和运用,甚至包括对企业内部组织架构了解和内部协调的能力,等等。使能者要预见到未来的市场和业务需求,还要掌握系统建设的进度,做到适度领先。最好的节奏是当系统建成的时候,业务部门的需求也刚好提出,这样才能“使业务部门能”。当然,理想的状况是很难达到的,一个人同时具备这些能力也是很难的,但是我们要以这为目标,以团队的方式逐渐向目标演进。真希望业务支撑人员借助这样的一个环境和空间,利用对战略、市场、系统、业务的全方位了解,在进一步提高自身能力,助力市场和业务的同时,为企业创造更大的价值。 补充一点:使能者要关注业务,但是最终要做的事情以及提出的建议都应该是围绕系统进行的;我们做业务的使能者,但不是要取代业务部门。 业务部门和支撑部门的关系3写这段内容的时候,可能和题目无关,因为这段是在描述业务支撑部门自身的发展问题。wendy也在问,近忧是什么?看看我们一些省公司的实际情况吧。 A省业务支撑中心有50多人,其中一半是研究生以上学历,还有好几个博士,对于一个中等省份来说,这样规模的支撑部门是相当奢侈的。但是这些高学历的人员在做什么呢?一个不到10个人的班组,在做系统硬件和网络的维护,按照公司领导的要求,他们要做到网络和主机等基础设备良好地运转,保证不出问题,为了达到公司的要求,他们一方面考了很多证书,一方面没日没夜地加班、学习,终于达到了可以替换集成商来进行硬件维护的能力,可他们获得了什么呢?其一,领导对他们还需要购买硬件、基础软件的服务感到不爽,认为这些钱应该可以省下来;其二,领导觉得他们很重要,因此出差、学习、接触业务,甚至正常的休假都与他们无关,因为担心一旦离开人系统就出问题;其三,公司的人力资源体系对这些人并不认可,无法给予这些专家应有的职级和薪酬。所以他们很痛苦,不知道自己的职业发展规划应该如何? 记得有篇文章介绍最后一台蒸汽机车退役时,其中讲到操作它的司机,非常专业,几十年和蒸汽机车在一起,从机车的声音就能判断有什么毛病,是劳动模范;但是蒸汽机车被淘汰是技术进步引发的,也是迟早要发生的,当蒸汽机车退役时,那些基于蒸汽机车的经验、能力和知识,都随着蒸汽的消失而烟消云散了。这些老师傅的经验对新的内燃机车有效么?大部分是无效的,新毕业的中专生半年后就具备和这些老师傅同样的能力。技术进步对于这些蒸汽机车司机来说是灭顶之灾,而这些如果只能依靠个人承担,对企业和社会来说都是问题,但是这些是真实地发生在我们周围的事实。 具体化到IT支撑部门,有人认为自己是技术专家,但是,随着时间的推移,新技术和产品会迅速地诞生,同时也迅速地更新、淘汰。人的学习能力和聪明才智都是有极限的,到了自己学不动的一天,该何去何从呢?有人说能不能做利润中心,给别的企业提供IT支撑,试问,有几个企业拥有向移动一样规模的IT系统呢?我们要提供外包服务的话,客户是谁呢?那么中国移动有没有可能转型成为一家提供IT基础服务和计算机服务的公司呢?好像不会,至少目前的战略目标和发展都不是朝这个方向走的。于是就出现这样一个问题:我们IT专家的发展和企业的发展并不同步甚至同向,那还能指望企业对你的价值有多认可呢? 所以,近忧就是:如果这些IT专家不转型,那么单纯在IT基础技术方面的发展,会使得这些专家象橙子一样,总有一天被榨干,然后被抛弃,原因嘛,是因为这些“专家”已经根本上企业的发展了,企业有堂而皇之的理由将之淘汰。 面对这些曾经出生入死,给企业带来利益和价值的兄弟,我们能忍心看着他们逐步走向被淘汰的境地么?如果这些人员被淘汰不是因为自身能力不足,而是我们没有在适当的时候给他们适当的转型的机会和空间,那就真是所谓的一将无能,累死三军了。所以我们才说要未雨绸缪,在具备转型条件的时候,鼓励、引导和帮助IT专家转型,使之具备长久的竞争力和生存、发展能力。 向何转呢? 业务部分和支撑部门的关系2前一部分和我们部门转型本来没有直接关系,但是现在看到众多的IT部门和主管都在被这样的问题困扰着,所以还是写出了一些我们的经验和体会。不吃苦中苦,难为人上人,当面对业务部门的时候,确实要掌握技巧的,不要以为短期的胜利和满足感是好事,业务部门当面屈服,意味着他内心的不服气和怨气,一旦有机会,这些“气”是要释放出来的。一线部门压力很大,而这种压力一定要会传递给后面的支撑部门,也许老板会骂一线部门,但毕竟这些部门是直接给公司带来业绩和增长的,所以长期来看,这些部门还是企业领导最偏向的部门,用眼前一场小战斗的胜利换来对方的对立情绪以及长期的PK,不值得啊。 但是这种局面并不是永远不变的。当企业的IT部门逐步形成了规模,并在企业领导和相关部门那里获得了信任之后,这种地位就可能会转变。中国移动的业务支撑部门就在逐步获得这种地位。而当你拥有了这样的条件时候,才发现又面临了一个新问题:洗脑洗过了。也就是说,我们一直强调业务支撑要对业务部门无条件支持,不允许对业务部门说“NO”,结果全国的业务支撑部门都已经习惯于对业务部门和人员的言听计从,习惯于躲在业务部门的后面,当企业的领导征询IT部门的意见时,省业务支撑部门已经很难拥有自己的主见了。 这说明以前的洗脑力度是空前的,效果也是很好的,支撑部门的人员已经渐渐发现服从于业务部门的好处了:第一由于替业务部门挡了很多东西,所以业务部门也不会过分地让支撑部门背黑锅;第二不用承担责任,领导过问的时候可以把问题的源头推给“业务需求”;第三因为业务支撑部门的人员对业务是最熟悉的,可以在财务、计划、业务三个部门之间玩推手或者“移花接木”,总之板子打不到自己。可这是好事么? 如果在一个静态的企业里,这么思考、做事,其实也没什么,这已经是很多IT部门和人员向往的理想工作环境了,还要改变么?改变会不会让自己的境遇变得更糟糕?没有人喜欢变化的,但我想说的是:人无远虑,必有近忧。如果不转型,会如何呢? 业务部分和支撑部门的关系1这是个老话题,也是个困扰IT部门的核心问题,对业务部门,大家往往有很复杂的心态:一方面,业务部门是业务需求提供源,没有业务需求就没有建设的驱动力,就不能说服计划等资源部门提供支持,就谈不上业务支撑系统的发展。中国移动的业务支撑资源就是在强烈的业务需求驱动下,一点点地积累起来的。另一方面,业务部门提出的需求太多了,太怪了,太不合理了,时间要求太紧了,要求变化太大了,等等等等。还有,IT人员自己还有些孤芳自赏:我是名牌大学毕业,我这么强的技术能力是十年寒窗+加班熬夜才积累起来的,而那帮搞业务的人员其实什么都不懂,让他瞎指挥我们,真是浪费我们的青春和热情。 从96年3月邮电部移动通信局计费结算中心成立到现在,中国移动的业务支撑已经经历了11年的发展了。绝大多数的人都难以想象,现在每年投资数十亿的这个专业,最初一期的投资是150万;现在中国移动内部业务支撑人员已有数千,这个产业周围的直接就业人员超过10万,而当初这个部门成立的时候只有7个从学校初出茅庐的年轻人。这只队伍从小到大,已经创造了发展的奇迹,为什么不能在总结、创新的基础上创造新的辉煌呢? 言归正传,还是谈谈IT人员和业务人员的关系问题。业务支撑很弱小的时候,必须隶属于业务部门,借助业务部门才能成长起来,在业务部门的呵护下,为自己争取一些生存的空间,积累资本。饮水思源,不能忘本啊,所以在业务支撑部门独立出来成为一个专业部门的时候,还是要主动、依托市场和业务部门发展,牢固树立以业务部门为客户的服务意识,无论需求多么难实现,都要努力去完成。记得前任业务支撑系统部吴部长打过个比方:就象踢球一样,作为场上的队员,你拼死拼活地努力,一旦做得不好就会挨骂的,好像是最痛苦的了;但是,想想板凳上做的替补,他们恐怕连出场被骂的机会都很难,那他们的心情又如何呢?事实上,如果业务支撑部门不努力,不用服务说服业务部门,恐怕多种多样的外挂就会升级为主力了。只有当IT人员表现得更为专业,服务意识更强的时候,业务部门才会心甘情愿地将系统的建设和开发交给业务支撑部门。 所以计费业务中心在面对业务部门的时候,始终处于一种被动的地位,受着很多委屈,任劳任怨地做了很多工作,但在这个部门很弱小的时候,这种工作态度是让自己得以生存的基础,而只有以生存为前提才能谈发展问题。如何发展呢?就象前面说的,要借助业务部门的需求和帮助,向资源部门争取投资、人员、以及必要的自主管理权限,争取获得周边部门和企业领导的支持乃至信任。枪杆子里出政权,没有雄厚的基础和资源是无法拥有与企业的一线部门平等对话的权力的。 5月24日 需求与实践2
煮鸡蛋的启示 有个英国人学煮鸡蛋,开始,他把鸡蛋放到开水里煮时总会炸裂。他为此想了各种方法,并找到了一个解决方案:在鸡蛋上打个孔。但在鸡蛋上打孔带来了另一个问题:孔打小了,鸡蛋还会裂;孔打大了,蛋清会在它凝固以前流出来。于是,这个英国人给一批鸡蛋分别打了各种不同孔径的洞,并记录下每个鸡蛋孔径的大小。通过这一方法,他找到了一个最合适的大小──既避免了炸裂,又保证蛋清不会流出来。这时,虽然煮鸡蛋炸裂的问题解决了,但这个英国人仍然不知道煮多长时间才能把鸡蛋煮熟。为了解决这个问题,他又开始尝试煮不同时间的结果,并从中找出最佳的时间长度。最后,他终于找到了一个放之四海而皆准的煮鸡蛋的方法。这个案例对很多中国人来说是个可笑的例子。因为聪明的中国人早就知道把鸡蛋放在水中与之一起加热至鸡蛋浮起来就可以了。 从煮鸡蛋这样一个小小的事件上,中国人和英国人体现了两种完全不同的思维习惯──中国人凭借他的聪明直奔结果,而英国人却仔细地把每一个过程细化到最简单,然后按部就班地执行。(管理软件的发展之路 洪奇) 聪明的中国人虽然拥有四大发明,但是对于现代的管理思想,中国人一直没有领会到真谛所在。无论是哪一种的管理方法,过程能力都是特别重要的,虽然生产一件产品的相关人员有千千万万,但是生产出来的产品却只有一种。这种能力并不是从天上掉下来的,是通过制定极为详尽的生产过程规定得到的。在中国接受了ISO的思想之后,这种能力也在国内的制造业中逐渐体现出来。但是在软件行业中,拥有这种过程能力的软件组织仍然是少的可怜,大多数的软件组织奉行的还是一种在八九十年代的个人英雄主义,开发软件单靠个人的力量,能力强的程序员能够成功的完成软件,能力差的则失败。大多数的软件组织中,少数人掌握着代码,他们就是一切,如果他们因为私人原因离开所在的组织,手上的代码则是他们的资本,原有的组织将受到沉重的打击。 中国人热衷于结果,2001年的热点在CMM上,现在还很难说CMM中是不是有一定的泡沫存在,但是可以肯定的一点是,CMM之进入中国软件组织为中国软件工业的发展开创了一个新的时代。中国的软件工业将逐渐摆脱原来的作坊式开发,进入软件工业时代。之所以用软件工业而不用软件产业的原因是希望软件产品能够像工业革命那样进入大规模生产,降低价格的时代。 可惜,软件毕竟不同于工业产品,在工业化生产的过程中,质量检测的一个方法是在产品出厂前设置质量检测,通过质量检测的出厂,否则回收。这种方法无法适用于软件。后来,质量检测逐渐倾向于生产过程,在过程中监测产品质量。这种方法比起前一种方法进步了很多,但是它需要对生产全过程进行追踪。这种方法的思想正是软件过程的质量保证的精髓所在。 在《软件工程》一书中,作者把软件工程分成三层,最底层是软件过程,上一层是软件方法,最高层是CASE工具。软件过程中充满了各种各样的方法论,从需求到最后的维护。要在自己软件组织中应用所有的方法是不可能的。所以你如果看完软件工程的文章后有一种要在明天就实现现代化的冲动的话,打消那种念头,从零做起。 需求过程 需求过程是软件过程的一个很重要的部分。软件项目中百分之四十至百分之六十的问题都是在需求分析阶段埋下的"祸根"(Leffingwell 1997)。我在自己的身边也做过一次小范围的调查,结果显示成功的项目都离不开成功的需求(一个重要的标志是用户的支持)。 需求过程,也有叫做需求工程和需求阶段的,包括了需求开发和需求管理,他们所涉及到的具体工作流如图所示:
需求分析的这个过程,我们可以称它为需求工程,也有叫做需求过程和需求阶段的。需求工程包括了需求开发和需求管理,他们所涉及到的具体工作流如上图标明的那样。 需求过程和CMM 软件工程协会 (SEI Software Engineering Institude) 的能力成熟度模型 (CMM Capability Maturity Model) 提供了一种著名的软件过程成熟度基准。CMM 已经成为了许多领域内的流行工具,用于评估一个组织的软件过程的成熟程度。(更详细的定义和说明请参看《CMM白皮书》)。 CMM中和需求有关系的是第2级(可重复级)中对需求管理的要求和第3级(已定义级)中对需求跟踪能力的要求。必须指出的是,CMM只是规定成熟的软件组织应该达到的关键能力,是一种改进软件过程的策略,对具体的方法并没有做限制规定。所以CMM中没有涉及到需求开发的内容。 需求过程和软件生命周期模型 任何软件都是从最模糊的概念开始的:为某个公司设计办公的流程处理;设计一种商务信函打印系统并投放市场。这个概念是不清晰的,但却是最高层的业务需求的原型。这个概念都会伴随着一个目的,例如在一个"银行押汇系统" 的目的是提高工作的效率。这个目的将会成为系统的核心思想,系统成败的评判标准。99年政府部门上了大量的OA系统,学过一点Lotus Notes的人都发了财(IBM更不用说了),但是更普遍的情况是,许多的政府部门原有的处理模式并没有变化,反而又加上了自动化处理的一套流程。提高工作效率的初衷却导致了完全不同的结果。这样的软件究竟是不是成功的呢? 从概念提出的那一刻开始,软件产品就进入了软件生命周期。在经历需求、分析、设计、实现、部署后,软件将被使用并进入维护阶段,直到最后由于缺少维护费用而逐渐消亡。这样的一个过程,称为"生命周期模型"(Life Cycle Model)。 典型的几种生命周期模型包括瀑布模型、快速原型模型、迭代模型。瀑布模型(Waterfall Model)首先由Royce提出。该模型由于酷似瀑布闻名。在该模型中,首先确定需求,并接受客户和SQA小组的验证。然后拟定规格说明,同样通过验证后,进入计划阶段…可以看出,瀑布模型中至关重要的一点是只有当一个阶段的文档已经编制好并获得SQA小组的认可才可以进入下一个阶段。这样,瀑布模型通过强制性的要求提供规约文档来确保每个阶段都能很好的完成任务。但是实际上往往难以办到,因为整个的模型几乎都是以文档驱动的,这对于非专业的用户来说是难以阅读和理解的。想象一下,你去买衣服的时候,售货员给你出示的是一本厚厚的服装规格说明,你会有什么样的感触。虽然瀑布模型有很多很好的思想可以借鉴,但是在过程能力上有天生的缺陷。
迭代式模型是RUP推荐的周期模型,也是我们在这个系列文章讨论的基础。在RUP中,迭代被定义为:迭代包括产生产品发布(稳定、可执行的产品版本)的全部开发活动和要使用该发布必需的所有其他外围元素。所以,在某种程度上,开发迭代是一次完整地经过所有工作流程的过程:(至少包括)需求工作流程、分析设计工作流程、实施工作流程和测试工作流程。实质上,它类似小型的瀑布式项目。RUP认为,所有的阶段(需求及其它)都可以细分为迭代。每一次的迭代都会产生一个可以发布的产品,这个产品是最终产品的一个子集。迭代的思想如上图所示。 迭代和瀑布的最大的差别就在于风险的暴露时间上?quot;任何项目都会涉及到一定的风险。如果能在生命周期中尽早确保避免了风险,那么您的计划自然会更趋精确。有许多风险直到已准备集成系统时才被发现。不管开发团队经验如何,都绝不可能预知所有的风险。"(RUP)二者的区别如下图所示:
由于瀑布模型的特点(文档是主体),很多的问题在最后才会暴露出来,为了解决这些问题的风险是巨大的。"在迭代式生命周期中,您需要根据主要风险列表选择要在迭代中开发的新的增量内容。每次迭代完成时都会生成一个经过测试的可执行文件,这样就可以核实是否已经降低了目标风险。"(RUP) 快速原型(Rapid Prototype)模型是我喜欢采用的另一种模型。快速原型模型在功能上等价于产品的一个子集。注意,这里说的是功能上。瀑布模型的缺点就在于不够直观,快速原型法就解决了这个问题。一般来说,根据客户的需要在很短的时间内解决用户最迫切需要,完成一个可以演示的产品。这个产品只是实现部分的功能(最重要的)。它最重要的目的是为了确定用户的真正需求。在我的经验中,这种方法非常的有效,原先对计算机没有丝毫概念的用户在你的原型面前往往口若悬河,有些观点让你都觉得非常的吃惊。在得到用户的需求之后,原型将被抛弃。因为原型开发的速度很快,设计方面是几乎没有考虑的,如果保留原型的话,在随后的开发中会为此付出极大的代价。至于保留原型方面,也是有一种叫做增量模型是这么做的,但这种模型并不为大家所接受,不在我们的讨论之内。 上述的模型中都有自己独特的思想,其实现在的软件组织中很少说标准的采用那一种模型的。模型和实用还是有很大的区别的。 软件生命周期模型的发展实际上是体现了软件工程理论的发展。在最早的时候,软件的生命周期处于无序、混乱的情况。一些人为了能够控制软件的开发过程,就把软件开发严格的区分为多个不同的阶段,并在阶段间加上严格的审查。这就是瀑布模型产生的起因。瀑布模型体现了人们对软件过程的一个希望:严格控制、确保质量。可惜的是,现实往往是残酷的。瀑布模型根本达不到这个过高的要求,因为软件的过程往往难于预测。反而导致了其它的负面影响,例如大量的文档、繁琐的审批。因此人们就开始尝试着用其它的方法来改进或替代瀑布方法。例如把过程细分来增加过程的可预测性。 RUP和XP RUP是瑞理(Rational)公司经过不断的实践和理论总结发展出来的一套软件开发统一过程(Unified Process)的思想集和方法集。还记得我们在第一章的那张图吗,那就是RUP的核心图。RUP把软件开发过程分成4个阶段(Phases)和9个核心工作流程(Core Workflows),通过一次次的迭代(Iterations),完成整个的软件生命周期。RUP可以把软件开发过程分到非常细小的单位,每个角色(Workers)都参与活动(Activities),产生出工件(Artifacts)。由于精密的控制,所以RUP可以胜任于超大型的项目开发。虽然RUP定义了很多微小的活动,但是由于CASE工具的使用,它并不会像传统瀑布模型那样陷入文档的海洋中。RUP通过适当的剪裁,同样可以试用于较小型的项目。 XP(Extreme Programming),极端编程。不过好像并没有这样翻译的(听上去像是计算机领域的极右组织)。它是由Kent Beck大师提出的。大师在经历传统软件开发的痛苦之后,希望能够找到一种优秀的软件开发方法。大师总结了大量的软件的成功和失败的因素之后,提出了改进软件开发方法的四个要素:沟通(communication)、简单化(simplicity)、反馈(feedback)、勇气(courage)。这形成了XP的核心价值观。在经历了数年的发展,XP在软件开发的各方面都发展出了众多的方法来支持软件开发。 制定了大量的规则的RUP方法被称为重量级(Heavyweight)的方法,而像XP这样只制定少量的规则来规范行为的方法被称为轻量级(Lightweight)的方法(实际上,现在有一种倾向称这种方法为Agile方法的)。近来,也看到一些文章在讨论两种方法孰优孰劣。例如:XP兴起,RUP不适合中国国情等。我想,这和以前大家讨论C++和Java谁好的性质是一样的。方法都有两面性,只有最适合的方法,没有最好的方法。我在实践中也感觉到,国外的理论确实不能照搬于中国,毕竟中国人的人文环境和国外相差太大了。不过,RUP不适合的,我想,XP也未必会适合。如果说,有人把RUP的一整套东西生搬硬套,导致了最后项目失败的结果的话。这种行为无异于刻舟求剑。 在我看来,RUP就像是一个软件工程思想和方法的大百科全书。在其中,你可以看到诸子百家的论调,可以了解软件工程的整个演化过程。RUP是很值得你投入大量时间去研究的东西的。一个武林高手走进了少林寺的藏经阁,你可以想想,那是一种什么景象。一周只工作40小时。相比较之下,RUP比较适合大企业、大项目,因为大的团队往往需要法制;XP适合于小团队,比较能够发挥小团队的创造力。但是在实际中,也有例外的情况。例如XP方法的第一个项目就是克莱斯勒公司的一个名为C3的大型项目。 在现实中,RUP和XP应用于目前中国的软件企业都有一定的难度。有一些来信来问我,RUP真的适合中国的企业吗?我会直接告诉他们肯定不适合。对RUP这个庞然大物来说,很难去评定它的优和劣。关键在于它裁减以后的样子。我看到过一篇文章,是讨论如何将RUP裁减适合XP思想的方法的。所以RUP的使用要很小心。一个高明的铁匠用铁锤可能可以打出一把好兵器,如果是普通人搞不好就会砸到脚。 提升企业的内力值并不是一两天的事情,这需要长期的投入和锲而不舍的努力。大刀阔斧的引进一整套流程并不是不行,只是猛药伤身这个道理大家也应该懂得。很多年轻有为的软件界人士希望在自己公司中引入先进的开发理念,但是在真正实施时,往往会被碰得头破血流,也有这方面的原因存在。对他们,我是很佩服的。 需求与需求实践1
从猴子说起 有这样一个笑话:一个旅客走进硅谷的一家宠物店,浏览展示的宠物。这时,走进一个顾客,对店主说:"我要买一只C猴。"店主点了点头,走到商店一头的兽笼边,抓出一只猴,递给顾客说:"总共5000美元。"顾客付完款,然后带走了他的猴子。这位旅客非常惊讶,走到店主跟前说:"那只猴子也太贵了!"店主说:"那只猴子能用C编程,非常快,代码紧凑高效,所以值那么多钱。"这时,旅客看到了笼子中的另一只猴子,它标价10000美元。于是又问:"那只更贵了!它能做什么?"店主回答:"哦,那是一只C++猴;它会面向对象的编程,会用Visual C++,还懂得一点Java,是非常有用的。"旅客又逛了一会儿,发现了第三只猴子,它独占一个笼子,脖子上的标价是50000美元。旅客倒抽一口气,问道:"那只猴子比其他所有猴子加起来都贵!它究竟能做什么?"店主说:"我们也不知道它究竟能做什么,不过它是做项目顾问出身的。" 虽然这只是一个笑话,但是有一点是可以肯定的,项目管理是非常重要的,而项目管理的人才又是极为缺乏的。在软件工业发达的国家,大家多少都知道点软件工程规划的重要性。在我们身边的台湾、印度、日本,都不乏因实施软件工程而成功的软件团体,更不用说身为软件大国的美国,已经从较低级的软件实现摆脱出来,进入了设计和营销的境界。 软件首先是一种产品(软件是服务还是产品的问题,向来未有定论),看看世界上制造业的发展历程,就会发现一些很有意思的现象。在本世纪早些的年代,西方国家的制造业经历了规模生产、提高质量等等促进生产力提高的过程。可是由于西方国家的人力资源成本不断的攀升,越来越难降低产品成本,所以西方国家又不可避免的经历了一次将制造业外移的过程(制造业外移的结果是成本大幅下降、国际贸易频繁、接受制造业的国家发展了自身的制造业),而西方国家只留下营销和设计的能力,掌握了产品生产的重点。 同样,IT行业也在经历这种过程:美国将软件外包给印度,硬件外包给台湾。而中国的硬件也在崛起,但是在软件行业,中国和其他国家的差距还是太大了,且不说在软件行业中处于核心地位的操作系统、数据库。即便是应用软件,中国的软件水平也实在低的可怜。在国外制造业刚刚迁移进中国的时候(改革开放),中国的小企业家同样没有任何管理经验、质量意识。但是随着制造业的发展和国外先进思想的进入,中国也诞生了极为出色的全球制造业巨头。而中国的软件行业现在正是处于刚刚有了一点管理思想,但还没有成熟的地步。我们有理由相信,在不久的将来中国也会诞生出出色的全球性软件企业。 憧憬归憧憬,现实的问题还是必须要考虑的。软件这个产品很奇特,软件企业的管理思想同样很奇特。不同于现在企业推崇的各种管理思想,软件企业的管理思想主要是针对项目的管理,确保项目的成功。 项目和需求 笑话里的猴子对应到项目就是指项目管理人员,这里要引入一个角色的概念(同样的人可以担任多种的角色),通常的项目管理角色包括:项目经理、项目复审员、变更控制经理、企业流程分析师、业务模型设计师、需求分析员、需求复审员、系统分析员…在一个成功的项目里,多种角色职责明确,分工合作,共同完成项目的设计实施。那么这?quot;猴子"在项目中都做了些什么呢?RUP(Rational Unified Process 瑞理统一过程,本文采用了众多的RUP的思想)把一个项目分成10个核心工作流程(Core Workflows)和4个阶段(Phases),并以核心工作流程为Y轴,阶段为X轴建立起一个项目视图(图一)。
本文将主要对先启阶段做介绍。在先启阶段,需求是重中之中,这里指的需求不仅仅是RUP的一个工作流程(在业务建模下),而是比较广义的概念,包括了RUP的工作流程中的业务建模、需求、一部分的分析、测试计划、配置和变更管理。 需求是根本 由于忽略需求过程造成的项目返工是恶性的,大量的项目在需求阶段就注定了它的失败。以下是需求过程不科学的典型例子: 1.开发人员在用户处呆了两三天就埋头开发; 2.用户告诉开发人员我要开发一个XX系统,但是我很忙,你先开发一个让我看看; 上面的这两种态度都意味着项目的不成功,应该说上面的开发人员和用户都应该对此负责。需求是开发者和用户交互的一个过程,任何一方的不投入都会导致项目的失败。当然,由于用户不是专业人士,开发者有权利告诉用户应该采用何种态度来对待项目的需求。曾经和几个朋友聊过他们公司开发过的项目,最后得出一个结论,所有最成功的项目都有一个重要的特性:用户非常的支持。 评判一个软件项目成功的标准是看它是否解决了用户的问题,而用户的问题就是体现为用户的需求,需求也就顺理成章的成为项目的成功标准。而需求阶段的一个不慎都有可能导致软件实现阶段的大量返工,而需求的不慎不是说你小心就可以的,因为很多需求是隐性的,连用户都不清楚自己的需求。这时候就需要一种科学的方法来帮助软件组织实施需求过程。 需求是变化的 大师说:"没有不变的需求,世上的软件都改动过3次以上,唯一一个只改动过两次的软件的拥有者已经死了,死在去修改需求的路上。" 目前众多的软件项目有什么样的问题呢?早些时候上ERP的企业在企业发展的时候发现原有的ERP系统需要改进,可是要改进或者是更改现有的ERP系统,唯一的方法就是重新开发一个ERP系统。这对于企业来说是笔不小的支出。此时,落后的信息系统就成为制约企业发展的重要因素。是什么原因造成了这种情况呢?主要的因素是传统的系统分析是在假定需求不变的情况下进行的,这样可以把企业的资源配置到最优的程度。可是在现代瞬息万变的社会,一个企业固守旧有模式,势必会在竞争中处于劣势(因此现在也出现了"组件化"的ERP,这是题外话)。既然企业的需求是变化的、不稳定的,那么以变化的需求为基础建立起来的企业信息系统当然也就不稳定了。这时候,有个问题就产生了,前面我们已经说过,需求是项目的根本,既然需求都是不稳定的,那么何以建立起稳定的企业信息系统呢? 要回答这个问题,首先要比较面向过程和面向对象的开发方法的差别,传统的面向过程的开发方法在前20年大行其道,为中国企业的信息化建设立下了汗马功劳。之所以称为面向过程,是因为开发的焦点集中于过程,开发者集中于以函数为核心的过程,例如前些年很多人试图编写一些通用转账函数来满足银行的需求。面向过程的开发语言包括:Cobol、Pascal、C及C的变形语言。面向对象的概念是在近10年才进入中国的,而它的思想至今也没有真正意义上得到普及。简单的说,面向对象就是面向世界,世界上的任何事物都是对象,因此面向对象是很自然的思想,是符合我们的思维习惯的。面向对象的语言包括了Smalltalk、C++、Java,还有Object Pascal,以及刚刚诞生的C#。 需求是不稳定的,那么需求之中是不是没有稳定的东西呢?有的,就是对象。世界都是由对象组成的,而对象都是持久的,例如动物、植物已经有相当长的时间。虽然对象也在变化,动物,植物也在不断的进化。但对象在一个相当长的时期内都存在,动植物的存在时间肯定比任何一家企党ぞ谩C嫦蚨韵蟮目⒎椒ǖ木杈褪谴悠笠档牟晃榷ㄐ枨笾蟹治龀銎笠档奈榷ǘ韵螅云笠刀韵笪±醋橹枨蟆⒐辜芟低场U庋贸龅南低尘突岜却车南低骋榷ǖ枚啵蛭笠档哪J揭坏┍浠恍枰榷ǖ钠笠刀韵笾匦伦橹托辛恕U庵挚⒌姆椒ň捅怀莆狾OAD(Object Orient Analysis & Design 面向对象的分析和设计),而分析出的企业对象就被称为Common Business Object。 需求是什么 在RUP中定义了需求工作流程的工作目的: 1.客户和其他涉众*在系统的工作内容方面达成并保持一致。 * 涉众:涉众是所有会受到项目结果重大影响的人。如客户(或客户代表) 用户(或用户代表) 、投资者 、股东 、生产经理 、买方 、设计员 、测试员 、文档编写员等。 从上面的目的我们可以大致想到需求过程中要做些什么事。事实上,用简单的话来说明需求过程,就是确定系统该做些什么以及该符合什么条件。话虽然简单,实现起来可没有那么容易。所以科学的需求过程有一整套完整的理论、工具、方法来实现。就像任何企业要盈利都必须要有业务和伴随业务的管理一样,需求过程也分为需求分析过程和需求管理过程。企业的业务是盈利性的,需求分析过程在项目中也是产出型的;企业要保证业务的开展就必须要有管理,而需求分析过程也同样离不开需求管理。小企业没有成为体系的管理方法,企业规模小的时候还能够对付,可是企业一大,各种问题都接踵而来,管理上的不足直接导致了业务开展的低效性。同样,需求管理的不足可能可以应付小型的软件项目,可是对于大型的项目,管理的不足就会暴露出来,而直接的后果就是项目的失败。 插句题外话,很多人认为需求管理的目的是为了控制需求过程,这是没有错,但是在RUP的思想中,更重要的思想是迭代*。迭代的目的是为了发展,为了进化,为了完善。所以RUP中的软件生命周期是分为多个迭代周期的。 * 迭代:迭代包括产生产品发布(稳定、可执行的产品版本)的全部开发活动和要使用该发布必需的所有其他外围元素。所以,在某种程度上,开发迭代是一次完整地经过所有工作流程的过程:(至少包括)需求工作流程、分析设计工作流程、实施工作流程和测试工作流程。实质上,它类似小型的瀑布式项目。 需求分析过程主要做的事情无非就是获取涉众对系统的要求,可是需求是多变的,而你不可能告诉客户等到他们把一切都固定下来再开发软件。所以需求管理过程做的事情就是保证需求变更的可管理性。 需求的层次 《软件需求》一书中有对需求层次的详细定义:
对应到RUP的工作流程,业务需求其实是RUP的业务建模流程(Business Modeling),在这个流程中,参与者主要是业务流程分析员(Business-Process Analyst)。主要的目的是对企业目前的业务流程进行评估,并根据要进行的项目,确定进行何种程度的业务建模(你要做一个ERP项目就意味着你必须优化业务流程,而上一个部门级MIS项目就没有必要用牛刀了)。然后你会得到一个叫做业务前景(Business Vision)的东西,其实就是项目成功后会是个什么样子,并在涉众范围内达成一致。业务需求层次需要投入的精力视具体项目而定,而业务需求的确定对之后的用户需求和功能需求起了限定作用,业务需求就是需求过程的宪法,任何需求不得与之相违背。 到了用户需求层次上(RUP的需求工作流程),重心就转移到如何收集用户的需求上,即确定角色和角色的用例,需求分析是很难的,因为很多需求是隐性的,很难获取,更难保证需求完整,而需求又是易变的。一般来说,在过去作需求分析的时候,更多依靠的是阅读企业的文件,但是企业的文件往往有局限性,例如落后于当前的业务,不够明确,依赖于管理水平的高低,所以后来获取需求的方法逐渐倾向组织访谈会(Interview)。 功能需求依赖于用户需求,可以说是用户需求在系统上的一个映射(Mapping)。开发者思考的角度从用户转移到开发者。在这个层次上,为用户做一个软件原型是一个很不错的主意。直到现在,用户对软件还是没有一个实实在在的概念,如果你给用户一个原型,用户就会说,"哦,我的XX系统原来就是这样的。"这就避免了用户在软件开发完成后才看到软件所带来的一些风险。是否有必要采用快速原型开发法和原型应开发到何种地步取决于具体的项目,很多时候,用一些非正规的方法来生成原型:如果你要开发一个WEB系统,让你的美工做几个页面给用户看看,如果你做一个C/S系统,做一个界面给用户,都已经足够用了,甚至你完全可以在黑板上画一画你将来的软件的面貌都可以。用户大都是比较友善的,不要把问题想的过于复杂。 需求的标准 讨论软件需求的文章有很多,对于需求的标准也不尽相同,但是在思想上是相同,都是为了保证项目的顺利进行。这里我总结一些比较通用的标准,可能并不完善,但你只要能保证做到这几点,你的项目就不容易失败:明确(Clear)、完整(Complete)、一致(Consistent)、可测试(Testable),此外还有其他的概念,如可跟踪、可修改等等。 明确:目前大多数的需求分析采用的仍然是自然语言(因为如果采用形式化语言的话,和用户的沟通将成为一个大问题,这意味着客户在开发软件之前必须先进行形式化语言培训,这是不现实的)。自然语言对需求分析最大的弊病就是它的二义性。所以我们不得不对需求分析中采用的语言做某些限制。例如尽量采用主语+动作的简单表达方式。说白了,需求分析中的描述让人看上去像是刚学习写作的小孩子就对了,千万不要采用疑问句、修饰这些华丽的表达方式。 除了语言的二义性之外,注意不要使用行话,就是计算机术语。需求分析最重要的是和用户沟通,可是用户多半不是计算机的专业人士,如果在需求分析中使用了行话,就会造成用户理解上的困难。 打个比方,如果你要做一个银行的信用卡系统,你就可以这样描述软件需求:银行的卡部管理信用卡,每张信用卡只属于一个帐户。信用卡有卡号、余额。一张信用卡有多笔的交易记录。 完整:再也没有什么比软件开发接近完成时才发现遗漏了一项需求更糟的事情了。需求的完整性是非常非常重要的,想象一下遗漏需求而不得不返工,这简直就是恶梦。可是令人遗憾的是,需求的遗漏是很经常发生的事情,不仅仅是你的问题,更多的问题发生在用户那里,他们不知道该做些什么。要做到需求的完整性是很艰难的一件事情,它涉及到需求分析过程的各方各面,贯穿了整个过程,从最初的计划制定到最后的需求评审。 一致:一致性也是一个比较大的概念,很难用几句话讲清楚。简单的来说,就是用户需求必须和业务需求一致,功能需求必须和用户需求一致。严格的遵守不同层次间的一致性关系,就可以保证最后开发出来的软件系统不会偏离最初的实现目标。在实现过程中,我们还必须把一致性关系细化。比如说用户需求不能超出先前指定的范围。 可测试:大家觉得一个项目的测试从什么时候开始呢?有人说从编码完成后开始。更清楚一点的说是编码的时候同时进行单元测试,编码完成后进行系统测试。这些都没有错。但是实际上测试是从需求分析过程就开始了。需求分析是测试计划的输入和参照。这就要求需求分析是可测试的。什么是可测试呢?quot;我们要用新的系统完成报表自动化处理",你觉得这个需求是可测试的吗?当然不是,报表包括哪些?自动化处理的标准是什么?这些在需求中都没有说明。因此这项需求是无法测试的,就是不具有可测试性。说到这里,大家可能就会明白之前的需求的几项标准都是为了保证需求的可测试性的。事实就是这样,只有系统的所有需求是可以被测试的,才能够保证软件始终围绕着用户的需要,保证软件系统是成功的。 需求工程怎么提需求,提好需求、整理需求、读懂需求是一个软件项目的前期重要阶段。 需求概述 客户和需求 需求获取 需求分析 需求规格 用例技术 需求管理 文档模板 文档实例 需求验证 需求人 需求工具 5月21日 WEB2.0好久没有新Web2.0网站的介绍了,以下的10个网站都是相当的有特色,并且几乎都采用了网页技术,并且非常实用,都是值得一去的地方。
5月19日 中移动、中电信独立互联网公司即将成立如果一切进展顺利,中国移动计划成立的互联网公司“移动互联”公司本月将挂牌.就在上月底,中国电信颁布互联网增值的“新政”,组建一家负责互联网及增值业务的独立子公司.几乎同时,中国网通对外宣布正式启动“视网计划”,并表示将借此驱动视频产业升级.细心的业内人士也许早已经注意到,在2007年互联网大会上,中国移动、中国联通、中国电信和中国网通均发表了各自的互联网战略.此次中国移动、中国电信独立互联网公司的成立,可以看作是前期战略的体现. 为什么移动网络和固定网络运营商会狂飙突进互联网业务?这背后隐藏了运营商怎样的焦灼?独立互联网公司成立后,运营商借助渠道优势是将互联网产业链通吃,还是“安分守己”地做分内之事?抑或成立独立互联网公司只是赶WEB 2.0的时髦? 5月18日 国务院公告国务院公告 5月17日 逆水行舟,不进则退逆水行舟,不进则退 书评人:畅销财经小说《基金经理》作者赵迪 父亲问年幼的儿子:“你的人生目标是什么?” 儿子回答:“金钱和美女。” 父亲清脆的赏了儿子两个耳光,接着问道:“重新回答,你的人生目标是什么?” 儿子捂着脸,支吾道:“事业和爱情。” 父亲满意地点了点头。 这则笑话至少说明,事业和爱情,或许是人生永恒的主题。 最近,清华大学出版社出版了一本商业小说,叫做《无以言退》,描写的正是一个普通的理科硕士生从兼职到求职、从培训到职场、从技术到管理、从国内到海外的职业成长历程。这本财经小说基于现代IT企业背景,以事业和爱情为两条主线,描写了男主人公面对各种环境,以无以言退的信念一步步自我超越和实现价值,最终赢得了真正的爱情,找到了人生坐标。 故事本身并不新鲜,但放在信息化浪潮的大背景下,还是有不少的新意。在这样一个浮躁和迷茫的年代,强调坚持不退却的精神似乎有些不合时宜。然而,对于IT企业而言,这种精神其实是不可或缺的。 古人云:逆水行舟,不进则退。为什么不前进就会后退呢,这里面有一个前提条件,就是“逆水”。那么,顺着流水的方向,不就可以轻松的前进了么?事实并非如此。因为“顺流而下”,顺着流水的方向,只能够越来越向下,不可能登上远方的高峰。 对于每天都要面对外部环境变化和竞争对手威胁的企业而言,就更是如此了。 我并非从事IT行业,但出于证券分析的敏感,我十分关注IT行业的上市公司。从拓普软件到中兴通讯,从歌华有线到同洲电子,国内IT行业的上市公司在不断成长,也在不断的推陈出新。他们当中有的成功坚持了下来,并成长为在世界上都有影响力的企业领袖,有些因为走上弯路,试图通过财务造假来迷惑投资者,最终却折戟沉沙,如今已杳无音信。 这一切,缘自坚持与否。《无以言退》的作者本身从事IT行业十多年,几乎经历了国内高科技、IT行业发展的整个过程,因此有着更加深刻的理解。在作者看来,信息化催生了很多高科技信息行业,铸造了一批著名和有代表性的科技公司,为中国企业的国际化作出了典范和榜样。 从《无以言退》中,我看到了这些企业沉浮起落的影子,只有在正确的时间、选择做正确的事情并坚持到底,才能够在血腥的市场竞争出杀出一条生路。在这些成功企业的背后,则是一批时代的弄潮儿。他们的工作和生活充满压力,他们从事的职业竞争残酷。他们在坚持着、努力着,支撑他们的,正是无以言退的精神。 正如作者所概括的——无以言退是彻底的坚持,低调和真挚的执着,快乐的过程…… 我们每一个人都需要这样的过程…… 5月16日 好领导1、目标明确。请示自己的上司,一定要知道自己岗位的职责,上司的期待,本岗位以前的业绩。了解了知己知彼,明确了奋斗目标,工作才会有了干劲和方向。 2、能干果断。尽快熟悉工作,进入角色,以自己的努力证明自己的胜任和能干。加强工作的预见性,处事一定要果断。一般员工的思想是,胜任工作比我强,我才服;处事果断不武断,我才听。 5月15日 中国民间组织抗震救灾行动联合声明中国民间组织抗震救灾行动联合声明 邀 请 函 5·12汶川地震灾害突如其来,党和政府高度关注,社会各界已经行动起来。 民间组织参与救灾行动是我们义不容辞的责任! 在此,我们呼吁中国民间组织作为一个整体积极参与抗震救灾,以示对政府的支持,对灾区人民的关心! 中国扶贫基金会、中国青少年发展基金会、爱德基金会、中国初级卫生保健基金会、友成企业家扶贫基金会、华民慈善基金会、西部阳光基金会、万通公益基金会、南都公益基金会、中国社会工作者协会、北京华夏经济社会发展研究中心、北京恩玖信息咨询中心等组织起草并发表“中国民间组织抗震救灾行动联合声明”,我们诚邀贵机构共同参与! 如同意参与,请填写下面的反馈表,具体说明贵机构能够采取的行动内容,并尽早发给我们。我们将统计各机构填写的回执,以联合声明的方式,通过媒体向社会公布。 参与抗震救灾行动方式由各家机构自主选择并落实。 热切盼望贵机构的支持与参与!请向相关民间组织推荐。 联系电话:010-51656856-811 传真: 010-59070038 联系人:汪黎黎 手机: 15810716164 |
|
|