4.6.資訊管理與系統分析

　資訊管理與系統分析，雖說分析的是商業邏輯與管理機制，產生的成品是管理資訊系統，但管理資訊系統的開發工作大部分的心力都放在和系統本質無關的人的問題上面。

4.6.1.優先要務是先認定目標以及確認團隊成員之間的利害關係

　〔沒有聖人，別相信道德口號〕

　身為一個系統分析師，這個職務的使命是什麼？用我們的常識應該可以擠出一個大概的形象當作答案。不外乎是要思考細節，分析規劃與溝通協調，然後為了達成目標盡自己的責任。一般來說，這和實情不符。系統分析師常常只是表現良好的系統設計師被「升遷」上去的，這樣的角色一開始通常都還當自己是一個實幹的工程師，而試圖與滿口渾話的業務單位人士保持距離。但這樣的心態勢必無法勝任SA這樣的功能角色的需求，於是常常會陷入一個兩難的處境，是讓自己放棄身為工程師的自尊，變得油條點，還是繼續拿理性那套與現實硬幹下去，成為團隊裡頭難嚥的硬梗。這實在是一種道德情感上的衝突，從SD到SA竟然是兩種文化，兩種價值觀，兩種工作態度，直升上去的人很難不受到衝擊。

　這樣很容易產生一種名實不符的特殊病狀。只要一點點逃避現實，只要一點點灰心喪志，這種病很容易蔓延。這種病嚴重的時候，裡頭的人會不自覺的講起道德來了，應該如何怎樣，要那樣做，不能這樣想，特別的理想化。但自己根本就不相信這套鬼東西。以一個新人的姿態進入職場，如果那個環境病得嚴重點，上面說的這種情境會是日常生活的一部分。你好像被要求表現的像一個聖人一樣，那是你應該要做的。壓力好大啊，責任太重了，根本擔不來嘛，於是被壓力壓垮了，最後成為病態環境其中的一份子。這或許是這裡頭的人不自覺的行為目的吧？

　道德不是沒用的東西。但是聖人般的道德，其效用卻和表面上的神聖，恰好成反比。適度，合理，公平，有效率的道德，才是可以實踐，與值得實踐的行為規範，否則就只是拙劣的謊言手法而已。所以要對極端到不合人性的道德要求產生警覺，這是一個組織環境腐化的顯著病徵，如果不能警醒於此，就會身受其害。如果團隊表面上說的道德價值觀是畸形的，那你就得小心的找出背後真正的事實，否則會，即使有心也難以施力的。

　〔沒有目標是常態〕

　追求目標，努力達成目標，這好像是一般管理的最基本要求吧？然而在一般的工作環境裡面，沒有真正追求的目標，反而才是常態。表面上的名義目標，與和獎金機制掛勾的管理指標，不見得能稱得上是真的目標。目標必須是對長遠的將來成果做有計畫的追求，不然，那些表面上的目標，只會讓人迷惑，以至於瞎忙一通，最後把整個團隊的士氣瓦解，僵屍化或醬菜化了。好的，正確的，可行的目標不是本來就應該要有的。目標是要經過廣泛的行銷(不是推銷)努力，從觀察市場與顧客需求做為基礎開始的，不是像連續劇一樣自然就會有目標，只要心夠黑手段夠辣，或是編劇與戲迷夠喜歡就能自然發展並取得成功的。目標的尋找其實是需要耕耘的。

　就像現在的政黨政治，多數都是沒有目標的，只是為了下一次選舉能贏而已，根本就沒有長遠的目標理想存在。所以政治會腐敗不是沒有道理的，這種氛圍之下，要真的為理想努力，不被貪腐侵蝕，不淪為一個只會做虛偽表面工夫的偽君子，那本來就是很難的。政黨政治的幕僚決策與當然也是知識工作，而且是最容易腐敗的。沒有正當的目標是其原因。系統分析師這個職務所處的地位，正好就是尷尬的政治問題最多的崗位之一。這是要決定系統需求的角色。決定，就牽涉到權力，就牽涉到政治。如果沒有真正的長遠大目標存在，爭執一些細節上的決策，就會陷入政治情節，爭來爭去也不是什麼重要的議題，而淪於小打小鬧。於是為了做而做，與因應辦公室政治的自然發展，工作自然多到做不完，時程永遠延遲，目標永遠無法達標。這樣的環境下，真正目標是什麼？其實就是沒有目標啊。

　〔給團隊機會重新思考到底什麼才重要〕

　所以系統分析工作最大的重點是目標是什麼。價值在哪裡？什麼成果才代表這個系統達成了其使命？不思考這個問題，只是努力的工作，也是無法帶來任何成果的。就如同企業不做好行銷工作，不深入了解客戶需求，自顧自的做自己的產品，然後認為顧客應該要為自己的優秀與努力買單一樣，那是很瞎的做法，系統分析如果不想瞎忙一場，累到被人罵到臭頭，就必須在一開始就思考這個問題。到底這個需求能對組織帶來什麼？實際產生什麼影響？與任何具長遠計畫的戰略目標有任何掛勾嗎？

　不要認為工作就是應該要努力達成，然後這樣就好了。工作的意義不在於努力，而在於價值，對其他人有貢獻的價值。不思考工作的意義，又希望有所成就，那除了運氣好碰到什麼都能幫你想好好的領導人以外，那是沒有指望的。知識工作，系統分析的工作，如果要領導人先想好好的，說清楚講明白才能做得好，那這樣的人就不具備智力上的任何的實際生產力，反而只是拖累而已。

　系統分析工作常常是很忙碌的，為了對User承諾的時程忙著溝通協調，又或是忙著趕需求規格，或是更多的在驗收功能時為了大量的與需求不符的設計大傷腦筋。就算這還不夠忙，只要員工看起來有點閒，好管理的主管通常都會找點事給下面的人幹，做做研究與評估之類的，像資訊安全就是一個沒事找事的很好的任務來源，說重要也重要，要弄到複雜的沒人能懂也很容易，有過度管理傾向的管理者通常都很喜歡這樣的東西。於是從忙忙忙，變成茫茫茫，這些任務真的是重要的嗎？對大多數人來說，怎麼看都覺得是狗屁的任務，要是真的能產生成效，就反而會很好笑，天大的諷刺劇情哩。

