2008年8月26日
     摘要: 从网上看到Delphi2009正式发布,很是欣喜,但愿这是一个契机,Delphi能够重筑辉煌! 可是不支持Web开发的Delphi能走多远呢? 以下是转自www.xdowns.com的文章。  阅读全文
posted @ 2008-08-26 22:09 iclotus 阅读(20) | 评论 (0)编辑
  2008年6月5日
创业者必看的小故事
 小故事是父母讲给小孩子听的,但是成人世界更需要这些启示:

  第一个故事:困境即是赐予

  有一天,素有森林之王之称的狮子,来到了天神面前:“我很感谢你赐给我如此雄壮威武的体格、如此强大无比的力气,让我有足够的能力统治这整座森林。”

  天神听了,微笑地问:“但是这不是你今天来找我的目的吧!看起来你似乎为了某事而困扰呢!”

  狮子轻轻吼了一声,说:“天神真是了解我啊!我今天来的确是有事相求。因为尽管我的能力再好,但是每天鸡鸣的时候,我总是会被鸡鸣声给吓醒。神啊!祈求您,再赐给我一个力量,让我不再被鸡鸣声给吓醒吧!”

  天神笑道:“你去找大象吧,它会给你一个满意的答复的。”

  狮子兴匆匆地跑到湖边找大象,还没见到大象,就听到大象跺脚所发出的“砰砰”响声。

  狮子加速地跑向大象,却看到大象正气呼呼地直跺脚。

  狮子问大象:“你干嘛发这么大的脾气?”

  大象拼命摇晃着大耳朵,吼着:“有只讨厌的小蚊子,总想钻进我的耳朵里,害我都快痒死了。”

  狮子一边走,一边回头看着仍在跺脚的大象,心想:“天神要我来看看大象的情况,应该就是想告诉我,谁都会遇上麻烦事,而它并无法帮助所有人。既然如此,那我只好靠自己了!反正以后只要鸡鸣时,我就当做鸡是在提醒我该起床了,如此一想,鸡鸣声对我还算是有益处呢?”

  温馨提示:一个障碍,就是一个新的已知条件,只要愿意,任何一个障碍,都会成为一个超越自我的契机。在人生的路上,无论我们走得多么顺利,但只要稍微遇上一些不顺的事,就会习惯性地抱怨老天亏待我们,进而祈求老天赐给我们更多的力量,帮助我们度过难关。但实际上,老天是最公平的,就像它对狮子和大象一样,每个困境都有其存在的正面价值。

  第二个故事:成功并不像你想像的那么难

  1965年,一位韩国学生到剑桥大学主修心理学。在喝下午茶的时候,他常到学校的咖啡厅或茶座听一些成功人士聊天。这些成功人士包括诺贝尔奖获得者,某一些领域的学术权威和一些创造了经济神话的人,这些人幽默风趣,举重若轻,把自己的成功都看得非常自然和顺理成章。时间长了,他发现,在国内时,他被一些成功人士欺骗了。那些人为了让正在创业的人知难而退,普遍把自己的创业艰辛夸大了,也就是说,他们在用自己的成功经历吓唬那些还没有取得成功的人。

  作为心理系的学生,他认为很有必要对韩国成功人士的心态加以研究。1970年,他把《成功并不像你想像的那么难》作为毕业论文,提交给现代经济心理学的创始人威尔;布雷登教授。布雷登教授读后,大为惊喜,他认为这是个新发现,这种现象虽然在东方甚至在世界各地普遍存在,但此前还没有一个人大胆地提出来并加以研究。惊喜之余,他写信给他的剑桥校友当时正坐在韩国政坛第一把交椅上的人朴正熙。他在信中说,“我不敢说这部著作对你有多大的帮助,但我敢肯定它比你的任何一个政令都能产生震动。”

  后来这本书果然伴随着韩国的经济起飞了。这本书鼓舞了许多人,因为他们从一个新的角度告诉人们,成功与“劳其筋骨,饿其体肤”、“三更灯火五更鸡”、“头悬梁,锥刺股”没有必然的联系。只要你对某一事业感兴趣,长久地坚持下去就会成功,因为上帝赋予你的时间和智慧够你圆满做完一件事情。后来,这位青年也获得了成功,他成了韩国泛业汽车公司的总裁。

  温馨提示:并不是因为事情难我们不敢做,而是因为我们不敢做事情才难的。人世中的许多事,只要想做,都能做到,该克服的困难,也都能克服。只要一个人还在朴实而饶有兴趣地生活着,他终究会发现,造物主对世事的安排,都是水到渠成的

  第三个故事:追求忘我

  1858年,瑞典的一个富豪人家生下了一个女儿。然而不久,孩子染患了一种无法解释的瘫痪症,丧失了走路的能力。

  一次,女孩和家人一起乘船旅行。船长的太太给孩子讲船长有一只天堂鸟,她被这只鸟的描述迷住了,极想亲自看一看。于是保姆把孩子留在甲板上,自己去找船长。孩子耐不住性子等待,她要求船上的服务生立即带她去看天堂鸟。那服务生并不知道她的腿不能走路,而只顾带着她一道去看那只美丽的小鸟。奇迹发生了,孩子因为过度地渴望,竟忘我地拉住服务生的手,慢慢地走了起来。从此,孩子的病便痊愈了。女孩子长大后,又忘我地投入到文学创作中,最后成为第一位荣获诺贝尔文学奖的女性,也就是茜尔玛·拉格萝芙。

  温馨提示:不要把自己当做鼠,否则肯定被猫吃。忘我是走向成功的一条捷径,只有在这种环境中,人才会超越自身的束缚,释放出最大的能量。

  第四个故事:断箭 - 不相信自己的意志,永远也做不成将军

  春秋战国时代,一位父亲和他的儿子出征打战。父亲已做了将军,儿子还只是马前卒。又一阵号角吹响,战鼓雷鸣了,父亲庄严地托起一个箭囊,其中插着一只箭。父亲郑重对儿子说:“这是家袭宝箭,配带身边,力量无穷,但千万不可抽出来。”

  那是一个极其精美的箭囊,厚牛皮打制,镶着幽幽泛光的铜边儿,再看露出的箭尾。一眼便能认定用上等的孔雀羽毛制作。儿子喜上眉梢,贪婪地推想箭杆、箭头的模样,耳旁仿佛嗖嗖地箭声掠过,敌方的主帅应声折马而毙.

  果然,配带宝箭的儿子英勇非凡,所向披靡。当鸣金收兵的号角吹响时,儿子再也禁不住得胜的豪气,完全背弃了父亲的叮嘱,强烈的欲望驱赶着他呼一声就拔出宝箭,试图看个究竟。骤然间他惊呆了。

  一只断箭,箭囊里装着一只折断的箭。

  我一直刳着只断箭打仗呢!儿子吓出了一身冷汗,仿佛顷刻间失去支柱的房子,轰然意志坍塌了。

  结果不言自明,儿子惨死于乱军之中。

  拂开蒙蒙的硝烟,父亲拣起那柄断箭,沉重地啐一口道:“不相信自己的意志,永远也做不成将军。”

  温馨提示:不相信自己的意志,永远也做不成将军。自己才是一只箭,若要它坚韧,若要它锋利,若要它百步穿杨,百发百中,磨砺它,拯救它的都只能是自己。

  第五个故事:再试一次

  有个年轻人去微软公司应聘,而该公司并没有刊登过招聘广告。见总经理疑惑不解,年轻人用不太娴熟的英语解释说自己是碰巧路过这里,就贸然进来了。总经理感觉很新鲜,破例让他一试。面试的结果出人意料,年轻人表现糟糕。他对总经理的解释是事先没有准备,总经理以为他不过是找个托词下台阶,就随口应道:“等你准备好了再来试吧”。

  一周后,年轻人再次走进微软公司的大门,这次他依然没有成功。但比起第一次,他的表现要好得多。而总经理给他的回答仍然同上次一样:“等你准备好了再来试。”就这样,这个青年先后5次踏进微软公司的大门,最终被公司录用,成为公司的重点培养对象。

  温馨提示:什么东西比石头还硬,或比水还软?然而软水却穿透了硬石,坚持不懈而已。也许,我们的人生旅途上沼泽遍布,荆棘丛生;也许我们追求的风景总是山重水复,不见柳暗花明;也许,我们前行的步履总是沉重、蹒跚;也许,我们需要在黑暗中摸索很长时间,才能找寻到光明;也许,我们虔诚的信念会被世俗的尘雾缠绕,而不能自由翱翔;也许,我们高贵的灵魂暂时在现实中找不到寄放的净土……那么,我们为什么不可以以勇敢者的气魄,坚定而自信地对自己说一声“再试一次!”

  再试一次,你就有可能达到成功的彼岸!

  第六个故事:为生命画一片树叶

  美国作家欧;亨利在他的小说《最后一片叶子》里讲了个故事:病房里,一个生命垂危的病人从房间里看见窗外的一棵树,在秋风中一片片地掉落下来。病人望着眼前的萧萧落叶,身体也随之每况愈下,一天不如一天。她说:“当树叶全部掉光时,我也就要死了。”一位老画家得知后,用彩笔画了一片叶脉青翠的树叶挂在树枝上。

  最后一片叶子始终没掉下来。只因为生命中的这片绿,病人竟奇迹般地活了下来。

  第七个故事:跨越自己

  有一天,龙虾与寄居蟹在深海中相遇,寄居蟹看见龙虾正把自己的硬壳脱掉,只露出娇嫩的身躯。寄居蟹非常紧张地说:“龙虾,你怎可以把唯一保护自己身躯的硬壳也放弃呢?难道你不怕有大鱼一口把你吃掉吗?以你现在的情况来看,连急流也会把你冲到岩石去,到时你不死才怪呢?”

  龙虾气定神闲地回答:“谢谢你的关心,但是你不了解,我们龙虾每次成长,都必须先脱掉旧壳,才能生长出更坚固的外壳,现在面对的危险,只是为了将来发展得更好而作出准备。”

  寄居蟹细心思量一下,自己整天只找可以避居的地方,而没有想过如何令自己成长得更强壮,整天只活在别人的护荫之下,难怪永远都限制自己的发展。

  温馨提示:对于那些害怕危险的人,危险无处不在。每个人都有一定的安全区,你想跨越自己目前的成就,请不要划地自限,勇于接受挑战充实自我,你一定会发展得比想像中更好。

  第八个故事:永远的一课

  那天的风雪真暴,外面像是有无数发疯的怪兽在呼啸厮打。雪恶狠狠地寻找袭击的对象,风呜咽着四处搜索。

  大家都在喊冷,读书的心思似乎已被冻住了。一屋的跺脚声。

  鼻头红红的欧阳老师挤进教室时,等待了许久的风席卷而入,墙壁上的《中学生守则》一鼓一顿,开玩笑似的卷向空中,又一个跟头栽了下来。

  乱哄哄的教室静了下来,我们惊异地望着欧阳老师。

  “请同学们穿上胶鞋,我们到操场上去。”

  几十双眼睛在问。

  “因为我们要在操场上立正五分钟。”

  即使欧阳老师下了“不上这堂课,永远别上我的课”的恐吓之词,还是有几个娇滴滴的女生和几个很横的男生没有出教室。

  操场在学校的东北角,北边是空旷的菜园,再北是一口大塘。

  那天,操场、菜园和水塘被雪连成了一个整体。

  矮了许多的篮球架被雪团打得“啪啪”作响,卷地而起的雪粒雪团呛得人睁不开眼张不开口。脸上像有无数把细窄的刀在拉在划,厚实的衣服像铁块冰块,脚像是踩在带冰碴的水里。

  我们挤在教室的屋檐下,不肯迈向操场半步。

  谁也没有吭声,我们老老实实地到操场排好了三列纵队。

  瘦削的欧阳老师只穿一件白衬褂,衬褂紧裹着的他更显单薄。

  后来,我们规规矩矩地在操场站了五分多钟。

  在教室时,同学们都以为自己敌不过那场风雪,事实上,叫他们站半个小时,他们顶得住,叫他们只穿一件衬衫,他们也顶得住。

  温馨提示:面对困难,许多人戴了放大镜,但和困难拼搏一番,你会觉得,困难不过如此。正如生命中的许多伤痛一样,其实并不如自己想像的那么严重。如果不把它当回事,它是不会很痛的。你觉得痛,那是因为你自以为伤口在痛,害怕伤口的痛。

  第九个故事:永远的坐票

  有一个人经常出差,经常买不到对号入坐的车票。可是无论长途短途,无论车上多挤,他总能找到座位。

  他的办法其实很简单,就是耐心地一节车厢一节车厢找过去。这个办法听上去似乎并不高明,但却很管用。每次,他都做好了从第一节车厢走到最后一节车厢的准备,可是每次他都用不着走到最后就会发现空位。他说,这是因为像他这样锲而不舍找座位的乘客实在不多。经常是在他落座的车厢里尚余若干座位,而在其他车厢的过道和车厢接头处,居然人满为患。

  温馨提示:生活真是有趣:如果你只接受最好的,你经常会得到最好的。自信、执着、富有远见、勤于实践,会让你握有一张人生之旅永远的坐票。

  第十个故事:心中的顽石

  从前有一户人家的菜园摆着一颗大石头,宽度大约有四十公分,高度有十公分。到菜园的人,不小心就会踢到那一颗大石头,不是跌倒就是擦伤。

  儿子问:“爸爸,那颗讨厌的石头,为什么不把它挖走?”

  爸爸这么回答:“你说那颗石头喔?从你爷爷时代,就一直放到现在了,它的体积那么大,不知道要挖到到什么时候,没事无聊挖石头,不如走路小心一点,还可以训练你的反应能力。”

  过了几年,这颗大石头留到下一代,当时的儿子娶了媳妇,当了爸爸。

  有一天媳妇气愤地说:“爸爸,菜园那颗大石头,我越看越不顺眼,改天请人搬走好了。”

  爸爸回答说:“算了吧!那颗大石头很重的,可以搬走的话在我小时候就搬走了,哪会让它留到现在啊?”

  媳妇心底非常不是滋味,那颗大石头不知道让她跌倒多少次了。

  十几分钟以后,媳妇用锄头把大石头四周的泥土搅松。

  媳妇早有心理准备,可能要挖一天吧,谁都没想到几分钟就把石头挖起来,看看大小,这颗石头没有想像的那么大,都是被那个巨大的外表蒙骗了。

  温馨提示:阻碍我们去发现、去创造的,仅仅是我们心理上的障碍和思想中的顽石。

  你抱着下坡的想法爬山,便无从爬上山去。如果你的世界沉闷而无望,那是因为你自己沉闷无望。改变你的世界,必先改变你自己的心态。

  第十一个故事:驴的哲学

  有一天某个农夫的一头驴子,不小心掉进一口枯井里,农夫绞尽脑汁想办法救出驴子,但几个小时过去了,驴子还在井里痛苦地哀嚎着。

  最后,这位农夫决定放弃,他想这头驴子年纪大了,不值得大费周章去把它救出来,不过无论如何,这口井还是得填起来。于是农夫便请来左邻右舍帮忙一起将井中的驴子埋了,以免除它的痛苦。

  农夫的邻居们人手一把铲子,开始将泥土铲进枯井中。当这头驴子了解到自己的处境时,刚开始哭得很凄惨。但出人意料的是,一会儿之后这头驴子就安静下来了。农夫好奇地探头往井底一看,出现在眼前的景象令他大吃一惊:

  当铲进井里的泥土落在驴子的背部时,驴子的反应令人称奇──它将泥土抖落在一旁,然后站到铲进的泥土堆上面!

  温馨提示:人生必须渡过逆流才能走向更高的层次,最重要的是永远看得起自己。就如驴子的情况,在生命的旅程中,有时候我们难免会陷入“枯井”里,会被各式各样的“泥沙”倾倒在我们身上,而想要从这些“枯井”脱困的秘诀就是:将“泥沙”抖落掉,然后站到上面去!

  第十二个故事:成功就是简单的事情重复做、重复做

  全国著名的推销大师,即将告别他的推销生涯,应行业协会和社会各界的邀请,他将在该城中最大的体育馆,做告别职业生涯的演说。

  那天,会场座无虚席,人们在热切地、焦急地等待着,那位当代最伟大的推销员,作精彩的演讲。当大幕徐徐拉开,舞台的正中央吊着一个巨大的铁球。为了这个铁球,台上搭起了高大的铁架。

  一位老者在人们热烈的掌声中,走了出来,站在铁架的一边。他穿着一件红色的运动服,脚下是一双白色胶鞋。

  人们惊奇地望着他,不知道他要做出什么举动。

  这时两位工作人员,抬着一个大铁锤,放在老者的面前。主持人这时对观众讲:请两位身体强壮的人,到台上来。好多年轻人站起来,转眼间已有两名动作快的跑到台上。

  老人这时开口和他们讲规则,请他们用这个大铁锤,去敲打那个吊着的铁球,直到把它荡起来。

  一个年轻人抢着拿起铁锤,拉开架势,抡起大锤,全力向那吊着的铁球砸去,一声震耳的响声,那吊球动也没动。他就用大铁锤接二连三地砸向吊球,很快他就气喘吁吁。

  台下逐渐没了呐喊声,观众好象认定那是没用的,就等着老人做出什么解释。

  会场恢复了平静,老人从上衣口袋里掏出一个小锤,然后认真地,面对着那个巨大的铁球。他用小锤对着铁球“咚”敲了一下,然后停顿一下,再一次用小锤“咚”敲了一下。人们奇怪地看着,老人就那样“咚”敲一下,然后停顿一下,就这样持续地做。

  十分钟过去了,二十分钟过去了,会场早已开始骚动,有的人干脆叫骂起来,人们用各种声音和动作发泄着他们的不满。老人仍然一小锤一停地工作着,他好象根本没有听见人们在喊叫什么。人们开始忿然离去,会场上出现了大块大块的空缺。留下来的人们好象也喊累了,会场渐渐地安静下来。

  大概在老人进行到四十分钟的时候,坐在前面的一个妇女突然尖叫一声:“球动了!”刹时间会场立即鸦雀无声,人们聚精会神地看着那个铁球。那球以很小的摆度动了起来,不仔细看很难察觉。老人仍旧一小锤一小锤地敲着,人们好象都听到了那小锤敲打吊球的声响。吊球在老人一锤一锤的敲打中越荡越高,它拉动着那个铁架子“哐、哐“作响,它的巨大威力强烈地震撼着在场的每一个人。终于场上爆发出一阵阵热烈的掌声,在掌声中,老人转过身来,慢慢地把那把小锤揣进兜里。

  老人开口讲话了,他只说了一句话:在成功的道路上,你没有耐心去等待成功的到来,那么,你只好用一生的耐心去面对失败。

  温馨提示:很多的人以为成功很难,成功要付出太多、成功会很痛苦,就不去想和追求。实际上,只要我们注意观察,就会吃惊地发现,那些生活在贫困线上的人才是真的有耐心,有吃苦耐劳的品质,他们正是以这种惊人的耐心忍受着不成功的现实和生活。你可以不思成功,但你的生活并不会因此而轻松。你追逐成功,你会因此而生活得更好。

