process

爪哇教室＞ 獨孤木專欄 - Process《上》

我記得在我還是個學生的時候，很多電影裡面所謂的電腦高手，大概都是披頭散髮，外表打扮不修邊幅，打字打得飛快的人。除此之外，這些人還可以長時間面對螢幕喃喃自語，驀然地靈光一現之後，就可以從不斷飛逝亂七八糟的亂碼中，找出頭緒來。段數比較高的怪才，還可以入侵所有人的電腦，當然，主要都是入侵美國五角大廈的電腦，藉著威脅對全世界發射核武，從此成為宇宙的主宰。

當然，到了現在的電影，這種刻版印象已經被打破了。電腦功力超強的主角已經從得了自閉症的怪人，變身成為戴著墨鏡，穿著黑衣的俊男美女，不僅如此，還會在天空飛翔或是徒手躲避子彈。這種人，已經不需要透過威脅要發射核子飛彈，光憑他與眾不同的帥勁，就可以變成救世主。

※作者註：這世上應該不會還有那個從事軟體開發的人沒看過駭客任務(Matrix)吧？

到了職場後，這才發現這個世界好像不是這麼一回事。我遇到的工程師，確實有不少人因為醉心工作，所以打扮比較邋遢，打字不見得打的飛快。不過大多數的人看到亂碼其實並沒有解讀的能力，看到電腦中了病毒，大概也不會一眼就知道解藥是什麼，接著到野外拔幾根藥草，就可以徒手調配出解藥來。大多數的軟體工程師，就是很稀鬆平常的一般人。每天兢兢業業的超時工作，想要賺到一筆可以糊口的薪水。

當然，還是有幾個可以被稱為超人的人，確實是不怎麼注重外表。需要debug時，手指頭指著螢幕，不斷地捲動滑鼠，切換螢幕，口中喃喃自語，瞬間就可以洞悉別人的bug在那裡。

不過，在這行裡的高手，並不是個個都可以坐擁難以想像富可敵國的高薪。這跟電影裡面的帥勁模樣，其實相去不可以道里計。根據我優秀的經紀人所進行的行銷調查報告顯示，可以被稱為絕頂高手的人，佔總人口的比率太低，所以屬於可以被忽略的市場區隔，關於他們的行為，我們就略過不談。

在很多軟體公司裡，大多數人做的事好像是在古廟裡面，跟著老和尚誦經抄寫經書一樣地無趣。每次有一種新版佛經發表了，信眾們就趕快拿著教主寶訓，照三餐研讀這些智慧的言語，外人看來是無趣到極點的事情，可是工程師們卻甘之如飴。還有人會努力地比較，不同教派之間的寶典到底孰優孰劣。

當然，在外人看來，這種比較實在也蠻無趣的。不管你是拿著Microsoft的.net聖經，還是拿著Sun的J2EE金剛經，只要你會驅鬼辟邪，算出樂透彩的明牌，除了不同流派的高手之外，其實一般人並不會太在乎你到底是用什麼方式把一個系統做出來。

有了法力高強的高僧灌頂，專案就會高枕無憂嗎？根據睽違了許久的靈犬萊西市場調查顯示，高僧的加持，並不會為專案的成功帶來決定性的因素。大多數的專案，並不會因為有能夠以光速撰寫程式碼的超人在這裡串場，就會結束的比較快。

咦，有超人助陣，透過光速飛行，應該會飛得比較快呀？為什麼專案還是一樣delay呢？很多人嘗試著為這個現象找出一個合理的原因，一個常見的答案就是process。

有了超人助陣，專案沒有開發的比較順利，其實不一定跟process有關。不過因為process幾乎是無所不包，所以你把process拿來review，問問大家：『為什麼，我們有了超人，專案還是會delay？我想一定是process出了問題，你認為呢？』這大概也不會有人認為這有什麼不對。況且做不好的案子，鮮少process沒有問題。

不過凡事會把焦點放在process上，我覺得也是個企業文化的問題。在不少公司裡，特別是組織龐大分工很細的公司，如果遇到大家看法不同，彼此之間起了爭執，常常都會有人說：『我們應該要就事論事，對事不對人。不要做人身攻擊。這樣才有辦法獲取別人的合作，真正解決問題。』例如以下的這個場景。

布魯斯：我跟所有的team member討論過了，照現在這個狀況，我覺得啦，這個案子應該還要一年才有辦法做完。

吉娜：你怎麼現在才這樣講？我們已經promise人家一定要在今年年底上線！

布魯斯：那有可能？每次都是sales部門在亂給promise！這次又是誰答應人家的？

吉娜：是喬安娜跟歐尼爾去客戶那裡開會的時候答應人家的。

布魯斯激動地說：Shit！又是他們兩個！他們根本就不懂怎麼開發軟體系統！喬安娜每次去客戶那裡，都會唱高調，什麼客戶的需求永遠是我們最重視的，我們一定會誓死達成任務。每次都講那一套！根本不考慮做得到做不到。歐尼爾這個死胖子，每次根本就只想到他今年的quota。

吉娜：布魯斯，我們應該要對事不對人。我們應該把重點放在怎麼改善這個現象。

布魯斯想，唉，又來對事不對人這套了，這些大爛人：我想我們應該要改變這部份的process，sales在promise任何事情之前，應該要知會PM。

吉娜：這樣也只有解決歐尼爾這邊，喬安娜我們就拿她沒輒。

布魯斯想，高階主管不知道自愛，實在大家都沒皮條：我想只能請你盡量陪她一起去，幫忙踩踩煞車。

吉娜：看來也只能這樣了。對了，有關內部process的修正，就在下次的cross function process review board中提出來吧。

為什麼會一直強調，要對事不對人，這或許跟很多軟體公司都強調要尊重個人有關。很多軟體公司因為流動率高以及長時間處於缺人狀態，所以變成你要花時間和每個人好好討論，看看怎麼樣讓他發揮他小小的才能，而不是要他走路。在這種狀況下，你就不得不把事情婉轉一點講，期待透過迂迴間接的暗示，加上天生的羞恥心，可以發揮作用。當一個人羞愧至死，又浴火重生之後，願意把他份內的事情做好。

所以，我們在發言之前，常常都得要顧慮到不要傷害別人脆弱而幼小的心靈。當你遇到程式設計師寫了一支爛程式，你就必須婉轉地跟他講：『這個程式這樣子寫，可能會有問題喔。你要不要再把spec study一下呀，要不然，可能會遇到……這些狀況。』而不是『你這個大豬頭！你到底有沒有認真地看spec啊！』

這種只能對事不能對人的現象在大公司尤其明顯，因為很多時候，你對你不滿意的人，根本就沒有管轄權。這個時候，你就只能眼睜睜地看著別人做傻事，幫你製造出一大堆無止盡的麻煩。

當我們只能夠對事不對人時，有很多其實應該是屬於人的問題，就很難加以解決。例如我有個朋友，最近剛好有個白癡當上他們部門的主管，整天發出莫名其妙異想天開的指令，所有下面的人莫不叫苦連天。每次當這位主管發言時，每個人都要屏息以待，深怕他又有什麼靈機一動的想法。

可是等到事情出包時，大頭們要來檢討啦，這個時候又不能直言主管的不對，而這位主管呢，通常又把問題的核心指向下面的人慧根不夠，悟性太差，不能夠了解他意在言外的微言大義，遇到問題又不能夠主動積極地進行溝通。所以呢，都是部屬無能的錯。於是乎這些無能的部屬，只好被罰寫檢討報告。寫報告的人又不想按照主管的指示，寫出一份下詔罪己的報告。誰想跟分紅或是獎金過不去呀，可是既然有人闖禍，就得要寫份檢討報告。這該如何是好呢？解決之道，就只能把矛頭指向process。

在進一步討論之前，應該要先做一下名詞解釋。所謂的process，中文通常翻譯成流程。指的就是一件事情該怎麼做，要完成這件工作的話，應該要採取那些步驟？每個步驟又應該遵循什麼規範？彼此之間又有何因果關連？分派出來的每個工作，又該由誰來負責？簡單來說，process就是經過實踐驗證後所整理出來，我們在做事情時，應該要遵守的遊戲規則。

