: 我所谓的资料拆解也包括了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/cn.aspx?n=bbs/P_Management/M.1436690501.A.34E.html ※ 编辑: chadtracy (111.249.192.64), 07/12/2015 16:48:55