1、微軟研發致勝策略10您是否曾經暫時停下手邊的工作，思考一下如何能使項目的進行更有效率？您想到的是需要高深學問才能解決的方式呢？還是只要利用一些經驗法則就能化為神奇呢？但愿這個像猜謎一般簡單，這樣訓練工作就容易多了，可惜事實不然。要讓項目提高效率，需要長時間、一點一滴地累積非常多的知識、技巧和信念，尤其新手更是如此，不幸的是，這種能力的培養需要很大的耐心和毅力，而大部分的人都是用嘗試錯誤的方式來學習，這樣代價既高，功效也不大。嘗試錯誤的方式會耗用很長的時間，可能得到經歷很慘痛的教訓，如果能前人的經驗和智能，學習前人已經歸納出來的知識，避免犯下同樣的錯誤，不就快得多了嗎？本章首先來介紹前人的經驗。

2、就我所知，對于一個希望不加班就能如期完成任務的團隊，必須把握好的原則，這是開發部門的基本觀念，也是往后幾章的基礎。專心改善產品公司付薪水給程序設計師，是要他們在合理的時間內11做質精良的，但是程序設計師的時間卻經常被其他的事情占用掉了。這樣的程序設計師或他們的經理們，就是因為不了解開發的真理：任何不能改善產品的工作，都是浪費時間或是偏離方向。如果您一時不了解這個觀念的重要，請想以下兩個典型的比較：一位程序設計師一天到晚開會、寫、閱讀和回復電子郵件，另一位程序設計師則專心研究、設計和測試新產品的功能，試問誰比較容易脫穎而出？前完成工作呢。是心無旁騖的那一位，他甚至可能提我經常發現，團隊出問題的原

3、因之一，往往是因為程序設計師們都在做他們不該做的事：他們花太多的時間準備開會、參加會議、讀寫開會和進度，以及回復電子郵件。這些不能改善產品的工作，固然一部分是程序設計師自己主動做的，但更大的一部分是主管下令。曾經與我共事過的一位經理，要求每一位組員要用交一份工作周報，每周開一小時的會目前各人手上的工作內容，以及其他突發性的事務，開完會后，提奠定基礎微軟研發致勝策略12出意見的人負責寫出這位經理的，交給經理。只是想管理每一個細節，但并不了解這會讓團隊被無意義的工作壓得無法喘息。這些進度真的那么重要嗎？那些后續的用意又是什么呢？如果開會時經理自己做個簡單的筆記，不就省了這些用的時間和精神？所占很顯

4、然，這個問題的必須視您身處的企業環境而異，但從我剛才所舉的實例來說，其實只有最初制定進度的那份是有價值的，其他的都是可有可無，甚至進度檢討會都沒有必要召開，而且每次那位經理要求后續時，我都很納悶，心想：“我剛才不是已經的想法了，為什么我還得再寫一遍？”我我不過是偶爾去參加他們的定期進度會議，所以對我的時間損失并不大，不過，我常在想，不知道公司里有多少不必要的例行工作正在加重員工的負擔？這位經理本意是盡力把每件事情做到巨細靡遺，但是卻違背了身為開發者的基本守則：者的任務是努力消除程序設計師工作上的一切，讓程序設計師全力專注在真正重要的工作改善產品。13這并不是世界的大發現，而是極簡單的道理，但是

5、，有多少開發主管是真的把“消除程序設計師工作上的”當作積極追求的優先目標，而且確實做到呢？如果剛才提到的那位經理真的用心去減少組員不必要的工作，我確信他可以想出更簡單有效的方法掌握工作進行的狀況，而不必一再浪費組員的時間開會和寫。千萬程序設計師的時間浪費在改善產品以外的工作上。請不要從字面上解釋話我所謂的程序設計師的時間花在改善產品以外的工作上，請不要從字面解釋成程序設計師只許寫程序。事實上，思考如何設計、測試程序和接受需要的訓練等等，雖然不是直接投入在改善產品上，但對產品品質卻有深遠的影響。如果程序設計師在動手寫程序前，仔細思考過產品的設計，把缺點改正，當然會比一味地埋頭苦干要好得多了。奠定

