Re: [分享]坊間遊戲程式設計之教與學都還要再進步
※ 引述《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
推
10/23 16:33, , 1F
10/23 16:33, 1F
→
10/23 17:25, , 2F
10/23 17:25, 2F
推
10/23 18:45, , 3F
10/23 18:45, 3F
推
11/04 04:33, , 4F
11/04 04:33, 4F
討論串 (同標題文章)
本文引述了以下文章的的內容：
完整討論串 (本文為第 12 之 14 篇)：