　不要害怕面對現實，要勇於思考才是。逃避現實，不去思考可能性，其實是沒有任何好處的，就以功利的角度來看，這只是很乾脆的放棄了擁有其他選項的機會而已。面對現實，勇於思考，即使是對於卑鄙猥瑣的小人，也能帶來好處的。太忙就會忘了思考，而當失去長遠的目標方向的時候，很容易就會因不知所措而把自己弄得很忙。這算是盡心工作的好品德，但在這個情境下，實在也是很危險的事啊。這個功能有什麼價值？這個需求真的是必要的嗎？這個要求是為了什麼理由而做的？這樣的質疑其實是健康的，如果對這種質疑感到反感甚至憤怒，那這個人可能病得不輕了。

　〔團隊運作的好壞常是看機緣〕

　系統開發團隊的效能好壞，與成員有關係。當然，領導團隊的人的影響是最關鍵的，但是個別成員也會發揮影響力。特別是，當領導團隊者並沒有相應的管理經驗和技能的時候，往往他也沒有堅定的目標，只是走一步算一步，不想被罵，想被上司稱讚而已。這個時候，團隊的運作效果，受到領導人的影響就很小，更多是由團隊成員的每個人不同個人特質互相影響而決定的。裡面只要一個成員特別積極主動，團隊就會比較主動積極，只要有一個成員極限的自私自利，整個團隊就會成為絕對的叢林。常常，這個轉變是帶有隨機性的。因為我喜歡這個人，所以我支持他的意見，因為我討厭這個人，所以我覺得他的意見是不好的。喜歡不喜歡，有時候是第一印象和一些不經意的小事所影響的。可能一個擦身而過的小意外，能讓兩個人成為朋友，或是敵人。一念之間的讚美或批評，可能會決定之後的關係。一個不經意的心不在焉，產生的誤會，也有可能讓兩個人從此不合。有時候，整體情況是許多看似無所謂的小事堆積而成的。運氣的成分是存在的，有的時候還很強大。

　既然如此，如果我們主動觀察，留心注意，這種巧合的機緣其實有一部分是可以靠我們的意志與努力所主導的。為什麼要讓可以掌握的運氣來決定自己的前途與自己辦事的效能呢？

　〔忽視利益衝突的代價是超低效率的工作〕

　一個系統開發的團隊經常是缺乏效率的。團隊的人和越差，通常效能越是低落，也就是說，有利益衝突和勾心鬥角的團隊氣氛，工作會更累，而成效會越少。沒辦法，當有人存心算計自己的時候，最有成本效益的對應行為就是盡可能的提防他，不然自己的努力成果也只會被自己的敵人所接收，氣死自己。

　這個利益衝突有時候很現實，也很殘酷。開發單位和需求單位的立場就是不一樣，雙方眼前的利益就是互相衝突的。誰都無法退一步，就是個僵局。這還算好的。像外包廠商與內部員工的關係，其利害就更加難以協調了。把程式維護做好，容易理解與維護，只會讓這些維護工作更便於被其他單位所取代掉。為什麼要把工作做到最好？有些提供資訊服務的企業，其業務模式是短視的把現金帶進來再說的模式，甚至把這個模式當成企業經營的主要商業模式，靠這個在發獎金與業務的佣金的。先搶單，賠錢也要接，等系統開發出來之後，在後續維護上頭再慢慢回收成本，是一些企業經營的指導方針。就因為這樣，所以系統的設計不能做得太好，也不能為了客戶的需求做設計，不然呢，就會賠錢倒閉。而一些諸如政府單位或營運的像公家機關的組織企業，因為一些沒想很清楚的理由在做資訊化，只是為了消化預算而進行資訊化，就會吸引這樣的廠商來投標。一開始可以殺價搶單，反正後來系統上線了，設計做得夠複雜，程式寫得夠神秘，除了自己以外，換任何廠商去做維護的成本都不如整個重做，在捨不得沉沒成本的情況下，這些組織都會和這些提供系統服務的廠商維持一種有點特殊的共存關係，在這種局勢之下，任何一方若是真誠為對方打算著想，只會讓自己被對方吃掉而已。於是整個任務，成本就是隱形的高，系統成品的品質那就是一個爛，這也是因為利益衝突的僵局而不得不如此的。有時候，PM的陣亡率特別高，甚至讓這個職務蒙上了被詛咒的傳說，那個屎缺，誰幹誰倒楣呀。因此而搞出了一套專案管理的理論，還有PMP的專業訓練與認證。能解決問題嗎？對那些考到認證的人而言，在表面上，一定會說幫助很大。但是，如果問題是出在利益衝突的本質上，專案管理技巧是派不上用場的。因為問題並不在缺乏把事情做好做對的能力，而是事情本身就「不能」被做好做對。

　當關係處在一個利益不一致的時候，靠個人品德與技術能力都無法把事情做好。此結不解，任何管理理論與技巧也都無法改變結果。這不是很自然的簡單道理嗎？

　〔利害關係可以加以設計〕

　好像很黑暗啊。知識工作的產業現實的確是有點黑暗的，不僅僅是管理資訊系統的開發，任何需要思考分析的動腦專業工作都是這樣的。厲害關係只要不對頭，努力都是白費的。厲害關係一旦定型，要再改變，真的是不容易的。

　但是厲害關係本身並非宿命論。如果目標清楚，厲害關係是可以加以主導與設計的。這在系統開發工作上，就是在兩個階段要處理的。一是在系統的戰略意義的定義上頭，二是在績效指標的規劃設計上頭。

