※ 引述《yauhh (姚呵呵)》之铭言： : 看这样子我觉得蛮奇怪,二个是合作专案,并且对方比你资深, : 你有指挥对方改code的权力吗? : 说不定,是你太急了,不愿意给对方长一点的时间, : 又说不定,是你要秀bug给他看的时候,并不在他有空的那个节骨眼. : : 只能说既然每个人都有分工,你管好你自己的范围进度步调就好, : 你愿意热心秀bug,对方应该会感谢你,也会听进去, : 但是虽然知道有bug,却不代表他必须尽快修正你所指出的bug. : : 你根本是搞错权责了. : 对专案来说,专案成员修bug当然责无旁贷; : 然而,对方比你资深,你怎麽会以为对方必须对你所指正的bug负责呢? : 对方当然要修bug,不过即使赶不及修他的bug,他也不对你欠责任. : : 做事情是一回事,管理是另一回事,不要没事就跳进管理者的位置. : 你自己去问问PM,PM才是真正有权管专案的, : 如果他不讲话,你应该也没什麽话可以讲. : : 不要责人太严,有时仁慈一点比较好. : 很多细节，在网路上没办法一字一句的讲清楚， 这个专案，如同我之前文中所提过的，我几乎是"不在其位、却谋其职"的感觉， 可能PM不敢或不主动管事？所以最後不只PM、连那位工程师有问题时， 很多时候都会问我建议，所以才会有股我是地下PM的感觉。（并非是我要大家来问我） 而且每个公司、每个team都有自己的行事方式， 在我们team里面，其实资深这件事情，除非当事人自己依仗资深去压人， 否则谁抓到bug，都可以告知对方，请对方修改（当然没限定修改时限）。 而在这案子中事情的轻重缓急，我当然也清楚，我相信对方也很清楚， 因为我们同样都只专注在同一个案子，也排序过各modules的紧急程度， 一旦最紧急的modules出问题，一定要以会造成schedule bottleneck的为主， （因为我们各自负责的modules，互相依赖的程度很高） 即使是别的资浅工程师告知我负责的有bug，我同样也是得如此做， 这是我们一开始做之前就有的共识，包括修改的末期，可以直接动别人的code。 我也不想细讲，这件事情到最後算默默地解决，因为对方已抽离这个案子， 而事实上，去反应这件事情的也并不只有我。 : 推 tonytsai88:说的没错! 完全同意 07/07 20:47 : 推 andymai:推管理和做事要分开... 07/07 21:00 : 推 yjkuo:你说的没错,但是我觉得跟原po状况不一样 07/07 21:49 : 推 iincho:我一直觉得不让自己的bug影响别人是基本礼节..... 07/07 22:32 : → iincho:很复杂的case当然没话讲, 想/测清楚再commit是必要的... 07/07 22:34 针对前篇讲的，其实我们的code有做unit test的， 但却发生了unit test最大的盲点，因为谁写的code，刚好也是谁写的test case， 所以错误的test case，去执行了错误的module code，刚好得到pass的结果.....Orz 以致於後来，不只是要改code，连test case都要改。 至於cvs，虽然没有使用cvs system，但事实上我们是有做版本控制的， 所以做这个案子的过程中，code的管理并没有发生什麽大问题。 但我也一直觉得每个人该为自己commit的code负责才对， 可是这种事情，不只在我们这种开发中的案子，连在我们public cvs上都会发生， 但似乎很多人没有这种自觉。 另外，这篇有讲到我最大的困扰，就是原本不该我管理的，却变成我被拉出来做决策， 情况更复杂，基本上就是我夹在leader和PM之间、又搞不清楚发生什麽事的情况， 所以後期常常变成是我和PM各自向leader报告schedule。 （我并不认为三人中谁有问题，只是对我来讲资讯不透明，所以感觉很奇妙） 说真的，责任划分可以说的很简单，可以说当初就是这样划分的， 说那bug不关我的事、schedule delay不关我的事， 但是讲归讲，这些细节不见得有人想在乎，案子可以如期出来才是重点（我指对上面）。 就像有时跨部门的合作时，这种问题更严重， 每个部门都只会在抢先推卸责任，没有人在想要怎麽做去解决问题， 结果就让情况越来越糟....。 --

※ 发信站: 批踢踢实业坊(ptt.cc) ◆ From: 218.187.7.130 ※ 编辑: makotoan 来自: 218.187.7.130 (07/08 00:13)