posted @ 2008-06-05 13:00 iclotus 阅读(32) | 评论 (0)编辑
  2008年5月13日
@@SERVERNAME : 返回运行SQL Server 2000本地服务器的名称。
  1. @@REMSERVER : 返回登录记录中记载的远程SQL Server服务器的名称。
  2. @@CONNECTIONS : 返回自上次启动SQL Server以来连接或试图连接的次数,用其可让管理人员方便地了解今天所有试图连接服务器的次数。
  3. @@CURSOR_ROWS : 返回最后连接上并打开的游标中当前存在的合格行的数量。
  4. @@ERROR : 返回最后执行的Transact-SQL语句的错误代码。
  5. @@ROWCOUNT : 返回受上一语句影响的行数,任何不返回行的语句将这一变量设置为0。
  6. @@VERSION : 返回SQL Server当前安装的日期、版本和处理器类型。
  7. @@CPU_BUSY : 返回自SQL Server最近一次启动以来CPU的工作时间其单位为毫秒。
  8. @@DATEFIRST : 返回使用SET DATEFIRST命令而被赋值的DATAFIRST参数值。SET DATEFIRST命令用来指定每周的第一天是星期几。
  9. @@DBTS : 返回当前数据库的时间戳值必须保证数据库中时间戳的值是惟一的。
  10. @@FETCH_STATUS : 返回上一次FETCH语句的状态值。
  11. @@IDENTITY : 返回最后插入行的标识列的列值。
  12. @@IDLE : 返回自SQL Server最近一次启动以来CPU处于空闭状态的时间长短,单位为毫秒。
  13. @@IO_BUSY : 返回自SQL Server最后一次启动以来CPU执行输入输出操作所花费的时间(毫秒)。
  14. @@LANGID : 返回当前所使用的语言ID值。
  15. @@LANGUAGE : 返回当前使用的语言名称。
  16. @@LOCK_TIMEOUT: 返回当前会话等待锁的时间长短其单位为毫秒。
  17. @@MAX_CONNECTIONS : 返回允许连接到SQL Server的最大连接数目。
  18. @@MAX_PRECISION : 返回decimal 和 numeric数据类型的精确度。
  19. @@NESTLEVEL : 返回当前执行的存储过程的嵌套级数,初始值为0。
  20. @@OPTIONS : 返回当前SET选项的信息。
  21. @@PACK_RECEIVED : 返回SQL Server通过网络读取的输入包的数目。
  22. @@PACK_SENT : 返回SQL Server写给网络的输出包的数目。
  23. @@PACKET_ERRORS : 返回网络包的错误数目。
  24. @@PROCID : 返回当前存储过程的ID值。
  25. @@SERVICENAME : 返回SQL Server正运行于哪种服务状态之下:如 MS SQLServer、MSDTC、SQLServerAgent。
  26. @@SPID : 返回当前用户处理的服务器处理ID值。
  27. @@TEXTSIZE : 返回SET语句的TEXTSIZE选项值SET语句定义了SELECT语句中text或image。数据类型的最大长度基本单位为字节。
  28. @@TIMETICKS : 返回每一时钟的微秒数。
  29. @@TOTAL_ERRORS : 返回磁盘读写错误数目。
  30. @@TOTAL_READ : 返回磁盘读操作的数目。
  31. @@TOTAL_WRITE : 返回磁盘写操作的数目。
  32. @@TRANCOUNT : 返回当前连接中处于激活状态的事务数目。
