Re: [討論] 我同學常對我說:資管沒用.

看板Soft_Job (軟體人)作者 (boy)時間17年前 (2007/10/03 19:08), 編輯推噓13(13025)
留言38則, 7人參與, 最新討論串30/42 (看更多)
※ 引述《atst (電腦無法阻止人類做蠢事)》之銘言: : ※ 引述《ricky906 (boy)》之銘言: : : 有點疑問... : : 需求變動的事實是真實存在的啊 : : 程式因應變動而修改也不是什麼不能接受的事 : : 為什麼說這就是dirty work? : : 建立prototype不就是為了找出問題的範圍 : : 好讓接下來的設計能反應事實,而不是憑空想像 : 事實上,前一陣子蠻流行的XP方法, : 正是為了解決這類情況所提出的工程方法. : 用短期,大量的開發週期,取代過去長期,少量的循環。 : 在每一個開發週期後,針對客戶的需求,再作修正與檢討. : 不過,雖然週期縮短了,但還是得維持一個完整的開發週期。 : 現在的問題是,不論開發週期的長短,客戶都會在不適宜的情形下,介入或是打破原有 : 的開發週期。 : 舉例來說,假設你現在做一個案子,使用XP方法,打算在3~5天之間,先做一個prototype : 出來,跟客戶也講過了,5天後再依照完成的prototype做討論與修改. : 你很高興的開始進入開發的第一階段,你可能由programming開始,也可能由design開始. : 不論你的第一步是什麼,當你在第一天的下午,很愉快的,將第一階段完成,心裡想著: : 接下來兩天,你可以把prototype完成,同時還有點時間做些內部測試,說不定還可以找 : 機會去跟QA的漂亮妹妹哈啦兩句.... : 這時候電話響起了,客戶劈頭就跟你說:"那個xxx, 我這邊還想到一個好主意...." : 然後你就知道了,之前做的階段全都白費了,運氣不好的話,你又得重頭開始.... : 所以說啦... : 程式總是會修改的,這句話不論在商業上,或是技術上都是正確的... : 問題是,就算要修改,你也要先有東西可以改啊.... : 如果連個屁都沒生出來,就在那加一堆有的沒的....那當然是Dirty Work... 嗯....感謝 看了這個例子就清楚多了 以我個人的經驗, 工作到目前為止是還沒遇過太誇張的"動態需求" 但是,對於這樣的狀況也不漠生就是了 客戶機不機車 / PM 夠不夠力 / .... 這些造成問題的原因,我想以programmer的角色 應該是無能為力的, 所以就先放一邊吧 我想請教大家的是, 有沒有對策!?? Ex: 1. prototype在客戶改變心意前搞定. 2. 把客戶可能變動的部分 highlight 另外處理 3. 以專業的立場 引導客戶的需求 4. 領先客戶一步 先把功能做好等著 我覺得再頻繁的變動, 只要是同一個案子 總是會有不變的地方 而且隨著時間進行不再變動的部分就會愈來愈大, 也就是漸入佳境囉 如何快速的通過初期的痛苦,才是我比較關心的部分 -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 58.86.128.2

10/03 19:29, , 1F
prototype本來就是確認需求用的
10/03 19:29, 1F

10/03 19:29, , 2F
能在prototype出來前就更清楚客戶的心意 該燒香才是
10/03 19:29, 2F

10/03 19:30, , 3F
所以1個論點怪怪的
10/03 19:30, 3F

10/03 19:30, , 4F
2的話 要切割出「會變」和「不會變」的部分
10/03 19:30, 4F

10/03 19:31, , 5F
等於和4一樣 變成先做半成品 再兜solution的形式
10/03 19:31, 5F

10/03 19:31, , 6F
這種和SAP、Oracle的模式不是差不多?
10/03 19:31, 6F

10/03 19:31, , 7F
而上述兩家公司不正也體現了3的行為?
10/03 19:31, 7F

10/03 19:30, , 8F
用合約時程檢視prototype來使需求與規範減少逆轉,排時程.
10/03 19:30, 8F