　如果賦予了這個系統開發任務一個明確的長期戰略目標方向，那麼，「要什麼」應該是清楚的。不能提供需要的服務的資訊廠商或團隊，就不會去合作，也知道這個任務有多少價值，值得花多少成本去打造能提供所需資訊服務的團隊。業務的嘴再強，再會砍價搶單，如果其意圖對自己的目標無法利益一致，短視近利的貪便宜其實是買貴的浪費，就會很清楚了。不然呢？有便宜的為什麼不要，要去和貴的廠商簽約，是收回扣還是怎樣？沒有堅定的目標方向，就會陷入錯誤的成本結構，從而引入腐敗的開發團隊文化。

　績效指標的規劃設計也需要目標的指引。想要什麼？想要什麼就應該要那樣去設計，要怎麼收穫，就要那麼栽。績效的設計要清楚的和目標掛勾，要看的是具體成果，而不是理由。定義具體成果是什麼，要簡單直接，要沒有太多迴旋解釋空間，否則，就只會得到失敗後的一堆解釋。目標設計錯誤時幾乎肯定會充分達成，然後讓自己受傷慘重的。所以要收起管理的朦朧感覺，訂定管理績效指標時，要直指成果，不要攙和進太多感覺性與是非對錯的邏輯解釋，那只是逃避責任的不自覺藉口而已。

　根據目標設計一個合理可行的利害關係，雖然說起來抽象，但其實並不複雜。就好比你明明很討厭某個人，但你有特定的理由不能和他交惡，所以會對他加以容忍那樣，只要有目標的指引，該怎麼做就那麼做，並不是很複雜的。在任務開始前先確保和客戶與團隊成員當下的利害關係為何，是否能用共同目標將這群人的利害綁在一起，就是專案成功的最重要因素。這當然是一種能力，是一種思考分析，一種靈巧的人際關係設計的能力。

　〔系統分析師與客戶的利害分析〕

　孫子兵法的基本是上下同欲，治軍有道。這個道也就是上下有共同的利益。所以要成為一個優秀的系統分析師，對於客戶利害關係的掌握，那會是很重要的事。要主動了解顧客真正想要的是什麼，而不是應付對方用言語表述的需求就好，要對顧客的想法感到好奇，要有觀察對方價值觀取向的意識在。不為什麼，因為只有這樣才能掌握什麼是對顧客是有價值的成果。只有這樣才不會忙到翻掉還被嫌到臭掉。這是常常被忽略掉的。畢竟和SD與PG的習慣不同，只要針對明確的需求規格做到精確的符合，那就算做好了，SA的工作第一就是要先弄清楚到底怎樣才算做得好。畢竟管理系統需求本身就不是絕對明確的任務，彈性很大，同樣的目標有太多種方法可以達成，更何況連目標本身都牽涉到人的因素而不是很穩定。

　小至團隊裡的個人系統分析師，大一點到領導專案的PM，這個先弄清楚需求，把利害關係預定在一個調和好的狀態，就是工作的最重要根本。這點做好，後續的努力自然就能產生回報了，客戶的需求與想法沒摸清楚，矇著頭下去幹，只會被人修理得亮晶晶的而已。系統分析師的工作任務，和系統設計程式開發是截然不同的，不能再心存幻想，只要用以前的經驗與做法，努力用心一點就能把事情做好，那是行不通的。工作遇到瓶頸的時候，不妨想想，客戶真正想要的到底是什麼？真的是我現在在做的嗎？重新審視需求，通常都能找到好答案的。

4.6.2.判斷主導權的所在與協調自己的目標與整體的目標

　〔找出主導的核心人物〕

　誰是老大，誰說了算，弄清楚這點很重要。到底什麼任務重要，哪些工作是有價值的，需要裁判。如果搞錯真正的決策者，那只會讓自己越做變黑而已，畢竟決定什麼是重要的，是最重要的。如果一群人七嘴八舌，無法決定，甚至搞起民主投票來，那只說明了沒有人敢出來擔責任而已。能決定的人，除了擁有權力，也有承擔責任的義務。一個沒有人需要承擔責任的開發團隊肯定只會把工作搞得一團糟。

　即使是共識決，也必須先有默契，該有人承擔的責任，必須要分配好，不能有重要的任務沒有人負責。責任要明確，要怎麼分都行，但每個關鍵任務都必須要有人負責，而且這個人要能做決定才行。如果責任分配的很公平，權力平衡，人人有獎，那團隊就會像無頭蒼蠅一樣混亂。

　管理學大概就是講這個。在管理資訊系統的團隊工作上，這當然也是適用的。責任如果沒有清楚劃分，就會有人濫用權力搞政治，進而腐敗團隊。每個團隊都需要有人站出來領導，做決策，然後擔責任。如果都沒有人願意站出來的話，那就自己站出來吧，反正，你不站出來，團隊也是死得一樣快。安穩的好日子通常不屬於缺乏領導的團隊成員，躲起來也是沒用的。

　〔找出握有主導權之人的價值判斷與任務目標〕

　那和承擔成敗責任，負決策權力的人的互動會很重要。他在想什麼？他在意的是什麼？他的方向與偏好為何？甚至他的價值觀是怎麼個樣子，都是需要用心了解的。因為這才是任務的目標。

　這可以說是紀律的議題。如果身為團隊的一份子，你不能為團隊盡一份心力的話，那就會拖累這個團隊。總是有人要負責的，每個人也都有屬於自己的職責－如果管理上軌道的話。你不能為其他人服務，設法滿足他達成任務的需要，那其他人又有什麼理由要配合你的想法，協助你完成責任呢？如果團隊不能互相支援，不能盡量以協助主導人達成目的，每個人都想表現自己，都想壓過別人，那麼，整個工作的效率就會很差。任務的達成，工作分配上要有主從，要有人擔，責任要明確而沒有含糊。只要責任是跑不掉的，只要不是太過不可能的任務，通常每個人都會發揮得相當好的。當然也要其他人不來絆腳才行。一個系統分析師，當他的責任很明確的時候，表現多半不會差到哪去。因為跑不掉的責任掛在那，這個傢伙就不會有多餘的心思搞這搞那，搞得烏煙瘴氣。雖然有時候目標責任訂得不好而充分達成是件慘劇，但是整體來說，當目標與責任很清楚的時候，運作總是比較好的。

　〔個人目標與主導者目標的平衡妥協〕