posted @ 2008-05-13 09:04 iclotus 阅读(32) | 评论 (0)编辑
  2008年3月10日

  

想首先问大家一个问题:你觉得中国人聪明还是美国人聪明?
    我见过最好的回答是美籍华人。我们说美国人很愚蠢,为什么呢?你们都考过T或G吧,他们经常会出这么一道题1/3+1/2=? 50%的人回答是2/5,这可是美国研究生入学考试的试题呀!通常在这个问题之前还有一个1/2+1/2=?为什么?他们怕太难了,先给个容易的热身一下。我在美国的时候见过很多的PHD,对于美国人来说if...else...是逻辑,而if...if...else...就成了哲学,也是美国这么多哲学博士的原因:)我们说美国人很愚蠢,那我们为什么还要学习他们呢?这个问题稍候我们会回答。再问一个问题:如果你刚买了一个豪华的房子,可你三岁的儿子把整个墙壁上都写上“我爱长城永不到,我爱北京天安门”,你该怎么做?有的女孩子说暴打,呵呵,这个答案从女生的嘴里说出来还是比较少见。
      美国人怎么办?他们会对孩子说:“你老人家真有绘画的天赋,简直就是毕加索的毕加索,你这一幅画至少能卖100万美金”你们知道美国人喜欢钱,用金钱来量化一定是效果明显。但显而易见,您老人家把画画在墙壁上是不能永久保存的,所以我明天给你买一个画布,你就尽情的画吧。否则我们要损失多少个毕加索呀!于是我们就可以看见我们的小宝贝在画布上快乐的滚来滚去。墙面也干净了。(注:国人是暴力强制,美人是引导)
      中国人很聪明,从大家就可以看出来,但中国人聪明做工作就有了聪明的做法,他们往往是每个项目都是按照自己的见解来做。而美国人如何来操作呢,他们就象洗澡,会在面前挂一张纸,上面写着先洗头,再洗耳朵,再细脸,,,这样做事情就有了一定的流程,渐渐的就形成了一套体系。所以这也是我们今天来探讨项目管理的目的所在。    项目管理分九个知识领域,分别是成本管理质量管理时间管理范围管理人力资源管理沟通管理风险管理采购管理整体管理。其中时间,质量和成本管理构成了三角形大家在纸上画一个三角形在各个边上标上时间、质量、成本(等边三角形)任何一方的移动必定带动其他的变形,如果时间缩短,怎么样?就是我们常说的“献礼工程”,同时必定会影响质量和成本。问大家一个问题,这个三角形中间是什么东东?对,是范围管理,也就是我们说的项目范围。这也就是我们常说的项目“项目管理三角形”

下面介绍一下项目管理的“项目管理三角形“
项目三角形中的成本,主要来自于所需资源的成本,自然也包括人力资源的成本。这个相信很好理解。为了缩短项目时间,就需要增加项目成本(资源)或减少项目范围;为了节约项目成本(资源),可以减少项目范围或延长项目时间;如果需求变化导致增加项目范围,就需要增加项目成本(资源)或延长项目时间通过“项目管理三角形“我们了解了项目成本、时间,质量和范围的简单定义。我们说一个项目经理有多少时间是用来做沟通的工作的?应该不少于75%的时间是用来沟通的所以项目管理将项目沟通管理单独列了出来。所有这些领域都有一个主线就是项目的整体管理来统一的。由于时间的限制我们不详细讨论其他的知识领域,因为今天是入门的,哈哈另外项目管理除了九个知识领域,还应该了解5个过程组
5个过程组就是:启动,计划,执行,控制,收尾。这5个过程组贯穿于每个知识领域的始终,你们了解吗?举个例子字来说某人(比喻)好不容易找了个女朋友,为了增进进一步的距离,他想来个欧亚8日游,于是他把自己多年的积蓄——3万元,一次性投入。但在旅游过程中,他的MM看上了另外一个帅哥,于是人财两空,说明什么问题?说明他的项目启动的时候就出现了问题,没有很好的做市场调研,结果过程就没有办法控制。根据PMI的解释,接单之后项目自然转入启动阶段于是他刻苦的工作,终于又攒了3万,这次他不和美女旅游了,考虑到自己的费用,他请这个姑娘看了场电影。于是他带这个这个姑娘看了——《第一滴血》看的那叫爽,姑娘看的也很爽,看看完后她觉得这个家伙有暴力倾向,于是又分手。说明什么问题?对,没有进行有效的需求调查,也就是在计划的时候没有明确的需求定义。于是他下次的时候知道了姑娘爱看歌舞剧,于是他就请一个靓女看了《天鹅湖》,可是以外有发生了——
进去后发现座位不在一起,等他们把位子换到一起的时候歌舞剧结束了,这说明什么?对,说明没有很好的执行,起码在执行过程中没有进行有效的监督。其他的过程不一一解释,我在这里强调的是收尾的重要性。我们往往非常注重合同性收尾,却总是忽略管理性收尾。什么是管理性收尾呢?某人同志吸取了所有的经验教训,终于领了结婚证,还应该干些什么呢?对了,还应该把所有的经验教训总结一下,以书面的形式汇报给老妈,并张贴于门后。然后在中堂挂一幅对联:欲谈恋爱者需先阅读门后之——《恋爱指南》以后凡是自己的兄弟姐妹要谈恋爱的,必须先参阅门后的恋爱指南。这样能起到什么效果呢,对,以后他们的恋爱项目操作至少能停留在这个水平。这个过程怎样来保证呢,对,还需要我们的QA人员,也就是他的妈妈负责质量控制。家规一条,不参阅者或不照此操作者不许谈恋爱!大公司一般有质量管理部门(QA),QA的成员基本上都是由非常有经验的PM转型过来的老狐狸,是老总接班人的有力争夺者:)这也是我们说一个失败的项目会培养一批优秀的项目经理的原因。
哪个门后的《恋爱指南》我们称之为文档,文档重要吗?我们说在电信科技处的同志们说重要,为什么因为他们管这个,但对于我们呢?大家拿起你身边的一只笔,告诉我他多长?有的说10厘米,有的说10。0987厘米。我们说他的估算很精确,但不准确!!这是我如果拿一只笔告诉你正好10厘米,然后和你的笔比对你是不是就比较容易得出测算?这说明文档是非常重要的,有的人认为文档是最无聊的,项目结束后做个总结不就是了吗。错,文档的整理应该贯穿于项目管理的始终。文档的管理是对项目进行良好的跟踪和监控的一个手段,简单的讲就是根据你的项目计划进行你的文档管理。一般档案分类主线是:立项、计划、执行、结束4大类;然后在每大类中,再根据任务或者团组分类管理,根据哪个需要根据你项目复杂程度和管理习惯,总之原则是方便你对整个项目进度的追踪。以上我们讲了项目管理的九个知识领域,五大过程组,还有“项目管理三角形“,下面我们讲PMBOK。
PMBOK是项目管理圣经,也就是Project management body of
knowledge,项目管理知识体系指南它是美国项目管理协会(PMI)的核心指导出版物但它象一本字典,往往你看到第三页会睡着:)在此简单介绍美国项目管理协会(PMI)和国际项目管理协会(IPMA)美国项目管理协会只有PMP一个证书,而IPMA有四级,你可以一毕业就可以考试,这个我们后面详细的讲。
下面讲几个名词,如果你掌握了,一和人讲项目管理你就抛出来,一定没有人敢小看你。
他们是WBS、甘特图、基准(BASELINE)、项目干系人和关键路径
WBS是WORK BREAKDOWN STRUCTRE ,工作分解结构
    WBS的定义还是很麻烦的,PM要召开团队进行讨论,向成员提供与项目相关的所有详细资料,并把WBS树分解到二层三层。然后要花上一段时间让成员