因為process這個術語涵蓋的非常廣，所以天地之間萬事萬物出了毛病，都可以推託跟process有關。例如：

我們公司沒有明確的目標：這是因為設定目標的process出了問題。
我們開發產品沒有明確的requirement，也沒有清楚的市場定位：這是因為開發產品的process出了問題。
我們公司開發軟體時，大家都各做各的，搞得一團亂：這是因為development process出了問題。
客戶都不願意準時付款：這是因為收款作業的process出了問題。
我都一直交不到女朋友：這是因為結交異性的process出了問題。
我肚子好痛：這是因為消化食物的process出了問題。
總統選輸了：這是因為選舉的process出了問題，這是一個不公正的選舉。我要重新驗票，找尋槍手，還有尋找啟動國安機制的真相。

當然有很多事都跟process不能扯上等號。一件事就是單純沒做好，回頭檢討流程，其實沒啥大意義。不過如果你出了一個大紕漏，這時務必要大家把焦點集中到process身上，如此一來，做錯事的人，就可以逃避所有應負的責任。

當然，透過process的修改，常常可以在不知不覺之間，達成我們想要的某些效應。運用巧妙就存乎一心了。例如下面這個建議。

< 提案> 我建議把總統選舉改為七戰四勝制。
**************************************************
有鑑於2004年總統大選產生極大的紛爭，我建議總統大選應比照NBA主客場設計，採取七戰四勝的制度。投票最多就是七回。

美國是世界上以民主著稱的國家，NBA也是七戰四勝，美國職棒大聯盟也是七戰四勝。這麼民主的國家，用這樣公平的制度來產生冠軍。為什麼我們不拿它來選我們的總統呢？不要跟我說美式足球的超級杯也是一戰定生死，這種運動在台灣不流行。

每次投票時，候選人應輪流在對方主場的競選總部等待開票。例如這次連戰與阿扁雙方這次總部都設在台北，這是一種明顯的不公。下次重選，兩人就應該回到阿扁的故鄉來設立總部，以方便地主隊如果選輸之後，可以聚集群眾進行抗議。

競選期間，雙方可以使用神奇子彈、神奇炸藥、神奇火箭砲、神奇刀劍十字弓攻擊各所屬陣營候選人，以維護選舉公平。醫院應配合進行現場手術直播，全程監錄以及配合測謊。以免誇大受傷狀況，造成選舉不公平。各組候選人應推派專屬御用鑑識小組，進行勘驗工作。

為了徹底達到公平公正公開，雙方陣營都可以推派黑金被告控訴人，針對對方進行抹黑，這樣才能維持立足點的平等。為了避免有公投綁樁的疑慮，主場候選人可以制訂公投題目。此外，各陣營可以與配合媒體發布各項不實民調，以及開票時灌票，以協助選前造勢，選後聚眾抗議。

為了徹底終結作票所帶來的不公平，雙方陣營應該輪流派自家人馬負責選務工作，以方便主場時可以進行作票。大家輪流作票，各顯神通，這樣最公平。

選舉時間，為了避免因為非法集會遊行造成首都市長困擾，所以各陣營應該輪流依主客場次預約總統府前廣場。每次以一週為限。

原則上呢，就是從 320開始，每週六選舉一次。司法機關應該配合24小時加班，以處理選舉無效、當選無效、重新驗票、重新計票之訴。美國與中共應該要負責派員監督觀察，以徹底維護台灣選舉的公平公正公開。

想也知道，提出這樣建議的人呢，無非就是選輸了之後，想要多幾次翻盤的機會；或是在總統大選的賭盤上輸了一屁股，想要找個翻本的機會。可是只要掛著公平公正公開跟言論自由的大帽子，就算是他是來亂的，你也還是要保障他發言的權利。

在軟體開發的世界裡， process就跟總統選舉時的選罷法差不多。在這一章裡，我想先談談在台灣見到的幾個跟process有關的現象，以及我對於 software development process的一些看法。

在台灣，軟體工程跟專案管理其實一直到這幾年才開始被媒體炒的比較熱，在以往這門學問一向不是門顯學。所以有些不是很了解的人，就會把軟體開發跟寫程式直接劃上等號；當然這個業界還有許多飽讀詩書，經驗豐富不敢信口開河的人。不過大多數人想到開發系統，就是一堆天才，經過腦袋亂轉之後，在電腦前打字打得飛快，時鐘轉個幾圈，日曆紙撕掉幾張，系統就寫好了。

所以單單就software development process這點來說，你去觀察整個業界的現象，其實大家遇到的問題是蠻分岐的。不同的公司因為不同的現象陷入苦惱之中。我個人觀察到的現象大概是這個樣子：

有些公司在開發軟體時，完全沒有任何formal process。
主管開始尋找特效藥。
生產了太多的文件。
下面的人開始期待救世主的來臨。
信仰不同開發方法論的人，總是認為他們所相信的，才是唯一的真理。
真正執行的人，沒有訂定process的權利，可是訂定process的人，又沒有真正照著process去開發過軟體。
很多人會把process窄化成只是一些格式固定的文件而已。
有蠻多人相信，遵循formal process的專案就會成功。
認為依時間順序先後發生的事情，就是有因果關係。可是實際上所謂的因與果之間，可能根本就風馬牛不相及。

有些公司在開發軟體時，完全沒有任何formal process。
**************************************************
這種情況在小公司最多。當你就只有一個人在寫程式時，那有什麼大家寫的code要integration的問題？遇到這種狀況，也沒有太多版本控制上的問題。文件則是高興就多寫些，反正人數也不多，所以很多東西在溝通時就全靠口述。

對於規模不大的公司來說，如果他們想要做的軟體規模不是很大的話，沒有formal的process其實影響並不大。因為team size很小，所以彼此之間的溝通可以很順暢的話，就不會有大問題。更何況很多公司，在規模小的時候，做的都是類型相近的專案，裡面的成員在同一個domain合作久了，自然而然會產生工作上的默契。這時候就不是非常需要一套formal的development process。

對這些公司來說，開發系統主要就是寫程式。程式寫好了，系統就算做出來了。測試？這就請end user測一測就好了。

如果這些公司就打算這樣子一直下去的話，其實也不會有什麼大問題。而且這樣做起來的效率不見得不好。反倒有可能因為溝通順暢，大家都清楚彼此要做的東西，然後表現出超高的生產力。對這些公司來說，蠻多人都覺得：『我為什麼要走那麼多流程？簡直是人力、時間跟精神上的一種浪費。』

不過小公司都想長大，所以早晚都會認為，應該要建立一套完整的開發流程。特別是當公司規模如果真的長大的時候，單打獨鬥式的單兵作戰，就會很難應付層出不窮的問題。

遇到這種時候，高階主管很典型的想法就是：『那我就派人去上上課，學學別人是怎麼做的嘛。這些人學會後，再回來教其他人。』或是『我們就找這種大廠的人出來輔導我們嘛，我們引進他們的process嘛。啊，政府最近在推一個叫做CMMI的東西，乾脆找人來導入就好了嘛。』

這個時候呢，就會產生另一種現象：『主管開始尋求特效藥。』

主管開始尋求特效藥
**************************************************
如果主管們忽然想到公司內部的process不夠完善，這時候，他們通常會跟隨著當季的流行，去尋找當時最熱門的管理方法，或是開發模式。就像現在有很多人都想試試extreme programming一樣。很多主管，一聽到這種新思維，新概念，馬上就會忍不住想要找個機會來做個實驗。

感覺起來，這些主管在看完電影『美國派』之後，就會想要買個蘋果派來給team member嚐鮮吧。當他拿著派，看著部屬們錯愕的表情，嘴裡面可能還會若無其事地講：『快點快點，這是現在最流行的喔？怎麼樣呀？是不是很棒呀？奇怪，這怎麼不work，應該會有用呀？你們怎麼一副不怎麼高興的樣子？電影裡的主角可是快美難言喔。一定是你們哪邊有問題，這樣吧，我派你們去上上課好了。』

