溝通夠了嗎？-303 經理人的溝通方法學課程有感

「蔡桑，我們也合作那麼久了，就不要因為XXX專案經理的無能與無知影響到您跟這個案子…」在這【303 經理人的溝通方法學】的模擬案例中，肥蝦用這博感情的方式試圖去與SA溝通，嘗試解決因為PM與SA無法合作導致專案的困境。

2013年2月3日肥蝦參加了吳君瑤老師授課的【303 經理人的溝通方法學】，在這一天豐富的課程中，吳老師的二句話深深切入肥蝦的內心，「溝通上的挫折都來自於嘗試說服別人。」「人們溝通都急於解決問題。」正如課程中的重點闡述：人們大多落入極度<解決問題並控制管理>導向的線性思考(設定目標à擬定策略à執行與監控à思考與修正à重複執行à進度與達成度)。為了解決迫在眼前或可預見即來的問題，因此我們進行溝通。就如老師所言，在尚未與他人充分的分享訊息與瞭解感覺與觀點前，我們就跨越了溝通的界限進而去輔導、激勵、管理或領導。在未完成溝通前，就積極與努力地嘗試去說服別人接受自己的想法、立場、態度，要求他人採行自己以為可行的作為或不作為。這些反而可能落入了積極解決表象的問題，而忽略問題深層結構的原因，並可能引發更多「人」的問題。

坊間有不少討論或講解溝通的書籍，就因為溝通常常無法盡如人意，所以溝通書籍與課程一直就是一門顯學。雖然大家都知道傾聽是溝通的前提，但在面對溝通的成本與問題的壓力下，又有多少人能真正捺下性子，沒有預設立場的去傾聽與瞭解？但反向地說，如果沒有既定的目的與要求，又有誰願意與特定或不特定人士進行「無謂」的溝通？親子溝通，不就在渴望子女能按父母的期望成長下所為的溝通！專案溝通，不就在期盼達成專案目標下所進行專案執行的溝通！但溝通的真正結點應該是那「期望」與「目標」是單方面的意願？還是共同的願意？雙方是否已瞭解那「期望」與「目標」？

在諸多的專案管理或管理之中一直強調專案管理者或經營者藉由各種正式或非正式的活動，闡述群體的目標，擬聚共同的共識。但因著成本與時程的壓力，誰又不盼望能像郭台銘先生一般擁有那號令天下方式的「溝通」！因此權力、權力與權力成了溝通者首要爭取的目標物與訴求；對於如何開放心胸，以及爭取大家良善的建言，反成了溝通的附屬或衍生物品。大多人心中所想的溝通是要如何改變他人、改變被溝通者。就如老師課中一再提醒的，溝通只有對人不對事，沒有對事不對人。

人是主觀的，人的行為多是來自於以往的經驗深入思維模式的直觀反應，或是經由假定à認知à結論à感覺所觸發。因此如何進行深入溝通者與被溝通者內心思維模式，又或者假定à認知à結論à感覺過程的溝通，獲致溝通的真正目的－傳達彼此的真正訊息、感覺與觀點。因此溝通是需要準備的；溝通是要明確的；溝通是要求天時(時間)、地利(空間)、人和(組合)的；溝通是要能理解與評估的；溝通後是要能確認與回饋的…這些都是溝通所要具備的基本要項。記得在PMBOK第10章有一個溝通基本模型，正附和了吳老師課堂中所要求溝通所應具備的要素與條件。

課程中諸多的模擬案例經由與課成員間的互動，也展現出不同個人在實際身處的環境與公司文化中，所塑造出的個人反應與作為。經由彼此間的學習，瞭解了溝通在主題、時間等框架的設定，在降低被溝通者的戒心，在營造溝通的環境，在脫離溝通頻率如何暫時中止溝通等等作為與方法上，如何與自身的經驗中取長補短。

溝通是一門藝術，是一門生活中無時無刻進行的活動，「強人所欲」、「強人所難」這不是溝通的要旨；如何改變自己預設的態度，如何精準拿捏溝通的立場與成本，如何有效營造良善的溝通平台與環境，如何創造與建立共同參與者的共識與優先順序…這都是溝通者要學習的課題與平時要努力的目標。

【303 經理人的溝通方法學】是一門不錯的課程，在老師的引導與學員的互動中，可以獲得意想不到的收獲。

人生與賽局

除夕當天下午三點肥蝦竟然有了個半日閒，就跑去誠品忠誠店逛逛，好久沒有這樣一個人可以獨自享受這書香的氣味與優閒。這三個小時的時間肥蝦買了三本書：「伊莉莎白」、「囚犯的兩難」、「偉大經濟學家薩繆森」。

