※ 引述《NDark (溺於黑暗)》之銘言： : ※ 引述《JJ1118 (JJ)》之銘言： : : 主管不懂你的工作內容，相同的RD也不懂主管真的的工作。 : : 主管永遠認為你應該要懂他的想法或需求，若你不懂要問。 : 這裡我跟你看法不同. : 一個好的主管一定要知道屬下在幹麻. : 可以不知道每分細節的事,但至少要知道大概五成.最好要包含寫了哪些函式或模組. : 主管(這裡可代換為不同公司的PM,就是管"事情"的那個人)要負責追蹤與掌控產出. : 如果主管(或PM)沒辦法"掌控"確切的進度.那就是差勁的管理. : 如果產出與規格不同(察覺並追蹤這件事絕對是視野高的人來作, : 可以委託QA人員,但是結果回來要十分清楚), : 絕對是主管要把執行者固定在原地直到問題解決為止. : 否則不可以再繼續進行其他的地方.因為炸彈會越埋越多.其他人會一起被波及. : 由下詢問上的執行是絕對會出問題的. : 因為權力不對等. : 主管一個眼神,都會讓原本(技術)正確的事情變成(政治)不正確的事情. 部分同意，大部分不同意，甚至覺得觀念有誤。 不過對於主管的定義要分一下。 你第二句的好主管是（高一階的主管），最後依據主管眼神是高好幾階的主管。 因為高一階主管要瞭解下屬的工作內容（尤其是中階主管對Working level的員工）， 但是通常出來罵人、變更需求、提出需求.....都不是高一階主管。可能是其他單位， 甚至更高層的主管，因此他們不瞭解你的那些細節是完全合理的。 因此在接收開發需求時若不完整，沒有向提需求的單位或是主管反應， 我不認為那些主管要負太多責，因為他又不是工程師，他怎麼知道要寫到多細， 表達到什麼程度你們才懂，你們也沒說不懂。 另外關於專案經理、負責人要確實掌握進度。 沒錯，專案經理的工作就是掌握進度、管理進度、甚至要協助管理風險。 但是他們不寫code，進度到什麼程度是誰回報的？ 難道今天我的驗收方式是，你把這個功能叫出來讓我確認過，真的可以run， 我才同意這個功能叫寫完了.... 當然是依據工程師的回報，工程師怎麼回報？ 依據估計要寫800行，現在大概寫了8成...還是依據要寫8天，現在寫6天？ 還是......太多種方式了。再加上寫出來的code要不要驗證？有沒有問題？ 要花多少時間確保正確？這問題連開發的工程師自己都答不出來， PM要如何寫進度呈報主管，更別說掌握準確的進度。 不要把問題都丟出來給其他單位，就因為程式開發的不可測，因此管理需要很有彈性。 但是就因為需要彈性，才會造成工程師永遠都抱怨管理人員不瞭解軟體開發。 問題是，連工程師自己都無法管理好自己的開發狀況，如何讓別人管理。 另外補充：權力不對等.....這種思維就是問題。 大家都是領出錢者的薪水，就算是總經理他也是領薪水的，只是大家做的事不同罷了。 雙方的終極目的都是把事情做好，如果需要去找他們詢問就該詢問， 揣摩上意就是問題。 如果一個單位只有由上而下的指揮模式，除非上意非常清楚，不然絕對會出事。 為何國外都不會稱呼職稱，直接叫名字，就是因為大家同樣是授薪階級， 你是總經理也不表示你就一定對。需要總經理給資料時，你就是要找他拿資料。 尤其軟體開發業通常不會很大，更少有主管擺主管架子。 通常都是工程師擺架子，主管在旁邊倒茶遞水，就怕這些工程師心情不好不爽寫。 我前一陣子逼我們一位工程師離開。他離開時一直說，公司都不管工程師的想法， 時程壓太短.... 別人家一個相同類型遊戲作2個月，他老兄開發6個月還一直有bug，很多功能沒做完。 然後跟我嗆「時程都是你們定的，哪有一個軟體開發不delay？」 每次問進度都是「我不知道，我也不能保證....」 「你也知道軟體開發突然有什麼無法解的bug也很難說」 每個案子請他先依據需求分析出需要製作的模組或功能， 他很努力的寫出來.....然後請他估時間（當然估不出來） 我想請問，如果你是PM，他無法估時程給你，當然只有你估時程給他， 難道你能跟老闆說，「這個案子就看那個工程師什麼時候寫完囉！」 我認同工程師有很多難解的問題，也背負很多壓力。 但是其他單位的角色一樣有壓力，一樣每天都在看別人臉色。 完成案子是大家的目標，如期如值如預算是專案管理的基本精神， 順暢的溝通更是完成案子不可或缺的。 請工程師主動跟其他人溝通，而不是被動等著接受上面的指令， 然後就認為指令都是你們下，我聽命行事，做不好也是因為你們指令下錯。 就是這種心態，我是完全不能接受的。 --

※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 220.128.227.51