: 我所謂的資料拆解也包括了workload的拆解
: 一般都是按目標 分下task 設定milestone跟預算
: 但是我覺得那個只是供匯報用的
: 什麼milestone 風險評估 老實講gaming的方式太多
: 最小可交付結果 根本是為了報告方便
: 好像真的有完成些什麼
: 這樣很容易落入kpi的陷井
: 要嘛就是頂著被罵 盡快完成
: 要嘛為了要趕上時程 再耍一些trick 那些我都不幹
這就是問題點了，trick是手段沒錯
但也是給自己跟案子安全的保險
有些時候風險高的案子做這些事情根本不是為了自己
因為你或許可以掌控問題點
但問題是不能掌控問題點的人所在多有
那就是為了提醒這些人，哪時候東西要出來
前後依存跟相關驗證機制要啟動
在某一個程度上，PM作的有些時候跟幼稚園老師差不多
所以我會跟一些想大學畢業就當PM的說
除非你對開發流程很熟，不然這個不要亂碰，很危險。
: 如果讓組員覺得因為什麼事沒有傳達 而導致最後失敗
: 這個pm的做法根本是射後不理 想以"我資料都給他了呀"推卸責任
: 或著根本不懂需要哪些資訊 可以產出什麼結果
: 我很清楚過程中需要什麼
: 譬如說我做過的一個防水設備 樣品測試會漏水
: pm可以抄送所有人二個星期我要它被解決 然後郵件一直轉發
: 我的做法是和ME一起決定需要什麼資料
: （工程師有時候要求的過多 很不現實）
實驗設計有些時候要的東西會多
主要就是卡在操作者無法有效控制變因，當然這有一部分是經驗的問題
所以才會要寫RCA跟5C，這就是幫助他去系統化思考問題
PM能幫他的點就在於
時間多少給你，預期可交付哪些東西，有哪些問題需要我幫你連絡傳達
客戶要怎麼Bargin，最後報告跟解決方案的呈現(包括錢、料況)
還要讓PM出來幫他作這些，你們的ME真的該打屁股
實驗設計的課應該要重修。
最後，我還是要強調一點，這些報告要寫的主要理由不只是Tracking
而是讓搞不清楚狀況的人有機會可以照規矩把問題搞定
就連最討厭寫報告的Agile跟Scrum都把這些當成是流程內化的一部分
我只能說，因為我很懶，所以我會把這些東西都做好
原因是我不想萬一出事情炸了，我還要一邊忙著搭舞台給老闆
一邊自己收這個殘局...這種事情才是我最不想幹的。