※ 引述《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)