FB雖然在訊息發布上相當方便，可在知識管理上，卻一點用也沒有...還是得靠人工去整合。以下整理2011.3.1～3.26 FB塗鴉牆上發布的相關資訊：
- 之一 需求訪談為什麼很重要？
「廠商認為客戶永遠都不知道他們要什麼，客戶認為廠商不專業，無法提供專業的建議和服務。」
2003年， Standish Group的Chaos Reports報導，大約66%專案是失敗的，即超出預算、時程，或者縮減功能。上述專案失敗或虧損的三大主因為：
1、缺乏使用者的參與
2、不完整的需求或規格
3、需求或規格的變更
．面對完成軟體專案的最後一道障礙
文/王建興 (清華資工所博士班研究生)
專案為何難以收尾 第1回若需求分析沒作好，到最後仍要應付用戶端因此提出的大量變更請求，甚至要改變之前的設計、架構，付出頗大的代價。
．軟體設計者如何面對需求不斷改變的客戶
很多人以為需求管理重在期初訪談、事後堅守規格，但實務上不可能如此單純；企業內部的IT人員責無旁貸要將任務完成，即使承接外部客戶專案也希望創造雙贏。
- 之二 進行需求訪談前，你需要懂什麼？
引述：「缺乏Domain knowledge只會被研發人員耍、被客戶嚇著、被供應商瞧不起，或者是大家都有意見，最後開發出個沒有競爭力的商品。真的是再慘也不過了...」
不懂技術只好當鴨子吧～呱、呱、呱、呱......
．[訪談PM系列] 菜鳥PM如何累積Domain Knowledge
Domain Knowledge還有另外一項重要的議題，Domain Knowledge何其廣泛，到底要學到多深入才算夠？其實要學多深入這個問題，應該要換個角度提問，那就是「產品經理具備Domain Knowledge的目的是什麼？」。
回到過往的文章，產品經理的工作內容就是要「影響」甚至「指導」各部門通力合作，所以Domain Knowledge在這個工作內容下，所要達到的目的是：
1、降低彼此間溝通成本。2、贏得各部門的尊重。3、摩擦出跨領域的火花。
根基在這三個目的下，筆者規畫了產品經理從幼稚園到研究所的Domain Knowledge學習內容，供產品經理參考：
1、幼稚園：名詞解釋與Know what
2、國小：競爭者狀態的了解與分析
3、國中：Flow Chart、系統架構與Know why
4、高中：上游供應商狀態
- 之三 需求訪談教戰手冊
{需求.1004.02} 需求訪談的教戰手冊
．訪談實況-1
．需求文件製作流程
．［故事］行銷網站需求訪談現場
．專案經理第四話：勇敢面對需求訪談吧
．需求誘導檢查表（Requirment Elicitation Questionaire）
- 之四 如何與IT人員溝通？
．淺談UML
作曲家會將其腦袋中的旋律譜成樂曲，建築師會將其設計之建築物畫成藍圖，行銷廣告人員會將其創意製作成簡報；這些樂曲、藍圖及簡報就是模型(Model)，而建構這些模型的過程就稱為塑模(Modeling)。
軟體開發如同音樂譜曲及建築設計，其過程中也必須將需求、分析、設計、實作、佈署等各項工作流程之構想與結果予以呈現，這就是軟體系統之塑模。
．寫給SA的UML-UseCase實務手冊
．UML Blog
．Kenmingの鮮思維。軟體、學習、交易、生活雜談。
- 之五 如何與MD人員溝通？
．數位教材腳本觀摩
數位教材在製作時,教學設計師會運用腳本將設計的內容與媒體設計的人員作溝通,其運用的方式與電影或動畫的流程相似。而每間公司所運用的腳本型態皆有不同,沒有一定的標準。唯一的方向就是「能溝通清楚」。
---
2011.3.26 初稿
