推薦一個不錯的新專案管理論壇

這個論壇剛成立不久，專注在專案管理的領域，感覺也很中立，肥蝦也在其中貢獻小小的版面，還希望大家能多多共襄盛舉！

肥蝦衷心希望專案管理能在臺灣蔚為風潮，在基礎的專案管理與作業上能走向一定的制度與架構；並能傳遞前輩與大家的心智精力，讓臺灣的軟性產業與服務業，能在國際市場上一爭長短！

論壇網址

http://www.pm-i-study.net/dis/index.php

問題，真得是問題嗎！－"你想通了嗎(Are you lights on?)"

本書如同"從需求到設計(Exploring Requriements)"一書，也為溫伯格(Gerald M. Weinberg)與高斯(Donald C. Gause)合著。本書的重點在闡述問題的界定、發掘與陳述，提供了如何去釐清問題陳述的方法。本書與肥蝦先前所閱讀的"發現問題的思考術(Professional Problem Finding)"(作者：齋藤嘉則)有著同工異曲與互補之妙。齋藤嘉則的重點則在分析"未來願景"與"現狀"去找出問題；溫伯格強調問題的陳述與自省。

肥蝦以為溫伯格所強調的問題的循環：問題=>解決方案=>解決方案所帶來的新問題=>解決方案=>解決方案所帶來的新問題=>…。說明了問題是永無止盡與無法百分之百解決的，但是要藉由問題釐清、思考、分析、陳述；進而界定功能、特性、限制、偏好、期望，轉化為可解決方案的空間；轉化為設計，以提供特定客戶與供應者可接受的解決方案；重新追蹤原問題與鑑別新問題；重新不斷地循環，以將期望與滿意度之間落差縮小至客戶可容忍(tolerance)的範圍內。

本書內容區分為六大部份：(一)問題是什麼－定義問題(Definition)；(二)這是什麼問題－問題定義(Analysis-What is the problem?)；(三)真正的問題是什麼－問題溝通(Communication)；(四)這是誰的問題－問題共同化(Analysis-Who has the problem?)；(五)問題是從哪來的－自我反省(Analysis-Where does the problem from?)；(六)我們真的想解決問題嗎－回應到目的(Problem and solution must be return to the business need)。

以下將各部份的重點摘要如下：
(一)問題是什麼
(1)問題是期望與感受間的落差；問題是Expectation與satisfaction的落差；問題是未來的願景與現狀的落差。
(2)解決問題可以考慮改變期望？或是改變感受？還是兩者均設法改變。

(二)這是什麼問題
(1)不要把問題的解決方案當作問題的定義(尤其解決方案是自己提出的時候)，回復問題的原貌，試著用不含解決方案的語意去陳述問題。
(2)你永遠無法確定自己是否已經取得了正確的問題定義，甚到到了問題已被解決！但決不要放棄追求一個正確的定義。

(三)真正的問題是什麼
(1)解決方案引發新問題與不合身，一旦設定任何決定其實就給定了範圍與限制。
(2)問題陳述需要不斷重覆調整，直到問題清楚的進入每一個人的腦袋。
(3)釐清問題陳述的方法：
-按順序強調一個字詞。
-字典法。
-肯定與否定互換。
-強迫語句與可選擇語句的互換。
-所有格的互換。
-頻率用字的轉換。
-籠統字眼的特定舉例與明確描述。
(4)定義問題應回應到真正原始的目的。

(四)這是誰的問題
(1)問題的共有化，解決問題的人必須要跟問題有實際的關聯。
(2)不要急著解決別人的問題，如果他們可以自己解決很好的話。意即要克制自我膨漲的欲望，先設想與尊重對方的立場。
(3)提供別人問題的解決方案，有時不如一個簡單的提醒。

(五)問題是從哪來的
(1)問題基本上都不會是從"自然"而來，但確是推諉問題的最佳藉口。
(2)問題的來源大多跟自己有密切的關聯(53.27%問題是出問題解決者身上)。

(六)我們真的想解決問題嗎
(1)人們很少知道他們的真正需求是什麼，直到你給了他們要求的東西。
(2)到了最後分析階段，沒有多少人真的願意想解決問題。
(3)解決方案絕對沒有所謂的絕對完美，因此不要想著不斷修改解決方案，達臻所謂的絕對完美。
(4)問題解決方案提供者，一定要忠於自我，忠於專業。

肥蝦以書中的一句話：「可以確定的是，大多數的人都認為自己知道問題到底是什麼，然而，實際上他們通常是錯的。」與各位共勉，還請 指教！