其中這「囚犯的兩難」這一個有名的賽局理論範例，記得在大學唸經濟學中老師也有特別說明；雖說在研究所，肥蝦則因自認數學基礎不夠不敢修讀，但同學間私下也多少討論了一下；出社會後也買了些社科讀物，初淺進行些閱讀與瞭解。

賽局理論在馮紐曼與摩根斯坦出版了「賽局理論與經濟行為」一書後可說已成為經濟學與社會科學中的一門顯學。從亞當斯密的完全競爭，到後續的寡佔理論、雙佔理論，漸漸的經濟學已把對手的可能策略與因應作為生產者生產決策的變數之一。除了賽局理論外，像SWOT或決策樹等分析工具也會分析競爭者的目前或未來的可能行為，但以數學或邏輯的觀點來看，都不似賽局理論複雜。肥蝦以為賽局理論係在特定的目標與範疇下，假設局中人都是理性經濟人之下，經由與局人策略的猜測、判斷與可能得失的機率中，強調從動態的互動中尋求可能的均衡解或者無解。

隨著人生的履歷與成長，對於賽局理論的生活應用也有了不同的看法！賽局所設定的目標與範疇，參與的人員或團體，自身的立場與態度，在生活的現實中都難以像個理性經濟人有著一致性的行為動機與目標；與局人也是難以明確界定或設定，就像那天龍八部中逍遙派蘇星河應師命為了清門戶廣邀天下英雄破解的珍瓏棋局一般，除了原先設定的與局人外，也可能來了些不速之客，最後的結局還是那讓心懷善意的傻小子虛竹獲得最大的利益(雖然蘇未獲致賽局的最佳解，蘇星河也未獲致個人的最佳利益)。

但不可諱言的，人生就像是由無數個變動的賽局組成，局中有局，局外有局，局內有局，局局相生，局局互衍！身為識見有限、能力有限的個人，在家庭、親情等人際關係的制約下，在財力、物力等實質資源稀少的狀況下，一個人所能作為與因應的策略與方法實是無多，感覺上是處處受人擺佈，就像讓傀儡一般有那萬千的細縷纏繞著周身。好似肥蝦去年經歷了訴訟專案獲得轉機(難得有IT軟體專案乙方於二審中獲得轉反)、公司歇業(從三十八年後第一次官股公司破產)、專案中止(因公司無力為繼)…這些困局就算肥蝦個人盡一己最大之力，也難以竟其全功。個人在整個局中是那麼的微渺；與局的團體、組織與人員是如此的複雜；賽局中除了所設定的目標與範圍外，每個與局人的私利與賽局的得失又是緊密的關聯。千萬絲縷互相糾結纏繞，有能解、不能解的；有可解、有不可解；有活結、有死結；有一結動全局的，有旁生枝外結。在眼見局中的一切一切恍似無解之際，所有的時點都必須有為或不為，時刻都在經歷Kahneman在「快思慢想」中所可能經歷的兩種思維模式的一種或兩種：系統一的直覺式思考與系統二的邏輯式思考；有時也依賴那所謂群眾智慧。設法從大局中切出小局，釐出每結的從屬，辨別與猜測不同人的利益，瞭解每個人的立場態度與能力，這些都是局中自己在進行策略思考所應盡力之事。

"Three rules of Work: Out of clutter find simplicity; From discord find harmony; In the middle of difficulty lies opportunity."這愛因斯坦的睿智之言，肥蝦在經歷了去年一年的困頓與挑戰後有著更深一層的體會。Simplicity(簡單)、harmony(和諧)、opportunity(機會)是如此地困難，但又是如此的重要。只有在自己明瞭並釐清之狀況下，才能提綱挈領的簡單自己的想法與作法，也才有進一步說服自己或相關利益之人採行可能的賽局策略；在人人殊異的利害之中，惟有設法產生和諧的氛圍，方能提供賽局進行的環境；在困難多變的賽局中也只有不斷尋求可能與可行的機會，方有達成目標的可能。雖說謀事在人、成事在天，凡事雖不能無往不利，也無法每戰皆勝，人生也不可能一路順遂，但也懇望經由自己的努力、學習與奮鬥，期盼能稍立於不敗之地。

學而知Localization-參與「一日專案經理模擬營」有感

今天參加了B&J開的「一日專案經理模擬營」課程，朋友說：「都在當PM了，還去花錢上一日專案經理模擬營喔！」上過課後，肥蝦可以理直氣和的說：「是去度假休息，兼溫故知新呀！」