6、基礎微軟研發致勝策略14有些團隊的活動，用意是讓團隊成員在愉快的環境中工作，提高程序設計師的生產力和士氣，雖然看似與產品無關，最后還是對產品品質與工作效率有正面的幫助。排除干擾如果您希望團隊能在期限之內完成好的，就必須盡可能排除一切不必要的工作，特別是您打算分派工作給全體組員之前，請等一下，問問自己，這件工作真的有必要叫大家做嗎？能不能由您自己做呢？比方說，如果您要準備向項目概況，非得要所有的程序員停下手邊的工作，為每個程序寫一份摘要嗎？我倒不這么認為。身為經理，您應該平時就對項目的進度及一切的狀況非常清楚，不必靠人幫忙就能做出切中要點的演示文稿，而且信息已經存在腦海中，比起再去匯總整理一堆人

7、的應該是快得多，也更好組織。或許這要花掉您幾個小時，但總比打攪整個團隊去做一件與產品無關的工作要好。我通常會做得更徹底一點。如果我發現一位程序設計師總是被不能不做、卻與產品無關的工作絆住，我會主動解除這件工作，由我來做好了，這樣程序設計師就能完全專心在上面。除非是為了訓練，否則沒有任何理由要15求程序設計師本人回復，詢問項目的交給適當的經理來回答就行了。凡是能由主管出席的會議或能由主管執筆的，都不應該丟給程序設計師，最好能把這些開會、都。我知道這些建議與大部分的管理課程或教科書上所指的(delegation) 有所，我并不是說這些課程和書籍錯了，而是您在實際工作中應該放聰明點，對于工作的分派應

8、該更有選擇性。如果把工作分出去的目的僅僅是為了減輕個人負擔，實質上您做的是團隊生產力的事情。別人“能”做某件事，并不代表他“必須”做那件事。您看過整個房子的搬遷嗎？我不是指搬家，而是整個移到別的地方 (房子從地基上拔起，用車的房子多是木造的，可以這樣搬移)。可以把項目比喻成那間房子，把經理想成開路先鋒，他的責任是把前面所有的物排除，讓房子能一路不停地穩定前進，而不是走走停停，停停走走。房子前進的時候，者不希望每到一個路口就停下來處理紅綠燈，或協調其他的車子讓路。他必須事先就規劃好最理想的路線，在房子抵達路口之前，就協調好工程卸下懸掛著的標志燈或是電線等會阻礙行進的東西，奠定基礎微軟研發致勝策略

9、16等房子經過了再裝回去。他應該避免將拖車停下來繳過路費，或是跟工程開完協調會。搬遷房子的開路明白一件事，如果要房子一路不停地向前行進，一定要找出所有的，并且排除掉。過這樣一來就得停下路費當然也可以由拖車車子，如果由開路來交，面交不是更好嗎？很不幸，有太多的開發經理在不該時，讓組員為了與產品無關的事情，被外界的雜事干擾正常的進度，以致項目進度不斷延誤，甚至停滯不前了。保護程序設計師不受任何阻礙和干擾如果我帶的不是程序設計師，而是主管前面的中，我假定您是程序經理，帶的是程序設計師，但是如果您帶的是測試、文件撰寫或是其他類型的小組，您的原則還是一樣的。基本上，身為主管的重責大任就是讓屬下專心做他該

10、做的事，不論他該做的是寫程序、測還是寫文件。17就算您帶的全是主管，您也應該決定哪些工作是不必要的，盡可能免除。開個會了解各位主管們手上項目的進度，和開個會了解各位程序設計師們手上程序的進度，都一樣是浪費時間，特別是獨立進行項目的主管，沒有必要讓一位主管了解與他項目無關的概況。主管的時間對產品影響也很大，浪費主管的時間，他就沒有辦法做他該做的事排除程序設計師的工作。一定有更好的方法可以減少干擾身為經理，我在項目的每個階段都會問自己一個問題：“我努力的目的究竟是什么？”我總是不斷用這個問題提醒自己，因為太容易被不重要的工作拉偏方向了。如果您經常把或備忘錄東修西修的，換個字型或樣式，結果美化文件的

11、時間比寫的時間還長，您就明白意思。因為在那一刻，這件工作占住了您全部的思緒，似乎是最重要的事情，但只要您隨時以整個項目的眼光來看事情，您就不會陷入細枝末節了。談過了把時間浪費在進度例，現在您應該可以回答這個問題：和檢討會議的案奠定基礎微軟研發致勝策略18“我舉行進度會議和要求進度竟是什么？”的目的究，主要的目的是了解項目進行的狀況，以便及早發現任何進度上的延誤，避免項目發生進度失控，不是嗎？假定沒有發生延誤，每一個項目都如期完成，也沒有人需要加班，那還有必要進度嗎？當然不必了。如果您開進度會議和要求進度目的，是想確定項目進度有沒有，有必要動員全體去收集這些信息嗎？我不這么認為。我從來不開進度會