　所以目標目標，個人目標與團隊目標都是目標，但目標之間不一定是協調的，不一定啊，所以是人可以設法決定的。

　交易不是骯髒的。利益交換也不是卑劣的。只要不以惡劣的手段去迫害弱勢者，那麼利益的交換本身是一件對整體效率有益的事。為什麼不能妥協，不能協商，不能作利益交換？這是一種似是而非的政治道德。如果這樣的交換對大家的好處大於壞處，那就值得去做。別被自己都沒搞清楚的道德給模糊掉了。今天，就算你的行為看起來像是拍馬屁，像是在討好，如果團隊能因此創造更多的價值，能夠避免更大的損失，能夠從腐化的懸崖邊勒馬止住，那麼這又於道德有何虧？出發點是好的，也經過充分的考慮與籌畫，做出來的行為，如果結果也是好的，又何必自限手段？反倒是怕被人認為不道德的偽善，出發點並非善，只是裝裝樣子而已，成果也是負面的，這樣的善人的有臉面，其實反而是無能與可恥的囉。系統分析師的氣節是什麼？是堅持專業據理力爭嗎？還是堅持讓需求的品質有保證，任務總是能達到目標的成效？這是值得思考的一件事。很多的IT工作，其實是SA，SD與PG混在一起的軟體MIS工程師，有氣節的執行專業工作，這個態度對不同人來說解讀可以很不同。差別就在實際的績效，同樣是天差地遠的。

　〔主導者目標與組織長遠利益目標之間的平衡妥協〕

　但主導者也是個人。偉大的領袖也只是個人。是人就會有弱點，要一個人在智慧與道德上都臻完美無瑕之化境，那是強人所難的。會有這種自我感覺的人，通常離優秀都有一段距離，因為看不到自己的缺點，無法自我檢討，就沒有進步的空間。既然人多半有弱點，那麼，領導人的目標，與組織長遠利益的長期目標方向之間，也未必能充分契合。這可能是個大麻煩。

　我們有觀察領導者，主事者他的目標方向與價值判斷的必要。我們同樣可以思考，組織長遠的目標利益應該是什麼。就杜拉克的管理學而言，這叫做高階管理的任務，這是每個企業都需要的一種機能，這不是事務性的工作，不是常態性的例行工作，但是對企業的存續非常重要，必須要有專人來負責。簡單說就是要找一個領導團隊，負責思考企業的使命與方向是什麼這種根本的任務。大多數的知識工作者並沒有這樣高階領導的權力與地位，只是某個事務性責任的小螺絲釘。但是就因此而不該思考嗎？那是大人物才需要想的，只要過好自己的日子就得了？

　其實不該這樣想。知識工作的本質其實和高階管理是一樣的。在遙遠的過去或說二十世紀初以及其以前，沒有那麼多的管理工作，也沒有那麼多的幕僚任務，現在這些知識工作全都是老闆的任務。要把這種工作做得卓有成效，就必須要站在更高的高度來看事情才可以，這是平常就需要思考與訓練的。就算沒有辦法，或是沒有後台背景吧，爬不到高位上去，至少也能成為一個能幹出點實績的螺絲釘吧？像系統分析的工作，多半和商業模式有關聯。為什麼系統分析師就應該堅守技術本位，不能對業務層面的做法提出任何問題呢？創意與創造都是在不同觀點的人之間磨擦出來的，用不同的角度，更能找到更多的選擇。所以，就算只是一個小卒，也是有成長與發揮的空間的。

　更何況，現在這個社會最缺的，似乎不是扎實的螺絲釘，而是能獨立思考，幹出成績的領導人才吧？領導人的目標與想法與組織整體有矛盾的時候，身為其中的一份子，也是可以想想辦法的。就算不是為了你的老闆，也該為自己想想吧。

　〔系統分析師需要爭取的主導權〕

　系統分析的工作，常常彈性很大。可以累得要死，壓力很大，卻得不到任何肯定。這是因為喪失了主導權，於是只好被對方牽著鼻子走。主動出擊，能掌握主導權的話，是可以規劃分析，然後「設計」出更有效的工作方式的。

　有時候，需求單位對IT相關的專業知識有恐懼症，不願去了解，但卻特別想要表現，努力爭取強勢。要是不小心讓檔次不夠的需求人員，或是檔次不夠的菜鳥PM主導任務的進行，這個系統分析的工作可就悲劇了。不只如此，系統分析師還要面對來自工程師那一端的壓力，他們不但勇於以技術的角度來挑戰這個他們必須努力表現以求「升遷」到的這個下個職務，現在坐在上頭的人，而且工程師也很容易有特殊的工程師文化，反正就是和把任務做好不是很協調就是了。這個不行，那個不行，絕不妥協，絲毫不能退讓，這樣的工程師也是讓人頭痛的，而或許自己在升上來之前也就是那個樣子的啊。

　其實掌握主動也就是早一步想到，早一步行動而已。在工作上必須要掌握足夠的主動，這不是說做事要強勢，主動與強勢是兩回事。系統分析師要盡可能的爭取自己責任的明確，這當然是在充分的利益妥協與溝通協調之後。只要任務能明確，那良好的成效通常是可以預期的，而責任明確也會意謂著相應的權力，才能爭取合理的資源。如果大家不清楚你到底是幹啥的，就只會把一堆他們碰都不想碰，一點也不想知道的含混東西推給你而已。那就是穩死的了。反之，讓他們知道你能做什麼，能給他們什麼，你的工作有什麼重要性，那麼，你才有空間可以思考分析，與應用思考分析的成果來制定執行計畫，真正的在推動你的工作。系統需求是什麼？當答案是在需求方身上的時候，如果無法把球給丟回去，把不該攬的責任攬在自己身上，那下場就不會好。

　說來說去，也就是爭取主動而已。這是軍事與兵法的最高指導原則，在知識工作領域同樣是很受用的。

4.6.3.複誦與確認

　〔誤會無所不在〕