※作者註：美國派是一部經典的青春性喜劇，劇中笑點很多都是限制級的葷。裡面很經典的一幕是男主角拿著一個剛烤好的派，想要試試用這種東西來打手槍，有什麼特殊的快樂。結果他爸爸就出現了。這時就見他手拿著派，表情一臉驚恐與錯愕，堪稱同類型電影中的經典畫面。不是?道人士，又想看看無厘頭的青春性喜劇時，可以看看這部電影。

很多時候，我覺得很多主管只要看到現在的流行是什麼，癮頭一上來了，就會想要來個大躍進式的改革。台灣有句閩南俗語說的好：『沒有那款屁股，就不要吃那款瀉藥。』對於開發軟體來說，每件事情為什麼得要這樣做，當你端出一個答案時，其實背後都躲著一個想要解決的問題。你如果不了解前因後果，沒有依據專案的規模，開發系統的特性，人員的技術能力種種因素加以考量，就貿然採取了大刀闊斧的改革，一定會遇到很多困難。

※作者註：這句閩南俗話好像是指如果你的屁屁不能收放自如的話，最好就不要吃強力瀉藥。

不過，對於很多人來說，一方面主管喜歡嚐鮮，可是另一方面又有專案的壓力，所以常常會不得不在認識不清楚的時候，就趕鴨子上架，硬著頭皮在專案裡面大幅採用新的process。由於當事人常不甚了然，所以就只能拿香跟著拜，依樣畫葫蘆。這個時候唯一的方向，就是大師們的言論了。久而久之，就會言必稱標準，行必遵大師嘉言錄，凡是大師所言，必定極力膜拜。

< 性向測驗> 你是高階主管，某天當你奉行著走動式管理的建議，到處在辦公室閒逛時，忽然警覺到辦公室裡面，大家好像沒什麼共識。感覺起來，似乎有各式各樣的信徒在膜拜著自己心目中的大師。然而，不同派系之間，壁壘分明。此時，比較激進的信徒又在撰寫又臭又長的email炸彈，準備開始進行自殺性郵件炸彈攻擊。遇到這種狀況，高階主管又該怎麼辦呢？
**************************************************

A. 聽聽各方的觀點，並且獨自做出正確而睿智的決定。然後要大家照著實行。

B. 隔山觀虎鬥，弄一個討論大會，沒有結果，不准休息。反正物競天擇，經過充分的討論，有意見的人講話也講累了，當大家膀胱忍不住，紛紛解衣曳甲，雙腿夾緊之時，就是結論產生之日。這還可以獲得一個經過民主程序認可的美名。

C. 找個顧問，讓他來收集各式各樣的數據進行分析後，提出完整的研究報告。接著召集各部門的主管，讓顧問來虐待他們的膀胱，逼迫他們做出結論。你只要引領方向，也就是說在把顧問找來時，要先做個開場，等到他們結論做出來時，開一個會感謝大家的辛勞，接著成立一個跨部門的process推動小組以及process auditing board。

這個性向測驗主要是測量你有多適合在官僚體制下工作。A這種答案呢，原則上就適合在小公司裡面稱王，到其他類型的公司會被人質疑你不夠民主，不懂得什麼叫做互助合作。B這種答案大概就是在中型企業工作，公司的資源不夠，就不會有錢去找顧問。如果你選C的話，其實就蠻適合在大企業裡面生存，如果流程改造計畫失敗了，還有顧問可以諉過。如果流程改造計畫成功了，當然就會理所當然地升官發財了。

提到顧問就會讓我想小小離題一下。資訊產業的進展非常地神速，各式新型技術、標準，不斷地推陳出新。所以這個行業的人，無可避免的得要去研究很多各式各樣的新科技。市場上的人力供給一直跟不上需求，所以資訊類型的教育訓練顧問業，一直都是相當蓬勃地發展。

這些年我還真看過不少顧問。如果是學者出身的，所提出來的建議呢，大多體系完整，看來頭頭是道。不過學者的實戰經驗太少，所以有很多建議其實是全憑想像與推論，所以他們所提出來的建言，有時就會立論高遠，卻與實際工作有一定差距。

產業界出來的就會比較好嗎？這也不一定。真正厲害的高手，大多會陷在實際的專案裡面，再加上會做事的人不見得很會講課，七折八扣之下，會出來當教師或是顧問的就比較少。如果講解的是新玩意兒，通常顧問的年紀就蠻輕的。這時感覺起來做案子的經驗，就不會很豐富。年輕人的特點就是理想性十足，所以這個時候，常常會提出很多實務上不可行，可是看來很美好的建議出來。

這就好像很多少男在對性事懵懵懂懂的時候，常常會在朋友之間，交換很多似是而非的觀念與經驗。最會說嘴，講得最頭頭是道的人，常常都不是實際戰果最好的人。我看到沒什麼經驗，只好硬著頭皮裝懂的顧問，內心裡面總是會想起在『美國派』電影裡面，那個吹牛自己性經驗豐富，可是被拆穿後，嚇到尿褲子的配角Sherman。

※作者註：又找到一個該去看美國派的理由了。

< 隨堂性向測驗> 你是個顧問，當你發表了你精心分析的高妙言論時，終於到了Q&A階段。頭一個發言的人，劈頭就給你難看：『你講的書上都有，你可不可以提出比較具體的做法？或者提出你自己的經驗心得？不然我們花那麼多錢請你來做什麼？』這時你會怎麼回應？
**************************************************

A.『你的態度很惡劣喔？警衛，把他趕出去，關門！放狗！什麼？沒有狗？那我走。他媽的，老子不幹了，有幾個臭錢了不起呀？』然後就氣沖沖地走了。很多顧問在受到客戶的鳥氣之後，常常會幻想這個場景。有阿Q式的排解心情的效果。

B.『景氣不好，賺錢不容易，我也是出來混口飯吃嘛。兄臺何必如此苦苦相逼呢？』接著開始搖尾乞憐。大談他家中尚有高齡老母，一家妻小嗷嗷待哺的窘境。

C.『我想我在這裡只是協助大家快速地了解這個新的理念，我個人是用這樣的觀念去做過一些pilot project，我也覺得這些pilot project大體上也證明了這個方法的優越性。我個人是認為，既然美國這麼先進的國家，都在使用這種開發方式，一定有它可取之處。我個人深信，這一定會變成世界的趨勢，整個宇宙的潮流。』請記得需要面帶傻笑，表情呆滯，臉上必須顯露出完全欠缺邏輯思考能力的表情。

D.『這個建議很好。我想是事前我們在溝通時，忽略了這一個面向的問題。我回去之後，會仔細全面地通盤思考你們所提出來的需求，重新調整後，再向諸位進行更嚴謹的報告。』收完錢之後，就找一堆理由永不再來。基本上這種顧問如果長的玉樹臨風，要是沒飯吃了，就可以考慮從政選市長。基本上只要把身體鍛鍊好，穿著性感小背心慢跑，講講場面話就可以了。

E.『就產業界的經驗來說，各位都是經驗非常豐富的前輩。』先戴一下高帽。『我在這裡所提出來的建議，無非是基於一般的通則，加上我個人，以及公司同事之間經驗交流，相互討論所提出來最佳的建議。各位的指教我會虛心檢討。以後將會參考諸位寶貴的意見，繼續本著我的專業，盡我的全力，提供給各位最好的服務。』嗯，好像不管什麼意見都可以用這段話來回應。

上面這個題目的標準答案請參考本人尚未開始寫的新書─如果你找得到的話，請通知我一聲。我一直不知道它在哪裡。

好的顧問其實不容易找到。很多人看的只是顯赫的經歷，名校畢業，任職於大公司…這類型的條件。然而，我個人覺得最重要的是他的經驗跟你的需求是否相吻合。一個很有經驗的人，他的經驗不一定對你們適用。公司的規模，team size大小，開發系統的特性…很多因素都會影響software development process的擬訂。所以你找來的顧問是否可以跟你們在開發的系統相配合，就是一個重點啦。

此外就是在他面對問題的時候，會不會實事求是地追求真正的解答，還是就拿著大師的嘉言在搪塞，這就是另一個觀盤的重點。有很多顧問，其實就是會講好聽的場面話，可以講得一口好理論的人，提供的建議不盡然就是個好點子。

即使你找到了一個好的顧問，他也點出了正確的方向，這也不一定有用。很多事情落實到執行面來，還是常常會有差距。擁有一套好的process，並不是成功的保證。

