推 sofss:越精良的設計...越頂不住隨心所欲的客戶亂改SPEC... 06/28 01:05
推 poqwer:規格改個幾次，所有的rule就會互相衝突，最後時間不夠 06/28 01:08
→ poqwer:整個從底層改起，就會隨便改，然後就....，祈禱不出錯就好 06/28 01:09
→ StubbornLin:我不懂為何精良的設計會頂不住修改 06/28 01:59
→ StubbornLin:我指的良好設計包括藕合度低等容易維護的特性 06/28 01:59
→ StubbornLin:藕合度如果低 改某個不份不會影響到其它地方 06/28 02:00
→ StubbornLin:當然 大規模的更動或許是例外 但是爛的設計情況 06/28 02:00
→ StubbornLin:只會更慘而已 06/28 02:00
→ StubbornLin:沒有什麼越精良的設計越不經改 設計越好 才越好改 06/28 02:02
→ StubbornLin:如果你指的精良設計是所有組件都剛剛好組合在一起 06/28 02:03
→ StubbornLin:那我只能說那是爛的設計 組件互相依賴才會剛好合起來 06/28 02:04
→ StubbornLin:不然真正良好的設計組件對其它部份都是無知的 06/28 02:04
→ StubbornLin:何來的頂不住改? 06/28 02:04
※ 編輯: StubbornLin 來自: 118.170.180.12 (06/28 02:04)
→ StubbornLin:與其說精良設計 過度設計似乎比較有那樣的問題 06/28 02:45
推 iincho:通常是沒時間設計啦, 尤其是寫網頁程式的... 06/28 03:08
→ iincho:另外客戶前後吐出來的constraint有可能是完全不一樣...XD 06/28 03:08
→ iincho:這種狀況除非你搞overkill不然爛掉的機率很高... 06/28 03:09
推 juriolegend:真的是沒時間還是不會設計?你忍受的了哪個? 06/28 03:33
推 summerme:基本上.只要客戶一個堅持的需求.有時連架構都要翻了... 06/28 05:10
推 prag222:部落格文章講的真貼切阿`我可以引用你的文章嗎? 06/28 10:57
推 TonyQ:是良好的設計或是過度設計 , 並不是單純由設計面來看的 , 06/28 11:35
→ TonyQ:而是由 spec 來定義的 , 06/28 11:36
→ TonyQ:當你的spec 不停的變動 , 今天的良好設計變成明日的不足或 06/28 11:36
→ TonyQ:過度設計 , 這就是現在的 pg 所常見在處理的日常工作 , 06/28 11:36
→ TonyQ:但是這其實也還算正常 , 但是最重要的地方在於 spec 的改動 06/28 11:37
→ TonyQ:是因為實驗性質？又或是一時興起？還是長久規劃？ 06/28 11:37
→ TonyQ:規劃的人有沒有考慮過 spec 改動所帶來的漣漪效應 , 這才是 06/28 11:37
→ TonyQ:被concern的重點 , 當然重要的是資源釋出的夠不夠. 06/28 11:38
→ TonyQ:很少有東西是不能改的 , 但是很少有東西是有足夠時間改的. 06/28 11:38
推 wa120:這是軟體工程的基本概念阿 06/28 11:46
→ StubbornLin:當然可以引用 只要有出處 06/28 13:39
→ StubbornLin:嗯 的確不停的改spec會有這樣的問題 06/28 13:40
→ StubbornLin:那就不是設計層面的問題 而是客戶或方法的問題 06/28 13:41
→ StubbornLin:但以我個人的經驗 依照xp的做法 有很多個週期 06/28 13:41
→ StubbornLin:每完成一小部份就給客戶確認一下是否是他們要的東西 06/28 13:42
→ StubbornLin:確實對於做出客戶想要的東西很有幫助 06/28 13:42
→ StubbornLin:但是如果就算這樣做 規格還是不停的大幅度更動 06/28 13:43
→ StubbornLin:我只能猜想客戶連自己要什麼都不清楚 06/28 13:43
→ StubbornLin:或許是我沒遇過這樣的客戶 不過我都會約定在前頭 06/28 13:43
→ StubbornLin:如果因為更動規格造成需要大幅的修改程式需要額外的 06/28 13:44
→ StubbornLin:收費 如果客戶錢燒不完的話 而我又有空做是沒差啦= = 06/28 13:44
推 qrtt1:思考改 spec 前先結清前次費用的可能性 (誤) 06/28 15:43
推 andymai:客戶:好啦!好啦!就改一下那邊而已啊!先改來看看再說嘛... 06/28 18:01
→ andymai:如果軟體像鞋子一樣~那架構就像模具~有人在買鞋子的時候會 06/28 18:03
→ andymai:說:反正就裁一下~車個邊嘛~你先改來看看再說嘛... 06/28 18:04
→ andymai:為什麼軟體可以被客戶這樣凹呢??? 06/28 18:05
推 fotofolio:訂製服設計師也是會被凹的... 06/28 18:15
推 sofss:給錢的是客戶,對PM來說,RD對於架構的心力能賺到錢嗎... 06/28 18:38
→ sofss:不如架構很差,但可以對客戶交差就好...先賺到這一單再說... 06/28 18:39
→ sofss:為了架構得罪客戶,可能連這單都沒了...幹嘛為了不一有的下單 06/28 18:39
→ sofss:去搞個很好的架構? 06/28 18:40
→ sofss:對這一單負責的RD來說,下一單又不見得是我負責...不如趕快 06/28 18:41
→ sofss:弄個可以跑的版本,趕快出貨,弄個好看的考績,拿bonus走人... 06/28 18:42
推 sofss:很不幸的...真的有下一單了,接手的RD那到一個架構超爛的code 06/28 18:52
→ sofss:但是可以正常運作,要加新功能可能要繼續破壞最早架構的理念 06/28 18:53
→ sofss:不然就得整個砍掉重練,而且練完不知道會不會正常的動,砍掉重 06/28 18:53
→ sofss:練的好處是下一個RD會輕鬆點,壞處是有300個以上的function藥 06/28 18:54
→ sofss:重寫,而且架構改了,一些undocument的裏技不能用了,又不確定 06/28 18:55
→ sofss:客戶有沒有用類似的裏技,改了八成會要一兩個月重新請QA重測 06/28 18:56
→ sofss:你會選擇為了RD的自尊進行重搆嗎? 06/28 18:57
推 summerme:所以這時厲害的PM..就會開始勸客戶用新案重做.. 06/28 18:57
推 sofss:然後利害的客戶就會說既然要重做可以挑你的對手來,而且她們 06/28 19:20
→ sofss:比你們便宜.... 06/28 19:21
推 sofss:PL曾說:多給一個月, 包裝盒上你要寫架構更好還是功能更多? 06/28 19:31
→ sofss:除了RD...PM, PL, BOSS, 客戶都不會在意你的架構好壞... 06/28 19:32
推 summerme:我比較常遇到的是對手用低價搶來做不到只好再賠錢轉包... 06/28 19:46
推 iincho:會講那種話的PL有點不大負責任，除非非你打定project是免洗 06/28 21:21
→ iincho:不然PL要擋PM的壓力，PM要擋客戶的壓力，這樣有機會做好... 06/28 21:22
→ iincho:很多短時間看不出效果的東西做在位子上的人要有guts去做... 06/28 21:22
→ sofss:是嗎?後來我倒是頗同意PL的說法...公司付錢給我要我寫可以賣 06/28 21:26
→ sofss:可以賣的code,而不是架構良好的code...優先的是可以賣,硬要 06/28 21:27
→ sofss:弄個架構良好的code出來,大多是RD對自己的制約... 06/28 21:27
→ sofss:這點並未列在Project內的必需條件,時限內你可以寫出良好架構 06/28 21:28
→ sofss:那是你的自由,但不是一個用來推拖要求的理由... 06/28 21:29
推 iincho:如果是做一次性的商品是可以，如果是次性的這樣搞...zzzz 06/28 21:29
→ iincho:PM和PL的工作除了把project跑完以外還要確保最大出力... 06/28 21:31
→ iincho:如果code可能是多次使用，之後修改需要的時間也應該算進去 06/28 21:32
→ iincho:所以我說，你賭定這code只用一次的話沒差，不然就算做完 06/28 21:32
→ sofss:後來想想...PL本來就沒必要為了我的架構去跟客戶炒,維護架構 06/28 21:33
→ iincho:還是應該回頭把架構整理一下，最理想的狀況是設計時就解決 06/28 21:33
→ iincho:我幹PL的話會做這件事，因為我認為那是技術主管的份內事... 06/28 21:34
→ sofss:並且完成功能是我的工作,做不到是我的責任... 06/28 21:35
推 poqwer:坦白說，客製化的東西，如果確定不會有第二代，有時候真的 06/28 22:14
→ poqwer:是功能做完就算了，架構、好維護....，通常都拋諸腦後.... 06/28 22:14
推 poqwer:但如果是會一直有新版本的軟體，架構真的很重要，但是.... 06/28 22:16
→ poqwer:那也要主管或高層在乎，不然，你為架構花的心血，也不見得 06/28 22:17
→ poqwer:你能夠得到回報啊...有時候會有只是白花時間的感概~ 06/28 22:17
→ sofss:花時間去設計良好的架構,結果客戶嫌配合度不夠,客製化困難 06/28 23:39
→ sofss:別想有第二單,放棄原始架構,照客戶需求東改西改,下一單苦的 06/28 23:40
→ sofss:是不是自己還不一定... 06/28 23:41
推 ledia:與其信仰 XP 能解決一切, 不如期望你有個硬度夠的 PM .... 06/29 00:02
→ StubbornLin:軟工沒有銀彈 xp也只是方法之一 沒有信仰的問題 06/29 01:16