　系統分析的工作內容相對而言是很抽象。使用者提出的，乍看之下可能亂七八糟的需求，如果仔細問一問，整個從頭到尾搞清楚之後，可能會對這個亂七八糟有了改觀。其實使用者常常是想了很多的，是很用心的，是使出渾身解數的，才變出了這一團怪東西。雖然就整體來說，這樣的需求品質就系統設計可能不是很理想，但就管理需求上通常多少有點道理。如果懶得花心思去理解這些整體來說還算不上能行的需求，而開始鄙視使用者，那這個樑子結的可就深了。

　特別抽象的工作內容，在理解上本來就不容易。這些思考出來的東西，原本就可以賦予各種不同的定義。怎樣都可以是對的，解釋的角度太多了。對沒有經常配合的人來說，可能連習慣用語都會產生誤解，更遑論一些設計的細節了。實務上，必須小心謹慎才能避免誤會。管理資訊系統，另一個面向是管理。這又是一個很容易陷入虛無縹緲情境的主題。管理是主觀的，和系統設計是一樣的，主觀的事物要溝通與理解，本來就是很困難的，兩相加成，更容易變得迷糊。如果能避免不必要的誤解，工作效率就能大大改善了。

　〔誤會的嚴重後果〕

　誤會並不是讓人莞爾一笑的輕鬆經驗。有時候，連續忙了好幾個小時，焦頭爛額的，努力解決一個大問題。好大的問題啊，唉呀，但是在問題解決後再來看看，竟然只是因為一個不起眼的小小誤解造成的，本來就該是無關緊要的事才對。

　搞錯需求是常有的事。千萬別認為這是專業程度不夠，不夠聰明才會搞錯需求。搞錯需求通常是程度上的問題，而不是有沒有的問題，能讓誤會的傷害控制在一個較無關痛癢的範圍，是不容易的。

　人最大的毛病就是健忘。其實常常犯錯，常常粗心，也有很多錯誤是很無言的誤會，但是就是不會記取教訓，一犯再犯。說是說不二過，做得到的人並不多。可以試著用紀錄與統計的方法輔助自己，看看到底哪些錯誤常犯，哪些問題是是可以加以避免而有很高的成本效益的。在系統分析工作上，誤會應該是很大的一條，甚至不輸給利益不同心的障礙。

　如果只是犯犯錯，小打小鬧浪費點時間人力，那也就罷了。這也是人生嘛。小誤會可能會引來更大的誤會。有時候我們會很鐵齒，堅不認錯，或堅要對方認錯。但是彼此解釋的角度本來就不一樣，就有可能變成僵局，結果每個人都認為自己是對的，然後整個組織團隊沒半個地方是像樣的，就是這個鳥樣子。誤會有時候會有連鎖效應，將錯就錯的一時意氣可能比我們想像還要威力強大。這個可不好玩，要是賭起氣來，小誤會可以升級成冷戰甚至熱戰。辦公室政治的鬥爭，有時候並不全是爭權奪利才鬥的，而是誤會造成的爭執。相當蠢吧？看別人在幹什麼的時候，大概就是這個感覺吧。

　〔用覆誦的習慣與會議記錄的待辦追蹤規範來降低誤會〕

　既然誤會的成本那麼高，那麼矯枉可以適度的過正。重要的需求確認，首先口頭可以習慣用覆誦的方式來加強確認。照著對方的說法再順著提問一次，作為確認，是看似平凡無奇，但效果卻相當好的一門技巧。不只是重複說對方說過的話，能給對方親切的好感這個不易察覺的心理暗示效果相當出色以外，有時候用對方的說法自己重複說一次，嚇到的反而是自己。啊，是這樣啊！原來剛剛想錯了！當我們用自己的思路持續思考的時候，就容易遇到盲點。摘錄對方說話的重點，並鸚鵡學舌般的就重點一一覆誦確認，通常不會讓人覺得煩，反而會有一種有禮貌，重視對方這樣的正面印象。就算這樣的行為看起來並不聰明，這個動作卻是有很大的性價比的。想太多了，反而會忽視事實的認知與解讀，換個態度平衡一下，是很好的。

　會議記錄，這是很煩的事。特別是寫得像公文一樣，格式不符，用詞不當還會被唸東唸西的，這鬼東西本來就沒人會看啊，這麼囉嗦幹嘛？的確，這常常是沒事找事幹的繁文縟節，搬石頭砸自己的腳。但這不是會議紀錄本身的錯，而是這個團隊本身已經腐化了，才會這樣的。紀錄記錄，其實資訊系統的基礎就是記錄。把事實明確紀錄下來，大家都跑不掉責任，就勢必得面對現實。必須面對現實的時候，就能少幹許多蠢事了。會議記錄的精神不在於詳盡，不在於宣揚領導的高瞻遠矚，不在於那些最熱門議題的爭辯。那些或許是有點重要性的，但那不是應該干擾紀錄這件事的本質。紀錄就是要把事實給寫下來，要突顯責任，讓每個重要任務不致於被摸魚打混的手法給矇過去。會議記錄真正重要的是，有哪些行動要採取，有哪些任務需要追蹤。這才是重點。誰說了什麼話，如果無關執行的需要，那就不是重點，要做的事才是重點。會議如果不能聚焦於釐清責任與完成任務，那會議紀錄看起來就會像煩人的公文一樣。但若是能避免官僚風氣的侵蝕，會議記錄是凝聚共識，減少誤會的很好的工具。剛剛在會議上慷慨激昂的辯論，耶，看看後續記錄下來的內容是啥，真的形成的行動決議又是什麼，這和複誦其實有些異曲同工。其實也就是多聽聽別人說的是什麼，如此而已。

　〔標準文件與系統管制〕

　更進一步的，是把溝通作業的程序給標準化。文件是更正式嚴謹的覆誦與會議記錄，當文件與流程規範已經制定出來的時候，在這個設計範圍之內的誤會基本上就很難再發生作用了。

　太好了，不是嗎？當然沒有絕對好的事情。越是嚴謹的文件規範，需要的額外工作量就會相應的增加，做一件事的必要成本就會相對的沉重。大企業通常行動緩慢，反應能力低下，多半是受到繁瑣而嚴謹的管理流程的拖累。這很可能只是必須的代價。