推薦微軟的一位技術經理的程式開發專案管理專欄

昨日有幸與一位微軟的技術經理-周旺暾先生見面，看著他名片上的PMP標識，因此上去台灣的MSDN看看，結果到他所撰寫的程式開發專案管理！

雖然專欄內的篇數不多(僅有三篇)時間也稍嫌久遠，但文章的內容非常不錯！
1.成功開發團隊的八項特質 (2005 年 3 月)
2.軟體架構師的成功秘訣 (2005 年 1 月)※第二篇應該是【程式開發工作的時程預估】。
3.談程式開發專案進度管控 (2004 年 12 月)
大家可以上網參考！
http://www.microsoft.com/taiwan/msdn/columns/PMP/default.htm

肥蝦對於【成功開發團隊的八項特質】乙文最有感觸！近來負責的研發專案，由於團隊成員缺乏一個成長與激勵自我的態度，在溝通與願景的凝聚上困難重重！
特別把八項特質列述於下，以供肥蝦與各位先進一同勉勵與參考！
1.促進開放的溝通
2.為共同的願景工作
3.授權給團隊成員
4.建立明確責任並共同負責
5.專注於提供商業價值
6.為了變動, 隨時保持最佳的彈性
7.投資於品質
8.從經驗中獲得學習

Five ways to make or break your team

PM Network Vol. 23, No. 4, Page 53-57.
本篇文張舉出了五個會嚴重破壞專案團隊的五種狀況─(一)失控的會議。(二)隨機變更專案的方向。(三)利害關係人的過份需求。(四)未預期延遲。(五)專案人員的爭執。─這種情況在肥蝦的專案經驗中其實常常遭遇，對於專案的進行，以及專案成員間的和諧，真得有莫大的衝擊。文中提供了一些實務的經驗予讀者分享，個人認為非常具有參考性。因此肥蝦特就文章內容，並對應個人的經驗，分述五種情況的核心，以及可能有效的建議。

