※ 引述《JJ1118 (JJ)》之銘言： : ※ 引述《NDark (溺於黑暗)》之銘言： : 主管不懂你的工作內容，相同的RD也不懂主管真的的工作。 : 主管永遠認為你應該要懂他的想法或需求，若你不懂要問。 : 不會主動溝通的員工，悶起頭來做的再好還是容易犯錯。 : 以上面第三點（c3）來說，有心的主管可能會告知把規則說清楚， : 但是既然開發者不知道要開發成怎樣，也不問就悶著頭開發， : 我不認為開發者心態和做事方式是對的。 : 每天坐在辦公室前10小時就表示我認真，付出很多，是優秀員工。 : 放屁，重點是能不能完成需要完成的工作，滿足需求者的需求。 : 就因為抱著「我有做就對了」的心態，所以才會連需求都沒確實確認就做下去。 : 最後做錯時還會抱著一副你都沒講清楚的想法..... : 如果是需求者的需求和當初開的需求書不同，那還可以說嘴。 : 如果當初沒有聽好需求，確認需求，只能說被評估績效不彰也是自找的。 關於"溝通"這一點, 我相信這是一個軟體專案成敗的重要因素, 客戶和PM必須溝涌, PM和RD也要溝通, 一個常見的狀況是, 對於某項功能, 在規格書之中只有一個簡單的文字描述, 最後是"一項功能, 各自表述" 最後, PM 會認為 RD 沒有主動問清楚, RD 也會亳不遲疑地指責 PM 寫不清楚 另外, 像是一些非功能性的需求 (例如: 效能、安全性、相容性、穩定性) 通常 客戶、老闆、PM 每個人都覺得"本來就要OK" 的東西, 通常也不會寫進規格書 為什麼沒寫進去? 客戶可能根本沒去想這些, 客戶只想著自己需要的功能, (甚至有些客戶連自己要什麼都不曉得 XD) 而 PM, 理論上該去釐清客戶需求, 可是, 既然客戶都沒提, 幹嘛多事呢? 即使 PM 積極地去做了, 那麼, 怎麼樣叫 "高效能"? 怎麼叫 "安全"? 需要一個 KPI, 對吧? 誰來訂? 訂了客戶願意買單嗎? 對 RD 而言, 這些"本來就要OK"的東西, 偏偏是最難處理的地方, (會動->動得好->可以賣錢, 這三者要付出的代價, 差異非常大, 而且不見得是漸進完成的) 這些需求, 在設計階段(如果有所謂"設計階段"的話..囧rz) 不被 high-light出來, 大概之後就只能付出更多代價來完成了 做為實際的開發者, RD 當然會被要求 "有不清楚就該問" 扣除那些 "一項功能, 各自表述" 的狀況 (那些狀況, RD 已經自認很清楚了) 當這些"煩人的小細節"(大家OS:這不是本來就要OK? 這RD新來的唷?) 被提上桌面, 請 PM 確認時, 這就看各公司的溝通成本了.. 積極 PM + 條理分明 RD = 找客戶、找老闆問清楚 消極 PM + 口齒不清 RD = "RD到底有什麼問題? 行不行啊? 這不是 Common Sense 嗎?" 個人聽過最誇張的回答是... PM: 啊~ 問這麼多幹嘛? 做出來我們再和客戶一起看看啊!~ RD: 都做出來了, 客戶不買單怎麼辦? PM: 那就改啊~ (先不論改來改去的品質, 對某些系統, 這根本是重做, 怎麼可能不延期?) 關於專案管理的文件部份, 真的要做, 也不只是 RD 會人仰馬翻, 光是和客戶端釐清需求, 教育客戶"需求定了就不能亂改, 亂改要加錢", 大概 PM 也是會哇哇叫的... XD 不過, 講了這麼多, 我很認同 "RD不該自以為有技術就有飯吃" 這句, 要推出成功的產品, 要靠大家合作, 把細節釐清、把問題拉上桌面討論, 是每個參與開發者(PM、RD、QA)的責任. (不過, 真正做起來, 會發現細節怎麼那麼多? 真的很煩人, ~_~ PM, RD, 或 QA 都這麼覺得.. 囧rz) 可是, 因為進行了"有效"的溝通, 大家幾乎把每個細節都弄清楚, 在事前就能把變因盡可能減少, 這對於產品品質或是進度的控管, 都會有十分大的幫助, --

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