　所以，文件標準與系統管制這檔事，是需要小心使用的武器。需要仔細拿捏成本效益，不要浪費這個「昂貴」的子彈。如果只是為了很有管理的Fu而在這上頭大作文章，那這樣的過度管理將會腐化組織，並阻礙團隊獲得成效。

　其實系統分析師幹的工作常常就是這些過度管理的打手。這樣的工作注定不會有實際成效的。而主管的意圖就是那樣子的，這好像只能悲劇了啊？戲法人人會變，各有巧妙不同。當主管只是個不懂管理的管理狂，與其拍他馬屁，幹些表面功夫，其實還有另外的選項。就把實際的情況紀錄下來，如實的反應，然後「不經意」的把事情做好，這也是一個選項。這會讓擁有權力卻沒腦袋的領導人有點新鮮感，然後會很高興的把這個發現當作是自己的成就，於是你就有機會趁勢發展些活動了。當然，做人的技巧很重要，若是堅持正義而和主管爭功，最後只會什麼也不剩的，要設法讓自己的工作能產生正面的成效，那才是對自己有利的。畢竟一個功績遠播的人才，換個老闆一樣吃得開，而只會計較功勞不能被搶的人，也不能持續做出成績，只會兩頭空而已。

　〔仔細分析現行運作的溝通失誤成本後再加以調整因應〕

　誤會的成本是驚人的。而對策，還是要謹慎而理性，不要過度反應。過度的文件與管制對組織有害。任何事物，只要走上極端，多半都是蝕本的買賣。所以說，要先分析當下的溝通失誤到底產生了多少問題。這值得增加多少的管理機制去改善？

　不要從複雜高深的管理理論著手。看看有沒有看起來簡單陽春，但是能有效的滿足需求的方案吧。誤會常常就只是誤會，雖然殺傷力強大，但本身並不是什麼太複雜的問題。可以的話，盡可能用最簡單的方法解決吧！其實這也是高效能的系統設計的指導理念，要擁抱簡單，複雜的東西當然可以用，但是要斤斤計較這些措施帶來的效果是否值回票價，它們是貴在看不見的地方，等真正感受到它們真實代價的時候，那可就一點也不好玩了。不要花一塊錢去做節省九毛錢的改善，那不是管理，那只是一種浪費。

4.6.4.適當的文件

　〔文件的目標是為了整體利益的目標〕

　系統分析師的工作，可以看得到的部分，就是文件了。腦袋想的，嘴巴說的，那都是暫時的，也可以不認帳的，只有寫下來的，才算數。但是系統文件往往是最可恨的，不但浪費時間，而且在很多地方都是，根本不會有人看的擺飾。正因為沒人看，所以也不值得用心寫。不用心寫的文字又更沒看的價值了，這真的是注定的結局啊。

　不是不看，只是時候未到。寫系統文件的目的當然是為了日後的維護，與溝通協調的順利的長遠投資。當下，只會增加成本，把寶貴的人力拿去寫文件而已，開發的時候，哪需要這些東西，寫程式都來不及啦！系統分析師就算不殺下去，重作馮婦幫忙趕程式進度，好歹也要負責測試，準備測試案例與做單元測試嘛，這樣才算物盡其用哩。在小公司，小團隊，這真的是常態。於是呢？系統分析師的真正的職責，需求分析，到哪去了？分析思考，到哪去了？簡單的說，很多團隊並沒有認識到這個角色到底有什麼用處，只是當成工程師晉升的一個階段而已，人還是一樣當工程師在用。這個後果是什麼？該做的事，還是少不了，需求是一樣得決定的，只不過在這種環境下，常常是需求單位自行決定了事，甚至是老闆自己就拍板定案了。這些人的主要職責與工作的重心不在管理資訊系統的需求分析上頭，這也和他們的績效關係不大，於是呢，需求的品質爛到無以復加，然後接手開發的團隊自然焦頭爛額，只有苦難的日子可以過。等到團隊成員流動，需要訓練新人的時候，咦，文件呢？品質上好像有點見不得人，實在派不上用場啊，還是不要拿出來丟臉好了。有些業務規則到底是怎樣，說真的，當系統實在特別的複雜時，當人員流動較為頻繁時，有時候還真的是沒人敢打包票是怎麼回事。所以呢？當有需要修改現有系統的時候，那就是一個很難動的情況。貿然把自己看不出所以然的奇怪代碼給拿掉，誰知道會發生什麼問題？通常，沒人敢擔這種責任。於是只好小心翼翼的，委屈求全的，脫褲子放屁的進行系統的維護。人月神話所說的改一個Bug出現更多Bug的奇景，實在太常見了。當系統的架構已經失控，當系統的功能已無法被有效的掌握與管理的時候，就算想回頭補文件，也來不及了。

　說到文件就讓人頭痛啊。真的很雞肋？或許吧。但寫系統文件，到底目的為何？真的有仔細思考過，我們是為了什麼需要系統分析的工作，到底為什麼需要需求文件與系統文件？我們要的當然不是分析工作與分析產生的文件本身，我們要的是成果。先想清楚要的成果是什麼，這些工作是必須的手段，是有效的手段，是為了達成目標必要的成本而已。如果看清楚要的是什麼，就不會為了文件而文件了，不需要恨它，也不必對它畢恭畢敬的，它只是達成目標的手段之一，只是一個選擇而已。

　〔用成本效益分析適當文件的規範程度〕

　文件是該寫的。文件是一個標準，讓所有人都能達到一致的手段，如果不寫下來，可能根本就沒想清楚，就在那裡吵個不停了。寫，有強迫思考的用處。寫下來，也有助於責任的明確，這也能減少管理上的腐敗。寫下來，經驗才得以累積，不然每個人一套，永遠都在經驗前人已經學到的教訓，永遠都是風風火火的，卻沒什麼突破。如果壓根就從沒想過文件的用處與意義，只要開始進行這樣的管理行動，很快就能看到相當的效果的。