找了顧問之後，引進了一些新的想法跟作法，接著就會造成新的問題。每次實驗了新的作法，產生了新的問題，這時候其實主管們常常都會裝死，互相推諉責任。此刻，最常見的企管佳句就是：『我只負責領導，點出一個正確的方向。』例如在以下的這次status review meeting。

大頭：這個project怎麼又delay了？上次不是說UAT這個月底要結束嗎？怎麼你們現在又要調整時間。

吉娜：這個問題，我想要由布魯斯來回答。他比較清楚實際的狀況。

布魯斯：沒辦法，客戶在這一個round的測試提出太多有爭議的bug。我們認為是new requirement，他們說是bug。

大頭：這種事情不是發生過很多次了嗎？你們先前不是告訴我說，這個project你們會採用新的開發方式，可以大幅降低requirement change的機率嗎？怎麼一延就要延一個禮拜？

布魯斯：我們確實是很快就把prototype做出來了。User看到這個prototype之後，確實也比較清楚問題在那裡了。可是後來公司又要推OOAD，所以我們寫了不少use case跟sequence diagram要user confirm。而在confirm的過程裡，我們的prototype跟這些東西兜不起來。所以requirement的收集與整理變得很紛亂。

大頭：那這個問題也應該早就浮出來了呀，怎麼這麼明顯的risk你們都沒發現？還有，這個OOAD幹嘛在這個案子插一腳？

吉娜小聲地說：老闆，就你上次去參加研討會後，下的指示呀。

大頭：我只是負責領導，點出一個正確的方向。實際執行跟後續的follow-up，這當然要你們去做。要不公司花錢請你們做什麼？事情做一做，發現了窒礙難行的地方，當然要趕快反應呀。這個案子這麼急，當然不要再實驗這些我們還不熟悉的新作法嘛。

吉娜跟布魯斯心想，你上次才不是這麼說的呢，沒辦法，官大學問大：是的老闆。

改善公司的process，在我所待過的軟體公司裡，幾乎是每家公司每年必列的目標之一。高階主管每年都信誓旦旦地說要做什麼大刀闊斧的改革，可是實際上，絕大多數的主管，都只有口惠。或是只有提供『方針』與『領導』。而缺乏實質的參與和推動。

我後來看到這種只長著一張嘴的主管，誇言要改善process。都覺得很像是一家已經爆滿的酒店裡，媽媽桑對著等不到小姐來坐檯的客戶說：『讓你們等這麼久不好意思啦。這樣吧，待會兒小姐來了，你們就盡量蹂躪我們家的小姐吧。我一定會叫她們拋開所有的束縛，全力配合到底。』很多主管找顧問來對project team施行震撼性電療時，講的話也差不多就是這樣：『王顧問，如果我們的員工沒有好好學習，儘管跟我講。他們有什麼缺失，還是不配合，你都直接講不要客氣。不能夠配合公司政策的人，沒有資格繼續留在公司裡面。』理論上來說，媽媽桑只要提供了方向，小姐們就會奮勇向錢，勇往值錢。好的媽媽桑不會做這種傻事，不過不好的主管倒是常常讓工程師遭受折磨。

回歸主題，執行面最常遇到的問題是什麼呢？我個人覺得是：『生產了太多的文件。』

(續)
(全文共有上、下2期)

爪哇教室＞ 獨孤木專欄 - Process《下》

生產了太多的文件。
**************************************************
官僚制度最大的問題，就是會讓原本單純的事情，搞得很複雜，透過官僚的運作，就可以讓員工人人有飯吃，個個有事做。如果你在一個龐大的官僚體系下，想要討論出一套process時，很多人的焦點會放在，誰才有權利去接觸到這樣的資訊，或是誰才有這個做決定的權利。你把流程弄單純了，很多蓋章的人就會沒有飯吃，做出這種建議的人，絕對會被同事鳴鼓攻之。

所以這時候process最大的重點，就在於防弊了。很多事情，就需要經過層層簽核，才可以決定，多蓋一個章，就可以都養一個同事。反正有飯大家吃，有錢大家賺，這絕對是最高指導原則。凡是違背這種原則的人，要質疑他也很簡單：『你怎麼可以讓一個官小位卑的人來決定這麼重大的政策呢？』

有些人生性比較駑鈍，不能參透話中機鋒，聽到這種話，就會想：『嫌官不夠大，那我們就直接找大頭來開會吧？』這當然不成，大頭們日理萬機，我們做部屬的怎?可以沒有經過充份的討論，沒有提供任何可行方案，就叫他們在狀況不明的情況下貿然進行決策呢？

解決之道，那就把一干人等一網打盡，發一堆meeting notice給他們，大家來開個會吧。經過充份的討論跟溝通之後，就可以擬出幾個建議方案，再讓大頭們來做決策。開會加上蓋章就是繁衍官僚體系最好的肥料。

其實開這種會，通常主題就是：『這件事應該來會我。』『這件事應該要讓我知道。』『這件事應該讓我來做最後的決定。』這種『這件事一定要先知會我』的會議，其實開來格外無趣。每個人都想透過參與決策，來分一杯羹。不管是功勞，還是影響力，都是一樣。我可以多蓋一個章，如果它做的起來，論功行賞時少不了我一份；如果它看起來會幫我找麻煩，我就可以拖他一下。趕快找補救的方法，或是逃到別的部門去。

因為這類會議的主題就是在界定每個人的政治影響力。被排除在權力核心內的人，如果不是滿腹牢騷，抱怨沒有被事先知會的話，會對企業造成多大的危害；就是一再地說明，如果我事先被知會了，會為企業帶來多大的好處。

開會雖然被許多人視為畏途，不過許多人為了想要在企業內部出人頭地，掌握可以藉著冗長開會，欺負眾人膀胱的權利，就會要求要參加任何一個可以參加的會議。連不關他的事的會議，他都想參一腳。

當你的會議參加的夠多，老闆就會覺得，咦，你很熱心參與，工作主動積極，特別是每次都主動去參加老闆不想去參加的會，還可以發言踴躍，真是足為員工表率。當你參加任何會議，都可以滔滔不絕如同滾滾黃河一番的話，每個人為了怕你亂講話，導致人人憋尿憋到內傷，雖不情願還是會想辦法在email功勞簿上記上你一筆。『感謝某某先生的大力幫忙。』

如果每次開會這種攪局的人都很多，到最後就一定會演變成冗長又無趣的馬拉松會議。這世上比起討論標準作業流程還無趣的會議應該也不太多了。除了那種想升官發財的人之外，有許多工程師或是專案經理，對於這類型的主題則是有莫名的喜愛。

制訂一套制度，讓大家都照著我卓然出眾的思想來做事，這對工程師來說，真是莫大的誘惑。這種事情帶來的快感，大概就只有開發出一套絕妙的系統時的感覺差相彷彿。

不過因為工程師在做這種事情的時候，都會確信自己的想法純然出於理性，自己就是真理的化身，如果有人喜歡採用OOAD，另一派喜歡畫DFD，整天聽這兩派論述大對決，把會議裡的對話寫下來，就可以製造出一劑失眠最佳良藥。

基本上呢，這種爭論就像是宗教信仰上的差異，不同的人有不同的信仰。所以就好像聽到基督徒跟回教徒在吵架，討論誰是真主一樣。到最後大家的耐心都被磨光了，膀胱也快要爆裂了，這時就會聽到一貫道的來插花，說是萬教本同宗，我們應該要中學為體，西學為用，兼容並蓄，博採兩者之長。

等會議到了這種地步時，通常結論也蠻簡單的，因為你的膀胱再也受不了了。所以結論就是什麼死人骨頭文件都要寫。你也不用管寫這些文件原本想要解決的問題是什麼，你也不用管寫這些文件寫了到底有什麼用。反正就是要遵循規定去寫文件。

所以我們會因為需要做文件而做文件。因為這是大師的說法，所以我們需要寫這些文件；因為我們要推行軟體工程，把process tune得比較好一些，所以我們需要寫這些文件；雖然我不知道為什麼要這樣做，不過應該要這樣子做才會符合標準，所以我們需要寫這些文件；因為寫了文件之後，可以促進世界和平宇宙大同，所以我們需要寫這些文件。反正只要你高興，總會找到一堆理由去生產一堆文件。

