以前总会觉得，为什么大佬们经验丰富，能想到很多小白想不到的点。现在慢慢明白，哪有谁一开始就事无巨细，面面俱到。都是踩过的雷，吃过的亏。正所谓九层之台，起于累土，从现在起慢慢复盘积累经验值！
现在经历的一个项目可以说是能学到各种管理上的不足的反面教材。以前的项目和前辈一起做事开会的时候，总会觉得对方怎么这么厉害，哇能学到好多好开心。现在的这个项目是觉得对方怎么做成这样，下次我可不能这样。
最先想说的是，在一个项目开始的时候一定要明确好责任划分，要有明确的SOW（Statement Of Work）啊！我这个项目就是，因为职责划分不清，我所在的小组又占据技术上的要塞，所以导致事无巨细，全都是前辈和我两个人大包大揽。前辈性格比较随和，不太会拒绝，所以有什么都会接下来。
我是以两个身份进入项目，而这次的项目对于我是第一次，对整个日本这边也是史无前例的一个项目。所以我很懵逼的进了项目，我的上司也很懵逼。所以我一开始也啥都不懂，有啥活就跟着前辈做呗，权当积累经验。后来慢慢也感觉到不对劲了，关联最紧密的负责运维设计的团队毫无节操的当甩手掌柜，不管什么问题都不和开发团队对接，而是全丢给前辈和我处理。
真正的导火索是有一天晚上我被拉去帮他们做前期测试，在一直做到晚上十点之后，面对对方leader提出的要求，直接和对方leader吵了起来。。第二天把责任不清这个情况跟上司说，然后这几天就在和几个大佬一起讨论责任划分这个事。
如果不明确职责划分会怎样？出问题的时候对方会觉得是我们组做的不好，项目出现迟延的时候只会使劲儿催促我们组尽快对应。而我方又会觉得我们只是产品推进，既不是提供方，也不是项目成员（虽然我属于项目成员但是不属于运维设计组）。应该项目成员做的事凭什么要我们来做。所以即使好心好意帮对方做事，对方不仅不感激，甚至觉得你工作做的不到位。
尤其今天才知道对方连SOW都没有，我就很纳闷他们哪来的自信觉得这些事都应该由我们组来做呢。还是惯性选择甩手掌柜的选项来得比较轻松呢？
可是这次我又怎么会让他们得逞呢。
下次再进项目时，绝对绝对要提前先确认好SOW！
作業範囲記述書 SOW とは、複数の主体が共同で進める事業・業務・プロジェクトなどにおいて、そのプロジェクトの目標や、 成果物 の定義や仕様、スケジュール、作業工程、作業内容、各主体の役割、分担、権限などを定義した文書。