(一)失控的會議(Out-of control meeting)：專案從啟始到結束總有不斷的會議要開－kick off meeting, group progress meeting(Daily), status review meeting(weekly, project performance report meeting(monthly), change control meeting, project management meeting…。但經常都是流於形式，參與者大多不知道會議的目的與要求；或是成為長官單向佈達的會議，無法真正的有效溝通，更進而長官們厭倦聽到問題；簡報的資料一再重複，會議資料與實際狀況嚴重脫節，無法真正的反應現況，更進而專案經理或長官玩起數字遊戲，藉由變更計算方式粉飾太平；與會人員雜亂，主題失焦…。這種種的會議惡象，我想很多人都有經驗。

在本文中提供了一些方法試圖杜絕上述的惡果：(1)聚焦：每個會議必需有確定的目標與議題，切忌離題。(2)慎選與會人員：會議人數應適當參與人員須對會議主題有明確相關。(3)訂定基本規則(ground rules)：遵守既定的規則獲取與會人員以及未與會人員的信任。(4)限制會議時間：會議應有明確的起始與結束時間，冗長的會議徒使與會人員喪失注意力。(5)確保會議是雙向(上層與執行者)有效的溝通。

(二)隨機變更專案的方向(Seemingly random changes in project direction)：專案管理計劃最重要的是標明what、when、how、who (why基本上會建議寫在project document)去執行一個專案。因此專案的目標必須非常明確；標明每個特定區間與milestone的重點，專案成員才有依循的努力方向。

但是專案的本質就是【變化】，在遭逢無法避免的改變下，惟有開誠佈公的跟專案團隊說明變更的理由，大家同心合意下，才能化解因為專案方向變更，所導致成員戰鬥力的衰減。試想，如果專案方向經常在成員無法獲知、無法理解的情形下變更，專案成員將會如何迷失工作的方向，喪失鬥志。當一個人不知道今天或以往的努力是否有效的情況下，誰願意去努力達成目標。

(三)利害關係人的過份需求(Overly demanding stakeholders)：在專案的進行中利害關係人(包含使用者或客戶或公司高層)常會無端的加進很多臨時的要求。這不只發生在客戶身上，更常遇到的狀況就是公司內部的高層，常會為了某些理由(如公司管理…)要求專案成員提供相關的資料或報表，更可悲者，還會限定交付時間。

一般的情況下，每個成員在瞭解專案的目標與方向下，大多會擬定每日的工作進度與內容。突然安插的要求，常會導致成員淪落於疲於應付非專案主體的工作。此時專案經理必須有所擔當，除了建立一個暢通完善的溝通管道與流程，應將要求記載於書面，獲致正式的同意，按照標準的作業流程處理；對於不合專案目標的要求，應該要明白的向要求來源陳述事實跟現況，爭取有利與合理的作法；對於不可避免的要求，也要向成員坦誠的溝通，獲取成員的支持。

(四)未預期延遲(Energy-zapping soul-sucking unexpected delays)：專案的任何計劃均無法保證百分之百無誤，難免會有疏漏或執行上有所錯誤，進而影響專案的時程。因此最重要的處理方式就要是向成員充分的揭露，發現問題，戮去解決，保持專案不斷的往前進行；而不是去找個替罪羔羊，想個卸責的藉口。因此在遭遇某些問題或發現疏失，第一步是要向成員主動的說明。再來，就是與團隊中的相關人員商討解決的辦法，凝聚團隊的共識，朝向克服問題與達成專案目標前進。

(五)專案人員的爭執(Team squabbles gone awry)：專案團隊間常會諸多因素引起爭執或紛爭。雖然PMBOK說明要求爭執的雙方先行協商合解；如果無法獲致解決爭端的方法時，再由專案經理介入。但在本文中要求專案經理應立即安排面對面的會談；如果無法解決，接著是專案經理與爭執的雙方依序的一對一面談；如果確定爭執雙方無法在一同合作之時，專案經理應透過上層管理階層留下對專案有較大的貢獻者。

針對上述五種情況，肥蝦認為主要可歸類於專案的溝通管理(失控的會議、隨機變更專案的方向、利害關係人的過份需求、未預期延遲)，以及人力資源管理(專案人員的爭執)。由於專案的本質就是要集聚特定人員與資源的力量，處理變化難測的狀況，達成既定的目標。因此對於專案團隊、公司內部以及客戶，首要的是建立"信任"的關係。

如果客戶能相信您與所有專案成員，都是為了建置一個為客戶設想的系統的前提下，對於雙方的溝通奠定穩固的基礎，在共通的基礎與限制上，雙方才能進行折衝商談，共同追求一個較佳的解決方案。肥蝦至今的經驗還沒有遇到一個案子，客戶擺明就是要您掛掉的狀況。一旦專案無法完成，不只會對vendor side造成傷害，對user side也有一定程度的損失，惟有設法使客戶認清這個事實，才可以有效減少客戶過份的要求。

在公司內部的溝通上，也是如此一旦公司上層懷疑或認定專案出現問題，上層主管將會不斷地想探索專案團隊，甚至每個成員，每天的工作內容與進度。如此一來專案成員會光填寫報告與進度回應將浪費掉無數的寶貴光陰，進而使專案停滯不前。坊間很多專案管理的工具或方法論，但實行的結果往往本末倒置。原本為著加速與方便控管專案的管理流程，反過來變為成員每日的主要工作。因此專案經理應設法強化公司與專案間的溝通，扮演一個折衝的角色，必要時應坦白的向上層反應。說句實在地，如果上層執意如此，並可預知將造成團隊的生產力與士氣蕩然無存，與其委曲求全，不如另謀他路。

至於處理專案成員爭執的作法，每個人基於自身的經驗與瞭解有著不同的作法。個人能認同文中所說：「專案沒有時間可以浪費。」因此先由爭執雙方自行處理可能無法獲得滿意的答案。以肥蝦個人的經驗，會建議由專案經理與爭執雙方一同與會討論。但是會前專案經理應設法私下分別與爭執雙方以及相關的周遭成員討論，設法釐清爭執的"起源"－工作界面不明、專案資源爭取、或個人情緒問題…。不同的爭執原因應有不同的處理方式。如果是雙方個人情緒上的問題，已經無法排解，我會建議如溫伯格(Gerald M. Weinberg)在"從需求到設計(Exploring Requriements )"乙書中所說的讓雙方都離開團隊，以免可能造成留存的人自大的心態。

有效收集需求－"從需求到設計(Exploring Requriements)"

溫伯格(Gerald M. Weinberg)在IT軟體專案管理界是耳熟能響的國際大師，伊寫了一系列的專著，都是專案管理人士的必讀經典。本書為溫伯格與高斯(Donald C. Gause)合著，主要在探討如何有效的釐清客戶的期望，以精確、正確、完整，且保留應有設計空間的去記錄使用者的需求。個人以為每章之後的摘要，敘說why(為什麼？)、when(何時？)、how(如何？)、who(誰？)可說是精華中的精華、值得一再的閱讀與深思。

本書區分為五大部份：

第一部 先有一點共識：語意曖昧(ambiguity)是整個需求要件(requirements)作業的最大問題，因此如何有效的釐清需求，並建立與客戶間的信任關係，是收集需求階段的最重要目標。

第二部 起步的方式：需求要件作業重點在縮短客戶的期望(expectation)與感受(satisfaction)間的落差。在探訪需求之前，雙方均一同假設解決方案一定存在，再經由有效的訪談、找到對的人與群組、有效的會議、不斷澄清與調查，去減少語意曖昧的字句與敘述。

第三部 探所各種可能性：說明經由有效方式，集思廣意去擴大解決方案的基底。

第四部 釐清客戶的期望：逐步以功能、特性、限制、偏好、期望的作業程序，從解決方案的基底，進一步獲致一個合理與認可的解決方案空間。

第五部 大幅提升成功機率：應儘量設法將解決方案的界限與問題加以數字化與圖表化，藉由一些有效的工具─技術審查、滿意度的檢測、黑箱測試案例、與現有產品的比較與區隔─達致雙方一致的意見，雖然承諾繼續溝通，但以獲得客戶有效(sign off)的認可，為一切的後續作業核心。

本書提供了很多有效，而且實用的工具，如：叢群法、決策樹、使用者分類法、功能表、特性表、所值幾何圖(what-if worth) 、期望表、語意曖昧的衡量指標、滿意度測試、黑箱測試案例等等，協助分析人員有效地搜集、彙整、分析，以產出精確、正確、完整，且不失嚴苛的需求文件。

文中也對如何舉行一個有效率的會議(一般的討論會議、激發創意的腦力激盪會議、技術審查會議) ！如何進行訪談！如何進行開放式問題詢問！如何調和衝突！如何界定解決方案的適當空間！均提出不少有用的建言、規則，與應注意防範的重點。

本書也一再強調：收集需求重點，不但在產出有效的需求文件；也在經由建置、研議、探索需求的過程中，獲得重要的收獲，回饋至專案的成功。因此過程與結果是同等的重要。

書中以兩個例子貫穿本書探討的所有主題：一、超級粉筆專案。二、電梯資訊裝置專案。因此對沒有IT背景的人士而言，閱讀起來也一樣"輕鬆愉快"。

書中對肥蝦啟發較大的有：

(1)不可將困難的部份留給他人處理。各人對圖表的解讀不同，務要接受不同的解讀意見；而不可要求齊一意見。並且要確認每人都可以瞭解與使用，相關的圖表與方法。

(2)使用圖表的目的應根據我們現有手上的工作類型，以及希望避免的錯誤(使用工具；而非被工具使用)。

(3)使用者的確認(Identify stakeholders)後應再繼續將其分別群組；並列示產品(product, service or result)對使用者的態度－friendly ,Ignore, Unfriendly。鑑別使用者或利害關係人是專案初期(initial)的重要工作，但肥蝦往往並不會再加以分類；並記錄產品對使用群組應有的態度，以致後續在處理需求變更或相關變更、修正的議題時，迷失的應有的立場與態度。

(4)偏好的度量與以圖形化表達需求、期望與限制。肥蝦非常喜愛作者於第四部份－藉由功能、特性、限制、偏好、期望－這五個步驟，來建立一個解決方案的有效空間的說明。

(5)對於專案決策的分類－選擇(基於有意識的思考判斷) 、假設(未察覺、偏見、資訊不足、錯誤判斷)與強迫(法律、習慣、高層指示)－應加以區別，並寫下原因。以便後續可以追溯決策立基的緣由，檢視其是否已經不存在或異動，以擴大專案成功的可能性。

(6)凍結需求要件是一種妄想，收集需求的最後一個步驟是：雙方同意繼續溝通。但可以進行下一階段作業的前題是：有足夠的同意書(客戶簽字) ，以及有效的需求收集程序。

(7)培養自己以專業做事的勇氣，以及至少要將一半以上的時間花在自己的身上；而不要被技術層面的事務，或為他人進行協調佔據所有的時間。

本書不但是一本探索如何作好需求文件的說明書籍，更可以當作是一本工具書。對應於PMBOK 5.1 Collect Requirements有著幾近完美的闡述，與詳盡的作業說明。

The Global Risk Factor

PM Network, vol. 23, No. 4. Page 34-39

此篇文章一開頭以去年十二月所發生義大利與埃及間的海底電纜斷線，說明目前專案國際間合作模式所遭遇的風險因素與風險考量。主要可說集中在PMBOK方法論架構中的第十二章(外購管理)與第十一章(風險管理)。

由於國際間因為國家間藩籬的降低，以及網路無國界，專案經理為追求預算的最大效益與縮短開發的時程，會考慮將專案的部份工作(task)或工作包(work package)經由採購(procurement)的方式轉移出去。但如果轉包予國外的廠商，就必須考慮到國際間的溝通、不同國家間的文化差異，以及外包商所在國家的國家風險等，不同於一般專案所認知的風險。

該文中所提及的風險，包含供應商所在國家的政治、經濟的動亂到恐怖攻擊、重大公共基礎設施的損害(如本文一開頭所提及的海底電纜斷線。)、當地流行疾病等都應列入考量，並提出適當的風險因應對策(contingency plans, fallback plans, workaround)，以減緩所遭受到的衝擊。其所建議的方式有：(1)一定至少一次的面對面溝通。(2)將外包商結合至整體專案的利益。(3)儘量分散在不同的區域或國家。(4)對於比較重要的部份應轉向成本效率高以及標準高的國家或地區。(5)該國的公共設施是否允許在家工作。(6)合約中訂定服務水準等級與處罰條款。(7)堅強穩固的fallback計劃。

因此專案經理在將自國外外購專案的工作應首要思考：「什麼是可以外購？什麼不應該外購？如果外購的話會附帶進什麼樣子的風險？」而且也要建立一個觀念：「外購也不是經由合約將應有的責任完全轉包出去，而應要考量自己與外包廠商不同但互相關聯的義務與責任。」因此最終的決定，還是在於專案經理的理智與聰明的決策跟判斷！

土法煉鋼出來的─肥蝦版"訪談作業程序"

在建置應用服務資訊系統時，需求分析師或系統分析師最重要的工作之一就是去訪查客戶的需求與期望，釐清現有的作業流程，溝通雙方彼此的意見。因此肥蝦在初步累積了近十年來的經驗與參考一些書籍的方法，土法煉鋼的擬定了一個簡單的訪談作業程序"一個基本、二個希望、三個步驟、一個注意"：，希冀經由這拋磚引玉的動作能獲得更多的收獲。
(一)一個基本：
(A)"採購合約"與"工作說明書"要滾瓜爛熟。

(二)二個希望：
(A)希望工程師可以不用跟(只要能有效掌握需求，並不需要工程師跟，有時兩者間的語言不同會造成更大的問題；而且有可能造成客戶直接跟工程師約定了不當的承諾！)
(B)若非有工程師在場不可，希望要跟我事先先演練或套好招。

(三)三個步驟：
(1).訪談前：
(A)瞭解受訪者的背景、單位、與專案利害的衝突，以及受訪單位在專案中的角色與定位。
(B)瞭解此次訪談目的、牽涉到專案的範圍與重要性。
(C)詳列訪談的重點與預測可能的發展。
(D)事先約定受訪者受訪之人、時、地、物，以及告知預估所需花費的時間。
(E)訪談記錄的標準format。

(2).訪談
(A)約定前五到十分鐘到達與準備。
(B)穿著打扮要得體(注意工程師)
(C)先行詢問可否錄音或記錄
(D)注意訪談的技巧(避免誘導、避免主觀...)與問題的次序性。
(E)受訪結束前詢問是否還有我們應該要知道的
(F)告知訪談記錄交付時間，並請求訪談若有不足或不夠詳盡處，是否可以電話通知或再次見面。

(3).受訪後
(A)快速並有效整理撰寫受訪記錄(受訪記錄的詳細程度與次序應要斟酌)。
(B)先給予會自己公司的內部同事看過。
(C)email給受訪者，特電話告知已寄出，並請受訪者告知記錄中有任何不妥或不當之處！
(D)訪談事項進行分析、歸納，並列入相關的專案議題或追蹤項目。
(E)條列出三到四行的訪談重點email給主管。

(四)一個注意：
對於需求超出合約的部份通常我會如下處理：
(A)刺探需求的重要性跟急迫性。
(B)以客戶角度出發是否有更好的方案。
(C)哀兵政策或博感情。
(D)儘量不當面回絕，會說帶回研究。
(E)針對此點會在訪談記錄作些小小的..。
(F)看程度是否要報告主管。
(G)從其他人再刺探受訪者。
(H)非作不可，那就上呈主管與業務，請他們再去溝通(或要錢)。

以上是肥蝦個人的作法，還請 各位先進惠賜更適當的建議或任何忠告！