對很多人來說，文件不是在你在工作時的副產品，而是一種要特別去寫它的東西。寫程式時不寫註解，而是到寫完後再把註解加進來，這樣就可以把時間擺在寫真正有意義的程式碼上。開發時不寫該寫的design spec，而是到系統上線後，再改一版來交差。

為了寫文件而寫文件的事情變得越多，浪費的時間與資源也就越多。可是很多主管就是克制不了這種產生文件的衝動。可能大多數的主管前輩子都是伐木工人，見不得有森林存活在地表，一定要砍下來，做成報表紙，要求屬下們把文件印成一本一本厚厚的紙枕頭，以便中午午睡時可以墊著睡比較舒服。

在開發過程裡，需要撰寫哪些文件，這類型的標準一旦開始採用，要進行修改就會面臨各式各樣的挑戰與質疑。所以文件只會越來越多，做事情時會越來越繁複，等到開發系統的流程已經繁複到人類無法承受的時候，這時候就會再來一個process reengineering。我們會生產新的文件，來律定那些類型的文件是開發系統時不可欠缺的文件。所以有些大公司會成立流程改造委員會，來改善系統開發標準委員會所訂定的標準開發作業流程。

很多人經歷過凡此種種改善process的諸般劫難之後，就會開始期待救世主的來臨。

下面的人開始期待救世主的來臨。
**************************************************
我以往少不更事的時候，每次只要有新的主管空降，就會期待他有一番作為，那時總以為，只要他規定好應該要怎麼做，我們大家就照著去做就好了，接下來所有的人就會過著幸福快樂的日子。開發系統也就可以一日千里，以超光速邁向結案。

不過年紀越大就越不好騙了。根據我的經驗，上天賜你一個聖君賢相，天生就是個治世能臣，可以幫助你們大刀闊斧厲行改革，然後獲得前所未有的成功，這種事情發生的機率，大概跟你走在路上被雷打到差不多。

你可能會從書報雜誌上讀到，這個世界上還是有像是IBM前執行長Gerstner這種能讓大象跳舞的人，所以你應該有機會遇得到一個可以濟世的好老闆。這世上會有這麼多人願意花錢買樂透，不是沒有原因的。我只能說，我在八卦雜誌上也看過很多性感名模，AV女星，被踢爆深夜陪著男性蓋棉被純聊天(這是當事人的說法啦)。可是我並不會期待，她們會在晚上為了想要與我促膝長談，跑來陪我不穿衣服蓋棉被睡覺，或是為了配合要幫我欺騙跟蹤我很久的狗仔隊，願意配合我深夜開車到荒郊野外演出車震事件。

※作者註：沒有八卦雜誌會來理我的原因，主要是因為我沒有那麼有名。小人物的緋聞報導太無聊了啦，寫這種新聞會賣不出去。根本沒有名氣的作家獨孤木，深夜演出車震事件？沒有名的人大概只有靠在街上裸奔，才有辦法吸引鎂光燈。不過如果你本身就是個名人的話，你遇到超強CEO的機率應該會提高。所以如果貴公司的名號跟IBM差了十萬八千里，你們的老闆剛好是不世出的奇才的機會應該很低。

大多數的主管其實也不過就是個年長你一些的普通人，他們不會通靈，也沒有三頭六臂，更有可能的是，他們跟實際作業脫節很久了，又一直被馬屁精們吹捧的自以為高瞻遠囑。所以他們能夠做的變革，其實也不用期待太高。

對制度不健全的公司來說，很多process的問題，都是導因於無知。每個人根本就不知道什麼才是對的，所以大家各行其是。結果很多該做的事沒做到。

比較有規模的公司呢，process的問題，則多半導源於企業文化的特性。所以如果真的要改善，卻沒有從企業文化進行根本的改變的話，所做的努力根本就是徒勞無功。

如果你遇到的是企業文化的問題，這就不是一個救世主一句：『信我者得永生。』就可以解決的。你得要想辦法讓共識可以形成，所以你的溝通協調方面的政治能力會遠比你的專業能力來得重要。這個時候常常會面臨的問題是：『信仰不同開發方法論的人，總是認為他們所相信的，才是唯一的真理。』

信仰不同開發方法論的人，總是認為他們所相信的，才是唯一的真理。
**************************************************
每個人在討論軟體應該要怎麼開發時，腦袋裡面都有他們自己的一套想法。很多人就會認為只要每個人都能夠充份表達他的意見，經過理性的思辯之後，就可以產生出最棒的process。即使中間還有什麼不足的地方，最少也是經過一個民主程序，所以應該可以達成一定的共識。

原則上有機會讓大家討論process，這會是一件好事。在做project的過程裡，每個人都會累積不少負面的能量，透過策劃美好的未來，可以宣洩一下這些情緒。達到心理治療的效果。如果負面的能量沒有獲得適當的釋放，整個team就會跟人便秘很久，卻拉不出來一樣的痛苦。

不過這類的討論呢，卻有一個很大的潛在危機。很多人在討論process時，其實還是抱持著文人相輕的想法。凡是非我族類，其心必異。遇到跟你論點不同的一方時，第一個想到的不是他講的有沒有道理，而是他反駁了我的講法，要不要給他一點顏色瞧瞧？

特別是如果有兩派人馬各自擁有不同的經驗與認知時，那種方法論的戰爭就非常慘烈了。有些人會辯論，到底應該採用Object Oriented Analysis & Design (OOAD)，還是要走傳統的Structure Analysis？到底要畫UML diagram，還是要畫DFD？到底要follow Rational Unified Process(RUP)，採用iterative的方式去開發，還是要用傳統的System Development Life Cycle(SDLC, also known as waterfall)，或是採用最新的extreme programming？Team的build up ，要不要做一個GUI prototype，要怎麼估計專案的大小…各式各樣的問題，都有永無止盡的爭辯。

有些時候呢，爭辯其實是導源於開發團隊內部的分工所造成的。像是開發MIS 系統時，有些公司就會把team分成兩組，一個是component team，另一個是application team。Component team負責開發底層的component，而application team則是負責要了解使用者的需求，然後透過使用 component team所提供的component來架構出使用者所想要的系統來。

這個觀念就理論上來說是不錯的。一個人專門做積木，另一個人專門用這些積木來蓋房子。如果蓋房子的人需要特別的積木，他也不要自己動手做，只要告訴他的同伴就好了。做好的積木，因為接受過各式各樣的考驗，所以如果下一次要蓋房子，就可以拿來繼續使用。這基本上是所有OO教科書的標準官方說法。

每個做component的人，總是希望他做出來的component可以用在任何一個project之中。所以他不太願意為了單一project來修改他的component。然而component的spec是什麼呢？卻又很少人可以在一開始的時候就定義出來。所以呢，如果你在一個component team，通常會採取iterative的開發方式，進行分析設計時也會採用OOAD。也就是說你會隨時都有因應變化的準備。

可是application team呢，則通常有個明確的需求，最少end user覺得很明確啦。所以他們的重點呢，則在於怎麼樣透過跟end user之間的互助合作，可以把需求以及spec定下來。所以通常是用傳統的waterfall加上傳統的結構化系統分析。因為他們要解決的，是現在手頭上的單一問題，所以這個component是否能夠適用在各種不同場合，是否夠generic，其實他們並不care。

就實務來說，如果這兩個team可以相互配合的很緊密，那當然很好。不過常常看到的狀況是，這兩個team會因為遭受到project的壓力，而互相踢皮球。

例如下面這個場景。

AP team的PM布魯斯：team member跟我反應，他們需要component team提供一個function，讓他們可以透過文件的相關編號，來尋找一份文件。

Component team的PM韋恩：我們的team member覺得這個要求並不合理。這應該是屬於AP要自己handle的部份。

布魯斯：可是你們把相關的object都封裝起來了，應該要提供我們相對應的method去處理呀。

韋恩：我覺得我們的component不應該為這種單一事件進行修正。AP team需要的information，應該要自己處理。你們現在所謂的文件編號，這個資訊我們目前implement時，是放在xml裡面。如果要提供查詢的機制，整個效率太差了。

