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