作者ricky906 (boy)
看板Soft_Job
標題Re: [討論] 我同學常對我說:資管沒用.
時間Wed Oct 3 19:08:11 2007
※ 引述《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
1F：推 aaronliu0719:prototype本來就是確認需求用的 10/03 19:29
2F：→ aaronliu0719:能在prototype出來前就更清楚客戶的心意 該燒香才是 10/03 19:29
3F：→ aaronliu0719:所以1個論點怪怪的 10/03 19:30
4F：→ aaronliu0719:2的話 要切割出「會變」和「不會變」的部分 10/03 19:30
5F：→ aaronliu0719:等於和4一樣 變成先做半成品 再兜solution的形式 10/03 19:31
6F：→ aaronliu0719:這種和SAP、Oracle的模式不是差不多？ 10/03 19:31
7F：→ aaronliu0719:而上述兩家公司不正也體現了3的行為？ 10/03 19:31
8F：推 ggg12345:用合約時程檢視prototype來使需求與規範減少逆轉,排時程. 10/03 19:30
9F：→ ggg12345:讓用戶選用程式的參數做為變動的輸入, table driven 10/03 19:34
10F：推 ggg12345:預估會有龜毛的模組,留一些做特別的服務,仁盡義至. 10/03 19:39
11F：→ leicheong:PM預的期限通常不會讓你有這種餘閒去想怎樣做好接口的. 10/03 19:54
12F：推 atst:多溝通吧,跟PM,客戶,以及同組的組員多多溝通... 10/03 20:02
13F：推 ledia:其實在學校學了一堆軟工, 最後發現還是會做人比較有用 XD 10/03 20:20
14F：→ ledia:和客戶承辦人打好關係, 安撫他不要天天作夢 案子會好做得多 10/03 20:21
15F：推 leicheong:樓上正解. XD 10/03 20:30
16F：→ leicheong:因此「反論」的等級要練高, 客戶出要求不管怎樣先擋下 10/03 20:31
17F：→ leicheong:再說... :P 10/03 20:32
18F：→ leicheong:而說服甚至催眠他們, 讓他們明白那樣改是壞主意. :P 10/03 20:33
19F：→ leicheong:他們滿意了, 老闆就滿意了, 你就有好日子過了... 10/03 20:35
20F：推 ricky906:多溝通, 能溝通當然是最好的solution 10/03 23:05
21F：→ ricky906:不過我想focus在自救的方法上,去減輕溝通不良時的痛苦 10/03 23:07
22F：→ ricky906:還有其它的想法嗎?! 10/03 23:10
23F：推 ggg12345:不用軟工就是買通打穿,讓利是天底下一定通行的辦法,溝通 10/03 23:28
24F：→ ggg12345:也得用上給好處這個辦法,基本上還是技術掛帥的毛病,軟體 10/03 23:32
25F：→ ggg12345:公司倒了,那買的訂製型軟體誰來後續善後?這裡存在不合常 10/03 23:34
26F：→ ggg12345:情的狀況.這種狀況只會出現在公務機關的行政電腦化,而且 10/03 23:36
27F：→ ggg12345:是首長偏袒身邊鶯鶯燕燕才發生,PM/PG不理客戶才可能會鬧 10/03 23:37
28F：→ ggg12345:得不肯驗收,現在有民代又有審調不可能一面倒,反而會是PG 10/03 23:40
29F：→ ggg12345:不耐煩不肯配合居多. 好關係跟好溝通是一體兩面. 10/03 23:42
30F：推 ledia:PG 不耐煩不肯配合居多 .... 讓我想到 "何不食肉靡 ?" 10/03 23:48
31F：推 trueQoo:只要多接幾個專案,你會得到結果:客戶全都一個樣...XD 10/03 23:59
32F：→ trueQoo:不...是結論.... 10/03 23:59
33F：推 ggg12345:學校跟隨他校買兩校已先訂製使用中的公文系統,價位不變, 10/04 00:00
34F：→ ggg12345:使用單位一開始就指明要更改幾個地方做為配合,結果拖了一 10/04 00:02
35F：→ ggg12345:年,完全無法被接受,而賣方也死不肯改,最後雙方作廢沒收保 10/04 00:03
36F：→ ggg12345:證金.這是一個需求明確也不必重新開發都能鬧成這樣. 10/04 00:05
37F：推 ggg12345:聽說這個現成軟體還維持原來的價位高達300萬. 10/04 00:09
38F：推 ledia:請到刀光劍影的現實世界來吧~~~~ 10/04 01:48