12、議，不論我是帶新的項目或是接手其他人帶了一半的項目，我第一個的就是這類沒有意義的流程，我就是不相信非得用開會寫的方式才能掌控項目的進行狀況。至于進度呢，它究竟有多重要？我認為進度雖然令人厭惡，但卻是必要的，經理總得了解項目是否出了問題。但請別忘了，進度雖然必要，但是它絕對不會對產品有任何幫助。所以，當您遇到一件必要但對產品沒有幫助的工作，您得尋求這個問題的：“我該怎么樣保有這項工作的好處，消除它的缺點？”19進度確實有重要的目的，但得花時間去寫，而且令組員心生害。 至少在微軟曾經有不少團隊深受其如果一位程式設計師要花幾個小時寫，交代自己做了什么工作、解釋這件工作為什么花的時間比預計的長，那的確

13、會對他造成過度的壓力，并且讓每個人預定項目一定會延誤。更常見的現象是，程序設計師明明每天賣力工作至少12小時，而且沒有磨洋工，整整工作了80小時之后即發現他只完成了本周日程表上27小時的工作。進度會議（Sus Meeting）的用意，每家公司的進度會議都不完全一樣，我所指的進度會議，是指每個人坐在一起輪流講講自己做了什么，或是沒做什么，只有這個用意。還有一種進度會議，其用意不是講述各人做了什么或是沒做什么，而是同一項目中不同小組的協調，只有多小組項目 (multi-teroject) 才有這個需要。每一個小組的組長并不各事項進行的細節，而只提出會影響其他小組的事項，例如上游工作進度比預期的慢，

14、或是目前已經完成可以交付下游工作小組，或有一件事希望別的小組配奠定基礎微軟研發致勝策略20合或支持等等。這種進度會議是為了協調小組之間互相依賴的工作事項。任何需要等待別的小組做完才能開始工作的下游小組，都需要預先知道上一小組的工作情況如何，而且每一位應該盡早知道，這對于制定下游小組的工作進度是非常重要的，不然會臨時手忙腳亂，或是影響整個項目的進行。但是真理依然不變，程序設計師是不該被這些事情干擾的，小組的組長去開會就夠了。如果您沒有過這種痛苦的經驗，請試著想像一下：您已經是拼盡全力加班了，但趕不上進度，目標離您仿佛愈來愈遠，那會多么令人沮喪！更別提您不敢浪費一分一秒，每天都累得像狗。假如這種情

15、況是日復一日、年復一年，您還能每天早上精神抖擻地跳下床，滿懷熱忱去上班嗎？或者更可能的是，您心中充滿、挫折、沮喪，愈是努力工作，工作積壓愈多，結果進度愈落愈遠，天啊！我恨進度，因為它迫使程序設計師想著自己沒做的事，而不是強調自己完成的事。組員無法感受到逐漸推進目標的，反而隨時被提醒：進度了喔，項目不21曉得會不會莫名其妙地搞砸。他們只知道自己工作確實很盡心盡力，但實在不知道如何跟上進度。團隊也和個人一樣。如果團隊覺得整體不斷往前進，那么就會一直保持前進，而如果團隊覺得自己一定會進度的，那么，慣性和自我預示的心理就會使它相信自己是者，導致士氣非常低落。請不要誤解意思：如果一位程序設計師明明工作了