今天的同學除肥蝦外，還有五人分別來自製造、軟體產業，因著產業屬性與公司文化的不同，大家經由課程的參與交流，更可以省視自己的問題與關卡。這一天的課程讓肥蝦感觸最深的就是：「學而知Localization」，何為？

在肥蝦所處的環境中，幾乎專案經理被要求的最重要職責就是「如期收錢」。專案管理所標榜的「如期、如質、如預算」，在現實中變成了「收錢、收錢、收到錢」，公司對於專案經理的惟一殷盼就是專案收到錢(還有少花錢)。專案經理在上有老闆、客戶，右有業務、部門主管，左有成員、協力廠商，動作之間受到整體社會與公司文化的拘束，因此一心一意只記得：「減少被責難，設法收到錢」，如果行有餘力，試圖進而作到「可以被肯定，如期收到錢」。就因為只顧慮著錢、錢、錢，一心想著專案目標、執行策略、作業戰術、保護合約己方權利，蠢蠢記得逢迎老闆與客戶、跟業務與部門主管協調資源分配、努力催促成員與協力廠商達成進度，卻常常忘了專案管理的核心與基本面－五大流程、九大領域。

「一日專案經理模擬營」最後Bryan的一句話讓肥蝦深有感觸，「一個專案不管規畫的好壞，專案的範圍界定、資源分配、人力資源協調、後續的持續溝通與管控，是一個專案管理最基本的要素。」在課程的模擬案例中，肥蝦一心只記得怎創造最大的無形與有形效益，如何極大化自己手中與獲取其他部門的資源，如何躲避或減除限制，擬定專案的目標、策略、完成應交付服務項目與提列風險計提金額；卻忘了擬定與甲方間專案範圍的界定及介面規範，忘了安排完整WBS進而配搭現有RBS，忘記了擬定專案作為應考量的base line schedule，忘了設定milestone與檢核點，忘了持續溝通機制建立，忽略了風險項目的鑑別與評估，忽視了procurement的管理。

專案規畫就如PMBOK所說的是漸進式的完善，因此不可能馬上就能完善，因此在拿到project charter後，專案開始的重點是思考面要足夠與立基點要紮實，促進專案成員大家一同思考一同努力共創大家的目標與夢想，協調專案間利害關係人的溝通機制與作業步伐，建立共同工作的ground rule。就像肥蝦常說的：「作軟體的不要拿到案子就只想著下去寫程式。」相對地，「作專案的也不應看到案子就只想著要完成的項目。」忽略了建立整體的鳥瞰圖或者說是大藍圖。

肥蝦作專案斷斷續續也已十年光景，接觸PMBOK也已八年的時間，雖然考過了PMP，五大流程與九大領域也是熟稔於心，但在面對周遭的環境卻只一心想著合約、完成老闆的交代，對於建構專案管理的應有基礎時常忽略。這態度與習性雖說是因著所接觸的環境與風氣而養成，但也實在太Localization，忘了一個專案經理應有的格局。

「學而知Localization」是肥蝦參加此課程的最大收獲，除了一心鑽營專案目標、執行策略與應交付項目外，整體的專案管理基石也要同步考量並設法紮實奠基－明確協調甲乙方PM與單位負責的範圍與交接介面，建立後續持續溝通與互動回饋的機制；建構包含完成專案交付明確項目的整體WBS，布局專案項目與專案管理項目的大藍圖；建立WBS與RBS的交叉矩陣專案組織架構，確立專責人員；建立專案過程的重要里程碑與檢核點；估計風險可能因子與因應對策；注意外購資源與人力的安排與訓練…等，這都是肥蝦應該再加強的部分。

這是的課程相當有趣，成員間與講師間的互動也很輕鬆愉快，課堂模擬只要動動腦筋想想、動動手指打打字，不用顧慮後續真實承受的壓力，B&J也以專案管理的專業角度指導，肥蝦不僅快樂地渡了個愉快週末假期，也認識新的朋友，更能趁機審視自己，接收新知，還可兼拿七個PDU，實在可說相當划算。

化繁為簡-從活動間的依賴說起

在臉書的社團中，好友八樓哥提了一個問題：MS project中，A活動duration=1 ；B活動duration=20 。在B活動開始3天時A就必須要完成。這樣子，任務連結要怎麼寫？我是直接把B切成B1+B2=3+17 ，然後把A設為B2的前置任務，A要在B進行3天時就要完成。A1要在B進行10天時就要完成。所以B的前置任務是A fs-3 B和A1 fs-10 B嗎？

接著，八樓哥又說了以下條件：