进行头脑风暴式(BRAINING STORM)思考,制订工作产出和相应人员的职责,记录每一个工作包的完成标准。比如我们要结婚了,怎么来分解呢无非是办酒席,拍结婚照,,等等,这个在论坛上曾有人做了详细的分解,大家都可以找到。我们说为什么WBS重要,而且大部分项目管理的咨询都是针对WBS的咨询因为WBS做好了,以后工作就有了参考物,你就知道在不同的阶段你应该干什么,完成到什么进度。其实WBS的划分是没有规则的,主要的考虑角度是方便你做各类的统计工作,为管理服务。同样的一个项目其管理的侧重点不同,WBS结构的划分也可能是完全不同的。衡量划分好坏的标准应该是看其是否满足你管理的需要。
甘特图也叫横道图等,很多名称,我们说它是甘特在第一次世界大战时开始使用,它就是在WBS的基础上将WBS形象化老控制进度
对于基准,我象举个例子。我们在没有结婚之前,你脚踩几只船?我们说法律允许但道德不允许,但你可以脚踩N只船:)但当有一天你和你的朋友进了一个小黑屋子,然后带了两个盖章的本本的时候,你还可以脚踩N只船吗?我们说此时就不允许了,因为你过了一个基准线(BASELINE)如果你还想脚踩N只船就需要重新回小黑屋子再盖两个章就可以了。那我们的项目要越轨怎么办,也就是项目变更?我们说对这样的项目变更会影响各要素比如时间,成本,质量等我们应该统一由项目管理办公室来进行控制,如果你要变更基准,必须要进行严格的限制。在客户提出变更请求时,要建立变更申请登记表和变更申请
表,并让客户签字。有时候一些不是非常关键的模块PM也不至于一点不讲情面,该卖面子的时候还是要卖,尤其是当着对方领导的面,千万要
卖面子,但是也别卖的太干脆,不要让他们得到的太容易。 PM在变更管理中需要做的是分析变更请求,评估变更可能带来的风险和修改基准文件。
如果一个项目进行过程中,比如现在的点心的3G项目,你发现如果再多花一点时间就可以编写出对以后非常有用处的程序,但这个程序不在本项目范围之内,你要不要做?对,我们说不能做,你可以重新起一个项目来做,但不能在这个项目里做,这样会是我们的项目成本超出,风险增加,而且和其他的项目缺少比对性和参照的价值。
这也是我们说现在有大约80%以上的项目失败的原因,我们说项目失败并不是项目进行不下去了,彻底破产,在PMI有明确的定义,凡是项目的成本超出预算,质量没有得到保证,时间超过预计等等都在失败的范围之内。这个在华为做的很好,华为有个有名的增量开发的名声。只用20%的功能先满足你80%的需求,其他的功能我可以开发升级的版本,于是就在小数点后平明的增加数字,于是就是了V1,V1.1,V1.11....等版本它从来不一下子满足你所有的需求,我们大家想想,谁没有事情拿出自己的手机把所有的PING码都试用一下,我们说没有,我们大部分的需求是在打电话,发消息,打打游戏,对不对?这点在项目管理中非常重要,请大家结合资料好好研究。
项目干系人是什么东东,谁给我举一个例子?对,包括项目人员的老婆孩子,正确我们说有的项目需要的时间很紧张,如果你的项目成功了,但项目的程序员们都成了光棍,那项目还是非常失败,至少不是丧心病狂的PM这么想。合理解决项目干系人的冲突是个很累的问题,其中还包括你的只能经理们,你的董事长,你的客户,等等,等等,有的说没用?好,如果你的项目进展不下去,你该怎么办?对,开会,把你的高层找一个坐到会议室,不用他说话,只让他暧昧的看着大家,大家一定会想,这个家伙一定和领导有关系,我们还是好好的做这个项目,下一个项目再给他使拌子吧:)所以为了不累死好好分析一下你的项目干系人吧我们上次讲了一些基础的知识,包括什么是项目管理,项目管理包括什么?
你说项目管理有几个知识领域?你说项目管理有几个过程组?让我们想起了泡MM的例子是不是?还有老母亲做QA的比喻几天我们着重强调的是
项目是什么?人们常用“时间”,“资源(或缺乏资源)”,“某种工作努力”,“交付物或者产品”,“综合工程”,“缺乏凌驾其他班组的职权”,以及“预算”来给它下定义。实际上,项目是一种独特的工作努力,即遵照某种规范及应用标准去导入或生产某种新产品或某项新服务。这种工作努力应在限定的时间、成本费用、人力资源及资财等项目参数内完成。
首先给大家一个项目的定义,到底什么是项目?根据PMPBOK的定义,项目是在一段时间内为完成某一独特的产品或提供独特的服务所进行努力的过程。这个过程受到时间、人力、资源、成本、质量上的限制项目有几个特征:
1.临时性
2.独特性
3.一次性下面大家告诉我下面哪个是项目:A惠普与康柏机构重组惠普与康柏机构重组。B建造一座新工厂 C改建道路 D工程材料采购 E开发软件包 F结婚典礼 G寻找拉登有人说是寻找拉登,大家说寻找拉登有明确的结束时间吗?当然我们可以假设寻找拉登50年如果找不到,项目就结束是不是?所以说我们今天不讨论哪个到底是项目,所有的问题都要放到具体的环境下,否则没有意义。
下面大家可以开始提问了。
什么是WBS呢?
WBS是工作分解结构,就象一张道路交通图,它能够指引你如何从当前位置到达想去的地方。没有它,你可能就要迷路了。怎样来做一个好的WBS呢?有时候在接受新项目时前无例子可借鉴感觉分解时真困难,
因为每个人的解决问题思路不同,同一个项目不同的人有很多种分类, 因为可以按照工作的流程分解,也可以按照系统论的方法进行结构上的分解,
但我觉得有一条很重要的原则应该注意,那就是麦肯锡的精髓,他们在分解工作时非常强调的就是MECE, muturally exclusive,
collectively exhaustive, 即相互独立,完全穷尽的原则, 也就是现在较流行的说法"横向到底,纵向到边" , 如果分解时坚持了这个原则,
我想一定会有Perfect 的WBS, 其实WBS并非是PMI的"真传", 只是被PMI起名为WBS,
有时候工作中我们也会用类似的方法解决问题无非是没有提升到理论高度, 但WBS确实是做事的核心步骤。做一个WBS需要注意一些什么问题呢? ?
第一级通常与项目生命周期相同(如需求分析,设计,采购,施工……) ? 第一级应在项目进一步分解前完成 ? WBS的每一级都是其上一级的片断(Segment) ?
一个工作单元只与一个上层单元相关 ? 上层单元的工作内容应该等于其所有直接下层工作单元的总和 ? 一个工作单元由一个人负责 ?
在整个WBS中使用同一种定义,在整个组织中亦然 ? 通过将人员包括进WBS来激励他去完成计划什么是甘特图呢? 1.以图形或表格的形式显示活动。
2.现在是一种通用的显示进度的方法。 3.构造时应包括实际日历天和持续时间。不要将周末和节假日算在进度之内
什么是风险呢?
首先问一个问题你们说在一个项目中,初始阶段和结束阶段哪个时候项目的风险大?对,是开始的时候,因为在开始的时候我无数的不可控制的因素。那什么阶段的损失大呢?对,在结束的时候,所以说两者是相反的/
所以说在项目的启动阶段成功的可能性最小,风险发生的概率也就最高,但是这时候一旦预计的风险发生了,损失是最小的。想想广州和深圳很多烂尾楼?损失会有多少???!!!!!
另外我们要明确几个定义:

1是确定性。具有明显的可能性,比如中国和韩国对抗赛,胜负是很明显的:) 2是风险。韩国队能赢中国队几个球是一种风险的预测。
3是未知性。中国和美国比赛门球那就是未知的:)

posted @ 2008-03-10 22:47 iclotus 阅读(43) | 评论 (1)编辑

让你的创业失败的18个昏招
  原作者: Paul Graham  原文  译者: 拙尘  12/21/2006 

在最近的一次演讲中,有人问我,哪些错误会导致创业失败。站在那里愣了几秒后,我意识到,这是一个很难回答的问题。它等于是在问:一个初创公司如何才能成功。如果你能避免所有导致失败的错误,那么你自然就会成功。这个问题太大了,很难在那样短的时间里回答清楚。

后来我又认识到,这个问题如果从另一个角度看,也许是有意义的。假如你有一个清单,列出了所有你不应该做的事情,那么只需要把这个清单取反,你就得到了一张成功的处方。而在实际应用中,这样的清单会更有价值。查觉你正在做不应该做的事情,总比一直记着你应该做的事情更容易些。[1]

从某种意义上说,导致创业失败的错误只有一个:没人需要你做的东西。如果你在做的东西是用户需要的,那么你应该能够生存下去,其它的问题都无关紧要。但如果你在做的东西不符合用户的需求,那么你死定了,任何事都改变不了这个结局。所以,这个清单里列出的18个错误,实际上是导致初创公司不能满足用户所需的因子。几乎所有失败的原因,都可以归结到这里面来。

1 孤家寡人 (Single Founder)

不知你是否注意到,极少有成功的初创公司是由一个人创办的?一些你可能会以为是单一创始人的公司,比如说甲骨文(Oracle),实际上是由多个人一起创办的。这似乎不是一个巧合。

单一创始人有什么问题呢?最起码,这反映了一种信心的缺乏。隐含的信息是,创始人无法说服他的任何一个朋友跟他一起打天下。这很值得玩味:别忘了,他的朋友是最了解他的人。

就算朋友们都错了,公司实际上可能很有前途;但是,单一创始人的不利仍然是很明显的。一个人创业实在太难了。就算你无所不能,你也需要同伴们来集思广益,避免愚蠢的举动,以及在遇到挫折时互相鼓励。

最重要的一点是,创业的过程中你可能遇到难以承受的低点。当你有多个创始伙伴时,彼此信念上的支撑就好比捆成了一捆的箭。每个人都暗暗给自己打气:“我绝不能让我的朋友们失望。”这是一个人最强大的动力之一。而单一的创始人则缺少了这一动力。

2 缺少地利 (Bad Location)

并不是所有的地方都适合创业的。硅谷是创业的最佳地点,波士顿其次,再其次是西雅图、奥斯汀、丹佛和纽约。除此之外,几乎没有什么其它的选择了。就算在纽约,初创公司的密度也已经降到了硅谷的二十分之一左右。而在像休斯敦、芝加哥和底特律这样的地方,创业的可能性几乎可以忽略不计。

为什么会有这么大的差别呢?其实,其它的业界也有类似的情况。全美第六大的时装中心在哪儿?第六大的石油,金融,出版中心又分别是哪里?不管答案是什么,可以肯定,这些中心的规模要远远小于榜首的规模。

为什么某些城市会成为初创公司的聚集地呢?这个问题很有意思。我想答案与在其它业界得出的结论类似:因为那里聚集了大批的专业人士。那里的专业水准较高;人们对你所做的东西更容易产生共鸣;你能更容易地找到你想要雇用的人;周边工业也较发达;你有更多的机会碰上跟你在一个领域内的人;等等,等等。天知道这些综合因素是怎样促成了初创公司在硅谷的繁荣,又是怎样让底特律这样的城市黯然失色。不过,数字能够说明一切:在硅谷的初创公司密度远远超出了在底特律得到的数字。

3 领域偏狭 (Marginal Niche)

在向 Y Combinator 申请风投的团队里,大多数都犯了一个共同的错误:为了避免竞争而刻意选取那些很狭隘、很冷僻的领域。

如果你看过孩子们打棒球的话,你会发现,在某个年龄段以下的孩子会有些怕球。面对来球,他们的本能反应是躲避。我在八岁的时候当过外野手,不过没有接到过多少球,因为每次球朝我飞来的时候,我总是闭上眼睛,举起手套来保护自己,而不是去力争接到球。

一个初创公司,如果净是挑选那些偏狭的项目来做的话,就跟我在八岁时对付来球的策略一样。要知道,如果你能够有所成就的话,就必然会有竞争者,早晚都要面对。所以说,如果你不想竞争的话,那么你想出来的点子好不到哪儿去。

我想,这种遇到大的困难就退缩的举动,往往是人们在潜意识下作出的。这跟你有一个很大的构想但却决定追求一个较小的较稳妥的目标不同,因为你在潜意识里就拒绝大的构想。解决这一问题的办法是假装你在为别人而不是为自己做策划。想想看,有什么好的主意适合某人去进行创业呢?

4 拾人牙慧 (Derivative Idea)

我们收到的许多申请都是在效仿一些已经存在的公司。现有的公司的确能够给你一些想法,但绝对不是最好的。如果你回顾一下那些成功的初创公司,很少是从模仿别人起家的。他们的灵感来自哪儿呢?通常是由创始人发现了一些尚未解决的特定问题。

我们自己的初创公司的业务是编写软件,使之能够生成在线商店的网站。当初我们是独此一家;少数几家支持在线交易的网站都是由互联网的专业设计人员手工编写的,成本很高。我们认识到,一旦在线购物红火起来的话,这些网站必然是要由软件来生成的,所以我们就写了这样一个软件。这个想法的起源很直接,如此而已。

那些对你个人产生影响的问题应该是最好的问题。苹果(Apple)的诞生是因为斯蒂夫·沃兹尼亚克(Steve Wozniak)需要一台电脑;谷歌(Google)则是由于拉瑞(Larry)和谢尔盖(Sergey)在网上找不到他们想要的东西;而 Hotmail 是因为沙比尔·巴蒂亚(Sabeer Bhatia)和杰克·史密斯(Jack Smith)无法在工作中互发电子邮件。

所以,不要去照搬 Facebook,在上面做些零敲碎打的工作;你应该到别的方向上去发掘灵感。也不要受已有的公司的影响,去炒他们的冷饭;你应该去找寻未解决的问题,然后设想一下什么样的公司能够解决那些问题。[2] 你需要弄清楚,人们在抱怨什么以及期待什么?

5 固执己见 (Obstinacy)

在某些领域里,成功的途径需要你认准了想做的事情并坚持到底,不管遇到多大的挫折。而创业则另当别论。如果你是想要赢得一块奥林匹克金牌的话,那么你应该咬定目标,决不放弃;因为你的目标十分明确。但是,创业更像是从事科学研究,你更应该遵循自然规律而不是主观臆断。