10/03 19:34, , 9F
讓用戶選用程式的參數做為變動的輸入, table driven
10/03 19:34, 9F

10/03 19:39, , 10F
預估會有龜毛的模組,留一些做特別的服務,仁盡義至.
10/03 19:39, 10F

10/03 19:54, , 11F
PM預的期限通常不會讓你有這種餘閒去想怎樣做好接口的.
10/03 19:54, 11F

10/03 20:02, , 12F
多溝通吧,跟PM,客戶,以及同組的組員多多溝通...
10/03 20:02, 12F

10/03 20:20, , 13F
其實在學校學了一堆軟工, 最後發現還是會做人比較有用 XD
10/03 20:20, 13F

10/03 20:21, , 14F
和客戶承辦人打好關係, 安撫他不要天天作夢 案子會好做得多
10/03 20:21, 14F

10/03 20:30, , 15F
樓上正解. XD
10/03 20:30, 15F

10/03 20:31, , 16F
因此「反論」的等級要練高, 客戶出要求不管怎樣先擋下
10/03 20:31, 16F

10/03 20:32, , 17F
再說... :P
10/03 20:32, 17F

10/03 20:33, , 18F
而說服甚至催眠他們, 讓他們明白那樣改是壞主意. :P
10/03 20:33, 18F

10/03 20:35, , 19F
他們滿意了, 老闆就滿意了, 你就有好日子過了...
10/03 20:35, 19F

10/03 23:05, , 20F
多溝通, 能溝通當然是最好的solution
10/03 23:05, 20F

10/03 23:07, , 21F
不過我想focus在自救的方法上,去減輕溝通不良時的痛苦
10/03 23:07, 21F

10/03 23:10, , 22F
還有其它的想法嗎?!
10/03 23:10, 22F

10/03 23:28, , 23F
不用軟工就是買通打穿,讓利是天底下一定通行的辦法,溝通
10/03 23:28, 23F

10/03 23:32, , 24F
也得用上給好處這個辦法,基本上還是技術掛帥的毛病,軟體
10/03 23:32, 24F

10/03 23:34, , 25F
公司倒了,那買的訂製型軟體誰來後續善後?這裡存在不合常
10/03 23:34, 25F

10/03 23:36, , 26F
情的狀況.這種狀況只會出現在公務機關的行政電腦化,而且
10/03 23:36, 26F

10/03 23:37, , 27F
是首長偏袒身邊鶯鶯燕燕才發生,PM/PG不理客戶才可能會鬧
10/03 23:37, 27F

10/03 23:40, , 28F
得不肯驗收,現在有民代又有審調不可能一面倒,反而會是PG
10/03 23:40, 28F

10/03 23:42, , 29F
不耐煩不肯配合居多. 好關係跟好溝通是一體兩面.
10/03 23:42, 29F

10/03 23:48, , 30F
PG 不耐煩不肯配合居多 .... 讓我想到 "何不食肉靡 ?"
10/03 23:48, 30F

10/03 23:59, , 31F
只要多接幾個專案,你會得到結果:客戶全都一個樣...XD
10/03 23:59, 31F

10/03 23:59, , 32F
不...是結論....
10/03 23:59, 32F

10/04 00:00, , 33F
學校跟隨他校買兩校已先訂製使用中的公文系統,價位不變,
10/04 00:00, 33F

10/04 00:02, , 34F
使用單位一開始就指明要更改幾個地方做為配合,結果拖了一
10/04 00:02, 34F

10/04 00:03, , 35F
年,完全無法被接受,而賣方也死不肯改,最後雙方作廢沒收保
10/04 00:03, 35F

10/04 00:05, , 36F
證金.這是一個需求明確也不必重新開發都能鬧成這樣.
10/04 00:05, 36F

10/04 00:09, , 37F
聽說這個現成軟體還維持原來的價位高達300萬.
10/04 00:09, 37F

10/04 01:48, , 38F
請到刀光劍影的現實世界來吧~~~~
10/04 01:48, 38F
文章代碼(AID): #170tWSfI (Soft_Job)
討論串 (同標題文章)
文章代碼(AID): #170tWSfI (Soft_Job)