→ MOONY135: 預估工時有其必要性 但我個人認為不應該是連寫都不會寫 07/24 23:16
→ MOONY135: 的人去估 這件事情 07/24 23:16
→ MOONY135: 或者lv80 用自己的等級去評估 lv20的人應該做完的時間 07/24 23:17
→ JackChena: 如果玩遊戲沒顯示經驗值你的感覺如何? 工時是必要的, 07/24 23:17
→ JackChena: 但被濫用來壓榨就不對 07/24 23:17
→ Feis: 所以是溝通的『起點』。會讓不會寫的人估不是偶然 07/24 23:18
→ Feis: 人事時地物都可能影響估計的結果,但是不代表估是錯的 07/24 23:19
→ Feis: 拿來壓榨就只是工具使用錯誤 07/24 23:19
→ MOONY135: 我覺得要讓不會寫的人估 可以 但可能要有一個資深的帶 07/24 23:23
→ MOONY135: 不然改道死也不知道改錯了甚麼 還影響到系統正常運作 07/24 23:24
→ MOONY135: 這就很麻煩了 07/24 23:24
→ MOONY135: 還是要為功能買點保險吧(?) 07/24 23:25
→ Feis: 如果你認為讓資深的帶真的就沒問題,那為什麼不提看看? 07/24 23:25
→ Feis: 每個專案組織的權力結構不同,組織的運作不是偶然 07/24 23:26
→ Feis: 但也不是必然。正常情況下沒人想期待專案失敗 07/24 23:28
→ Feis: 我個人的信仰是比較接近敏捷的,所以我理解與許多人價值不同 07/24 23:32
→ zaa0210: 我覺得意義是1.完成2.未完成,沒了。 07/25 00:28
→ Feis: 不是很確定樓上的意思,也許我們要先定義意義的是什麼 XD 07/25 00:31
→ Feis: 從另一個角度來說,應該說誰能真的知道東西『完成』了 07/25 00:32
→ Feis: 也許這輩子都沒有『完成』的一天? 07/25 00:33
→ zaa0210: Hi 樓上,您上面那幾句,正是我的想法。 07/25 09:44
→ zo6596001: 以專案管理的角度來說,一個專案必定有始有終 07/25 11:40
→ zo6596001: 如果完成專案之後還要進行改進,那麼要再開一個維護案 07/25 11:43
→ Feis: 我自己想法努力的讓專案越早關越好,不止維護分開,甚至原 07/25 11:57
→ Feis: 型跟產品開發階段都可以分成多個階段,才能聚焦需求保持品 07/25 11:57
→ Feis: 質 07/25 11:57
推 pkro12345: 推 07/25 11:58
→ Feis: 而怎麼讓專案越早關的方法很多,改需求也是一種 07/25 11:59
→ Feis: 聚焦在可完成的需求跟可接受的品質下盡早產生產品獲得回饋 07/25 12:07
→ jacknotblack: 到底怎樣保證下一秒軟體專案能『符合預期』的運作? 07/25 16:47
推 JingX: 為了做好事情的期望值,被扭曲成評價個人能力搾出產能的手段 07/28 09:27