條件1.A以及A1的開始跟B有甚麼關聯?? -> 沒關係

條件2.A以及A1的完成條件跟B又有甚麼關聯? -> 沒關係

條件3.A是一個部件到?時間，需要一天處理。

條件4.A1部件是即到即用。

就上述的情境，依據PMBOKGuide，正確的答案應該是【Activity A FS -3 Activity B】，Activity B依賴Activity A，這是非常明確的。

但肥蝦這幾年來在執行專案，設定時程與申請資源調度，有兩點想跟各位朋友分享：

(一)  一個活動不要弄太長，並且中間又陸續整合或串接其他活動。

(二)  雖然依賴關係有FS、SF、FF、SS，但其設定除了絕對的因果邏輯外，還要對照合約，並且要易於說明。

就PMBOKGuide上，說明WBS的Package要以有交付物或可管理的基礎作為單位較好，activity則為執行的活動，並不一定要有交付物，但應以管理為依據。因此以八樓哥的例子，肥蝦一看，A好像是B開始三天後投入物！因此是否B的activity搞的太大了，稍為切一下會不會比較好？

當然，如果只是為了表示符號去切割單位package或activity是不太恰當！如果B不能切割，就該說明來看：「在B活動開始3天時A就必須要完成」，這只有B開始日，以及要求A一定要完成的日子。所以最遲是B開始的第二日A就一定要開始，(A要一個工作天)；此外又沒有其它對A的限制，A的完成條件跟B沒關係。因此保守起見，又或者沒有活動A資源調度的問題，那就讓A與B一起開始【A SS B】。

在PMBOKGuide上也說，FS的關係是最常用的，但是想想：「當活動A完成後要啟動活動B」，對照一下合約！現在台灣的環境有幾份合約會寫說：「簽約次日起三個月內完成需求確認；需求確認完成起三個月內完成系統開發…。」好像都是「簽約次日起三個月內完成需求確認；簽約次日起六個月內完成系統開發…。」又再想想，當向老闆報告時，如果太多的FS、SF…的老闆的反應會如何？如果向部門主管協調人力或資源時，會不會被以「前一項活動都還沒完成，等前一個要項完成了再來討論」的理由搪塞？

記得當the one-page project management剛出來之時，肥蝦也想學學來看看，結果被一位老長官當面批說：「那一頁密密麻麻的，我只在乎合約，以及合約上的milestone。」專案管理的資訊很多，不管以何種方式呈現，重點是在溝通！在溝通過程與專案內部的使用工具或語言可否具有相當的一致性！內部使用要求的具體與週延可否順利並迅速的轉換為外部溝通的簡要與效果！

因此就上述的問題，肥蝦以為當活動A一天可完成時，需要活動B先完成三天的進度，因此風險是是B大於A，加上A  independent on B；B dependent on A,，要是B前2天進度delay了，A進來的效果也有限。此外，若是從合約的主體與溝通的效果來看，A FS -3 B跟 B SS +2 A哪一個較能觸碰人的感知與警覺？因此肥蝦在考量活動之間的關係時，除了實際的依賴邏輯外，也會儘量考量每個活動在整體風險上的份量與合約規範主體，盡量把那些SF、FF轉成SS，然後加上每個活動的duration、寬限期與警示期，尤其是那警示日。

如果肥蝦把此問題的答案由A FS -3 B轉成B SS +2 A~~~也許您會問到：「那到時關鍵路徑如何標示？」CP是那完成專案最長時程，因此理論上就算把依賴關係稍微變化也不會有影響的。也許您又會問到：「那把依賴關係弄混了，就看不清楚那前因後果，看不到可能的專案瓶頸。」專案中的每個活動都是重要的，如果不重要也不會排進專案的範圍與時程之中，因此重點是在於那些為瓶頸活動的瓶頸在哪呢？是該活動可使用的資源有限？還是人力技能不足？還是時間不夠充份？就以肥蝦個人有限的經驗，瓶頸活動的瓶頸重點大多還是在是否有適宜的資源，所以使用SS的方式來溝通，也許能夠給予主管較為深刻的印象，看看是否能在專案初期的組織安排上佔得些許許的先機。

專案的目標在達成專案目標，WBS, Activity, CP, Schedule僅是工具，因此專案的任何作為還是要以合約為依據，以合約規定的方式與設定的milestone來作為專案進一步範圍、時程等等細部規畫。因此些許PMBOKGuide說明的方式，也許在實際專案執行上可以再稍為調整簡化一下。

以上蝦扯一通，純是個人的愚見，還請  各位多多包涵。