　不過搞文件也是一個很誘人的管理陷阱。管理不是越多越好，管理必須適度。從全然不知管理到開始進行管理，一開始常是有點成效的，但玩過頭，反而變得官僚，進而讓組織僵化，最終得不償失。這真的是很容易誤入的陷阱。因為大多數缺乏成效的管理者，這個族群不小呢，都有過度管理的傾向，而不懂得中庸之道，只會努力表現自己而已。從有一致的溝通方式，可以進化到細如牛毛的文件規範，如果不小心翼翼，那就會犯錯，就會挨罵了。於是花大量的時間來處理這些過度管理衍生出來的文書工作，最後反而耽誤了正事。做得超過了，好處都抵銷光光了，反而還倒貼。很多團隊就是受到這種不當管理所害，因而變得痛恨文件，結果導致極為粗放的管理。這同樣是不明智的。

　管理需要能節制。做一件事情要考慮的不僅僅是做與不做，還要思考做到什麼程度比較好。過猶不及。如果這個文件規範浪費了大量的時間和人力，卻不能帶來多少好處，寫出來的文件也缺乏參考價值，那就應該檢討，是這個規範沒設計好，還是這個規範對現在的團隊而言，還不到應用的時機。大型組織為了生存而不得不忍痛採取的昂貴管理手段，常常被小型團隊拿來玩耍，以為只要有套像樣的管理辦法，自己總有一天也能長大成大型的偉大組織。這個自然是永遠沒有長大的一天。最基本的性價比分析是必不可少的。

　〔寫文件至少要寫到讓對此一無所知時的自己懂〕

　無論如何，總會有寫文件的需求。如果是自己在寫文件，甚至自己要決定文件的標準規範，或是成為傳說中的「第一版」的創始文件版本時，有什麼值得注意的呢？當然，不要忘記文件的目的為何，這很重要，但是，還有一些小原則也需要注意一下。不可能寫出每個人都能一目了然，一看就能完全了解全局與所有細節的完美文件。如果真的做到了，大概就是文件規格的設計過頭了。拿捏的尺度很重要。寫文件有一個最起碼標準，那就是，假設自己在一無所知的情況下，看到這份自己目前設計的文件，是否能夠得到足夠的資訊，而能掌握狀況？如果自己看了和自己思考習慣絕對相同的人寫的文件還是無法看出所以然來，那這份文件肯定是狗屎。我們看到自己寫的文件時，常常只是拿來當作對自己記憶搜索的提示而已，其實不是看文件看懂的，只是回想起來而已。如果是這樣的話，那寫出的文件只是勾引出撰寫者腦海裡部分記憶的指標，對其他人來說自然很難有效了。最起碼，假設自己在完全不了解這個系統文件的整個背景之下，讀完了文件，至少能掌握主要精神，知道該向誰問什麼問題，那這份文件才有存在的價值。

　〔共通語言與習慣可以提升文件效率〕

　每個人的思考習慣不同，連用語都不一樣。抽象的工作，很容易創造出抽象的專有名詞出來。只是簡稱吧，簡稱與縮寫，那倒是可以提升溝通時的效率的，如果雙方都知道這個簡稱的意義的話。

　專有名詞的解釋，其實是文件的基礎。另外一個重點是意圖與緣由。只有掌握這兩項，才具備從文件中挖取資訊與經驗的能力。這當然對文件的效率有很大幫助。

　因此在設計文件規範的時候，切莫忘了這兩點。文件的文件，有時候是必要的。甚至，文件的根本意義，從這點上頭來看，也就很清楚了，文件的文件之於文件本身，就像文件本身之於我們的目標，那是一樣的。

　〔沒有實際價值的文件設計要素是製造腐敗的浪費〕

　因此，我們應該要審慎的思考文件的設計方式。就像所有的知識工作一樣，文件規範的制定同樣特別有彈性，怎樣訂都成。有慣例照慣例，沒慣例第一個烈士湊出來的就成了以後的慣例，常常都是這樣的。多做一點，多一點巧思，多添一些花邊蕾絲裝飾，這是很容易犯的病。這是多餘的。如果它沒有絕對必要存在的理由，就應該把它排除掉。因為這種工作本質就是會引來複雜，關聯與關聯交錯本身就會製造大量的複雜度，不需要去裝飾更多的複雜度了。每增加一個要素，都要思考其必要性為何，性價比好不好，不夠划算的話，就捨棄吧。

　這個原則和良好的系統設計是一樣的。技術本身是一回事，應用技術有效率的完成任務是另一回事。系統設計如果把目標放在高深技術的應用，而不考慮目標任務的達成的話，那就會缺乏成效。技術本身也是帶來複雜度的昂貴元素，也是成本，不把成本往有成效的地方投，那就是一種浪費了。任意的引入不必要的複雜度，短視來看，在專業的自我保護上是有顯著效果的，但長遠來看，只是製造更多不必要的成本，自我阻礙目標的達成而已。維持簡單是系統設計師能不能有效率的設計出高品質好維護的設計的最大關鍵。需求分析又何嘗不是這樣？文件規範的設計不也一樣？

　簡單就好，是個好原則啊。

4.6.5.對強勢的人的應對

　系統分析的工作需要處理人的問題。其中一種最常見的麻煩就是，對方是個個性上很強勢的人。好勝，可以說是積極的表現，至少有想做事的態度。可是這樣的角色常常是最麻煩的人物。什麼都要爭到贏，其實就是死不認錯。但是死不認錯不代表就真的沒錯，也不代表就比較不會犯錯。要是這種人運氣不好，剛好抱了一個不太對的觀點或立場，在那邊死鴨子嘴硬，就算他真的自己發現錯了，也很容易因為面子掛不住，而將錯就錯，這就變成了麻煩。一旦和這樣的人據理力爭，那情節很容易演變成肥皂劇，這種情況下，工作其實是在開倒車，越做越回去啦。沒達成任何目標，沒解決任何問題，只會製造更多問題。

