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

※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 111.249.192.64 ※ 文章網址: https://webptt.com/m.aspx?n=bbs/P_Management/M.1436690501.A.34E.html ※ 編輯: chadtracy (111.249.192.64), 07/12/2015 16:48:55