你应该避免过于坚持原来的计划,因为它可能是错误的。大多数成功的初创公司,最后做的都不是他们刚开始企图做的——而且差别往往很大,以至于你很难把他们同最初的公司联系起来。在创业的过程中,你应该准备好接受任何更好的主意;而最难做到的就是放弃你已有的想法。

当然,这里也有一个度的问题。每周都换一个想法显然也不可能成功。有什么标准能够帮助你做决定吗?一个办法就是衡量那些新的想法是否代表了某种进展。如果你能够利用大部分你所做过的东西,那么你可能是在一个螺旋式上升的过程中;反之,如果你需要从头开始的话,那就不是一个好兆头。

幸运的是,你可以向你的用户寻求建议。如果你转向一个新方向,而用户又对此反响热烈的话,那么你很可能押对宝了。

6 遇人不淑 (Hiring Bad Programmers)

在早先的清单里我忘了列上这一条了,因为我所碰到的创始人大多是程序员。对于他们来说,这不是什么大问题。就算他们偶尔雇用了一两个差劲的程序员,也不至于天就塌下来了。紧要关头,他们都可以亲自操刀上阵,力挽狂澜。

不过,当我回溯90年代那些倒闭的电子商务初创公司时,却发现正是差劲的程序员毁了那些公司。很多公司都是由商业领域的人员创办的。他们以为初创公司就是有个好的点子,然后雇用一批程序员来实现它。这真是想得容易做的难。这些商业领域的人员根本就无法区分程序员的好坏。他们甚至接触不到最好的程序员,因为没有哪个程序高手愿意去实现一个商人的构想。

事实是,这些人招募了一些他们以为是好的程序员(至少这些程序员的简历是这样吹嘘的,什么微软认证的开发人员了,等等),但实际上却难副其实。接下来他们就会很困惑地发现,自己的公司就像老牛拉破车一样吱嘎吱嘎,而竞争对手们却跟坐了火箭一样。这种初创公司具有那些大公司的所有缺点,却没有那些大公司所具备的优势。

如果你本人不是程序员的话,怎样才能挑选好的程序员呢?我不认为有什么好办法。我本来想说,你可以找个程序高手来帮你做这件事儿。但问题是,你怎么找到这个最初的程序高手呢?

7 开发平台选取不当 (Choosing the Wrong Platform)

同上面一条相关的问题是开发平台选取不当(通常差劲儿的程序员都会犯这个错误)。我认为,在经济泡沫时期,很多初创公司都因为在 Windows 的平台上构建基于服务器的应用而身陷泥沼。Hotmail 在被微软收购若干年之后仍然运行在 FreeBSD (译者:一个 Unix 平台)上,估计是因为 Windows 无法胜任其负荷。假如 Hotmail 的创始人选择了 Windows 的话,他们很可能早就失败了。

PayPal 刚刚躲过了一劫。在同某个dotcom合并后(译者:这里应该是指 eBay,不知道作者同 eBay 有什么过节?:)),新的CEO 想要转到 Windows 上——尽管 PayPal 的联合创始人马克斯·莱文奇恩(Max Levchin)向他展示过他们的软件系统在 Windows 上的处理能力只有在 Unix 上的百分之一。幸运的是,最终他们换了 CEO,而不是操作系统平台。

平台是一个很模糊的词。它既可以指操作系统,也可以指编程语言,或者是编程语言之上的框架结构。它所隐含的意义,既包含了支持,也包含了限制,就如同房子的地基一样。

你不得不慎而又慎地选择平台。有些平台,对外行来说,似乎是很好的、很负责的选择,就象90年代的 Windows 一样;一旦你选了他们,就无异于自掘坟墓。Java applets 大概是最典型的例子了。它曾经被人们认为是发布应用的新途径。结果却是,100个对此深信不疑的初创公司里,就有100个被毁掉了。

怎样选取正确的平台呢?通常的办法是招些好的程序员来让他们选择。如果你自己不是程序员的话,也有一个小窍门:到顶尖的计算机系里参观一下,看看他们在科研项目里都使用什么。

8 发布迟缓 (Slowness in Launching)

所有的公司,不论大小,在完成软件之前都会有一段困难时期。从某种意义上说,这是一种固有的特性;软件的完成度永远都是在85%左右。你需要有极大的毅力来推动软件的完成并向用户发布。[3]

初创公司总是用各种各样的借口来为推迟发布辩解。这些借口跟人们在日常生活中为自己的迟到所找的理由大同小异:总是有一些事儿要在这之前办好。也许吧。不过假如你的软件已经全部完成,按个按钮就可以发布的话,你还会等吗?

尽快发布的一个目的就是迫使你完成应该完成的工作。一个软件,只要还没有发布,就不算真正完成。不管你认为这个软件已经如何完善了,在临发布之即,总还是有一大堆的事儿要做;这种情形已经司空见惯了。发布的另一个目的就是,只有通过用户反馈,你才能真正明白要做什么。

有一些问题,同发布延迟是有联系的:工作节奏太慢,没有真正搞清楚问题,惧怕同用户打交道,害怕别人的评论,分心过多,过于完美,等等。解决这些问题,只需要推动自己尽快发布一些东西就可以了。

9 发布过早 (Launching Too Early)

发布过早的情况比发布迟缓要少见得多,不过并不是没有。发布过早的危险是有可能毁掉了你的名誉。早期的使用者在试用了你发布的东西后,如果发现什么不满意的地方,他们可能就不会再来了。

如果你想发布一样产品的话,最低要求是什么呢?我们建议初创公司认真考虑自己想要做的是什么,确定其核心内容;这些核心内容既要本身就能够有用处,又要能够作为基础,在此之上逐渐地拓展成一个完整的项目。一旦确定了这些,就应该尽可能快地完成它们。

我和很多其他的程序员就是按照这一办法来编写软件的。思考一下总的目标,然后动手编写一些有用的最小模块。这些模块早晚是要写的,所以不用担心作无用功。在大多数情况下你会发现,实现这些模块既能够在精神上获得鼓舞,又能够帮助你对余下的部分看得更清楚。

其实,你需要打动的那些早期的试用者们是很宽容的。他们并不期待一个新发布的产品无所不能;但是,多少它应该有点儿用处。

10 没有明确的目标用户 (Having No Specific User in Mind)

如果你不了解用户,就不可能作出他们喜欢的东西。在前面我曾经提到过,大多数成功的初创公司,都是从解决创始人遇到的问题开始的。这里面有这样一条规则:你所创造的财富是跟你对问题的理解程度成正比的;而你最了解的就是你自己的问题。[4]

这条理论反过来说就是:如果你试图解决一个你不懂的问题,那无异于往自己的脖子上套绞索。

但是还是有很多创始人,喜欢假定存在某些用户愿意用他们的产品,至于这些用户会是谁,他们也不很清楚。那些创始人需要这些产品吗?不,他们不能算是目标市场。那么会是谁呢?年轻人?对本地活动感兴趣的人?还是商业领域的用户?什么样的商业领域?加油站?电影制片厂?还是军工采购商?

你当然可以为与你不同类型的用户打造产品。我们就曾这么做过。问题是,你必须认识到你踏入了一个危险地带。这就好比你在借助仪表在飞行:你自己的直觉将帮不上任何忙。因此你的每一步操作都必须小心谨慎,并且要经常查看你的仪表。

这种情况下,用户就是你的仪表。你必须遵循“从实践中来”的原则。任何主观猜测都是不允许的;你必须接触用户并考察他们的反应。所以,当你为别人而不是你自己设计产品的时候,你必须去说服一些特定的用户来使用你的产品;如果你做不到这一点的话,那么失败是必然的。

11 筹集的资金太少 (Raising Too Little Money)

大多数成功的初创公司到某一阶段都会接受投资。这就跟要有多个创始人一样,从统计上来说,是一个保靠的举措。那么,你应该接受多少投资呢?

初创公司的资金是用时间来衡量的。每个还没有盈利的初创公司(几乎所有的初创公司在刚开始时都不可能盈利)在钱花光之前都会有一段时间。这段时间有时候被喻为“跑道”(runway)。这是一个很好的比喻,它在提醒你,当你钱花光的时候,要么起飞,要么撞毁。

太少的钱意味着你没有足够的跑道起飞。当然,起飞的概念也需要视情况而定。通常你需要更上层楼:从仅仅有个想法和正在实现的原型;到有了原型,正在发布;到已经发布了产品,正处于显著的增长期。这也要看投资者的想法,毕竟他们是你在实现盈利前要说服的人。

如果你是从投资人那里接受资金的话,那么数量至少应该能够支撑你到下一个阶段。[5] 幸运的是,你对下一个阶段是什么以及需要花费多少都有所控制。我们建议初创公司在刚开始的时候把这两项指标都设得低一些:基本上不花什么钱,以及把初期目标定为构造一个坚实的原型。这样做会给你最大的灵活性。

12 花销无度 (Spending Too Much)

有时候很难把花销无度和筹集的资金太少区分开来。如果钱不够用了,你既可以说是开销太多,也可以说是筹集的资金太少。区分这两条的唯一办法是跟别的初创公司做个比较。如果你筹集了五百万的资金却还是不够用,那么原因就很可能是花销无度。

现在那些乱花钱的烧包们要比以前少多了。创业者们似乎已经学到了教训;再加上创业越来越便宜。所以在写这篇文章的时候,我并没有发现几个初创公司是在烧钱。我们投资的公司里一个都没有。(不仅仅是因为我们的投资都比较小,也因为许多公司都进行了多轮筹资。)

最经典的烧钱方式是雇用一大批人。这么做会对你造成双重伤害:既增加了成本,又减慢了速度。所以说,钱花得越快,你就得想办法让它撑下去的时间越长。许多软件大师们都懂得这一道理;弗雷德·布鲁克斯(Fred Brooks)在他的《人月神话》(The Mythical Man-Month)中作过详细的解说。

对于招人,我们有三条基本的建议:(a) 能免则免;(b) 用股份代替工资,这样做不仅仅省钱,更重要的是,你希望你的人是愿意把自己的利益同公司的利益挂钩的人;(c)招的人应该仅限于两类,或者写代码,或者出去拉客户,因为刚开始的时候,你只需要做这两件事情。

13 筹集的资金太多 (Raising Too Much Money)

筹集的资金太少显然是不行的,那么太多的资金是不是也有问题呢?

是,也不是。关键不在于钱的本身,而在于随之而来的问题。一个风投曾经说过,“一旦你从我这拿了几百万的资金,那么计时就开始了。”风投们给你投资,并不是让你把钱放在银行里然后整天泡碗面;他们希望钱用在工作上。[6] 最起码,你也要有一个像样的办公室,以及一些工作人员。而这会改变你的工作氛围——并不一定是朝有利的方向。现在,你的大多数人马都是你的雇员了,而不是合伙创始人。他们不可能像你那样投入;他们需要有人来告诉他们做些什么;更糟的是,有人会开始玩起办公室里的那些猫腻。

当你筹集了很多钱的时候,你的公司就会搬到繁华地段,并且开始拖家带口。

