線上訂房服務-台灣趴趴狗聯合訂房中心
發文 回覆 瀏覽次數:1026
推到 Plurk!
推到 Facebook!

微軟公司的�{品生�{管理經驗

 
conundrum
尊榮會員


發表:893
回覆:1272
積分:643
註冊:2004-01-06

發送簡訊給我
#1 引用回覆 回覆 發表時間:2005-07-30 14:24:19 IP:220.132.xxx.xxx 未訂閱
http://eyoungzhang.blogchina.com/ 微軟公司的?品生?管理經驗 微軟公司如何去做一個軟體?品呢? ?品,最初來自一個大家認同的好主意 就D在瑞特蒙得園區數年來的經驗而言,對一位元高級軟體設計師來說,任何一個研發新?品的設想與建議都是受公司鼓勵的,哪怕一時還沒有用。如果你又能糾集幾位與你差不多的同事認同你的設想,同時也能在公司整個市場戰略中找到你設想?品的位置的話,你拿到預算經費的可能性已經很大了。 一個好主意當然也要來自群?。因此,在早期的微軟,每隔一段時間,便會將小組內全體人馬集中到"與世隔絕"的風景名勝之地。好吃,好喝,好玩,然後便"胡思亂想,暢所欲言"。每個人都要求到臺上來暢想一番,你心中的?品應該是個何等模樣?其目的無非是一個:集思廣益。好主意,當然是"寧肯錯抓一千,不可放過一個",有過此種經驗的微軟人都會對這種極認真的"玩"記憶猶新。 一個好的?品,起始於一個好的Spec 光有一個好主意不足以使你心目中的?品形象化,更不能組織生?。雖然有幾個同事認同了你的主意,但你還必須把你的?品是什?東西,向方方面面交待清楚。也就是說,你要開始做你的Spec。 Spec是英文Specification(軟體詳細加工說明書)的縮寫字頭,行內人已習慣只說這前四個字母。反正,越簡單越好。 一個完善的Spec是美國任何一個大型軟體專案最?重要的一步。這在美國軟體業同行中恐怕也是全民共識。就如同你要造一輛汽車,總要先把一張張藍圖一絲不苟地畫清楚。不過,也有相當一部分軟體工程師在動手做自己想做的軟體專案時,並不真的從寫Spec開始。比如D吧,直到加入微軟前,都沒寫過Spec。那時候,D所編寫的大多是功能單一的程式。一般是搞明白了每一個程式的輸入輸出要求,便動手幹起來再說。邊寫邊改,十分靈活。一個程式跑通了,結果出來了,也就大功告成了。今天,就算在美國大學裏或某些科研機構中,許多人也還是這樣做。但程式一大,或者作?一個工業?品,這種幹起來再說的辦法顯然不行了。 實際上,做軟體又不同於造汽車。汽車必須一輛一輛地造。軟體卻只要做一套,如果想批量生?,壓拷貝就可以了。有過十幾年的軟體生涯,在微軟又浸泡過幾年之後,D倒是覺得,做一項軟體工程可能更像拍一部電影。而Spec則更像是拍電影用的劇本,一劇之本。 到東京去出差,D曾有機會讀過日本人?某個軟體專案寫的Spec。在這一套Spec中,對該軟體?品應該包含的一切,事無巨細,一一定義羅列。計劃中的每一個文件與函數都用自己定義的?語言(一種接近自然語言的演算語言)寫出來了。翻著翻著,D便想,雖然按這本Spec來寫程式的程式師,理論上只需將函數中一行行虛擬碼,用寫程式時的真實電腦語言置換一下就可以了。但是,其一,程式師一定少不了那種被牽著牛鼻子走的無可奈何的感覺;其二,編寫這樣一本詳細的Spec,幾乎相當於用虛擬碼將這個軟體寫了一遍。這樣做,不是將直接寫軟體會遇到的問題轉移到寫Spec中來了嗎?效率高嗎?這個Spec肯定要用極大的努力去寫。日本人的確是在拿做汽車的精神在做軟體。日本人有他們的道理與風格。 但在D看來,一個好的電影劇本,有一個故事,有一系列人物和一系列故事發生與展開的時間地點等場景。但在電影的拍攝過程中,從一部電影文學劇本到一部電影,又給導演、演員、攝影、音樂服裝等留下了許多發揮的餘地與創造的空間。 就像一個好的劇本一樣,軟體的Spec也是從一系列Features(功能,特色)開始的。Feature這個字應該是指,軟體包括哪些功能與特徵、軟體將要做哪些事情、事情與事情之間的關係、事情與軟體用戶間的關係。功能多少有點像劇本中的故事與人物。 有了功能的準確定義與描述,接著要設計用戶如何使用這些功能。即,你的軟體會涉及哪些輸入輸出設備,比如滑鼠、鍵盤、電腦螢幕與印表機。這就又涉及到,軟體?品的各種功能在這些設備上的所有可能的表現形式,在軟體業內習慣稱?介面?。也就是說,軟體用戶?了使用這些功能,與這些功能交流對話時用的介面。介面的設計,關係到軟體?品是否方便使用,是否通情達理,善解人意。介面反映了你的軟體是否具備某種人性。打開PC的電源,你在電腦螢幕上看到的一個又一個畫面,就是Windows最開始的介面。從一個電影劇本的角度看,介面多少有點類似故事與人物活動時的場景。 過去的20年,年復一年,電腦的介面發生著巨大的變化!在20世紀70年代初,電腦的輸入手段只限於撥盤開關、穿孔卡片與紙帶,最豪華的裝備也不過是台電傳打字機罷了。輸出設備只有一台寬行印表機或者繪圖儀。電腦的CRT終端還只能算大型機上尚未普及的奢侈品。因而,"介面設計"從來都沒有成?一個軟體設計中的主要問題。那時開發人員主要的注意力都在演算法上,他們要考慮如何用小得可憐的機器記憶體與慢得讓人焦急的CPU來完成計劃中的工作。80年代,圖形螢幕終端開始普及,介面設計提上了日程。一門新的學科,軟體心理學也隨之誕生。今天,在已走進千家萬戶,甚至人們衣服口袋中的各種電腦中,商業軟體的介面已變成了軟體設計中舉足輕重的一個部分。 功能與介面設計這兩個過程,並不一定需要電腦編程人員介入,就如同寫劇本並不一定要有導演和演員參與一樣。功能與介面設計,甚至無須電腦專業的人員介入,但設計人員要對該軟體所應用的領域有充分的瞭解,對該領域如何使用電腦要有充分的想象力與創意。設計人員還須對市場上已有相關?品胸中有數,並找准自己的設計在市場上的位置,揚長避短。這其中也應包括了對正在設計的軟體與其他市場上同類軟體是否"相容"的一系列技術上與商業上的考慮。公司大到如微軟,設計人員還需要具備一定的人際交流與協調能力,使自己的設計得到市場上大部分同業廠商中潛在的同盟軍與合作者認同的能力。 功能與介面的設計完成之後,才是Coding設計開始之時 完成了上述過程,接下來的設計工作要交給軟體工程師來做了。這有點像電影開拍前還需要準確的分鏡頭劇本一樣。工程師們現在要設計和制定一個技術規則了。這個技術規則包括,採用哪些軟體技術,用什?樣的軟體工具語言,在一個什?樣的環境與平臺上,如何將整個專案分割?一塊塊的子任務,詳細的子任務清單等等細節。這個過程當然也要強調想象力與創造性,但更重要的是技術上的可行性,子任務間相互配合與協調的高效率,以及完成整個功能與介面設計的準確與無誤。 一方面,照這樣做出來的Spec,對每一個子任務如何完成並未給出更詳細的約束。另一方面,所有的介面,與?品應該包含的功能,都通過演示程式在電腦上即時演示過了。設計中的問題,也通過這些演示看得清清楚楚了。在你的?品設計真正定稿之前,以上過程會反復幾次。這是公司裏?品研製過程中最民主的階段。全體人員"沒大沒小","橫挑鼻子豎挑眼",暢所欲言,直到大部分同仁認可?止。 以上步驟,是D在微軟公司工作時,完成一個軟體工程Spec的過程(如果更詳細的話,就要變成專題論文了)。到此?止,?品已經是看得見摸得著的東西了。這樣,一個Spec可以成文,人手一份了。 有了一個Spec,目標已經很明確了。接下來就是一張抵達目標的時間表,從整個大組,直到每個工程師都要遵循。這張表,大家習慣稱?"Milestone",也就是公路邊那一塊塊標誌著離下一站還有多少公里數的小石碑。這張表,以及將其分解到的每一個小組與個人,(針對個人,又可稱做每人的日程表(Schedule))雖然這主要是大小頭目的任務,但如果工程師自己興趣的話仍有足夠的權力參與。值得指出的是,如果已經有了一個全組反復參與下做出的Spec,那?這個時間表的?生,也就很清晰明瞭,並無太大困難的工作了。但時間表一經確立,就變成約束你自己的紀律了。再說一遍,這是微軟公司內最重要的紀律! 目標有了,路線有了,走完每一站的時間也有了,就該輪到一個個自命不凡的研發工程師們上陣了。在一個個的Milestone之間,微軟風格的Spec,是留下了足夠的餘地給他們在編程過程中去"八仙過海,各顯神通"。 有了網路,研發管理變得十分"鬆弛" 瑞特蒙得園區內,研發隊伍的管理其實是非常鬆弛的。除了極少數臨時工(Contractor),每位員工單獨擁有自己一間十余平米的辦公室,均有一套價值千元、高低任意調節、按人體功能設計的工作臺與工作椅。書架、文件櫃、白板、至少兩套PC,這些都是標準配置。許多人喜歡在自己的房間裏貼滿各自心愛的照片、卡通,擺放或懸挂花草、盆栽、風鈴......。將沙發床、健身器、音響設備搬進房間的也不在少數。 看到別人有趣,D也將70年代戴著領章帽徽的解放軍軍人半身標準照放得老大,端挂在牆上。照片之下再標上一行大字:中國軍人佔領了美國(Chinese Soldier Takes Over USA)! 除不考勤上下班時間之外,公司還從早10點到下午2點,每一小時一趟的班車,在園區內與園區邊設備豪華的健身俱樂部間穿梭。公司支付一切費用,員工可游泳,或網球......,活動筋骨,鍛煉身體;一年四季,或小組,或大組,或整個公司,三日一小宴,五日一大宴。美食美酒,Party不斷;新上檔的電影、熱門棒球賽、NBA籃球賽、橄欖球大賽、歌星演唱會,......,公司贈票給員工全家,請你務必賞光。一年三百六十五天,公司開滿了各式各樣的進修課程,鼓勵諸位踴躍參加。如諸位能大體上不影響日常工作,而學校又肯收你,讀博士、讀碩士,公司均樂於?你支付學費。聽起來真是神仙過的日子。 其實也不只是"聽起來"。頭一回參加全公司每年一次的Party,D還真的小有震撼。在西雅圖湖東區的一個大農場,幸虧有這?大一塊地方容得下這?多人和車。那時公司還只有7000人,但7000輛車密密麻麻地排在一起就已經是很大一片了。那一天,幾英里之外,便站滿了值勤的警察。一輛輛貼著微軟特別通行證的車輛,打扮如嘉年華會。方圓數百英畝的會場上早已搭起了一座座各色帳篷,擺滿中國的春卷、日本的生魚片、比利時的巧克力、美國的烤牛排、老俄的魚子醬......,幾乎全球的各色食品應有盡有。所有人,一律免費自助。不怕你肚子大,就怕你吃不下。所有飲料,包括低度數酒,當然也是無限制供應。各種各樣的音樂,混雜著燒烤的焦香在農場上空飄蕩。加拿大國家馬術隊在做著精彩的跳躍。一架架飛機拖著彩帶在天上盤旋,一朵朵花傘從天而降直落靶心。這是前來助興的奧林匹克跳傘隊。今天還有嗎?五萬人了,一天又要吃掉多少噸美食呢?D還真有點懷念這讓微軟人自豪的華宴。 不過,公司終究不是療養院。公司更不可能養"大爺"。任務已經明確了。Spec已交到你手中,Milestone已清清楚楚。好酒好飯無非是讓你上陣時精力充沛、生龍活虎罷了。就如同那第一流的奶牛場,請你聽音樂,給你做按摩,?的是請你多出牛奶。 既然公司已待諸位如上賓,吃飽喝足之後,就輪到把諸位的"牽出來溜一溜"了。公司也必須對諸位一舉一動了如指掌,方不?過。因此,每天,諸位從使用Card Key(身份證兼開門的電子鑰匙)進入辦公大樓開始,你打過的每一個電話,你每一次訪問源碼庫和資料庫(作?可選項,你在辦公室內電腦上每敲下的一個鍵),其時間、地點都記錄在案。如有必要,均可查詢。 一般而言,在你決定要結束一天工作離開辦公室之前,應給小組的每一位同事發一個日報告(Daily Report),有事則長,無事則短。這樣,同事們相互間知道你今天有哪些值得驕傲的進展,發現了什?問題,有什?需要求助?再加上周報告與月報告,這是不可偷懶的"瑣事"。各級頭目基本上靠這些電子郵件來瞭解和掌握工程的進展。(聰明如中國人,便有人也有這個本事,一天便幹完預計三天的工作,然後寫上三份Daily Report定時發出,樂得賺來兩天假期。多好的管理都有漏洞,但這是以你完成任務?前提的。當頭兒的知道不知道也都睜一眼閉一眼了。) 如果有必要,每天三五成群、共進午餐通常是大家一個非正式討論工作的時候。此外,除非公司有活動,小組通常每周僅有一次例會,探討那些E-mail中不容易說清楚和解決的問題。 公司內部不僅是省掉了許多會議,員工所有的公司布告與通知、出差購票與報銷、領取雜物、查找資料、借閱圖書,微軟公司的網路將這些都包辦了。行政後勤人員在前方第一線無事可做了。因此,比如D的部門,除一位?全體人員服務的秘書外,百分之百,包括總經理在內,全部是?第一線幹活的工程師。 一張企業網(Intranet),將一個個不考勤、不開會、整年嚼著口香糖的"美國大兵",緊緊地網在一起,成?一支協調一致的隊伍。也使得拼殺在第一線的隊伍,將自己的行政與後勤,統統甩給了公司內的少數直屬部門。微軟創造了在美國也是極高的前後方人數比。網路,用蓋茨先生的話講,是公司的神經系統! ?品的按時完成,源於雷打不動的 Milestone "Deliver,Deliver And Deliver",這句話的中文意思是說:一是按時出貨,二是按時出貨,三還是按時出貨。這是在微軟瑞特蒙得園區工作的,任何一個研發隊伍的大小頭目,都要牢記在心的最重要的一句話。相信這也是美國任何一間軟體公司都要追求的一個目標。雖然每一個大的軟體專案,比如在微軟,從Windows 95到Windows XP,幾乎每一次都比預計的時間延後投放市場,雖然理想與實際總是有一段距離,但理想總是要追求的。相對而言,對完成Windows這類規模已達幾百百萬位元組、又要涵蓋數以萬計PC硬體廠家的底層系統軟體,微軟還是做得相當出色的。 員工各自的Milestone,是從每位工程師到大小頭目最重要、也最醒目的目標。花香鳥語的微軟園區裏,前面講了那?多事,都可以請隨尊便,都是?了在諸位的Milestone上,容不得半點含糊。Milestone,可以說是微軟公司軟體?品專案管理中的核心。坦率地講,90年代初,直到D離開崗位(以後,就不便妄言了),微軟的進度管理是相當苛刻的。新老員工一視同仁,並不會因?你是新加入的員工給你更多的學習時間。在一群自命不凡的聰明人中,別人可以完成,你卻不能,這種壓力是可想而知的。在那個年頭,無論幾點鍾走進微軟園區,停車場上永遠停著一片片的車輛。加班加點是普遍的事情。所以,不考勤的好處就是不必付加班費。將沙發床搬進辦公室,連跑回家睡覺的時間都省了。無怪乎,法官大人對壟斷案的判詞中要指責微軟每周平均60小時的工作時間。 除了朋友間的相互幫助,政治思想工作外,那是心理醫生或者教會分管的職責,不在公司的議程之內。除了電子郵件中乃至會議上就事論事的爭論外,美式的日常管理中較少聽得到對哪位員工正式的批評意見。會議上聽到的大多是"你好我好他也好"的正面鼓勵。打工的諸位要想發現與自己相關的問題,就看聽話的諸位,能否敏感地直覺到,你好我好中的奧妙與異同。 如果老弟真的糊裏糊塗,完不成任務,而又自我感覺良好,那?,一年兩次的評審(review)就是毫不含糊地與你清賬的時候了:你自己給出一番自我鑒定,你的頂頭上司也會給你一個鑒定,一項一項?你打出一個分數來。這次不再會是"你好我好他也好",這關係到你這半年的獎金、股票、工資乃至你是否還幹得下去。因?這也關係到你上司,他的獎金、股票、工資乃至他是否還幹得下去。 坦率地講,無論公司?你準備了多?優秀的工作條件,提供了多好的福利待遇,努力?你營造一個鬆弛的環境,早期員工所承受的壓力也是無須掩飾的事實。壓力就是來自不太容易"泛竽"的Team Job和雷打不動的Milestone。 在D的微軟歲月中,D未解雇過自己的員工,也未見過開除員工的現象。但用不著多久,完不成任務的員工大多選擇自動辭職。以下隨便撿出幾個實例: 1992年,D曾從加州矽谷聘請了一位元已有5年軟體工作經驗的臺灣同胞加盟D的部門。但上班僅一周,這位同胞便跑來向D辭職。他抱怨,他無法承受這種不給切入時間便得立即上陣的壓力。他沒有信心按時完成任務,這與他過去5年的經驗不相符合。三十六計,走?上。 1993年,Visual Basic 未能按時出貨,該部門從上到下正職領導全部辭職。 1995年,一位畢業於中國名校,加入微軟前又曾在北京某一知名軟體企業工作過數年的北京老鄉,跑來向D投訴:他在自己工作部門內受到洋鬼子無法忍受的不公正待遇,希望D利用自己的位置給予申訴與幫助。D費盡了力氣,才發現,這位自視甚高的老弟實在是忍受不了 Milestone的壓力,精神開始變得恍惚了。雖然D?此事,求助了許多公司中包括其他中國人在內的同事,也包括今天任微軟(中國)公司總經理的唐俊能否?他更換一個壓力相對輕微些的位置,均未能解決他的問題。公司畢竟是公司,何況?矢之的微軟公司。 1996年,D深感自己三板斧已經耍盡,"寶刀"已老,已無法勝任微軟公司高級軟體設計師的重壓,乘著公司尚未討厭自己之時,向蓋茨先生遞出辭呈,飄然而去,實也一例。雖然形式不同,其本質一樣。 ...... 對員工的充實與培訓是公司的責任。但在美國,照顧弱者通常是社會與各級政府的任務。在戰場上,沖不上去的士兵,無論在哪個軍隊裏日子都不好過。 細緻的源碼管理,與嚴格的質量控制 Milestone與按時出貨,關係著每位元員工在公司內的"生死存亡"。但還有更重要的,關係著公司自己的生死存亡,那就是?品的質量! 在美國,不僅是微軟,任何一間真正的公司,在他們的"多快好省"總路線中,"好"字永遠是擺在首位的。有人說,老美有錢,可以把錢往裏砸。但也有人說,這其實更是一種文化。看看上海外灘上那一排排百年滄桑的花崗石大廈,的確是一種文化。再看看北京故宮那金碧輝煌的建築群,那是更古老的文化。無論各路專家如何詮釋這些文化,這裏都包含著一件共同的組成部分,讓人歎服的質量。 微軟研發?品,的確不吝惜金錢。他已花了足夠的人力物力去做市場的調查,去琢磨?品的Features(功能、特色),去反復完善?品的設計。在程式師開始動手Coding(編寫程式)之後,公司還要組織幾乎和研發人員人數1:1的測試人員反復測試設計中所有的功能。這是一支千萬人的龐大的隊伍(如果算上微軟外承擔了貝塔測試的數千家公司,人數將多達幾十萬人)。從?品的第一次合成(Build)開始,到阿爾發(α)出貨,到β出貨,直到投放市場前最後一分鐘(已經是數千次合成過了),這支隊伍數年如一日,一直都在做著永不停歇的質量測試,不停地尋找一個又一個各式各樣的問題。即使是這樣,由於一個大型軟體的特殊性,它的所有功能間排列組合所?生的近天文數字的不同情況還是難以完全覆蓋。這也是?什?每次微軟的Windows?品投放市場之後,仍能發現其中某些問題的原因。慶倖的是,至今?止,尚未發現過嚴重的弊病。試想,幾千萬份軟體在上億台PC上運轉,如果也像某些公司的某些做法,將大部分測試交由市場去完成,這樣大規模的?品,待到問題"百花齊放",那垮臺的就不僅是微軟,一時間,會?全球的PC業造成難以估計的災難。 人們常說,股票價值數千億美元的微軟公司,除了幾千個聰明的腦袋就沒有什?了(園區雖然漂亮,那幾幢樓可值不了這些錢)。腦袋值多少錢,多少有點虛。從這些腦袋裏寫出的一串串源碼才是微軟看得見的財?。 微軟公司當然有一整套嚴格的制度與措施。在這套措施的管理之下,你寫的每一行碼,都會保存得十分妥當和有序。每個程式師的源碼都會、也必須定期存檔(Check In),這是你創造的財富,也是你的工作紀錄。無論什?原因毀壞了你的硬碟,或損毀了某個文件,你自己再也無法挽救時,打個電話,就會有人在一個新硬碟上恢復你昨天下班前所做過的一切。 就D的部門而言,事前對每位程式師的源碼風格不做硬性規定。但每一階段,小組都會對全組的源碼做一次統一的整理(Code Review)。簽上各自的姓名,補上必要的說明,並使全組程式簡明、易讀,書寫風格大體一致。一套仔細有序的源碼保存與查詢體制,不僅僅是質量控制的必要保證(大大加速發現和修改錯誤的過程),也同時保障了?品的連續性。一個公司才有可能,"走了張屠戶,不吃混毛*",才能應上那句話,"鐵打的營盤,流水的兵"。 源碼還必須有一套無懈可擊的保護系統。源碼在軟體公司,猶如鈔票在銀行。Windows NT 4.0中文投放市場前夕,北京某個著名電腦公司向微軟派來了四位得力幹將,作?OEM代表,在微軟提供的園區內辦公室,由微軟協助共同解決該公司預裝NT4.0有可能出現的硬體相容性等技術問題。四位老弟,剛一上班,網上一轉,大概是頗有發現,立刻將餘事扔到一邊,找來軟碟,撿其所好,先下載再說。未料到,文件尚未拷完,公司保安人員已站在了辦公室門口。幸虧該北京公司反應及時,立即將四人調回中國,息事寧人,未釀成不必要的風波。 1994年,D陪同蓋茨先生訪問北京。訪問中,有人當面指出:微軟公司的軟體價格太高,不符中國國情。蓋茨先生回答:既然中國能夠接受收彩色電視的價格,?什?不能接受電腦軟體的價格呢? 軟體靠進口,當然越便宜越好。軟體若能出口,那可能就是另一種考慮了。 更多資訊請訪問我的網站:http://www.promaner.com
系統時間:2024-07-03 8:55:43
聯絡我們 | Delphi K.Top討論版
本站聲明
1. 本論壇為無營利行為之開放平台,所有文章都是由網友自行張貼,如牽涉到法律糾紛一切與本站無關。
2. 假如網友發表之內容涉及侵權,而損及您的利益,請立即通知版主刪除。
3. 請勿批評中華民國元首及政府或批評各政黨,是藍是綠本站無權干涉,但這裡不是政治性論壇!