前段時間，去看了某間公司自行開發的專案管理系統。

那天會議中，解說的技術人員在台上簡報時，強調的並不是專案中資源管理或是排程等方面的功能。 反而自己先承認在他們的系統上這兩模組不是很強，轉而一直強調以他們開發的觀點來看，他們覺得一般專案真正需求的是並非工作排程、而是「協同合作」的工具。 也因為這樣的思維，他們的系統僅開發了一個堪用(雖然從我的觀點來看，連堪用都還稱不上)的排程介面，而花很多心思在協同合作這領域。 簡報中還舉了他們自身的經歷，強調專案維基(Wiki)、新聞發布(News)、議題追蹤(Issue Tracking)、還有討論區(Discussion Board)等功能才是最重要的。

他們老闆稍後提到：「反正實際上很少人用甚麼實獲值，PMBOK那一套不適合台灣啦！」 「以我自己的經驗來看，專案重要的是溝通。 是溝通啊！ 討論區、Issue Tracking、與共同編輯才最重要！」 也因此，他特別強調「每個專案可以有自己的Wiki區域以及討論區！」然後展示這些功能是有權限鎖定的，除了專案成員以外，別人一概看不到也無法編輯。

我是同意台灣沒甚麼公司真的想用實獲值(也沒那條件用)，也同意很多公司所謂專案管理只是徒具形式，但我不完全認同設計專案管理工具時就可以完全忽略這一塊。 絕不能因此把排程、資源管理、或成本計算的部分隨便做做。 畢竟從我的觀點而言，當任何人想用專案管理工具時，若連專案全貌都無法隨時展現下，那不就根本上的失去了使用專案管理工具的目的了嗎？

至於溝通。 我是同意專案經理需要花很大量的時間做溝通，但對於很多人追求「專案溝通平台」的概念卻常常覺得不可思議。 先說，我不是說溝通平台不好，只是我覺得那是Priority較低的一個需求。 它有太多替代方案可以用，而不需要優先花錢電腦化。

因為就我的經驗而言，如果是真正緊急不可的事情，一般人可能直接且當面的去找當事人溝通。 就算今天是一個分散在各地的遠端團隊，也還有電話、視訊、簡訊、甚至Email這些工具。 在這情況下，誰也不會去選擇「討論區」這種東西。 好吧，若是不這麼有急迫性的事情、比方說技術問題的討論好了，我一樣不太可能會選擇使用討論區。 Well，最少不會選擇鎖住權限別人都不能進來的「專案討論區」。

這部分我的一個朋友Chris說的好：「一個專案裡頭能有多少人？ 有時候分工很細，搞不好你就是自己領域最強的了。 你還怎麼跟案子內部的別人討論？ 甚至貼在全公司的討論區都沒甚麼意義，了不起幾百幾千人。 我真有技術問題要問或討論，我寧願找個甚麼知名論壇。 隨便可能就是幾萬人看，這些人才有可能幫忙回答出些甚麼來。」

確實如此。

只有專案內部才可以看到的討論區，既不能增加溝通的時效性、又不能期待議題能被充分討論，自然沒甚麼人會利用這功能。 其實有內部討論區的公司，幾乎都沒太多人會好好利用這類的功能。 把這功能拿來當軟體功能或許很炫，但卻一點也不務實，所以何必花錢建構呢？ (除非你是有幾萬人的大公司)

專案維基(Wiki)也是類似的東西。 知識管理很重要，我非常肯定。 但我不認為這是專案內的事務，相反的這是一個企業層面的事務。 而且，我一直認為，知識管理是必須「專人專職」的。 如果只是期待「有人自發性」的放些東西，而且還能成為有組織、可被使用的知識庫的話，這期待恐怕有些空泛而且天真。

而且，誰都可以上去編輯的狀況，必然沒有整合性、必然可能有些內容是錯的。 熱心的同仁，不表示他最清楚做法的人；清楚做法的人，也不表示他做的方式是最符合專案利益或是公司整體商業利益的。 而且專案根據尺度大小，小案子可能根本不需要從頭做一遍這些流程與規則(只要Follow別人定好的規則就好)。 而大案子，有可能人人都忙，也未必有空或是心力自動自發的做些甚麼。 也因此，這類專案維基的概念雖好，但最後一定也是空蕩蕩的毫無內容。

唯有專人專職的從公司整體來做規劃，每次專案結案後的資訊都整理，隨時按照狀況、按照公司政策、按照能支援政策的做法統籌調整流程。 這才可能產出一些有用的「知識」，這也會比期待有人自發去編輯來的更實務且可行。

這也是為何我對於專案Wiki這類的平台也不是很以為然。 畢竟若能專人專職，以中央管控的概念來定流程時，這些流程或知識就算需要一個平台，那其實也可以是個任何的平台。 只需要注意不要流出去，內部的權限設定不一定會很複雜，在不需要User編輯下，甚至只是個靜態的網頁都可以。

至於新聞發布，這當然有其必要性。 但是可取代的工具一樣很多，而且新聞發佈不至於有敏感性，Email或是一個公布欄也都可以取代，沒道理花大錢買個可以鎖權限的工具。

也因此，對於想建構PMIS的公司而言，我是還滿反對把重心先放在這類事情上。 畢竟花了錢購買系統，應該要解決的是「真正」該被解決的問題、或是「迫切」該被解決的問題。 當然，如果一間公司排程、文管、版本控制、資源管理、成本管理、風險管理等各面向都有解決方案時，錦上添花的建置溝通平台，我覺得無可厚非。 但若這些都沒有，優先弄個溝通平台，那我覺得就有點本末倒置。

喔，對了。 Issue Tracking或許是唯一在這類「溝通平台」上我覺得有必要，而且可以帶來明確成效的一個功能。 但這類東西卻不一定是所有專案類型都一樣重要，某些產業對此需求重於另外的產業。 而且，最重要的關鍵在於，Issue應該是要能跟Activity結合而非跟討論區結合(如此PM或其他管理者才能理解為何某些工作Delay，並反向追蹤原因、以及解決的狀況)。

但無論如何，這部分的需求要Case by Case的評估(比方說Issue Tracking的功能，工程專案的需求就比研發專案來的小)。 但無論哪個產業，一開始建構PMIS都應該要重點放在排程、資源管理、成本管理上。 工作做不做的完若都沒人知道、發生問題會影響多深遠算不出來，卻只是有個小園地讓大家在上面留言、寫字、或塗鴉。 這根本上是對於管理輕重緩急的不理解啊！

延伸閱讀
關於專案管理工具(PMIS) (一)三大類型