而更危险的是,一旦你拿到了一大笔钱,那么你就会尝到船大难掉头的滋味。假设你最初的计划是向公司们出售某种产品。从风投那儿拿到钱后,你雇用了一些销售人员来做这事儿。后来你发现,应该把力量投入到消费者身上而不是那些商业公司。销售方式会有根本的不同。这时候,你怎么办?在实际当中,你甚至可能根本认识不到这点。招的人越多,你就越倾向于沿着既定的方向而不做改变。

争取大笔投资的另一个缺陷就是耗时太长。你能筹到的钱跟你所花的时间是成正比的。[7] 当投资达到上百万时,投资者会变得相当谨慎。风投们从来不会明确地说是或不是;他们会没完没了地约你谈话。因此,从风投那里筹集一笔相当规模的资金是一件很花时间的事情——可能比你创业所需的时间还长。当你的竞争者们争分夺秒于开发产品的时候,我想你不会愿意把你的时间都花在投资人身上。

我们建议那些寻求风投的创业者一旦遇到合适的协议就接受它。如果你能够从一个有信誉的基金那里拿到一笔基本合理的钱,并且没有什么不合情理的条条框框的话,那么成交好了;然后投入到建设你的公司里去。[8] 就算你能够从别的地方拿到多三成的钱,又怎么样呢?创业是一个要么赚得盆满钵满,要么输得精光的游戏。为了一点点小利而在投资者间四处游走无疑是在浪费时间。

14 受制于投资者 (Poor Investor Management)

作为公司的创始人,你应该掌握公司的投资者。你不应该忽略他们,因为他们可能提供有见地的建议。但你绝不能把公司运作交到他们手上;那应该是你的职责。如果投资者对于运作其所投资的公司有足够的见地的话,那他们干吗不自己创立一个公司呢?

由于忽略投资者而惹恼他们的后果,要比向他们缴械投降的后果轻得多。我们创业的时候,曾经错误地忽略了投资者。结果,跟投资者的争吵牵扯了我们的很多精力。不过,这也要好过投降许多,那样的话,公司可能就完了。一个知道自己在做什么的创始人,就算只花一半的精力在产品上,也比什么都不懂的投资者花上全部的精力要强。

掌握投资者所花的工夫通常取决于你从他们那里拿了多少钱。如果你筹集的资金有相当规模,那么投资者也相应的得到了相当规模的控制权。如果他们在董事会里占了大多数,那么他们就是你名义上的老板。更常见的情形是,创始人和投资者的权重相等,决定性的投票来自于外部的中立董事。这时候,投资人只需要说服那些中立董事,就获得了公司的控制权。

如果一切都很顺利的话,那么这也无所谓。只要你的进展看上去很迅速,大多数的投资者不会插手你的事情。问题是,对于一个初创公司来说,不可能指望一帆风顺。就算那些非常成功的公司,都曾经被投资者找过很大的麻烦。最有名的一个例子就是苹果。它的董事会曾犯过一个致命的错误:解雇了斯蒂夫·乔布斯(Steve Jobs)。(译者:1985年,因为权力斗争,Steve 被赶出了苹果电脑;1996年,随着他的NeXT公司被苹果收购,他又回到苹果,并在1997年重掌大权。请参见 wikipedia 词条。)即使是 Google,早期跟投资者也有过很不愉快的经历。

15 为(不存在的)利润而牺牲用户 (Sacrificing Users to (Supposed) Profit)

我在一开始的时候就说过,如果你做的东西是用户需要的,那么应该没什么问题。你可能注意到,我没有提及任何关于正确的商业模式的事情。这并不是说赚钱并不重要。我并不建议创业者们搞那些更本就没有希望赚钱的公司,然后希冀着在倒闭前把公司卖掉。我们告诉创业者们不要担心商业模式的最初原因是觉得搞出一个人们需要的东西要比这难得多。

我并不清楚这件事儿为什么这么难。看起来应该是一件很直截了当的事情。不过,只有为数不多的初创公司做到了这一点。从这儿你就可以看出这件事儿有多难。

正是因为做出一个人们需要的东西要比赚钱难得多,所以你应该稍后再考虑商业模式的问题,就好比你把一些琐碎而麻烦的功能留给第二版一样。在第一版里,解决那些最核心的问题。对于初创公司来说,最核心的问题就是怎样来创造财富(=人们在多大程度上需要你的产品*需要你的产品的人数),而不是怎样把财富转变为钞票。

能够获胜的都是那些用户至上的公司。以 Google 为例,他们先是开发了搜索引擎,然后才考虑怎么赚钱。总有一些初创公司的创始人认为,不在一开始就考虑商业模式是不负责任的举动。这些创始人通常是被那些思想僵化的投资者所蛊惑。

如果说不考虑商业模式是不负责任的举措,那么不考虑产品本身的不负责任性要十倍于此。

16 自命清高 (Not Wanting to Get Your Hands Dirty)

几乎所有的程序员都更愿意把时间花在写代码上而另找人去处理商业上与钱有关的龌龊事儿。这并不是因为懒。Larry 和 Sergey 在刚开始的时候显然也是这么认为的。在开发了新的搜索算法后,他们所作的第一个尝试就是找一家公司买下它。

创办一个公司?算了吧。大多数的程序大师们更满足于仅仅有个点子。不过,正如 Larry 和 Sergey 所发现的,点子是没有什么市场的。没人会去相信一个点子,除非你把它用在你的产品里,并以此获得用户。这样人们才会给你更多的关注。

也许这一点会有所改变,不过我很怀疑。对收购者来说,没有比用户更具说服力的东西了。这不仅仅是因为风险降低了;要知道,收购者们都是人,他们很难把几百万的美金砸到一堆年轻人身上,就为了他们机灵。当点子被一个公司实现并且拥有很多用户时,投资者们可以安慰自己,他们买的是用户,而不是看不见摸不到的机灵。这对于他们来说更容易接受些。[9]

如果你想要吸引用户的话,你可能不得不离开你的计算机,到外面去寻找一些用户。这的确不是一项愉快的工作;不过,如果你能够做下来的话,那么成功的几率就大大增加了。2005年夏天,在我们资助的第一批初创公司里,绝大多数的创始人都埋头于编写他们的应用程序。只有一个创始人,花了一半的时间去同手机公司的执行长官们交谈,以敲定一些买卖。对于一个程序员来说,你能想出比这更痛苦的事情吗?[10] 不过,他的付出是有回报的:那家初创公司看起来是那一批里最成功的,他们获得了一大笔订单。

如果你要创办一家公司的话,就必须面对一个事实:你不可能只是坐在那里写程序。至少你们当中的一位需要花费一定的时间在商业上面。

17 内部争斗 (Fights Between Founders)

创始人之间的争斗出乎意料地普遍。我们资助的初创公司中,大约20%的公司都有创始人退出的现象。这种频繁发生的事情让我们更加倾向于股权授让(vesting)。尽管不是必须条件,我们还是建议创始人们授让股权,这样,中途有人退出的话,也不会造成什么混乱。

一个创始人的离开并不会毁了公司。许多成功的初创公司都有过类似的情形。[11] 幸运的是,离开的通常都是投入最少的。
假如有三个创始人,其中一个不是很积极的退出了,没什么大不了的。如果有两个创始人,其中的一个走了;又或者离开的那个具备关键技术,那么就可能会有麻烦。就算这样也还不至于天塌下来。Blogger 曾经走得只剩了一个人,但最后又振作了起来。

如果创始人们能够更加谨慎地选择他们的创业伙伴,那么大多数的争吵都可以避免。多数的争吵并不是因事而起,而是因人而起。也就是说,是早晚会发生的。而大多数因为争吵而一怒离开的创始人,可能从一开始就信心不足,只不过被掩饰起来了。不要掩饰你的疑虑。在公司成立前把问题解决掉要容易许多。所以,不要因为怕疏远你的同屋而拉他入伙;也不要因为某人有某种用得上的技能就一起开公司,而不管你喜不喜欢他。一个初创公司,最重要的因素就是人,所以不要在这上面有什么将就。

18 不能够全时投入 (A Half-Hearted Effort)

你所听说过的失败的初创公司,都是一些很特殊的例子。他们实际上是失败者中的佼佼者。最通常的失败者并不是因为犯了这些很特殊的错误,而是因为没有做什么事儿——我们从未听说过这些失败者;他们往往是两三个人,在工作之余,玩儿上一把;从未取得过什么真正的进展,渐渐地也就放弃了。

从统计上说,如果想要避免失败的话,一个很重要的事情就是辞掉你的日常工作。绝大多数失败的初创公司,其创始人都属于业余性质;而那些成功的初创公司,创始人都是全副身家扑在了上面。假如把初创公司的失败比作是疾病的话,疾病控制中心就会贴出一张告示,警告大家辞掉日常工作。

这是不是说,你必须辞掉你的日常工作呢?也不一定。我在这里胡乱猜测一下。我想那些还没有辞掉工作的创始人,大多缺少一种创办公司所必需的决心;他们的意识深处是知道这一点的。他们之所以不敢投入更多的时间是因为他们知道,这不是一个好的投资。[12]

我还猜测,有相当多的人,如果能够迈出这一步而全时去做的话,是能够成功的,可惜的是,他们没有这样做。我不知道这样的人有多少,不过,如果把 成功者/骑墙者/毫无希望者 做个分布的话,那些如果辞掉工作就可能成功的人,要比那些现实中的成功者多出一个数量级。[13]

如果这是真的话,那么大多数有可能成功的初创公司最终失败的原因都是其创始人不能够全心全意地投入在上面。这跟我所得出的结论也是一致的。绝大多数的初创公司之所以失败,是因为他们做不出用户需要的东西;而之所以做不出来,是因为他们的努力不够。

换句话说,创业跟做其它事情一样。你可能犯的最大错误就是不够努力。如果有什么成功的秘诀的话,就是不要否认这一点。

 

注释

[1] 这个清单并没有列出所有的原因,只列出了那些你能够掌控的因素。有些事情是你没法控制的,比如说,能力不足或是运气不好。

[2] 好笑的是,从 Facebook 衍化出来的一个可行的点子,就是针对那些非在校学生的 Facebook。

[3] Steve Jobs 曾试图用“Real artists ship”来鼓动人们。这是一个很漂亮的句子,可惜并不代表事实。艺术里面的很多著名作品都未完成。对于有明确期限的领域来说,比如建筑和制片,这句话可能是对的。不过就算在这些领域里,人们也总是能拖就拖。

[4] 这里也许还有另一个因素:初创公司的创始人们一般都站在技术的最前沿,他们所面临的问题往往具有很特殊的价值。

[5] 你所筹集的资金,应该比你认为所需要的要多,大概多50%到100%吧。因为编写软件所花的时间往往比你估计的要长很多。

[6] 人们有时候会把我们也叫作风投,我这里要声明一下,我们并不算风投。风投的手笔很大,而且花的是别人的钱;而我们花的是自己的钱,数量也很小,更像是天使投资。

[7] 当然并不是线性的,不然你永远也筹不到五百万美金。不过在实际操作中,你会觉得真的是没个尽头似的。

就算你把风投不可能投资的情况也考虑进去的话,对于一般情况来说,你也会觉得费时太长。而追求大的投资的危险不仅仅在于花费的时间很长,更严重的是,你可能花了时间却拿不到一分钱。