布魯斯：Oh my god！這麼重要的資訊，你們居然沒有放在database裡！？

韋恩：我就跟你說過，我們要考慮更generic的需求。如果放在database裡面，就有可能會被它限制住，變成一定要綁某些特別的database。

布魯斯：不會吧，最少運用JDBC去連可以連得到就好了吧？把所有的東西都放在xml裡面，就為了要跨database，這代價未免也太大了吧？你們的需求到底是怎麼來的？怎麼會這麼誇張？連這種透過相關編號查詢，這幾乎是商用系統最基本的需求都沒有辦法滿足，這是什麼component？

韋恩：component的spec，上次有跟你們的team member confirm過呀。真的那麼重要，那要不就放到下個iteration。

布魯斯氣沖沖地說：下個iteration？我們的project下個月就要結案了，你跟我說下個iteration？

韋恩也很不爽的說：要不你想怎麼樣？我的team member難道就整天沒事做？

吉娜：兩位，兩位，先冷靜下來。我們先就事論事，看看有沒有什麼其他的 solution？

布魯斯：我的team member已經連續加班加了一個月，禮拜六日通通都來加班。現在實在是很需要一些component team的support。

吉娜：韋恩，這個有那麼難嗎？我知道你們的team member個個都很聰明啦，一定沒問題的。

韋恩：那個，老闆，真要做的話，怎麼會有問題呢？可是這樣就是hardcode寫死，為了布魯斯他們這個team來做修改了喔。我們的component本來就是想要避免hardcode呀。以後要改到別人可以用，還要再花一次工喔。

吉娜：哎呀，project的deadline要到了嘛，大家就變通一下，相忍為國吧。

韋恩：既然老闆這樣說，我們當然遵照辦理呀。不過這裡可能需要架一個search engine喔。要不performance一定會有大問題。

吉娜：這些太先進的技術我不懂啦，這就要靠你大力幫忙了。你們這麼強，一定沒問題啦。

這種爭論其實也蠻無聊的。拿積木蓋房子的人說，你做積木的流程有問題，所以你做不出我要的積木，應該只要給我一個積木，他的長相就跟我要蓋的房子一模一樣就好了。製造積木的人則是說，我要做的東西是可以符合各式各樣專案的需求，所以可以給你一個長的像是樂高的東西，你就該謝天謝地了。要蓋摩天大樓，用樂高就可以了呀，一定是你們太笨，蓋房子的process有問題，用樂高慢慢堆，總有一天可以堆出摩天大樓來。

很多人都喜歡悍衛他所信仰的一切，可是卻沒有想到各種不同的理論，應該套用在不同的情境之下。吵了老半天，大多數人沒結論，彼此相持不下，事情就會跑到大老闆那裡去。通常這種爭論呢，雙方的立論都有可以說得通的地方，而大老闆通常也不是什麼專案管理之神，所以能做的決定多半就是看看兩邊的政治勢力分布之後，接著去做一些政治上正確的決定。結果常常是順了姑情，就逆了嫂意。

在職場上，理性辯論的空間其實蠻小的。通常就是一些雞毛蒜皮的小事，大家都沒什麼興趣討論的時候，會存在理性辯論的空間。比如變數的命名規則啦，版本的命名規則啦，這種越無聊的事情，就會存在理性辯論的空間。否則，任何process上的改變，都牽涉到有人要跟著修改他習以為常的做事方法，也可能會牽涉到他要做的工作量。所以在推動任何reengineering時，組織本身抗拒的力量通常是最大的阻礙。

為了避免推動process修正時，組織內部會產生抗拒的力量，我們就把實際執行者找來訂定process，不就結了？不過，很抱歉，在台灣，另一個常見的現象是：『真正執行的人，沒有訂定process的權利，可是訂定process的人，又沒有真正照著process去開發過軟體。』

真正執行的人，沒有訂定process的權利，可是訂定process的人，又沒有真正照著process去開發過軟體。
**************************************************
一個人開車需要遵守交通規則，可是訂定交通規則卻不需要這個人會開車。我是沒聽過立法院修改交通法規時，得要先檢查立委的駕照這種事。建築師要會畫房子的藍圖，可是畫藍圖的人不用自己去砌磚塊抹水泥。

或許是基於類似的推論，真正執行專案的人，常常都沒有訂定process的權利，可是訂定process的人，又沒有真正照著process去開發過軟體。這種事發生在建築業可能還蠻合理的。你不會叫一個什麼東西都不懂的人去畫建築藍圖，然而在軟體業，很多公司卻找來什麼東西都不懂的人去當軟體專案經理。要當個軟體專案管理人員，好像並不用什麼特殊的技能。就很多人的認知來說，專案經理只要能把客戶搞定就成了。

在這種情況下，專案經理所訂出來的process，就跟瞎子摸象一樣。摸到了象的肚子，就說大象像是一堵牆，摸到了象尾巴，就說大象像是一根繩子，摸到象腿，就說大象像跟柱子。分開來看似乎都有道理，可是整個合起來，就像是一大團象屎。每個真正在做事的人，到後來就會像是那隻一直被騷擾的大象一樣，很想一?就把這些一直在亂摸的瞎子們給踹開。

其實主要的問題多半不在於參加的人裡面，缺乏經驗豐富的老手。這些人的確被叫來開會了，也發表了他們的意見，可是他們的意見沒有獲得應有的尊重。這樣講也不是很精確，應該說他們的意見，經過加油添醋之後，被加了很多不必要的細節進來。

在某一次process review board上。這次剛好是review布魯斯所寫的專案建議書(proposal)製作標準作業流程。在場官位最大的就剛好是布魯斯的直屬老闆吉娜。

布魯斯：我們現在收到sales的RFP(Request for Proposal)之後，就會先進行開發金額跟時程人月的估計。在真正開始要寫proposal之前，我們會先進行risk analysis。

吉娜：對呀，這個risk control很重要。我記得以前有很多案子都沒有把risk好好分析。你們現在都怎麼進行risk analysis？

布魯斯：我們會依據先前訂下來的專案風險評核表，依據專案的複雜度，時程壓力，技術難度，人員技能以及我們目前是否有足夠的資源，各個方面進行評估。

吉娜：我不是說你分析那些項目，我是說你們都怎麼樣進行risk assessment，有那些人參加？

布魯斯：目前這部份主要是專案經理自己視需求進行，技術上的問題會去詢問architect，scope有問題會詢問去做presales support的工程師，或者去問做過這個領域的系統分析師。

吉娜：所以主要就是專案經理來主導？

布魯斯：是的。

吉娜：你覺得這樣足夠嗎？

布魯斯：我們目前這樣運作還沒有遇到什麼問題？

吉娜：沒遇到什麼問題？我跟你說，你們就是太低估這個risk assessment的動作。我以前遇過的案子，就都是沒有進行risk assessment，所以才會到後來問題一大堆。你要把risk list印出來，貼在牆壁上，讓每個工程師都知道：『啊，這些就是risk。』你們不要笑。我們就是要讓每個人都知道我們的專案有這樣的risk，才可以讓每個人都有所警惕，就可以防患未然。回到主題來。你們的risk assessment有沒有工程部門主管參加？

布魯斯：目前沒有。

吉娜：那你們的人力資源估計根本就不切實際嘛。PM怎?會知道每個部門會有多少人可以用？我覺得以後要把部門主管都找進來，請他們提供意見。以後應該要召開一個risk assessment會議，把sales，architect，SA，部門主管，會計通通都找進來溝通協調。這樣子就算出事了，我們才不用揹這些責任。

布魯斯想，啊這樣是要多久才可以把這些人都湊齊？他說：老闆，可是我們收到RFP之後，都有時間上的壓力也。我們得要盡快完成proposal。現在這樣會影響整個proposal的作業時間。

吉娜：那接了一個不該接的project，是你要負責嗎？做案子賠錢，你要負責嗎？事情做不完，就叫大家留下來加班呀？

布魯斯想，部門主管跟你平起平坐的，幹嘛理我？想撇清責任也不是這樣？所以他說：我想這牽涉到部門主管的時間，可能還是要請副總進一步裁示。