軟體開發流程、開發文件與系統程式對得起來嗎？

因著前公司的政治糾葛，肥蝦不得不於10月1日轉移戰場。記得9月27日現在老闆打電話給肥蝦說：「有沒有空跟他去一趟客戶那！」本想說可以接到個新案子，疏緩一下這幾個月來的紛亂。不意去到後發現雙方正為了案子的文件與範圍鬧得不可開交，肥蝦還遭受炮火的轟擊！正所謂吵架無好話，這肥蝦是看淡了，只是這後續如何化解？如何完成專案？才是肥蝦關心的議題。

這個案子的主要爭議點之一就是要交付的文件種類與對文件品質的定義。因著客戶通過CMMI Level3的評審，對於案子文件種類與品質有一定要求；相反的，因著公司(10月1日上任了)內部進行的開發方式與文件撰寫方式，也因一定時間的累積有著自己的看法。因此就造成甲方嫌棄乙方的文件不夠Qualified，乙方認為甲方是變相增加工作範圍，引起雙方的不快，就變成了肥蝦首要面對解決的問題。

針對爭議，惟一的作法就是回到合約主體，看看原有合約到底有哪些條文是否涉及這爭議項目？盡力就合約記載去縮減雙方認知的差距！因為肥蝦不是本案的PM，因此就去請教PM與申請調閱RFP。結果發現了一條：本案專案開發應遵循CMMI相關規定。哇~~~光這一條，至少就得增加成本30%以上！因為本公司並沒採行CMMI，美其名可說我們Follow的是Agile software development，光就這文件的提供不啻要有專人負責，也要配合開發過程逐步產生才行。

因為甲方已經接受了先前第一、二階段的需求分析書、系統分析書、測試計畫書(雖然對方PM是諸多抱怨與覺得委曲，但木已成舟)，因此肥蝦首要的就是設法達成雙方對系統設計規格與程式規格文件的撰寫要項與內容。甲方PM是很有誠意設法完成專案目標(先不論對專案開發範圍的要求是否雙方都能接受！)，因此經過幾次的會商，就甲方提供的樣本進行討論與溝通，雙方作了部分的妥協，肥蝦就只好耐著性子、硬著頭皮，就程式碼回頭來寫相關文件。拼了一個月，經過三、四次的磋商，掰出了三十三份的程式規格書，以及系統設計文件，交付給甲方審查。至於第三階段，肥蝦就能本著自己的想法進行撰寫，但是光桿司令一員，也似無多大作用啦!

在軟體開發與測試流程，從需求分析、系統分析、系統設計、程式規格、程式碼，到對應的測試計畫、測試實例，有著一般普遍接受的V模型。

圖片來源：http://arithmandar.blogspot.tw/2009/08/v-model.html

另外，就物件導向開發文件，UML定義了十種圖示文件：使用案例圖(User Case Diagram)、類別圖(Class Diagram)、物件圖(Object Diagram)、順序圖(Sequence Diagram)、合作圖(Collaboration Diagram)、狀態圖(State Char Diagram)、活動圖(Activity Diagram)、套件圖(Package Diagram)、元件圖(Component Diagram)、部署圖(Deployment Diagram)。其中套件圖不是UML正式規定的圖表，而使用案例圖因為太過簡約，也多會配合使用案例文件。

以上各圖表的定義與使用，網路上與市面上均有各樣的資訊提供，肥蝦在此想要說明的是：文件、開發流程與程式間的對應，如何與實務間進行協調，達成一致性的要求，並且有助於後續系統的維護與開發。

就肥蝦所接觸的現況中，台灣除了資本雄厚、稍有制度的軟體公司(這可跟他們有沒有獲得CMMI或ISO認證無關)，一般多在確認需求分析後，程式設計師就著手Coding，開發所需的系統分析與設計等文件，因為在專案合約多未載明交付時程，都在驗收的時候在拼命補，搞得人仰馬翻，寫出來的文件也跟實際有著相當大的差距。甚者，因為每人的開發與coding習慣不一，文件寫得更是參差不齊，搞得一本多綱，連那目錄都難以統合。

就肥蝦經歷與合作過的廠商夥伴而言，基本上純外商的文件在就定義與內容上均優於本土化的外商；本土化的外商又多優於純本土廠商。若只就台灣設有分公司或公司的廠商而言，不可誨言的，I18M的確是較優的，其它有些廠商雖然也有詳細文件，但系統分析或設計文件，應該比較像是既有系統的說明書，多無法實際反應出客製化過的系統，更難以反映出系統從分析、開發到測試的過程。