[8] 有些风投会故意压低你的价值来试探你有没有胆量去要求更多。这是一个俗不可耐的游戏,不过的确有些风投在玩儿。如果你在同这样的风投打交道,那么应该在估价上进行一番讨价还价。

[9] 假如 YouTube 的创始人在2005年跑到 Google 说,“你们的视频设计太差了。给我们一千万的话,我们就指出你们犯的所有错误。”那他们肯定会受到嘲笑。可是18个月后,为了买这一课,Google 支付了16个亿。也许部分原因是因为 Google 可以安慰自己:我们是在买一种新事物,一个社区,或是类似的某个模糊概念。

我并不是挑剔 Google。他们已经领先于他们的竞争者了。那些竞争者可能已经错过了视频这班船。

[10] 事实上是有的:就是跟政府打交道。不过电话公司会很高兴。

[11] 这种情况比人们看到的要多得多,因为公司们从来不会宣扬这种家丑。你知道苹果最初有三个创始人吗?

[12] 我并不是瞧不起这些人。我自己也缺少这种果断。在 Viaweb 之后,我曾经有两次都很接近于开办一个公司,但每次都打了退堂鼓。因为我意识到,缺少了生存危机,我很难承受创业的那份紧迫感。

[13] 那么你怎么知道你属于哪类人呢?是那些应该辞掉工作的人?还是更大多数的平平稳稳过日子的人?我得说,单凭你自己是很难作判断的。你必须寻求外部的建议。我们自认自己是投资者,不过从另一个角度看的话,Y Combinator 是一项建议人们辞掉或是不要辞掉工作的服务。我们可能会犯错误,而且是经常犯,但至少,我们是根据我们自己的结论来押宝的。

posted @ 2008-03-10 22:39 iclotus 阅读(16) | 评论 (0)编辑
  2008年2月26日
     摘要: 超强免费网络电话,无限次数,每次10分钟
测试已一月,每次通话10分钟,不限次数,
拨打国内电话: 86+区号(区号前减个0)+座机号
如: 拨打 028 66324449 应拨( 86 28 6632449)
拨打国内手机: 86+手机号   阅读全文
posted @ 2008-02-26 13:51 iclotus 阅读(854) | 评论 (12)编辑
  2007年7月10日

第一是“贫穷”

贫穷不能等,因为一但时间久了,你将习惯贫穷,到时不但无法突破自我,甚至会抹杀了自己的梦想,而庸庸碌碌的过一辈子。。。。。。

第二是“梦想”

梦想不能等,因为人生不同的阶段,会有不同的历练和想法,试想一个问题:如果你20岁时的梦想,在60岁的时候才得以实现,那会是什么样的一个情况???

譬如说你20岁时的梦想是希望能买到一辆法拉利的跑车,然后到德国的无限速公路狂飙。你一直努力工作,好不容易到60岁了,总算买得起跑车了,但要实现年轻时的梦想,恐怕也是心有余而力不足吧。。。。。。

第三是“家人”

家人不能等,或许我们还年轻,未来有很多的时间可以让我们摸索、打拼,但是家人吗?他们还有时间等我们成功吗???还有时间等我们赚到钱,让他们过好日子,让他们以我们为荣???

树欲静而风不止,子欲养而亲不待。。。。。。这是很多人的痛,也是很多人一辈子的遗憾。

人的上半生:要不犹豫;

人的下半生:要不后悔;

活在当下,把握每次的机会,因为机会稍纵即逝,为自己的生命找到出路! 最近在经济日报看到一篇由郑丹瑞写的文章,值得分享,内容如下。

      急事,慢慢的说;

      大事,清楚的说;

      小事,幽默的说;

      没把握的事,谨慎的说;

      没发生的事,不要胡说;

      做不到的事,别乱说;

      伤 害人的事,不能说;

      讨厌的事,对事不对人的说;

      开心的事,看埸合说;

      伤心的事,不要见人就说;

      别人的事,小心的说;

      自己的事,听听自己的心怎么说;

      现在的事,做了再说

posted @ 2007-07-10 22:15 iclotus 阅读(95) | 评论 (0)编辑
  2007年7月4日
 
什么是企业软件
还记得我们一开始写程序的时候吗?那还是在学生时代,因为兴趣,或者你做毕业设计的时候,写出几行代码,实现了一个简单的功能,如计算出一个数学结果,或者弹出来一个窗口,你的心情是那么激动,你充满了成就感!好像看到世界掌握在你的手里了,后来你慢慢实现了很多的功能,一个比一个酷,觉得写一个软件不过如此,但当你毕业了,找工作的时候却遇到了困难:没有工作经验!我可以做软件啊?我可以实现很多功能啊?他们为什么说我不行呢?为什么说我没有经验呢?我和经验老道的工程师有什么区别呢?
我们现在就来探讨这个问题,为什么你写的东西幼稚?为什么人家不敢用你辛苦写的软件?当然,我们在这里讨论的是大部分普通学生,那些天才的高手不属于这个范围。当你以后逐步成为中国软件行业的主力军后,你会发现,你当年写的东西只能属于自娱自乐的“个人软件“,而行业内需要的是正规软件。就如那个文化站站长(尊龙饰)搞的那个”关中女侠“,在小范围内大家乐乐还可以,放到全国电影院线恐怕就不行了!达到我们所说的”企业软件“,这个进化过程,是一个需要大约2年的历练,当然,有人会更短,有人会更长。
企业应用软件,一般指的是那些为商业组织、大型企业而创建并部署的解决方案及应用,这些大型企业级应用的结构复杂,涉及的外部资源众多、逻辑复杂、事务密集、数据量大、用户数多,有较强的安全性、可靠性等考虑。
注意企业应用系统和通用商业软件的区别,商业软件一般是具有通用性的产品,比如金碟、用友的财务软件,它们作为产品,质量要求非常高,非常具有专业性,能满足多数客户的需求;而企业软件系统作为项目,常常是为一个企业定制的,业务比较复杂,直接面对需求多变的用户,需要良好的架构以满足需求的变化。通常会有较多的售后支撑工作。
企业软件的特征
我们现在先列出两种企业软件,来让你对企业软件有个感性的认识。
有一种企业软件的特征是访问量特别大,那些大型的门户网站,比如新浪,就是个例子,很多上班族到公司第一件事情就是打开新浪网,全国范围,全世界范围的华人,假如某个时刻有0.0001%的人在访问它的首页,那也是一个不得了的数字!这样的网站硬件要过得去,软件架构也绝对是非常出色的!
还有一种是业务逻辑特别复杂,要在某个大型的企业内部署,来解决一类业务问题,我们知道,企业内的业务不是孤立的,而是在不同层次上互相关联的,需要和企业已有的系统来建立联系,也可能需要外面的用户、供应商从中获取、输入数据,等等。而且这种软件的需求是不断变化的,你的软件需要适应这种变化。满足这样需求的软件肯定也是非常了不起的!
我们现在来探讨一下企业应用系统具有那些要求或者说特征,一般来说,它在如下的方面要求很高:
l         性能
l         可靠性
l         安全性
l         可用性
l         伸缩性
l         扩展性
l         管理性
 
这些苛刻的要求都是长时间以来用户提出的,他们希望我们能做到这些,才敢用我们的软件,才敢把他们重要的数据和业务放到我们的软件系统之中!想想那些重要的数据,我们银行存款,我们的手机费用记录,当然还有什么国防机密、卫星上天等数据,我们自己都想象不出来,如果出错,或者丢失,后果会怎样???
用户对我们IT界提出挑战,我们要应对这种挑战,我们要让他们信任我们,使用我们的技术,所以,IT技术一直发展到今天,IT的价值已经广泛被人们认同并应用。我们IT人员不断的努力,努力去满足用户的要求,给用户更好的体验。这种努力包含大体可以分为硬件技术和软件技术,硬件技术发展很快,那是我们同行努力的结果,我们在这里不多谈,但要给他们敬意!这里谈的是我们软件方面。
软件又分为系统软件和应用软件,系统软件一般为国外的大厂商所拥有,比如微软,IBM等,系统软件和硬件结合的比较紧密,而且很多前沿技术还处于研究阶段,学术范围之内,距离我们普通的程序员还比较远,我们这里也不多谈,我们只谈和我们关系比较紧密的应用软件,它的发展,它的技术和用户对它的理解!
 
每个特征的分析
我们来逐个讨论一下每个特征的解释和软件界应对这些挑战而发展的技术。其实,回顾软件技术发展历史,我们可以看出,很多技术就是来解决以上几个方面的要求(另外的技术用于解决软件行业的生产率提高问题),技术应需求而来,用户提出了这么苛刻的要求,我们软件行业就要想方设法来满足他们——因为他们是上帝,是我们软件从业人员的衣食父母!
 
性能
性能的概念很好理解,从用户角度来看,这个软件系统运行快,反应时间短,就说这个系统性能高。而从系统上来说,用的是事务吞吐量和资源使用率等指标。
为了提高性能,我们可以进行如下方案的选择:
分布式计算,和硬件结合,用若干个服务器,把软件系统也相应分为几个模块(层),一般为表示层、业务层、数据层,更复杂的还可以多加几个层。每个层在不同的服务器上运行,上层调用下层计算,下层把计算结果返回上层。这样就避免了使用性能更高的服务器,控制了成本,实现了分布式计算。
需要进行文件 IO 或繁重的数字处理的应用程序可能将繁重的工作卸载到另一个或更多的层上,这些层可以方便地伸缩以满足峰值负载需要。比如生成大报表、创建文档或发送 SMTP 邮件的组件就是这样一个例子。
分布式系统学习曲线比较陡峭,只有在一些大型系统中用到,Java平台上的RMI 与 .NET中的Remoting都为分布式计算提供了良好的支持,我们可以从案例研究来学习和实践分布式软件开发,比较出名的案例是“宠物店网站”,java版本和net版本都有。
缓存,以空间换时间,把将来会重复调用的数据、对象预先加入内存或者第一次使用后不销毁,而是缓存到内存中。这样可以节省很多数据生成或者销毁的时间,换来响应速度的提高。常见的缓存有:
l         线程池。节省了大部分线程创建和销毁的时间。典型的例子是Web服务器软件,每个用户访问进来,则线程池会提供一个线程来处理请求。在Java和.Net都提供了创建线程池的机制。
l         对象缓存池。如果某些对象的创建很费时间和资源,则可以当这些对象使用完后先不销毁,而是缓存起来,以备以后使用。J2EE架构中的EJB就是一种典型的对象池技术(图1)。
1 EJB容器的对象池
     对象池如果不是为了研究或者学习,请直接用运行平台提供的成熟实现来完成。
l         资源连接池。最常见的是数据库连接池,一般的商业运行平台都实现了此技术,我们只要进行一些简单的配置即可,比如下面的ADO.net数据库连接字符串:
          server=localhost;user id=test;password=test;database=Sample;min pool size=4;max pool size=40;
          这里设置了数据库连接池中连接的最大数量为40,最少数量为4,ADO.net按照此字符串的设置来提供连接池功能。
l         页面缓存。如果一个B/S系统用户访问量非常之大,我们就可以把某些web页面计算结果缓存起来,当众多客户访问此页面时,将不再计算,直接把结果放到输出流中,从而极大的提高响应速度。比如我们在asp.net页面上直接设置页面缓存:
        <%@ OutputCache Duration="60" VaryByParam="type" %>
                上面的指令表示缓存此页,缓存期限为60秒,并且根据传入参数type来缓存不同的版本。
          
