鳥毅想要說服主管推行 review 的計劃，喲哪桑學長提了一些建議可以供鳥毅參考，不過我認為要說服主管不是一件簡單的事，如果沒有樣學長那樣的辯才無礙，反應敏捷，可能很難畢其功於一役，不過這個 argument 倒讓我想起了丹娜左哈爾的服務型領導者的概念，也就是仰賴機會與才能不如創造內在需求。
記得在多年前在做李國光老師所教授的策略知識管理課程的期末專題報告，題目是某科學園區的實務社群時，過程中學到一個重要的觀念，就是推行任何的計劃，與其告訴別人他需要什麼東西，不如創造他的需求。這真是一個 key point，對於工程技術背景出身的我而言，向來習慣先提出解決方案，結果常常費盡了唇舌，卻還沒有辦法讓人家採納我們的意見，甚至造成許多不必要的誤會。因為我們不知道對方真正的需求，卻天真地以為我們的解決方案可解決一切問題，我們所做的只不過是誘導對方採納我們的意見而已。
閱讀全文
在哈米尼斯的天空看到〈專案管理：Change Management〉，作者提到軟體專案 change management 的重要，而對於專案無法掌控的部分，引用《與熊共舞》這本書所說的可以向上丟給 sponsor 或運用專案假設來限制它。但喲哪桑學長卻認為：
「不要被自己的假設所矇蔽，也不要被其所愚弄。記住，所有的假設在被證實之前，假設既不是對，也不是錯。假設，就只是假設而已」。
我蠻認同學長所說的。沒錯，假設往往是風險的主要來源，在專案風險管理中，最簡單而且最常拿來做風險分析的工具便是敏感性分析，它是用來評估當專案的假設與限制改變時，對專案的影響會受到多大的衝擊。所以不能過度依賴假設，假設是需要被管理的呀！
閱讀全文
看了喲哪桑學長寫的〈誰來檢查code?〉，又看了相同主題的「多人大辯論」，心中感觸頗深，大家的論點都圍繞著用 software inspection 來找出程式的 bug ，但這其實並不是 software inspection 的最大價值，因為 software inspection 不是只有檢驗而已呀！
雖然 software inspection 可以發現程式碼的 defect，但它卻不適合拿來做 QC，為什麼呢？因為用 software inspection 來 QC，其實是在殺雞用牛刀。software inspection 的主要目的是促進 team member 共同成長，不要被 inspection 的字面意義誤導了，切記 software inspection 的過程比結果還要重要。
以 TQM 的觀點來看，品質不是檢驗出來的， 而是不設計出有缺陷的系統，然而不管你的設計能力有多強，都不能保證我的設計絕對沒有問題，因此在這種思維下，全員參與是一個好主意，因此讓同僚參與 review 工作產出可讓系統更完善，一來可以用比較客觀的方式來確認設計符合需求及使用者需要，二來也可以讓同僚更清楚我們在做什麼，相互觀摩學習並增進團隊的效能。
閱讀全文
看了學長所寫的〈Stakeholder 還有誰?〉之後，也想提出我的看法與經驗。學長提到：
那些不希望專案成功、甚至會扯你後腿的 stakeholder，該如何處置？難道說，大家都這麼走運，遇到的人都希望你的專案成功嗎？
這是一個關鍵問題，也常出現在 PMP 認證考試的考題中，它的標準答案是請 stakeholder 涉入（involve）專案的規劃（planning）。涉入（involvement）是一種心理狀態（a psychological state），而參與（participation）則是具體表現的行動（action）（Daniel Robey，1994）。邀請對方涉入然後讓他參與規劃代表我們重視他的意見，仰賴他的能力，而這正是 team development 過程的目的，讓 stakeholder 貢獻其所長，key stakeholder 的參與可以提昇其滿意度而降低專案風險，可說是最好的做法。
木星又再一次進入人馬座了，與12年前所不同的是前次乙亥年木土成刑，而今年丁亥年木土卻成三合相位。木星的幸運不再像上次受土星所壓制，而是先前努力今年可望收成的一年；然而開春時盤的行星相位卻多刑衝相位，只有木冥與土星兩三合相位，顯見以今年的年運而言，掌握正確的方向十分重要。
丁亥年開春時盤，以2007年2月18日零時起盤，命宮為天蠍座，宮內有木星與土星成三合相位，與水星及天王星成刑，看來今年還是多意外，因此行事應多採謹慎保守的態度，做任何事都應有萬全的準備及縝密的規劃為宜。
二宮主財，宮頭在人馬座且有冥王星落入，冥王星的極端將加強人馬座在經濟活動的擴張現象，但冥王星刑金星，應小心合夥關係的生變，及孤注一擲的過度投資，除了做好風險控管之外，必須要有明確的目標與做好整體規劃。
喲哪桑學長在〈顧客永遠是對的．所以我是對的！？〉中提到了軟體文化的獨裁政體的恐怖－恐怖的不是獨裁者的不夠英明，而是沒有人知道獨裁者不夠英明。
這段話剛好讓我想到我之前寫過的〈容忍異端的文化〉，在組織中，如果有獨裁者存在，他自然不能允許別人有和他不同的意見，一旦發生，就會想盡辦法打壓對方。然而，獨裁者不會承認他是獨裁者，他會用一些冠冕堂皇的理由來包裝他的打壓理由，正如喲哪桑學長所言，那個產品經理以客戶的代言人自居，因此他可以順理成章的取得正當性，而這種正當性可以讓他為所欲為。
依據弗洛姆的理論，在民主社會中，人們有逃避自由的傾向，因為他們對要為自己行為負責任會感到焦慮，於是甘願把主導權交出去，重新去依賴及屈從他人。而逃避自由分為三種行為機制來表現－集權主義、反社會行為及自動從眾。
所以對一個以軟體開發為主要任務的專案團隊而言，一個沒有辦法接納團隊成員有不一樣想法的人，就會形成一個無法容忍異端的文化，而在這個文化之下，主導者建立集權主義，「保護」他的子民，而他的子民只要能放棄自我的理想自動從眾，就可以在這集權中心好好地安身立命，然而對於領導中心不滿的人，則會藉由反社會行為來表達不滿，甚至極端者會有不乏毁滅性的行為。不管是那一種角色，其出發點都是在藉由依賴、屈從他人來抒解無助的感受，但把心理的焦慮壓抑下來，並卻沒有真的解決問題呀！不能容忍異端的組織是很難會有創新發生的。
看了喲哪桑學長寫的〈Rule of Thumb in Program Log〉，他說：
程式 Log 的好壞，與軟體開發週期長短有關，也與軟體維護成本有關。
Log 真的很重要，但站在 architect 的角度思考問題，必須考慮多重觀點；所以，我會思考開發人員不寫 Log 的問題是動機問題還是能力問題呢？
如果是動機問題，我想學長的一番話可以激勵開發者，然而如果不單是動機問題，有時候沒有動機是因為能力問題所導致的呢？
「我也想寫 Log 呀，可是時程那麼趕，寫 Log 會增加我們的工作量，Log 可以等以後要 Debug 的時候再寫，先把功能寫出來比較重要！」
開發者的考量也有道理，要解決這個問題，我們應該想辦法讓 Application Log 更容易實現。
最近有人找我討論專案中日誌功能的整合問題，他認為以 log4j 實作的 Logger 已經完成了，所以系統後端的 service 實作應該直接呼叫到這個特定實作。
不對吧！依據我們系統的架構，任何的實作不應該相依到其它的實作，而是讓有 log 需求的 service 實作擁有一個標準的 Logger 界面，不管以什麼方法實作你的 Logger，只要實作這個標準的界面就可以不讓 service 實作被另一個實作來綁住，這是我們的鬆綁策略，一直以來我們就是這樣做的呀！原來用 console 的 SystemOut 實作，而現在只要把那個實作抽換掉，因為我們用 springframework 來做反轉控制，所以連 Factory 程式都不用寫，只要設定 context 把 Logger 的 bean 應對的 class 換掉就搞定了。
可是對方似乎很堅持，認為用注入的方式太複雜了，他想要用靜態連接，只要用一行程式就好了，不用設什麼設定檔，也不用宣告 attribute 及實作 setter 及 getter。
我發現再這樣討論下去，問題好像會失焦喲，於是問道：請問現行設計有什麼需求不能滿足嗎？對方回應：可以滿足，但這樣作很複雜，程式不好寫，因為…。其實我不想聽他解釋，為什麼？因為既然需求可以滿足，就沒有必要改變我們的設計，他想要做的事是以特定實作來主導設計，而不是面對問題來調整設計，既然要用這種頭痛醫頭，腳痛醫腳的做法，那就不需要架構的藍圖了，而可憐的對方他其實是NPS（No-Problem Syndrome）－沒有問題症候群（Gerald M. Weinberg，1986）的患者，而且似乎病得不輕。 閱讀全文
在我看過同人的文章後.
我覺得他的等級非常高,大概有外太空這麼高.
在外太空這種地方,什麼都沒有.
其實我還蠻高興喲哪桑對於我在〈內行人看門道，外行人看熱鬧〉的意見有正面的回應，距離神通高鐵開發團隊，我可能比喲哪桑近了一些，雖然我也沒坐過高鐵，也不屬於高鐵專案成員，但是網路上的言論卻讓我發現，很多人都在不了解狀況下來做評論，這是很危險的。當然，如果立場互換，我的反應可能也會一樣。然而，我觀察到這一點，為文除了自我警愓外，也想藉此做個提醒，有時候我們的觀感可能只是誤解，因為我們沒有看到事情的全貎。
總之，藉由這次事次能認識一個學養豐富又心胸廣闊的朋友，也算是好事一件。喲哪桑說我所引用的參考文獻他也有，真巧！我猜可能是因為我愛看的書和喲哪桑很接近吧，他寫的其它文章一看就知道，呵呵～也是溫伯格書籍的讀者。
看了喲哪桑對我的觀點的感想，我也有一些看法想要表達，於是提出來供大家參考。
喲哪桑所說的 Stakeholder Management 是 PMBOK 第三版新增加的流程－Manage Stakeholder，在 PMBOK 2000 版並沒有這個專案流程。前一版本雖然沒有規範出管理 Stakeholder 的流程，但它卻有提到「專案管理團隊必須識別出 Stakeholder，發掘出他們的需要與期望，然後管理及影響他們的需要與期望以確保專案能夠成功。」，所以管理 Stakeholder 的工作其實是分散在各 Knowledge Areas 的流程中的。而由 PMBOK 第三版把管理 Stakeholder 明顯地寫出來，就知道它的重要性是與日俱增的。
PMBOK 認為識別出 Stakeholder 是格外困難的，到底專案 Stakeholder 是什麼呢？只要是主動參與專案或他們感興趣的事情會對專案的產出或成功有正面或負面的影響的個人或組織。範圍相當廣，不過，當 Stakeholder 的意見衝突時，要以專案的客戶為主，也就是說為了要滿足客戶，其他人的需要及期望都可以被放棄。要在那麼多的不同中找出最接近的解決方案，是專案經理的主要挑戰之一。
以上是管理 Stakeholder 的原理及原則，而實務呢？據我所知，神通大型專案都會管理 Stakeholder，在專案會議中會與客戶討論重大議題並維護 Issue Log，並且會回報給 PMO 以利後續管控。在會議中，專案團隊會與所有 Stakeholder（包括客戶、使用單位及顧問）就議題討論、溝通、協商與談判，如果遇到難題（例如某些 Stakeholder 不肯退讓或專案團隊不該妥協時）會先跟 Stakeholder 保持和諧關係，會議結束後再由專案團隊討論對策後才回覆 Stakeholder，必要時請 PMO 或 Sponsor 出面協調。所以神通在專案管理方面是很重視 Stakeholder Management 的。 閱讀全文