在系統開發過程中，每個人對於系統文件與圖表的作法均有自己的偏好或公司的規定。肥蝦個人，習慣上喜愛使用案例圖與文件，流程圖或泳道圖(可能是因為一開始肥蝦是從程序式語言Cobol入門)，系統模組架構圖，操作畫面輸入/出示意圖，資料庫的ER圖表，模組內的程式設計文件(如果是物件化程式就改以類別圖)，並且針對每種圖形，再輔以表格說明。

由於肥蝦是非資訊本科系(後來唸了個世新資管在職碩班，還沒畢業，對不起指導教授ㄚ！)，對於【人】的角色與定位，在系統開發中非常強調，也很在意與專案成員的分工互動中，介面的界定。因此，就一個新系統的開發，個人習慣性的步驟會是：

(1)使用案例圖與表：界定使用者在系統中扮演與操作的角色與定位。

(2)流程圖或泳道圖：界定使用者的作業啟始到結束狀態，其間的系統處理過程，以及與其他使用者的互動。

(3)模組架構圖：界定系統處理過程的區塊切分，以及其間溝通的介面。

(4)用FrontPage畫個使用者介面輸入/出示意圖：確認使用者操作的輸入與輸出要求。

(5)資料庫的ER圖表：界定系統資料存放的方式與儲存的本體，以及配合系統流程的狀態轉移所要配合的儲存資訊與資料。

(6)就每個模組再進一步寫出程式設計文件：針對系統模塊負責的處理要項，明確對應資料庫的表格儲存。

(7)最後就整體系統繪製系統流程圖：界定細部的系統處理與資料轉接過程。

在遞次撰寫文件的過程中，也能不斷的發現問題，回頭審視上一層的文件，進行修正。至於程式規格，就請程式設計師在Coding的同時，根據個人的實際作法，把相關的細節增添進程式設計文件，成為程式規格書。因此肥蝦在進一步查看同仁的程式前，習慣上會要求讓我先看他(她)們寫的規格書，如果覺得可疑，再進一步去看程式碼，利用文件來QA程式碼的品質。

古諺有云：「大軍未動，糧草先行。」對應到系統的開發，至目前為止的經驗，肥蝦也深信：「程式未寫，文件先行。」經由文件逐步取得成員間的共識與反饋。使用案例圖與表，可以取得與使用者間對於系統地位與功能的共識；流程圖或泳道圖，取得開發團隊SA人員間對系統整體的共識；模組架構圖取得SA人員與各開發小組成員間的共識；使用者介面輸入/出示意圖進一步確認使用者對系統的認知；資料庫的ER圖表與程式設計文件獲得程式開發成員間coding的共識與基礎；而程式規格書就用來確認開發成員對於SA(SD)要求認知的回應與實現。

在系統開發架構中，肥蝦以為該簡單的就儘量讓它簡單，最後再就那20%較複雜的作業，思考那簡化單元的串接作法，或再進一步要求其他區塊配合。

在這一次後補程式規格文件過程中，肥蝦就深深體會到如果成員間沒有共識，沒有界定好大家可以自行發揮的範圍，先不論那程式的寫法大家差異很大，只光那DAO讀取資料庫的程式，大家就各出奇招，搞得程式規格實在非常複雜。

系統開發的文件類別，不管在教科書或實務上雖然有一定的共識，但對於每種文件的內容與細節卻是要因案、因人而異，重點在於每種文件的功用，以及誰是閱讀者。如果忽略了文件的主要閱讀對象與其資訊能力，以及他(她)們所盼望從文件中獲得的訊息重點，一份文件不管怎麼寫，一定是大家都有意見的！

以上僅是肥蝦的個人淺見，還請  各位先進多給予指導！在軟體專案的學習中，肥蝦還有很長的路要走、要學，經由您的提攜，希望能縮短一點學習的時間，並且累積更多的能量。

執行中專案的度量

肥蝦今日幫一位好友填寫開放式問卷，肥蝦這位朋友的研究主題是承攬後，或說得標後的專案進度衡量與估算。其實該友已是一位浸潤於軟體專案管理與系統分析多年的專家了，就只為了湊一下訪談人數，只好把肥蝦這濫竽拿來充數；肥蝦為了義氣，也只好厚顏的忝充一下【專家】(好像唸高中同學間為了考卷上的簽名只好彼此充當對方家長一樣)。因為問題還蠻有意思的，因此肥蝦就更無恥的把肥蝦的回應潑到部落格來一同與大家討論與分享！

為了尊重好友的智慧產權,肥蝦就搞了一個山寨版的問卷。