　強勢是一回事，那是個性上的特質，而能力強是另一回事，不要混為一談。強勢的人通常都會將這兩者搞混。其實沒有自信的人是強勢不起來的，有強勢的個性，基本的智力都不會太差，只不過人格不夠成熟，可能是從小就以天之驕子的姿態被寵壞了，而認為自己什麼都是對的。其實這是運氣太好的一種運氣不好，好運反而造成了人格成長上的阻礙。這樣的人，通常多少有點本事，只是他只關心自己的表現，只關心自己的成就被人重視，勝過別人對這種人而言比團隊有好績效要更有吸引力。就像很多會唸書的人，從小就被當成寶一樣，名校一路直升，培養了很高的自信心，但卻也養成了過度的強勢個性。如果沒有相應的眼光與能力，眼高於頂，只會讓自己的本領成為團隊的障礙了。

　很不幸的，系統分析師的工作夥伴，不管是管理面的需求單位代表，還是工程師，這兩種人，個性強勢的機率都特別高。這些人多半是主力，是比較有能力的，但是個性往往也比較惡劣一點，就是要贏。只有一個人強勢，那問題不大，如果只有領導人自己個性強勢，那不會產生什麼麻煩，也不會製造效能上的浪費，但，如果強勢的人不只一個，那情形就不一樣了。會吵架。而且是沒有營養的吵架。正因為邏輯思考的工作內容彈性很大，怎樣都可以說對，這個一吵起來，那就是沒完沒了。常常是到分出勝負為止，勝者留，敗者走，而這勝敗往往不取決於團隊目標的有利，而是取決於政治手腕的好壞。這樣的鬥爭容易腐化組織。鬥爭的過程中的確是激發了巨大的能量，只不過很可惜，很大一部分都化成了情緒，角力的這些人高度的投入多半都沒辦法轉化為實際的績效。知識工作，強勢是一種需要謹慎看待的危險個性。

　但其實，這種個性強勢的好勝小朋友算是相對容易處理的。這些人多半有高度的成就動機，也有衝勁，而且既然會一股傻勁的爭到底，個性上多半還算正直的。只要應對得當，這種人是很好用的。

　應對知識工作團隊中的問題人物的時候，基本的心法就是天之卷裡頭提到的生之道。就把這些人當成是RPG遊戲裡面的主人公同伴一樣的培養就好了，自己當主人公呀。要讓好勝的人變得更強大，變得更成熟有智慧，這些人才會有戰鬥力，這些同伴算是成長潛力高，但當下還有很大開發空間的強力夥伴，只要適當的引導，就能創造很大的影響力的。他們缺什麼？這分眼前的立即需要心理滿足的需求與長遠的真正獲得成長的成就達成的需求。兩者都是需要的。如果不馬上給他們贏的感覺，他們就會爭個不停。如果只一味讓他們爭眼前的一時意氣得逞，那他們就會永遠長不大，只會製造麻煩而已。先問自己的態度是什麼。如果很討厭這個人，還是別對他太好了，如果不是那麼討厭，或許可以互相利用一下囉。讓他們變強，團隊就會增加寶貴的人力資源了，當然你的自信要夠，要是怕被這些人比下去，不想被他們踩在腳底下的話，那無論如何是無法互相利用的，只能互相阻礙而已。

　第一個要點就是不要爭執。讓他們贏。但要設一個局，讓他們雖然贏了眼前，但卻在你的布局之下，依照你的計畫前進。口頭上的爭鋒可以稍微讓他們一下，給對方一點小肯定，如這也挺有道理的這樣。用一種好像是理解的態度，先認同他們可能不太成熟的問題意見。如果這個問題是不能忽略的，不是無所謂的雜事，那麼問題仍然要處理。用在先以認同取得對方的信任之後，用不經意的問題讓對方自行找問題的答案吧。就當作自己照著對方的思路在想事情一樣，但剛好碰到了那個不能迴避的關鍵問題，詢問對方，有沒有什麼好辦法呢？對方如果真的是夠好勝的話，那他就會認真的思考與解決問題的，解決他自己製造出來的問題了。只要幾次，他就會感受到你能帶給他的好運，信賴加深之後，對方通常也就不會那麼固執了。只要有台階可下，好面子的人其實還容易處理。

　第二個要點是要引誘對方自行思考其他的可能性。如果對方還沒有意識到這個問題，和他爭辯，無益。甚至有時候，讓對方犯一些無關緊要的小錯也無妨，好，雖然我覺得應該那樣做，但你應該有你的理由，就先照你的意思處理吧！對方如果不能自行發現錯誤，就很難有機會去正視問題。要製造爭執是很容易的，要被爭執拉走注意力也是很容易的。要冷淡的處理這種戲劇情節，讓對方有機會思考，甚至頓悟一下自己的想法是否有所失誤，要給對方一點空間，一點面子與尊重，而且在對方失敗的時候不要乘勝追擊，要給對方重新整理振作的空間。如果他的關注重點不在你認為的重要問題上頭，和他說再多，爭再久都不會有效果。就算你有東西能教給他，也要他意識到這是值得學習的，是他需要的，他才有可能會學習與學會，否則只是單方面的白費力氣而已。

　第三個要點是，需要拉出什麼才是重要的這個議題，讓他思考。啊，你說的這個很好，不過我現在比較關心的我們團隊設計的系統能提供管理者多少價值耶，你覺得如何呢？這種個性的人，只要引導對方向有挑戰價值的好目標去看，就有機會讓他跳脫小打小鬧的小格局。畢竟，爭執的議題常常都是無關緊要的，反倒是爭執本身對團隊造成的傷害還比較需要注意。其實到底什麼才重要這個議題是常常被過度忽略了，反正複雜的專業工作總是找得到事情可以忙，總是找得到話題可以炒，這個根本問題反而常被晾在一旁。只有思考這個問題，才有機會引發創新的思考，才有機會創造新價值。其實工作可以不用那麼累，也能創造更多的價值，當然起點是再思考到底價值是什麼！在格局上要站在制高點，別跳下去淌渾水。畫面應該怎樣一點，流程應該要在哪裡放什麼管控點，這些很容易讓人注意的議題未必真正是重要的任務，