并行计算,用多线程技术来达到并行计算,java和C# 都为多线程提供了语言层的支持。多线程可以让响应速度提高,特别是在多用户并发访问时,最常见的是Web服务器软件。每个用户访问到达时,Web服务器会为此用户提供一个线程来处理用户的请求。并行计算可能在企业软件中用的并不多,多数是用在一些系统软件中。但我们需要有清晰的了解,所以你还是有必要自己写点程序来实现一下。
对技术方案的选择,我们举一个例子:事务,事务对性能影响较大,减少使用事务可以提高性能。在开发中使用事务有级别上的差别,比如:
1.         自动事务,由容器(如EJB容器或者Com+)实现,一般你只需做个事务标记,容器会帮你实现。这类事务一般处理复杂的、分布式事务。
2.         手动事务,比如直接在业务层的代码中实现的事务。
3.         数据库脚本事务,直接实现在数据库系统内嵌模块,比如在存储过程中。
从性能上说,事务级别越高级,对性能影响越大。性能最高的事务是在数据库系统中直接实现的事务。微软提倡数据库操作一般写到存储过程中,很重要的一方面是为了性能的考虑。
 
系统和代码优化,优化你写的代码和后台数据库系统的性能,优化数据库访问,比如只获得你需要的数据,可以减少数据传送量从而提高性能。我们这里说一个常见的分页的例子:
假如一个分页的web页面,页面展示的数据非常庞大,需要分为好多页面,初学者经常会写一个固定的查询语句,如:“Select * from Users”,这样用户每次只查询一页的数据,但我们却每次都返回了所有的数据。浪费很多服务器和网络资源。我们可以写成这样:
select top 20 * from Users where id>lastId
其中lastId 可以根据上一页最后一条记录得到。
 
2 只返回每页的数据
 
还有一个相似的例子是值对象模式,我们把访问的相关数据打包成一个对象,传送到客户端,客户端代码可以从容访问此对象的各个属性,而不是每访问一个属性就去和服务器交互一次,这样可以减少网络访问次数,从而提高性能。
 
可靠性
可靠性衡量应用程序能正常运行的程度,更正式的定义为平均故障间隔时间 (MTBF),即应用程序在发生故障前运行的平均时间长度:
MTBF = 小时数/失败次数
还有一个我们经常用到的指标,即一年中正常运行时间的比率。我们说某个系统的可靠性达到了几个”9”,指的就是这个,如果系统在一年中失败了3个小时,那么可以达到:
(1-3/(365*24))=0.9997                  
大概是三个9。电信网络一般可以达到5个9,你想想它的失败率有多低!
提高可靠性是一个复杂的系统工程,涉及到硬件、操作系统、运行平台、开发人员和操作人员的培训等等,因为有人为和环境因素,要一个系统达到100%的可靠性是不可能的。可靠性与其他特征紧密相关,如安全、性能、扩展性等,安全性不强,任何人都可以进去捣乱,你还有什么可靠性?
提高可靠性需要考虑成本,不能一味地去追求。对于我们开发者来说,除了尽可能的优化你的代码外,还需要进行如下的考虑:
数据冗余,主要就是备份,包括各种冷、热备份。备份已经是企业软件系统不可缺少的措施,有条件的还需要异地备份,来防止自然灾害等。美国的911袭击过后,世贸中心里的一些金融机构可以马上恢复业务,主要就是他们的完善的异地备份措施。
服务冗余,集群具有容错性,在集群中,同样的服务可以由多台服务器实现,每台服务器的硬件和软件配合提供同样的服务(特别是软件)。当一台服务器因为某种原因而崩溃后,一个监测机制会及时发现失败的机器,迅速用另外的机器来接管它的工作。从而保证业务正常进行,这个过程就是故障转移。
3 用集群的故障转移技术
图4的第一台服务器 (Database01) 是处理所有事务的活动服务器。 仅当 Database01 发生故障时,处于空闲状态的第二台服务器 (Database02) 才会处理事务。 集群将一个虚拟 IP 地址和主机名 (Database10) 在客户端和应用程序所使用的网络上公开。
 
事务,提高可靠性的一种典型方法,在对数据进行一组连续操作时,为了防止意外,如中间的某个步骤出现错误,某个操作不能运行,甚至系统瘫痪、网络突然断掉等,我们就要使用事务。事务保证了数据的正确性、完整性、一致性,从而提高了可靠性。
重试机制,当一次操作失败后,会重复运行命令,重试次数可以设置,如果最后仍然失败后,可以给管理员发出警告。通常用在后台程序、异步执行等情况下。
减少计划内停机时间。比如要把数据库连接字符串放到一个文件中动态读取,才能不至于当数据库有变动时重启系统。
要有错误日志,系统出错后能迅速发现,迅速改正,使故障时间达到最小。
 
一个增强可靠性的例子是ASP.net中的会话状态存储。Asp.net提供了几种存储会话状态的机制:
1.         进程内模式,会话状态存储在进程内,一旦Web服务器失败,状态将丢失。
2.         状态服务器模式,会话状态存储可以存储在另外的服务器上,一旦Web服务器失败,状态将不会丢失。
3.         SQL Server 模式,会话状态竟然可以存储在SQL Server服务器中。
 
选择后两种模式的应用软件,很明显就可以增强它的可靠性。
 
安全性
如果你自己写了一个好玩的游戏,并且放到自己攒的电脑在家里玩,你的电脑没有联网,这是几年前我们做过的事情,那个时候,我们根本不用考虑安全性,不用为它写一行代码。而当今的企业应用系统基本上都是网络系统,若干用户从网络上访问系统,得到他们所需要的计算结果,安全性考虑随着网络因素空前的被重视。
应用程序的安全性受很多因素的影响,如网络、操作系统、软件运行平台,你需要进行综合的考虑,要进行各个因素的分析和针对的应对措施,我们开发人员要干什么呢?我们应该多了解一些知识,在其他配置完备的情况下,如数据库备份,操作系统设置,防火墙设置等后,根据系统对数据的安全性要求选用一些技术,如SSL、VPN等,尽量利用软件运行平台的安全设置,如Net平台提供了很多的安全性设置,选择平台提供的验证模式,而不要自己去写一套验证的代码。
       初学者还要了解如下的几点:
数据的加密,一些重要的数据,用户的密码都应该加密,尤其是密码,可以用不可逆算法加密。请不要写自己的加密代码,无论你觉得写的多么好,在黑客的攻击下完全没有作用,徒增笑料而已。一般我们要使用成熟的、已经实现好的加密API,这些在Net和Java类库中都存在。
不信任用户的输入,这点初学者尤其要注意,要过滤掉一些特殊的字符,这里顺便说一下我刚开始写代码犯的一个典型的错误,它是初学者容易犯的错误:登录。我们看这个语句
   Select * from User where name=’aa’ and password=’11’
其中”aa”,”11”是登录窗体用户名和密码两个文本框输入的数据,假如用户在密码框中输入:1’ or ‘1’=’1
则上面的SQL语句变为:
Select * from User where name=’aa’ and password=’1’ or ‘1’=’1’
结果是什么?无论用户名输入的是什么,他都可以通过验证!
使用最小授权原则。给用户和代码最低的资源访问权限,初学者最容易犯的毛病是SQL Server数据库连接字符串中用的是”sa”,要知道sa的权限有多大?你敢用吗?
我们还举上面的例子,假如有个聪明的人输入了:1’ drop table user,天哪,你的用户信息被清空了!假如你用的不是sa,而是一个没有删除权限的用户,那起码可以避免这样的攻击。
应用分层。相当于设立几个隔离层,你攻破web服务器,但后面还有应用服务器,最后面有数据库服务器,层与层之间设立严格的权限认证。从一层到下一层的通信应只通过特定信道来进行。每一层都为攻击者进入添加一道额外的屏障。电子政务系统所要求的内网和外网分离,也是基于这个思路。
 
 
可用性
可用性在有的地方定义为:一个系统可以为用户所使用时间的百分比,即正常运行时间的百分比。我这里说的可用性和它不太一致,这里的可用性主要在用户体验方面。可用性当然和其他的特征,如可靠性、安全、性能联系非常紧密,也可以说包含所有的其他特征,这些都会在用户使用中体现出来。
为什么现在对可用性越来越重视呢,在我看来,可用性是以用户为中心来考虑问题的,我们去问用户:这个软件用的怎么样?他们或者满意的回答:好,或者会给你一大堆抱怨。我们当然希望得到一个简单的“好“字,但这个”好“字却得来不易,它一般包含如下的要求:
l         系统不出错;
l         系统运行稳定;
l         操作简单、实用、功能全面;
l         容易上手,不要让我一直打求助电话麻烦你。
后面两点尤其要引起我们注意,经常有朋友说工作烦死了、烦死了,其实是因为这个系统的可用性不高,所以客户天天找你麻烦,你难道以为客户无聊找你吗?为了减少售后服务成本,使我们的软件利润不至于消耗殆尽,我们应该重视可用性。
提高可用性,需要从开始就要以用户为中心,及早了解用户的需求,从设计到测试,从界面到功能,都尽可能考虑到用户,或者让用户来参与。下面是比较常用的做法:
       人性化、标准化,比如一个良好的、模块化的工作界面,不搞一套花哨、另类的界面以致用户找个菜单要找半天,界面元素一般有标准化的Window风格,你需要尽量用标准化元素。初学者往往在这里做的很差,比如随便写一个窗体,窗体标题没有设置;一个表单上的表单元素很不整齐,这些是事情看来很小,但却是一个优秀系统不可缺少的,能尽早养成这样的习惯,对以后有很大好处的。
用户友好的消息,记住一些错误、警告消息要包装成用户理解的语言,不要出现一大堆技术消息。当用户操作成功时,请不要画蛇添足的去告诉用户:操作成功,只在错误发生时提示用户。
“推”信息,不要让用户去查找,要把下一步的操作自动的推到用户面前。比如很多系统的“待办事宜”功能,比如很多邮件通知服务。如果你把这点做到,那就有点专业的味道了,呵呵。
自定义信息,不要自以为是,要让用户来决定,比如查询,要让用户来选择查询条件,让用户来对数据进行他们想要的过滤和排序。
向导机制,对于复杂的操作,需要几个步骤,你可以做个向导来引导用户,这样会深得用户的欢心。在一些大型的针对大众的商业网站,经常有这样例子,我们也可以应用到企业应用系统中。
 
另外我们说说关于用户习惯方面的事情,你不去现场是考虑不到他们的做法的,我印象深刻的一个教训是刚参加工作写一个增加记录的表单,用户在按“增加”按钮出来一个表单页面,我在表单页面执行的开始生成一个ID ,用户填写完毕后按“保存”按钮,把记录保存到数据库中,谁曾想软件使用的第一天就出现麻烦,原来用户按“保存”按钮保存完毕后,添加第二笔记录时,并不是再按“增加”按钮,而是按IE的“后退”按钮,重用刚才的“过期”页面进行操作(他们倒也懂重用),这样不出错才怪呢!