開放問卷的回答

==============

問題一：肥蝦對不同類型的案子是否有不同的進度衡量標準？

回答：沒有針對不同類型的專案訂出不同的標準。原則上採行統一定義的標準，但會根據不同類型給予不同的權數或比重，尤其是對於完工的定義採行不同的百分比法。

問題二：您用的有哪些方式?優缺點？

回答：如果對於程序型的軟體開發專案就以WBS下各Package的完工進度加總後作為衡量；如果是產品客製化的專案，就以完成的交易數作為衡量的基準。

以Package的完工進度加總計算優點是各負責人責任明確，回報容易；缺點就是擔心各負責人隱藏訊息。

以完成的交易數作為衡量，優點是客戶容易明瞭，而且有明確的感受；缺點就是客戶看不到的部分，如：架構、品質…等工作難以反應，易造成給客戶沒有進度的感受。

但以上兩者都有一個重大的問題，就是實際進度的衡量基準與專案預估時的方法與基準不同，對後續新專案時程與成本預估的Lesson Learned幫助有限。

問題三：能反應實況嗎?

回答：應該可以反應實際狀況的百分之七十到百分之八十或九十，實際狀況要視配合同仁彼此間的合作氛圍與默契。比如就以交易數為例，有些同仁認真負責，瞭解交易的目的與重點，進度的顯示會同時真實反應品質等問題，而有些同仁的作法就有可能增加後續的修改時間。

問題四：影響進度度量的因素有那些？

回答：就軟體開發案來說，個人以為最主要的還是人的問題。

從一開始的Initial階段，參與人員的經驗是否足夠？參與人的是否明確研議招標書，審慎評估專案的風險，研議合約？對於合作的廠商與專案人員是否有正確的評估？

planning階段參與分析的規畫人員是否深入瞭解User的需求？，瞭解產品的架構？是否真實的反應哪些RFP項目是可能有困難的？進一步負責的擬定分析書與設計書？User參與人員是否全心投入？是否對於提出的需求有明確的認識？並且可以與廠商一同以完成專案目標為前提下，探討這需求是否在合約或RFP的範圍內？

Executing階段，公司主管是否認真看待本案？對於人力與資源的分配給予穩定的承諾？還是常常臨時變更指定人員？負責實作與執行的人員是否能確實研究分析人員開列的文件與要求？真實的陳報開發進度與反應問題？

Monitor時，最擔心就是怕因應公司或內部主管的想法就要求變更專案進度與文件，甚至管控方法與記錄？或者主管對專案不明瞭，對於專案的範圍、成本、進度與品質等要件有自己的看法？專案成員是否私下進行承諾？

在Closing階段，比較麻煩的就是先前各階段的人員是否真得write down下符合要求的相關文件？業主與廠商參與驗收的人員是否與先前配合的人員是否一致？如果人不一樣，那要求與重點是否差異太多？

問題五：那些階段估算容易失真？為何？

回答：一般來說，比較容易失真或出現失真是在Executing階段。其次是Planning階段或所謂的需求分析階段。但是最可怕的是失真問題出現在Closing階段。

就軟體估算來說，最常發生的就是規畫之時受到不同因素的干擾，對於專案範圍或要項有意或無意的疏漏，導致Executing之時還得不斷回頭重新進行分析，更甚者還必須變更整體的架構。其次，就是配合的廠商與人員不如原先的期待，導致增加的時程或成本遠超出原先的估算，更可怕的就是加時程或成本也無法解決，必須重新更換合作廠商或人員。

問題六：有更好的建議？

回答：軟體開發的平台，在目前的環境下多不是問題，【人】還是整個專案問題的核心！是否有足夠適當的人員參與？業主與廠商間的人際互動是否良善，並真實的立基於合約的規範？

目前任何的度量方式如：EVM是用換算成金額的方式來度量，功能點是將專案交付物各要項轉成另一個所謂點數方式，…是依據外顯的特性進行計算與度量。但是軟體專案不似其他土木建案或舉辦party的專案，軟體的特點在於依賴深度的人力與能力，並且一般單一軟體系統專案所交付是一個整體性的產品，各軟體組件間密切相關，難以明確快速替換。

因此，加求度量的方式不是設法強化人的約束，朝向所謂的『工程』導向，如：印度。不然就是設法改善人員的態度，如Google的人性化。期盼藉由人態度的正向改變來確實反應出度量的計算方式。

TOC理論提議了所謂『時間-金錢』計算單位，也許軟體進度度量單位可以設計一個『人性-時間-金錢』的度量單位。

專案經理的十個切忌

