: 我所谓的资料拆解也包括了workload的拆解
: 一般都是按目标 分下task 设定milestone跟预算
: 但是我觉得那个只是供汇报用的
: 什么milestone 风险评估 老实讲gaming的方式太多
: 最小可交付结果 根本是为了报告方便
: 好像真的有完成些什么
: 这样很容易落入kpi的陷井
: 要嘛就是顶着被骂 尽快完成
: 要嘛为了要赶上时程 再耍一些trick 那些我都不干
这就是问题点了，trick是手段没错
但也是给自己跟案子安全的保险
有些时候风险高的案子做这些事情根本不是为了自己
因为你或许可以掌控问题点
但问题是不能掌控问题点的人所在多有
那就是为了提醒这些人，哪时候东西要出来
前后依存跟相关验证机制要启动
在某一个程度上，PM作的有些时候跟幼稚园老师差不多
所以我会跟一些想大学毕业就当PM的说
除非你对开发流程很熟，不然这个不要乱碰，很危险。
: 如果让组员觉得因为什么事没有传达 而导致最后失败
: 这个pm的做法根本是射后不理 想以"我资料都给他了呀"推卸责任
: 或著根本不懂需要哪些资讯 可以产出什么结果
: 我很清楚过程中需要什么
: 譬如说我做过的一个防水设备 样品测试会漏水
: pm可以抄送所有人二个星期我要它被解决 然后邮件一直转发
: 我的做法是和ME一起决定需要什么资料
: （工程师有时候要求的过多 很不现实）
实验设计有些时候要的东西会多
主要就是卡在操作者无法有效控制变因，当然这有一部分是经验的问题
所以才会要写RCA跟5C，这就是帮助他去系统化思考问题
PM能帮他的点就在于
时间多少给你，预期可交付哪些东西，有哪些问题需要我帮你连络传达
客户要怎么Bargin，最后报告跟解决方案的呈现(包括钱、料况)
还要让PM出来帮他作这些，你们的ME真的该打屁股
实验设计的课应该要重修。
最后，我还是要强调一点，这些报告要写的主要理由不只是Tracking
而是让搞不清楚状况的人有机会可以照规矩把问题搞定
就连最讨厌写报告的Agile跟Scrum都把这些当成是流程内化的一部分
我只能说，因为我很懒，所以我会把这些东西都做好
原因是我不想万一出事情炸了，我还要一边忙着搭舞台给老板
一边自己收这个残局...这种事情才是我最不想干的。