吉娜：反正你先寫進去process裡面。副總有意見，我再跟他溝通嘛。好吧，這邊我沒問題了，大家有什麼建議嗎？沒有我們就繼續下去。看看下一個流程。

對於老手來說，這種process上的討論常常會在有意無意之間，對他們習慣的工作加上很多限制。出發點不見得不好，每個人都想提供他良心的建議。比如下面這一個中醫師的建議。

『我建議你跟你老婆做愛的時候，要恪遵九淺一深的頻率。因為根據中國宮廷秘方素女經記載，這樣可以延年益壽，治療百病。』這聽起來可能跟任何你不是很懂的事情一樣，可能背後真有幾分道理，可是真的完全照著去做，可能實行沒幾次，就會收到老婆嚴正的抗議。

官大的人不見得學問大，不過聲音的可見度絕對比較高。大多數時候，他們會把事情看得太單純，可是很多實際發生非常繁瑣的工作，沒有親身參與的人，其實很難體會箇中奧妙。很多原本立意良善的措施，其實會帶來你根本沒有預期到的結果。這種事情在專案執行時，常常是層出不窮。這裡面的學問很大，可是很多人，常常在認識不清的狀況下，就把所謂的process，窄化成只是一些格式固定的文件而已。

很多人會把process窄化成只是一些格式固定的文件而已。
**************************************************
Process不是只有文件而已，它的重點在於每項工作背後的精神，在於為什麼要寫這份文件，為什麼要做這樣的動作，而這些事情，又有誰要參加，每個人又要扮演什麼角色。文件只是當你照著去做的時候，所產生出來的副產品。

要讓development process真正可以有用，其實就是要讓每一個參與的人，都有機會透過教育訓練，或是實際工作的印證，可以了解每一個activity詳細的步驟，接著就是要給他一份可以參考的文件範本，並且期望讓他能夠了解流程背後所蘊含的意義，也就是想要解決的問題。

當每個人都有這樣的認知之後，就得要改善你的公司制度與文化，讓這套process有自我演化跟改善的能力。文件，只是對於沒有參與專案的局外人來說，一個判斷你是否有照著process進行的表象。

我記得我開始在做案子的時候，那時候客戶根本看不懂我們費盡心血所做出來的文件。其實真正的重點不過幾張紙而已，不過為了唬人，就把CASE (Computer Aided Software Engineering) tool所產生的一拖拉庫文件通通印出來，弄成一本跟枕頭一樣厚的小書，用漂漂亮亮的卷宗夾裝訂起來，再印個美美的封面，客戶看到就肅然起敬，哇，一邊做專案，一邊還可以寫出這麼厚的一本文件，感覺起來這些人就很專業，一定是沒日沒夜的在努力趕工。

可是那些文件有什麼實質上的意義嗎？需要交一份文件給客戶時，常常都是事後寫寫回憶錄，或是編編故事唬唬人。真正在開發的過程裡面，很多人因為沒時間，都是虛應故事。文件可能也隨便寫一寫，大家看得懂就好了。

在開發系統的過程中，文件並不是真正重要的關鍵，只是對局外人來說，這是唯一判斷開發團隊有沒有follow既有流程的一個佐證資料。我個人認為，開發文件存在的價值，在於大家的觀念，是否可以透過文件的媒介，進行更有效的溝通，而這個觀念，有沒有辦法也藉著文件，適當的流傳給日後要維護系統的人。

除此之外，還有一些文件，則是一些跟專案管理相關的資訊，可以讓你從文件，或是一些客觀量度的記錄中，來了解並掌握整個專案的現況。接著可以讓你依據現狀，來修正你的策略。以及對於日後的專案，可以有一個預估的基準。

我個人覺得，良好的process並不是萬靈丹，不過有蠻多人相信，遵循formal process的專案就會成功。

有蠻多人相信，遵循formal process的專案就會成功。
**************************************************
很多人在檢討失敗的專案時，都會把沒有遵循嚴謹的process當做是原因之一。反正大多數失敗的案子，到後來一定會荒腔走板，指責他們沒有遵照process，通常不會有什麼錯。

不過我個人覺得，大多數的專案，失敗的主因都不是因為沒有嚴格地遵照process去執行。否則這很難解釋同樣沒有遵照嚴格的process時，為什麼還是會有一些成功的例子。即使一切依據標準作業程序來進行，又為什麼還是有些案子就是會經歷千辛萬苦，到最後以失敗告終。

改善Development process會讓你整個軟體開發的過程裡，有一個可以遵循的標準。很多人都把重點放在流程的訂定上，卻不知改善流程並不一定會產生什麼實質上的改變，也不一定會帶來生產效率的提昇。它唯一代表的是，又有了一份新的標準，如此而已。即使公司已經通過各式各樣的process認證，如果企業發展的方向不對，或是產品的方向不對，還是有可能會關門大吉。遵守交通規則來開車，並不會保證讓你到達終點，如果你的方向不對，怎麼開都開不到目的地。

企業面臨的問題，大多數並不是因為缺乏一套完美的standard process所引起的。很多時候，就只是單純的該做的事情沒人做，或是該做好的事情搞砸了。這跟process之間，一點關係也沒有。遵循良好的流程所規劃出來的產品，並不一定會大賣；依據良好的流程，並不能保證執行面一定沒有問題。事實上，培養良好的執行能力遠比訂定process來得重要。

良好的process最大的功用都是在生產與製造方面。遵照process的話，可以讓生產出來的產品，有一定的品質，讓時間與成本的掌握，變得容易一點。對於軟體產業也是如此。訂定出良好的process，可以讓每個人工作時，弄清楚自己的權責，以及每個階段應該要產生的output。大家要一起co-work時，也能夠運作地比較有效率。

相對地，對於業務行銷類的工作來說，其實標準的process就不必然會有什麼宏大的效果。大家都遵照標準流程來進行產品的規劃，跟產品是否會有良好的市場佔有率其實並沒有直接的關係。畢竟process著重在於防弊，而非興利。完全依照標準流程來做事，並不表示客戶就會把案子給你，也不表示你所規劃的產品，可以在市場上打遍天下無敵手。通常表示的就只是，我確實在產品上市前有做過市場調查。不過僅此而已。

打個比方來說，很多情竇初開的少男少女，為了要成功獲取另一半的芳心，擺脫童貞，就會花很多時間研讀探討兩性關係的書籍，接著通常就會仔細推敲，到底要怎麼樣才可以喚起另一半的情慾。按圖索驥的結果，通常要來個浪漫的燭光晚餐，悅耳的輕音樂，鮮花，美酒，綿綿情話…。好吧，你花了大錢跟很多前置作業時間，來策劃一個完美的夜晚，不過這並不表示只要你遵照這個成功方程式，you can have sex。所有的這些規劃，只能保證你有美食，有美酒，有優雅的音樂，有舒適的環境，and nothing more。再好的流程規劃，可能都比不上突發的意外，例如：『親愛的，我也很想要給你…可是今晚不行，我的好朋友提早一個禮拜來了。』

這也難怪，其實不光是在制訂標準流程，我們在分析事物的時候，常常會因為自己對於事物的認知。就會傾向於認為依時間順序先後發生的事情，就是有因果關係。可是實際上所謂的因與果之間，可能根本就風馬牛不相及。

認為依時間順序先後發生的事情，就是有因果關係。可是實際上所謂的因與果之間，可能根本就風馬牛不相及。

在專案結案時，我常常會開一個專案檢討會議。試著去看看到底我們從這個專案裡面學到了什麼教訓，獲得了什麼收穫。當我們嘗試要探索因果關係的時候，常常會有人，把兩件風馬牛不相及的事情，用因果關係來解釋。在這邊摘錄一些以往開會時的會議記錄來解釋這種現象好了。

●這次的專案會在UAT還出這麼多問題，這通通都是我們沒有足夠的測試人員，執行的測試個案根本就不夠多，才會造成這個結果。

事實上在檢討的這個案子在UAT時所面臨最大的問題，其實是因為requirement analysis根本就沒有做好，導致整個架構根本就不對所造成的。沒有足夠的測試人員確實是一個問題，不過它並不是主要的原因。

●這個security上的問題，是因為廠商的程式是由外包商開發的，品質太差才會這樣。