最近友人們在臉書上開了個社團，肥蝦想想為了維持該社團的活絡與動力，因此想說就潑個每日話題，有意願或感觸的好友就可回回留言或按個讚。其中一天，提出了男女PM的差異。在大家討論(看得很多，留言的少)中，蔡桑就說他常與男PM發生衝突，並認為女PM比較善長溝通與管理；謝小姐也說：男PM善長技術，女PM專長溝通管理。這讓肥蝦想起自己看得或寫過的一些資料，投射到個人的工作歷程，不禁想說是否男生就不擅長溝通管理嗎？

肥蝦中途轉業進入IT軟體產業，從網路工程師、程式設計師、系統分析師、專案經理…，這一路走來，發現到個人以往成長與工作的經驗常會影響到下一個職位的工作態度與對特定領域的涉入程度(也許就是那「彼得原理（The Peter Principle）」的成因之一)。傳統觀念上認為：男生似乎長於理工，因此對那IT技術較為專長；女生具有文史方面的優勢，因此長於與人溝通。

不管傳統觀念、亦或個人的成長背景，既然專案經理的重點在於專案管理，至少應如PMBOK 2008所述具有：知識(Knowledge)、執行能力(Performance)、個人特質(Personal)。當然如果一個PM俱備了PMBOK 2004圖1-2 Areas of Expertise Needed by the Project Team的(1) Application Area Knowledge， Standards & Regulations. (2) Understanding the Project Environment. (3) General Management Knowledge & Skills. (4) Interpersonal Skills. 是很好，但是該圖已明確標示是by the Project Team。如果專案經理又兼任不同的身份，如系統分析師、架構設計師…當然有對應的角色與工作，但是在執行專案經理工作與扮演對應角色一定要設法減少混雜，在對的人、事、時、地、物下，去扮演好PM的角色。

對於專案經理在凝聚專案團隊與相關利害關係人達成專案目標上，肥蝦以為有幾個切忌可以供大家參考參考：

(1)切忌突顯自己：

PM的首要工作是突顯團隊成員的工作，而不是將光環都弄到自己身上！！！

(2)切忌自以為是：

也許PM出自基層，常會自以為什都懂，而去跨越了其他成員的專業。如果真得擔心，以肥蝦個人的常用作法：就只問問題！讓對方就問題提供回應。

(3)切忌老闆心態：

PM在溝通與協調，不在要求團員要服從自己！團隊要確實服從的是專案目標，因此PM的重點之一為讓大家確實瞭解專案的目標！

(4)切忌跨越界限：

PM在團隊中首要是要建立規則，但忘了自己也要遵守規則，並且要比團員更加嚴苛。

(5)切忌諉過團員：

為讓團隊成形，第一步要建立成員對PM的信任，加上一個專案型組織的PM對於專案本就應負成敗之責，怎能將過失諉於成員！

(6)切忌自我私心：

這也跟第五點一樣，重點就是讓大家能信任PM！

(7)切忌縮頭畏尾：

PM應居於第一線面對相關Stakeholder的考驗與挑戰，PM的責仁在於解決問題與化解危難，只要跟專案團隊與目標有關，PM應以捨我其誰態度勇於面對！

(8)切忌荒怠行政：

很多專案的記錄與Log是專案的重要命脈，Stakeholder聯絡表，會議記錄，管控表，專案日誌，…等這些行政作業雖然繁鎖，但應努力踏實，不可荒怠！！

(9)切忌有失禮儀：

專案經理在於調鼎專案相關之人，事，物~~~所謂見面三分情，場面，情面，人面，應適當顧及，如專案期間佳節將至寄個卡片之類的、沒事問一下狀況…等，這應該作到！！！(更深的禮儀就歸業務的事！)

(10)切忌四體不動：

不要只出張嘴，多動動，多走走，多聊聊，多看看，多接觸…，注意整體的風向！！！

以上切忌，肥蝦以為應不分男女。肥蝦以前當助理時，有前輩指導說：要談事情就"男人喝酒，女人喝咖啡" 。雖說應對進退可用性別優勢，但也要看對方的脾味~~~。比如：美女計、美食計、先小人後君子、以問代答、…，但也要有技巧，並拿捏情況。當使用問答方式詢問團員或相關人，也要看對方或週遭人的臉色變化，當臉色不對，或對方已開始亂套，那就要轉移焦點了，或打哈哈圓場！如果對方是個好咖，那他(她)會回去思考！如果對方是個爛咖，那你(妳)要回去想！畢竟除了(2)切忌自以為是，也要同時注意(9)切忌有失禮儀。