※ 引述《chadtracy (無名)》之銘言：
: 僅就中間這個部份作解釋。
: 我會覺得，資料拆解與消化只是一部份。
: 最重要的是怎樣把專案的大塊大部分，有效的切割成適當的Milestone
: 這就跟放積木在箱子一樣，大塊放下去很占位置空間
: 你要怎樣合理的拆解，讓大家都能跟著你把案子作完才是關鍵。
: 因應的方法最快的就是最小可交付成果、風險NUDD之類
: 另外，我不太贊成把資訊扣在身上，除非你能有效的過濾
: 而且讓每個人都能照時程搞定，不然這樣作只是搬石頭砸自己腳...
我所謂的資料拆解也包括了workload的拆解
一般都是按目標 分下task 設定milestone跟預算
但是我覺得那個只是供匯報用的
什麼milestone 風險評估 老實講gaming的方式太多
最小可交付結果 根本是為了報告方便
好像真的有完成些什麼
這樣很容易落入kpi的陷井
要嘛就是頂著被罵 盡快完成
要嘛為了要趕上時程 再耍一些trick 那些我都不幹
我看專案就是資訊的動態交換 過程中視情況調整內容
完成專案的過程就是無數個問題 被提出 理解 回答
在這循環的過程中 有些task剛好被完成
一般OC要求一個產出 譬如說一份報告或是task被完成 OB是比較直觀容易理解
但是它的核心就是結果導向
而我所謂的動態資訊交換比較偏向過程導向
雖是如此 但其實不跟我寫的"一個pm就是為最終結果負責"相悖
這有時間再說
如果讓組員覺得因為什麼事沒有傳達 而導致最後失敗
這個pm的做法根本是射後不理 想以"我資料都給他了呀"推卸責任
或著根本不懂需要哪些資訊 可以產出什麼結果
我很清楚過程中需要什麼
譬如說我做過的一個防水設備 樣品測試會漏水
pm可以抄送所有人二個星期我要它被解決 然後郵件一直轉發
我的做法是和ME一起決定需要什麼資料
（工程師有時候要求的過多 很不現實）
e.g. 證明給他看 4次的實驗一定就能知道哪個地方問題 不需要6次
然後協調射出廠 工廠重新打樣 測試機台預約
不可能發生組員要的東西我沒給 最後還能讓他用這來當藉口的狀況
我要的很明確 他要的也得很明確
沒有能力過濾 就先當助理好了 掛PM哪那麼容易