事實上這個案子在security上會發生問題，其實是因為有某些資訊被cache在proxy server上，才會造成這樣的security hole。問題主要是在於proxy server的設定，不在於程式本身。然而在測試時，基於成本以及資源的考量，就沒有架構一套一模一樣模擬production的測試環境，這個問題，才沒有在測試期間找出來。問題的根源，其實跟外包商的品質一點關係也沒有。

●我們schedule的delay都是因為沒有足夠的resource造成的。

Schedule會delay，其實大半的原因在於schedule根本就亂估。Resource確實不足，不過錯誤的估計才是失望最大的主因。

很多人看到2004年，台灣總統大選的電視台灌票，結局忽然在轉瞬之間翻盤，就認為一定是執政黨作票。當你看到一路領先的選票，忽然在開出了500多萬票後，票數忽然靜止，接著則是完全地翻盤，內心要是沒有任何疑慮，可能也不盡合理。所以很多人就會直覺地推論，在開票靜止的瞬間，一定是執政黨在做票。

雖然此刻法律訴訟依然還在進行，不過我個人覺得，很有可能，又是因為我們對於兩件完全不相干的事情，用因果關係來解釋。開票票數翻轉，跟執政黨做票，其實並沒有辦法畫上等號，用因果關係來解釋。根據目前的了解，這跟媒體卯起來依據民調去灌票比較有關。

當你做了錯誤的推論後，最後可能就會定出一些根本就不合邏輯的流程跟制度出來。很多事情，我們看到的都只是表象，當他們依據時間發生時，很難不用因果關係去推論。要下這樣的結論之前，需要三思。要真正推敲出彼此的因果關係，需要智慧，足夠的事證加上冷靜的思考，以及經驗所累積出來的直覺。

我個人對於process的心得
**************************************************
●專案開發沒有一種特效藥，是可以跨各式各樣的專案一體適用的。你需要了解有那些是該做的事情，為什麼要做這些事情，這些問題的前提假設是什麼，而目前有什麼已知的解法。

●當你確定了你的案子特性之後，就要適當地挑選一個合適的開發流程。案子的規模，技術上的難度，系統的本質，人員的能力…都是應該要考慮的因素。在可以解決問題的前提下，盡量減化你的開發流程。

●當你確定了開發流程之後，挑選一組恰當的開發工具。接著應該把開發工具盡量地整合在一起。

理論上來說，工具應該是我們在決定了要採取什麼樣的development process之後，經過仔細思考，深思熟慮後，才會挑選出來在專案中使用。不過根據靈犬萊西在『2004狗眼看人低資訊技術研討會』上所發表的論文指出，百分之八十以上的軟體開發團隊，當他們要決定在專案裡面，應該要採取什麼樣的development process時，會從他們所習慣使用的開發工具這個角度去思考。百分之十五的人，則從來都沒有思考過development process相關問題。剩下的百分之五，則是擁有嚴重的物種歧視，他們拒絕回答任何非人類所提出來的問題。

現在我們在開發工具上頭所面臨的問題，多半是在各個不同的領域之間的開發工具，彼此還沒有緊密的結合在一起。當你要開發的系統都屬於類似的類型時，挑選一組適合的工具，並且思考怎麼把這些工具整合在一起，就會是一件讓你競爭力上升的事情。

很多人都一直在思考怎麼樣可以把軟體包到比較便宜的國家去開發，以便節省開發的成本。我個人卻認為，如果你對於同一類型的專案，已經把適當的工具都整合在一起的話，你根本就不需要把案子外包到國外去。

●選定風險評估項目，並且定期評估。

●監控你的流程執行結果。光是訂好流程是不夠的，要去看看它執行的結果，並且參照風險評估的結果來調整流程。

●收集各種測量統計數據(measurement)，並且要依據measurement的結果來調整你對於專案的估計(estimation)。

●每個案子結束時，都開一個實事求是的專案檢討會議(Post Mortem)。把學到的教訓寫下來，提供給將來類似的案子做參考。

●對於類似的案子，不要貿然嘗試太劇烈的變革。不要把流程限得太死，應該保留彈性讓它有自己進化的機會。

很多人在聽了一場大師的演講，參加了一場精彩的研討會之後，都會期待有個大刀闊斧的改革。好像是拿著一把裝滿銀子彈的槍去打狼人一樣，碰碰碰，然後每件事就會迎刃而解了。

改革應該要緩慢漸進，讓團隊也好，讓文化也好，能夠有調整跟演化的機會。太過激進的改革，常常會讓組織適應不良，最後終究會失敗。

●不要為了寫文件而寫文件。

●如果你沒有任何既定的流程，在你規模小的時候可能不會有大問題，可是當人數一多時，沒有一套process的team，就像是航行在海上的船隻沒有羅盤一樣。隨時都有撞上礁石因而滅頂的可能。

●正確的陳述你所遇到的問題，你就已經找到一半的解答了。

● 推動任何process，都需要花錢，花時間，花人力。不過一套良好的process並不能保證任何事情，一個愚蠢的團隊依然會做出愚蠢的系統。

結語
**************************************************
開發系統不是只有寫程式而已，還有很多雜七雜八的事情要做。很多該做的事情，其實背後都隱含著一個需要被解決的問題。大多數的人，其實並不是很清楚為什麼需要解決這些問題，有很多人甚至於不知道有這些問題存在，所以常常會對於繁複的process提出疑問。

流程永遠都有改善的空間，即使你拿到了CMMI level 5，那也不表示你的專案就會幫你賺大錢。我個人是覺得，在開發系統的過程裡，為什麼要做這件事情，要比這件事情該怎麼做重要多了。如果你開發的系統類型都很類似，其實一套適合的開發工具就會很有幫助。不過用了開發工具，很容易就會被工具給綁住。這是另一個比較頭痛的問題。

我還記得我以往用過一套到現在還是懷念不已的開發工具，Sybase所出的Power Designer 6.0。那是一套進行結構化系統分析時，很棒的開發工具。不過很可惜，後來Sybase往UML靠攏，新的版本怎麼樣就是覺得不順手。而我的工作也漸漸往project management調整，所以就跟這個很好用的tool的這個版本，從此分道揚鑣了。

每次要進行開發工具的轉換，對當事人來說，都是一件蠻痛苦的事情，就像你要告別一段感情一樣，習慣的工具總會有讓你依依不捨的地方。不過資訊科技不斷地發展，各種不同的應用，各種不同的理論，不斷地推陳出新，工具汰舊換新的速度太快，也由不得我們原地踏步。

這陣子CMMI變得比較紅，很多軟體公司也都把改善開發流程，拿到CMMI level 5，當做是一個遠大而值得努力的目標。我個人覺得，軟體公司應該要想的，其實不是怎麼樣能夠當一個軟體代工廠，代工廠可以賺的就是工錢，而軟體公司的價值應該在於生產出可以複製，靠賣copy跟license就可以賺錢的軟體。

如何開發真正可以創造出價值的軟體，並且把它銷售給你的客戶，讓他們心甘情願掏鈔票出來購買，這遠比具有嚴謹的開發流程，來得重要多了。遵守嚴謹的開發流程，如果整個team都是笨蛋，還是做不出什麼有用的東西。有了完善的開發制度，卻一直只是做軟體代工，而不發揮想像力，想想我們可以做出什麼不一樣的東西，我個人覺得這是捨本逐末。有大錢可以賺，幹嘛整天汲汲營營，錙銖必較於蠅頭小利上？

當你有個確定的方向，也找到了優秀的人才，訂一套適合你要開發系統的流程，選擇良好的開發工具，並且持續地改進工具與工具間的整合，一定可以讓整個開發工作如虎添翼。不過如果你已經有了對的方向，也找了對的人才，其實用什麼流程開發，這就已經是枝微末節了。

在這一章裡，我所做的其實只是浮面的提供一些自己的看法，至於為什麼軟體開發得要撰寫這些有的沒有的文件，為什麼需要採用一些莫名其妙的工具，這就不是這樣子短短的一個篇幅，可以介紹清楚的。那可能需要一整本厚厚的書才講的完。或許有空時，我會再寫一些這方面的主題，跟大家分享這方面的經驗。

(全文完)
(全文共有上、下2期)