16、80小時，卻只能完成進程表上27小時的工作，那一定有什么地方搞錯了；也許他最近做了太多面試的工作，或是開了太多的會，或是最近太多，或是他正在調整自己的情緒，主管應該和他一起找出問題。但是，即使是他個人不懂得自己的時間，也不該用進度使他難堪。到前面待會兒有更好的方法解決這個問題。讓回問題：如何保持進度的好處，又不必忍受它的缺點？其中一個是設計一種新的進度，非常容易寫，既不花時間，且內容是正面性的。以下是方法)：方法 (我相信您一定可以想出更好的每當有人完成了一項新的功能或特色，就發個 e-給大家。奠定基礎微軟研發致勝策略22每當進度快要了，就到私下原因，一起開動腦筋尋求解決之道。就這么簡單。依樣

17、的：方型的進度可能是這“我已完成 Faxmangler 的搜尋與取代功能。Fr主管應該看一下結果，然后回一個：”“我檢查過Faxmangler的搜尋與取代，不太順暢，請再修改。Hubie”或是：“很好，繼續加油！Hubie”想想看，如果大家經常收送這類正面的e-，一定會覺得充滿干勁，這和可恨的進度多么不同！程序設計師會很樂意看見這類的好消息，當自己送出完成工作的信息時，也會很有成就感；沒有人會覺得這是很討厭的。當某位程序設計師覺得自己可能要如何避免這種事情。是了，我會和他談，研究將來在制定進程時疏漏了某一個重要環節嗎？或是時間表定得太樂觀了？是不是有個錯蟲(bug)在作祟，害得程序很難寫或無法

18、測試？不論問題是什么，我們一定想辦法解決掉，并且預防它將來再發生。我只要靠這兩種方式，就可以完全掌握項目進行的概況。23要求的話，我也可以輕松寫出項目演示文稿，根本不必勞駕別人，所以我帶的程序設計師不會因此而被打擾。更棒的是這兩種反饋方式產生了雙重好處：第一，團隊成員經常感到項目又向前邁進了一步；第二，這對主管和屬下都是很好的學習機會，不會聳聳肩，無所謂地說：“反正進程一定會的，沒啥大不了。”因為會認真面對問題，商討對策。為了強調進度的正式性，而把它弄成一件沉重不堪的工作，這就是主管過度重視進度而忘了自己真正的目標。結果陷入了流程的陷阱，倒把產品丟在一邊了。只有當您非常清楚您和您的團隊該做的是

19、什么，您才能用最少的時間和最少的挫折去完成項目目標。回頭檢討一下遭遇過的, 有沒有辦法可以改善？有沒有更好的方法，讓工作愉快些？至于那些對產品沒有幫助的雜務，如果可能的話，還是免了吧至少它丟給程序設計師。記得自己真正的目標，然后讓團隊用最有效又最愉快的方法把它完成。奠定基礎微軟研發致勝策略24被成功的喜訊了？您可能會有這樣的疑問，如果每個人都把自己完成某件事的訊息發給大家，會不會塞滿了每個人的電子信箱。實際的情形是，每天的并不多，因為信息不會送給每個人，而是只送給同一組的四到五位程序設計師而已。微軟比較大的團隊可能有多達 50 位的程序設計師，但是都會分成小組，每一個小組大約有五到六人。每一個

20、小組負責項目的一部分，有一個明確定義的目標，有一位組長，也有自己的進程。小組內的程序設計師當然也屬于整個團隊，但是以每天的程序開發工作而言，只與四五位程序設計師有關而已。事實上，即使是 50 位程序設計師的大型團隊，每個人收到的“完成”的也不多，數量穩定，剛好夠讓每個人感覺到工作的進行，絕無之虞。明白說出目標您所認識的人中，有多少位一早起來突然發現，選了幾門神奇的課程就拿到了計算機學位？有多少人隨便收拾一下東西就搬到了您的隔壁？聽起來不太可能吧。沒錯，一般人不會興之所至就去修個學位或搬家，這25些都是計劃過的，他們會決定：“我要成為程序設計師”或是“我要住在迪士尼樂園旁”，然后籌劃一番，再采取

21、行動，才會達到目的。，生活中的確有些事情是不經意就發生了，您可能靠運氣就得到一份好工作，或是福星高照在撈了一要完成筆。很不幸，推出一套WordSmasher”具體。的目標，并不比“不錯，大部分的時候您都可以完成目標，但問題是，在這之前，有多少時間被浪費掉了？雖然您運氣好，得到了一份理想的工作，但之前也許有好幾年頻頻跳槽；或者您先細細思量自己適合什么樣的工作，然后找到符合自己條件的幾家公司寄履歷、面談，會比較穩當？我所輔導過的案例中，有六個總是在失敗邊緣掙扎的團隊，他們都有一個共同的特征，就是目標太模糊。其中一個案例的情況是，小組的任務是做出使用者界面的函數庫，給20個左右的其他小組使用，他們做

22、得人仰馬翻，還被別的小組抱怨函數庫既笨重，錯蟲又多，很不好用。當我和這位組長共同檢討工作時，我問他項目的目標是什么。“為 MS-DOS 的應用程序提供像 Windows 環境的使用者界面函數庫。”我問他還。奠定基礎微軟研發致勝策略26“您的意思是？”我說，他剛才的太模糊，能不能說得更具體些？“嗯，函數庫應該做到零缺點。”我點點頭，再問：“還有呢？”他想了一下，聳聳肩，答道：“不出來了。”接著，我說明任何函數庫的主要目的是存放每位需求者必要的公用程序，不是大家非得用到的東西是不該在里面的。他很同意，認為這一點是顯而易見的。但當我繼續下面的著工作，我開始不確定他是否真的懂得這一點。我指上的一項，問

23、道：“這是做什么用的？”“那是 Works 小組要求的，是用來” “對其他小組有用處嗎？”“沒有，只有 Works 小組會用到。”我指著上的另一項，問道：“這個呢？”“那是給 CodeView 小組的。” “那，這邊這一項呢？” “是 Word 小組要的。”一路看下去，我發現他對任何要求都來者不拒。他也知道函數庫中應該只有大家都要用的程序，但他在做決策的同時并沒有確實把握這個原則。他的目標只是27“為 MS-DOS 的應用程序提供像 Windows 環境的使用者界面函數庫”，有沒有辦法說得更詳細些？目標是為MS-DOS 的應用程序提供像Windows 環境的使用者界面函數庫，只包含對每個小組都

24、有用的程序。如果把目標定義精確些，就可以發現很多程序其實是不應該放在函數庫中的。在檢討完工作后，我開始研究另一個問題：“很多小組抱怨，函數庫中每次一放入新版的程序，就會發生失敗，這是怎么回事？”“喔，那很簡單，他們只是忘了修改自己程序中的函數名稱而已。”這我就不太懂了，于是我請他給我一個實例。他的小組修改過函數庫中的bug了，或是加強了該函數的功能，然后就連名稱也順手改了，用另一個更能表達其功能的函數名稱；或者是做了一點小小的修改，然后把函數名稱一道改了，以強調所改的差異部分。這位組長不了解其他小組怎么會如此大驚小怪，不過是改個名字而已，非常簡單啊。他從來沒想過，有 20 個小組要因此檢查所有

25、的程序，把所有用到函數庫的地方都奠定基礎微軟研發致勝策略28改過來；他也沒有想到，經常失敗的函數庫是很不好用的，函數，別的小組會無所適從，根本不知道程序應該是什么模樣才對。如果這位組長稍微花點時間，從別的組的角度來看看這個函數庫，他就會明白放入新版程序時，與舊版能兼容是多么重要。大家都希望既用到新的程序代碼，希望所有的程序都能于是，成功，沒有任何失敗。把項目的目標再更具體化一些，那是：目標是為MS-DOS 的應用程序提供像 Windows 環境的使用者界面函數庫，只包含對每個小組都有用的程序，而且必須和其他部分的程序版本一致。現在了影響這個函數庫的重要相關，我和組長一起定出了清楚而明確的項目目

26、標。發現，只要用心考慮各之間的關系，考慮一項行動會造成什么影響，很多細節就會變得顯而易見，而且是可以事先建立正確的規范，避免事后再來花時間收拾殘局。只要在做出決定之前想，“我要這個函數庫能做到什么？項目的目標是什么？”很多問題都能迎刃而解，組長可以輕29易決定該做的，以及該如何做。如果做得更徹底一些，組長可以花幾個小時，甚至幾天來訂出詳細的項目目標，這些目標不一定要博大精深，只要目標能夠寫下來貼在容易看見的地方，隨時提醒、隨時指引，讓項目朝著正確的方向進行就可以。如果函數庫中都是全部小組需要用到的，函數庫就會體積小些、精簡而標準化，新增的功能特色就比較容易做出來，開發小組就不必拼命加班做一大堆

27、數人用得到的函數。想想看，只要把目標稍微理得清楚些，整個項目的方向就會有驚人的改變。詳細的項目目標，可以避免在不必要的工作上浪費時間。相互依賴項目失控最有可能的原因是小組之間工作上的相互依賴：一方必須依賴另一方把工作做完才能進行自己的工作，而且若是彼此的配合或溝通不夠好，整體工作必然受到不奠定基礎微軟研發致勝策略30利的影響，依賴愈多，愈容易失控。使用共享函數庫有很多好處，這是人盡皆知的事。但是身為組長的人，必須衡量是否該把這部分的程序代碼放進函數庫，所獲得的好處與必須忍受的缺點 讓其他的工作依賴于它，孰輕孰重。任何者，必須牢記并且實踐以下的座右銘：盡可能減少項目中小組彼此間的依賴。想想看，萬

28、一函數庫的開發工作進度了，又未能及時采取改善措施，對其他的小組有多大的！負責函數庫開發的小組會拖累大家的進程，使大家不由地一起延誤，若不挽救，項目就真的失控了。另一方面，如果依賴函數庫的小組聽說開發函數庫的小組無法在規定時間內完成要求的工作，也不該強迫他們。因為函數庫的開發是很多其他工作的基礎，絕不容許發生絲毫錯誤。如果強迫開發函數庫的小組必須在某個期限內完成過多的工作，等于是不恰當地依賴開發函數庫的小組。以上所談的道理似乎簡單淺顯，但是做起來可不然，我看過很多重復發生的錯誤，有許多小組真的耗費了大量時間在函數庫的依賴性問題上糾纏。31努力要有代價有些管理學的書喜歡把設定目標看成一種神秘的哲學

29、，讀起來會有這樣的感想：“我不知道究竟為何要設定目標，只知道經過研究證實，有明確目標的團隊，會比目標模糊的團隊更有生產力。”我不知道這些管理學書籍為什么把設定目標這件事弄得這么玄，設定目標只不過是要完成的事”用清晰的語言描述出來，讓每個人都有明確的概念。如果您的目標是買一棟這樣的房子： 20世紀初期的式三彩建筑，有四間臥室兩間浴室，后院還要一尊法蘭雕像，您大概會先看過一大堆的房子，然后才確定自己想要的是哪一棟。目標越是明確，達成目標的過程就會越有效率，因為您能馬上不符合腦中未來景像的事物；明確的目標之所以帶來效率，正是由于它能幫助您擋掉別的項目丟過來的不相干的本項目的策略性事項上。，專注在不幸

30、的是，在開發過程中，沒有任何事件能迫使者停下來想，卻有龐大的壓力迫使者沒有時間思考，反而忽略了設定目標這么重要的事。當項目已經了一大截，都快失控了，誰還有時間去設定詳細目標奠定基礎微軟研發致勝策略32呢？有些主管不設定目標則是基于完全不同的理由：別人都沒有設定目標為什么要這樣做？不論理由是什么，凡是沒有明確目標的小組，必定遭遇額外的挫折。如果您希望項目進行順利，就一定要花點時間設定詳細的目標，這不是什么有趣的事，但這一兩天的功夫的項目不會偏離方向，相對的是非常值得的。組員的努力應該有代價，而長期加班、飽受壓力的小組，多半是工作漫無目標的。不要因為制定目標需要花很多時間，或是別人都沒有做，就省略

31、了目標的制定。制定明確詳盡的目標所花的時間，絕對會讓團隊得到更大的好處。程序設計的優先考慮如果您請三位朋友順路到超級市場幫您買些蘆筍、綠豆、玉米，結果其中一位買了罐頭蔬菜因為最便宜，第二位買了冷凍蔬菜因為最容易煮，第三位買了新鮮蔬菜因為33最健康也最美味，您會覺得驚訝嗎？至少，您覺得這樣的事情會發生嗎？這三位朋友買了不同的蔬菜，因為在他們心目中，強調的優先考慮不同，程序設計也是一樣的道理：即使同一個程序，由三位程序設計師寫出來的程序代碼必定不同，第一位程序設計師強調程序代碼應該越簡煉越好，第二位認為容易使用最重要，第三位則喜歡追求執行速度。假若您的產品必須快得讓人目不暇給，而程序設計師卻認為寫

32、程序的第一要點是輕薄短小，那么做出來的成品不太可能會使用特別的加速方法，執行速度也不太可能令人驚喜。假若您的主要目的是在最短的時間內做出高穩定性的，但是您的程序設計師卻喜歡追求執行速度，而不太在乎穩定性，結果一定無法令人滿意。如果程序設計師心目中理想的考慮順序和項目目標并不一致，想得到滿意的產品就好比緣木求魚。項目目標和程序設計的優先考慮并不相同，但二者常會發生部分，主要是因為項目目標能幫慮順序的確立，以下是重要的基本觀念：項目目標引導項目進行的方向。程序的考慮順序影響程序設計的過程。奠定基礎微軟研發致勝策略34假定項目的目標是做出世界上最快的 Mandelbrot plotter (一種畫幾

33、何圖形的程序)，效率就是程序設計時的第一優先考慮。暫時不談程序設計的優先考慮有何重要性，在經驗中，主管很少注意到這個問題。程序設計究竟該以什么為最優先考慮？速度？體積？穩定與堅固性？可移植性？可性？每一位程序設計師對于程序設計的優先考慮看法不同，并且反映在他們的作品中。如果大家各自隨意，就很容易出現不一致的情況：有些人為了容易而堅持寫干凈漂亮的程序，另一些人認為速度是最重要的，所以寫了一大堆別人看不懂的程序代碼或匯編語言。如果您希望小組工作有效率，能夠精確地達成項目目標，您就得建立最適當的程序設計優先考慮順序，并且讓所有的程序設計師確實遵守。最低限度，您應該為以下的程序設計考慮點排出一個優先級

34、表：體積大小 (size)速度 (speed)堅固性 (robustness)安全性 (safety)35可測試性 (testability)容易(maainability)簡潔 (simplicity)再用性 (reusability)可移植性 (portability)這張順序表中唯一需要解釋的是安全性，如果您認為安全比速度重要，您就得選擇重安全而輕速度的方式，優先要求程序中沒有bug。比方說，程序有兩種方法可以選擇，一是表格掃描 (table-scanning)、一是邏輯判斷 (logic- driven)，前者比較慢，但也比較安全，既然安全比速度優先考慮，那么除非有別的重要理由，您應該

35、選擇表格掃描的方式。除了程序的優先考慮順序之外，您還應該建立各項考慮點的質量規范指導。例如您認為堅固性是第一優先考慮，那到底要多堅固才算合格呢？最低限度，程序在輸入資料正確時絕對不該發生錯誤，但萬一輸入資料不正確時，程序會怎么辦？程序應該很聰明地處理錯誤的輸入資料，在某程度內自動更正它 (那就得付出體積和速度的代價) ？或是在程序中加入檢查輸入的動作，盡可能督促使用者輸入正確的資料？或是就讓錯誤的資料進入奠定基礎微軟研發致勝策略36處理，干脆一路錯到底？這個問題沒有標準您對品質的要求。，全看大致上，如果是操作系統，在不死機的前提之下應該盡可能接受輸入值，如果是應用，應該盡量能更正不合法的輸入資

36、料，對無法更正的輸入應該提出警告。但是，如果純粹就程序的質量而言，也許該考慮強調性信息，例如一個函數庫中的程序，遇到部分不正確的輸入值時，雖然可以做下去，但無法預料會結果，此時不如當成錯誤的狀況處理而中斷執行，以免錯用這個函數的程序誤以為一切。總之，在一般情況下都應該對不正確的輸入作某種程度的處理，只要別讓程序代碼過度就好。這里的重點是，如果事前就決定了最合適的優先考慮順序，以及各考慮點的質量規范，團隊就不會浪費太多時間把程序改來改去，程序的整體風格比較容易一致。事前決定最合適的優先考慮順序，以及各考慮點的質量規范，能夠指引開發團隊的工作。37安全性或是可移植性？以我個人的觀點，我通常把安全性

37、放在比可移植性優先的地位，也就是說，我喜歡安全的程序甚于可移植的程序，這聽起來有點含糊，那是因為可移植性高的程序通常的安全性也高，事實上，這兩種特性沒有真正的關連，只是可移植性高的程序碰巧也是安全性高的程序罷了。寫 C 程序時，宏 (macro) 是很好用的，它可以用來當作子程序的定義，但事實上它跟函數 (function) 不同，每一次啟得不夠，會被展開成一段一般的程序代碼。但如果寫(例如同一名稱重復定義 )，它會造成潛在的bug，這一點 C 語言程序設計師都非常清楚。的方式來做函數，很好用但容易有。如果您愿意利用某些 C 語言編譯器特別提供的 inline指令，就可以充的好處，而不必冒潛在的風險，惟一是， inline不具有可移植性，在不同的編譯器之間未必兼容。對我而言，安全比可移植性重要，所以我寧愿選擇用 inline 的方式來保護宏函數。奠定基礎微軟研發致勝策略38當機立斷都有當機立斷 (