JWorld@TW the best professional Java site in Taiwan
      註冊 | 登入 | 全文檢索 | 排行榜  

» JWorld@TW » 交流、聊天、灌水  

按列印兼容模式列印這個話題 列印話題    把這個話題寄給朋友 寄給朋友   
reply to topicthreaded modego to previous topicgo to next topic
本主題所含的標籤
無標籤
作者 客戶100%對的專案=100%失敗的專案? [精華]
RR

~Nintendo64~



發文: 686
於 2005-07-29 16:04 user profilesend a private message to userreply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
是這樣的:

弟目前手上的案子拖了很久,前後歷經九人開發(Me: 9th)
最近已經beta給客戶了。
公司方面也希望我們盡快結案。

昨天我們Leader去和客戶開會,結果回來又帶了一些奇怪的要求。Orz
無巧不巧,好死不死,這要求就和之前客戶硬要求我們做的功能完全衝突了。

我和Leader解釋:
這東西和我們之前硬作出來的xx是完全衝突的。
之前已經為了硬作出xx打破系統的原有架構,
一些應該System架構去Biding的東西變成用程式來維護...
我可是花了好一段時間才把它重新整理好,變成新的架構。
現在還要為了yy再打破架構一次嗎?

Leader:這個很簡單,你就在xxx.jsp內用if來判斷這個特例然後...

Me:Orz(竟然完全沒聽進去)欸!現在根本不是技術上的問題啊。
上次為了xx已經耗掉很多時間改變系統架構,現在還要再來一次嗎?
更何況案子已經趕著結了...

後來,我幾乎是半強迫的方式請Leader去和客戶解釋,
問他們願不願意付出額外的時間成本?還有硬搞出來的東西增加系統的不穩定性。
目前還沒有最終結果,不過如果客戶堅持要的話,還是得硬著頭皮去做就是了。

已經離職的PM之前和我說過:如果客戶的方向搖擺不定,那我們可以試著
去暗示、建議、指引一條路出來。如果只是被客戶拖著走的話,這案子就
別想結了...

我想,這案子會歷經九人之手還沒結束,當中六人離職兩個不願意再碰,
和一直疊床架屋的硬來,搞的系統一團亂絕對脫不了關係。
老實說,我也很不想繼續做這案子了。不過在專業的自尊下,
我會盡量讓這期案子結掉。後續二三期的話...可能要另請高明了∼

標題後面雖然打了個全形大問號,
但是在我心裡,應該會有這樣的postfix
1
return str.replaceAll("?","!");


各位的看法呢?應該有不少人都有過類似經歷吧∼


reply to postreply to post
作者 Re:客戶100%對的專案=100%失敗的專案? [Re:RR]
yching

怎麼會醬子...



發文: 60
於 2005-07-29 16:42 user profilesend a private message to userreply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
嗯嗯嗯.....
我也遇過類似的情況....
只是說我的case沒歷經那麼多人啦....
就只有我一個人在coding...但是也拖了一年多才終於宣告結案....

這一年多裡面...
因為時間真的拖太長....
我又有其他的事也要做....我的客戶也忙的不得了...
所以常常我的客戶終於有機會和我再討論的時候....
我不但需要先去"複習"一下...前面做的東西有些後來又要變動...>"<

真的是一場惡夢呀.....
終於在我離職前...給結案搞定了....
不搞定的話...我想這個案子不但會變成我的污點(自己覺得啦)....
而且可能對下次要接case寫的時候...會"異常"恐懼吧!

ps.後來我那個客戶..又找我回去幫他們寫同一個案子的第二階段東西...真是嚇死我了!
  還好他們老闆可能不太願意花$$請外面的人做吧...目前沒再找我了...真是鬆了一口氣呀!


reply to postreply to post
作者 Re:客戶100%對的專案=100%失敗的專案? [Re:RR]
equalmin





發文: 55
於 2005-07-29 16:58 user profilesend a private message to userreply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
1
2
很少人會要求建築師在現有的 100 層大樓下再加蓋一層地下室;但是,一般人卻常
不自覺地對程式設計者提出類似的要求,還加上這麼一句:「這不是很簡單嗎?」


來源:http://ihower.idv.tw/index.php?item=1877

ps. 之前找資料的時後看到的
Wink


equalmin edited on 2005-07-29 17:01
reply to postreply to post
作者 Re:客戶100%對的專案=100%失敗的專案? [Re:RR]
ray_linn

什么都不懂的小白

版主

發文: 540
於 2005-07-29 17:07 user profilesend a private message to usersend email to ray_linnreply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
定一个Freeze Requrement的process嘛,之后要改就加钱~

reply to postreply to post
飞翔的候鸟
作者 Re:客戶100%對的專案=100%失敗的專案? [Re:equalmin]
sai





發文: 265
於 2005-07-29 21:22 user profilesend a private message to userreply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
equalmin wrote:
1
2
很少人會要求建築師在現有的 100 層大樓下再加蓋一層地下室;但是,一般人卻常
不自覺地對程式設計者提出類似的要求,還加上這麼一句:「這不是很簡單嗎?」


來源:http://ihower.idv.tw/index.php?item=1877

ps. 之前找資料的時後看到的
Wink

XP不是強調在開發的過程要能不斷加入新需求?
只要refactoring... Big Smile


reply to postreply to post
整合勞保、公保及勞工、公務員的退休制度,讓年資可以帶著走,這樣可以讓公部門和私部門的人才有機會交流,才不會讓公部門變成一灘死水!
作者 Re:客戶100%對的專案=100%失敗的專案? [Re:sai]
singlelog

換回來



發文: 416
於 2005-07-29 22:56 user profilesend a private message to usersend email to singlelogreply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
新需求跟完全推翻以前作法的需求不一樣吧。Big Smile

況且,一般的專案應該不是用XP。到了要結案的時候,還有發散的需求,這就很頭痛了。你想要結掉這個案子,根本沒有預期會有下一個iteration呀。

我想,RR遇到的應該不是在現有的 100 層大樓下再加蓋一層地下室。嗯,內心忽然擁現一個場景。

---------------------------------------
singlelog這天正在菜市場賣菜。

客戶:老闆,那個小白菜一斤多少錢?

singlelog:小白菜一斤30塊

客戶:那給我一斤小白菜

singlelog:這是你的小白菜

客戶:再多送我幾根蔥吧

singlelog:大哥,現在蔥一斤要250也。沒辦法啦。

客戶:你這人怎麼這樣呀?這不是很簡單嗎?你就把它抽個幾根過來就行了嘛。這有什麼困難的。你這麼機車以後我不跟你買喔!你要追求顧客滿意度嘛,有高興的顧客才有長久的生意嘛。

singlelog:颱風過後,菜價這麼高,真的沒辦法啦。

客戶:那要不然你這輛發財車還不錯,要不然,我多買你一斤小白菜,你這台車送我好了。

singlelog:※@#$@#$&^

客戶:你幹嘛罵人呢?那小白菜我也不要了,花錢買東西還找罪受,叫你們老闆過來,我要你再賠償我1000塊懲罰性違約金。要不然,小心我告你。

---------------------------------------

台灣的客戶總會要買車子送個皮椅鋁合金鋼圈,所以一般賣車子的人多少也知道,該送的是跑不掉的。你買東西買得多,我就阿沙力一點,送你點東西,例如跟熟人買保險,通常就會退你第一年抽成的部份。不過做軟體系統好像就不一樣了。在還沒做之前,很多東西都是空中樓閣,越模糊的話,就比看看誰臉皮比較厚了。

有時候就會是給你一點菜錢,就乾脆要你送一台汽車給他。反正只要敢開口,最糟糕不過也就是要不到。可以多拿,幹嘛不多賺一點呢?至於要到一台爛車我又不想開,那也沒關係,反正我用不到放在路邊等人拖吊我也爽。再怎麼說都會覺得自己是賺到了。

嗯,今天圖書館天使有發功,有一則漫畫很適合。

(縮略圖,點擊圖片鏈接看原圖)


singlelog edited on 2005-07-29 23:19
reply to postreply to post
我的書:專案管理Happy書!

我的網站:diggirl.net

my blog http://tinyurl.com/36gcye
作者 Re:客戶100%對的專案=100%失敗的專案? [Re:RR]
singlelog

換回來



發文: 416
於 2005-07-29 23:48 user profilesend a private message to usersend email to singlelogreply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
客戶"真的"知道他要什麼嗎?

如果是以前他沒接觸過的東西,是一種全新的system,這個時候不管他在系統分析階段說了些什麼,很有可能到了測試時,他會全部的翻案。

如果案子拖的太長了,有可能企業的需求,在這一段時間發生了變化,特別是在承辦人換掉很多次時,很多東西就會是有每個人講的話都不一樣的狀況。特別當一個人沒有很清楚的從頭走到尾時,修修改改就免不了了。

最好的狀況當然是導引客戶的想法。不過這個說的容易做起來難呀,很多SA並不具有這樣的能力。

我是遇過那種做到一半忽然來個scope大轉彎的案子。那就真的很像是買台腳踏車,到了一半要你換成大卡車的感覺。


reply to postreply to post
我的書:專案管理Happy書!

我的網站:diggirl.net

my blog http://tinyurl.com/36gcye
作者 Re:客戶100%對的專案=100%失敗的專案? [Re:singlelog]
ianhong





發文: 2
於 2005-07-30 01:35 user profilesend a private message to userreply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
Post is deleted

ianhong edited on 2007-04-26 15:13
reply to postreply to post
作者 Re:客戶100%對的專案=100%失敗的專案? [Re:ianhong]
wing_zero

Keroro捕獲~~是也



發文: 213
於 2005-07-30 08:47 user profilesend a private message to userreply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
ianhong wrote:
客戶真的不知道他們要什麼嗎? 他們不懂的是IT, 不是商業, 更不是他們的產業. 不知道的是IT可以為他們帶來什麼東西, 且實際可以應用的地方.

比方我遇到的case. 客戶想要引入Barcode到他們的公司內. 客戶想要利用barcode加快庫存清查的動作, 但是仔細品估後發覺該產業根本不適合使用barcodes. 通常遇到這種情況SA的回應是 硬做 或 拒絕. 但是如果再去細看客戶想要的, 簡單說就是聽到很多關於Barcode的好處想要簡化公司內的流程. 這時我們的義務就是去協助客戶簡化或加強企業流程. 事後我在該企業其他工作流程內導入Barcode的應用, 且簡化該公司內某一流程.

拿這個例子我想要說, 客戶實際上是不知道在什麼地方IT可以為他們帶來什麼利益. 但是他們知道他們想要的是什麼. 但是可能因為IT技術了解不夠深入, 他們常常道聽塗說把技術錯誤引用到錯誤的地方. 而當他們在實際使用時他們就會發現廠商做出來的根本就不是他們想要的(結果), 如果真的只依照客戶說的做出來. 很多不夠專業SA就只做簡單的requirement gathering的動作, 本身並沒有做到 Analysis 這個動作. 只要是客戶想要的全部做給他們. 接下來就會發生如同RR的問題. 更糟糕的是 下一個接手的人 也是個不專業的SA, 只是又把客戶說的硬弄到工程師身上去解決. 然後一直重複上一個SA的錯誤.

最後, 當然不同的客戶會有不同的情況. 我當然無法斷定RR case實際發生的錯誤是什麼, 但是在這我提供一種企劃上會發生的錯誤. 以供不同方向思考.


提到這個就讓人想到台灣這邊對軟工角色的定位為何。

在一家Vendoer site公司裡常遇到的情形都是這樣的。
Coding還可以的 --> 就當PG
Coding很猛的 --> 當SD或是Architecture
Coding不行但是寫文件一把罩的 --> 當SA跟User談需求
什麼都很兩光的 --> 當當無害的Tester(真的是無害嗎?我想只有天知道!)

這種組合下的產出是什麼,我想大家就都很心知肚明。
當IT人員本身都不專業或半調子時,會產出什麼就真的很另人懷疑了。DeadDead


reply to postreply to post
俺的部落格
作者 Re:客戶100%對的專案=100%失敗的專案? [Re:RR]
adoo





發文: 87
於 2005-07-30 11:14 user profilesend a private message to userreply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
接案不寫需求與規格書嗎
規格書寫的好 等客戶確認後
就照規格去做
這些都是合約規範的
如果雙方有人片面想更改規格 就照合約走
通常我都不會照著客戶說的去做
但都會另外變通給她們
已不影響專案進度為前提
這是專案經理的工作 也是軟體工程的規範
妳們的專案經理根本就沒有盡到責任

這些都不作 就只寫程式
那這種下場 也是無可厚非

妳們該做的反而是建立正確的專案流程
跟換一個專案經理
不然只是累死工程師


adoo edited on 2005-07-30 11:21
reply to postreply to post
作者 Re:客戶100%對的專案=100%失敗的專案? [Re:ianhong]
singlelog

換回來



發文: 416
於 2005-07-31 06:20 user profilesend a private message to usersend email to singlelogreply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
ianhong wrote:
客戶真的不知道他們要什麼嗎? 他們不懂的是IT, 不是商業, 更不是他們的產業. 不知道的是IT可以為他們帶來什麼東西, 且實際可以應用的地方.

從懂商業,到懂系統應該要怎麼樣設計,怎麼樣運作,中間有個很大的gap。當我們在討論客戶不知道他們要什麼的同時,其實是在說,客戶可能很清楚他們的商業邏輯是什麼,不過他們並不了解,商業邏輯->requirement->design之間的對應關係。

在科學的歷程中,很多人會觀察天象,然後做出天體運行的預測。有些人會形成一種理論,對照到各式各樣吉凶的變化,這是占星學。有些人,會觀察行星軌道,思考萬有引力,克卜勒定律...這是物理學。

一般的user,能夠說明現象,可是不見得可以推演出定律來。這就跟古人看到天象,可是不見得會知道萬有引力定律一樣。所以當我們拿各式各樣的requirement去進行confirm時,有些時候會發現,客戶會推翻以往的想法。因為當你嘗試著掌握通則時,可能會有一部份特定的特例。而這些特例,違背了你想要歸納出來的通則。

這只是最好的case。

我遇過有些客戶是真的不知道他們要什麼。因為公司很大,部門很多,而他們沒有辦法整合出內部的意見。特別是當上面的人要求他們配合流行來打造一個系統時,那真是一個大災難。在網路正熱時,這種case很多。每家公司都想要跨入網路產業,也準備了一票錢要花,可是你說他們真的了解商業,或是知道他們要什麼嗎?這很難說呀兄弟。

當然,隨著時間的演化,可能這種狀況會變得比較少。可是我還是相信,只要你做了大公司的案子,你還是有可能遇到一些大公司的米蟲,他們可能自己都搞不清楚他們的商業邏輯是什麼,可是會在你做案子的同時,加入特多有的沒的的意見。


reply to postreply to post
我的書:專案管理Happy書!

我的網站:diggirl.net

my blog http://tinyurl.com/36gcye
作者 Re:客戶100%對的專案=100%失敗的專案? [Re:singlelog]
RR

~Nintendo64~



發文: 686
於 2005-08-01 11:28 user profilesend a private message to userreply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
singlelog wrote:
從懂商業,到懂系統應該要怎麼樣設計,怎麼樣運作,中間有個很大的gap。當我們在討論客戶不知道他們要什麼的同時,其實是在說,客戶可能很清楚他們的商業邏輯是什麼,不過他們並不了解,商業邏輯->requirement->design之間的對應關係。

在科學的歷程中,很多人會觀察天象,然後做出天體運行的預測。有些人會形成一種理論,對照到各式各樣吉凶的變化,這是占星學。有些人,會觀察行星軌道,思考萬有引力,克卜勒定律...這是物理學。

一般的user,能夠說明現象,可是不見得可以推演出定律來。這就跟古人看到天象,可是不見得會知道萬有引力定律一樣。所以當我們拿各式各樣的requirement去進行confirm時,有些時候會發現,客戶會推翻以往的想法。因為當你嘗試著掌握通則時,可能會有一部份特定的特例。而這些特例,違背了你想要歸納出來的通則。

這只是最好的case。

我遇過有些客戶是真的不知道他們要什麼。因為公司很大,部門很多,而他們沒有辦法整合出內部的意見。特別是當上面的人要求他們配合流行來打造一個系統時,那真是一個大災難。在網路正熱時,這種case很多。每家公司都想要跨入網路產業,也準備了一票錢要花,可是你說他們真的了解商業,或是知道他們要什麼嗎?這很難說呀兄弟。

當然,隨著時間的演化,可能這種狀況會變得比較少。可是我還是相信,只要你做了大公司的案子,你還是有可能遇到一些大公司的米蟲,他們可能自己都搞不清楚他們的商業邏輯是什麼,可是會在你做案子的同時,加入特多有的沒的的意見。

也就是獨孤木大大書中所說的那種專門提供悖離邏輯的意見的神奇角色嗎?Tongue
是的,我們的客戶就是公家機關。
大頭們會突發奇想:如果加入些ooxx功能不是應該更好嗎?
下面的嘍囉們則是會要求多一些可以討好大頭的花樣,
甚至於是一些畫面上的排版...Orz
於是我們還得充當美編人員Dead

我想,我們需要的是一個有擔當的PM(敝公司目前沒有PM)
一個能真正抓出方向的Leader,而不是只能用硬幹的方式
完成一些對大頭們的demo,然後被他染指過的程式沒人看的懂,幾乎都要重寫這樣...Angry

算了,孤臣無力可回天。
這期案子完成後,我要要求跳個全新的案子自己當SA。
我再也受不了腦袋裡只有程式面的Leader半吊子的SA與SD埋出來的雷區了。Dead


reply to postreply to post
作者 Re:客戶100%對的專案=100%失敗的專案? [Re:RR]
adoo





發文: 87
於 2005-08-01 15:33 user profilesend a private message to userreply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
我規劃過國軍的案子
深知那些高官的風格
重點是 keyman(公家機關都是官大學問大) 規格要完整仔細 跟 引導高官們把專案控制在我們可以預期的範圍
因此 我們完成了 大家都不看好的專案
專案 金額 八位數(純軟體) 為期四個月
當時 幾乎是不可能的任務
但還是完成了

我想你們真的該換一個好的 leader

RR wrote:
也就是獨孤木大大書中所說的那種專門提供悖離邏輯的意見的神奇角色嗎?Tongue
是的,我們的客戶就是公家機關。
大頭們會突發奇想:如果加入些ooxx功能不是應該更好嗎?
下面的嘍囉們則是會要求多一些可以討好大頭的花樣,
甚至於是一些畫面上的排版...Orz
於是我們還得充當美編人員Dead

我想,我們需要的是一個有擔當的PM(敝公司目前沒有PM)
一個能真正抓出方向的Leader,而不是只能用硬幹的方式
完成一些對大頭們的demo,然後被他染指過的程式沒人看的懂,幾乎都要重寫這樣...Angry

算了,孤臣無力可回天。
這期案子完成後,我要要求跳個全新的案子自己當SA。
我再也受不了腦袋裡只有程式面的Leader半吊子的SA與SD埋出來的雷區了。Dead


adoo edited on 2005-08-01 15:37
reply to postreply to post
作者 Re:客戶100%對的專案=100%失敗的專案? [Re:RR]
singlelog

換回來



發文: 416
於 2005-08-01 17:25 user profilesend a private message to usersend email to singlelogreply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
呵呵,我做過電信公司的案子,他們是只要大頭一講話,就會告訴你,大頭都說要改了,你自己看著辦吧。

大頭的意見除了畫面gui的操作之外,有時候他並不了解detail要做什麼,所以會站在另一個奇怪的制高點來思考系統要做什麼。

當然,如果他講出口的就是聖旨,那也應該還ok。不過這種東西很難說會有什麼變化,所以這邊不可預測性就很高了。當然啦,有些時候就是一些零零碎碎的修改讓人覺得討厭。要做的東西都不會是做不出來的東西,可是就會覺得,哇勒!你幹嘛不早講。

做那種小修小改的東西最磨人的耐性。今天改一個字,後天改一個顏色,大後天加個欄位。你要說這是什麼很大的變化嗎?那當然不是。跟requirement有多大的關連嗎?我覺得還ok。可是叫programmer去改,改久了,他就會覺得,我難道學了這麼久的java,苦讀j2ee,就是為了要改這麼沒有營養的bug嗎?我的成長在那裡?我的未來又在那邊?

像這樣的東西,有時候,也會被叫做是requirement不清楚。Big Smile雖然,我覺得這根本就跟requirement不是那麼地有關。


reply to postreply to post
我的書:專案管理Happy書!

我的網站:diggirl.net

my blog http://tinyurl.com/36gcye
作者 Re:客戶100%對的專案=100%失敗的專案? [Re:adoo]
RR

~Nintendo64~



發文: 686
於 2005-08-01 19:47 user profilesend a private message to userreply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
adoo wrote:
我規劃過國軍的案子
深知那些高官的風格
重點是 keyman(公家機關都是官大學問大) 規格要完整仔細 跟 引導高官們把專案控制在我們可以預期的範圍
因此 我們完成了 大家都不看好的專案
專案 金額 八位數(純軟體) 為期四個月
當時 幾乎是不可能的任務
但還是完成了

我想你們真的該換一個好的 leader

哇!那專案獎金想必不少吧...真羨慕。
我們的案子總金額也超過20M的。
可是老闆不僅小器且膽子很大,
這樣的案子只有兩個人在Handle,
其中一個是不怎樣的Leader...

不過,要換掉他很難。因為它是老闆的紅牌。
可以在時間內硬幹完成大頭目要看的demo...

所以,一個好的PM真的是最重要的。
好的SA可以讓專案好過些。
好的Leader要懂得去Handle問題,
可是,這一切都集合的機率想必比中樂透低吧。
尤其是對方是公家機關,大頭一堆又沒個主見時...
真不知如何是好∼

附註:託大家的福,這篇竟然置頂放精華了∼Sleepy


reply to postreply to post
作者 Re:客戶100%對的專案=100%失敗的專案? [Re:RR]
ianhong





發文: 2
於 2005-08-01 20:38 user profilesend a private message to userreply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
Post is deleted

ianhong edited on 2007-04-26 15:14
reply to postreply to post
作者 Re:客戶100%對的專案=100%失敗的專案? [Re:singlelog]
adoo





發文: 87
於 2005-08-01 22:43 user profilesend a private message to userreply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list

所以我們還沒coding 就先做畫面
請大頭看過 說滿意 才動工
不然這些大頭 看門面很會
每次都改顏色 改欄位 一付很專業的樣子

singlelog wrote:
呵呵,我做過電信公司的案子,他們是只要大頭一講話,就會告訴你,大頭都說要改了,你自己看著辦吧。

大頭的意見除了畫面gui的操作之外,有時候他並不了解detail要做什麼,所以會站在另一個奇怪的制高點來思考系統要做什麼。

當然,如果他講出口的就是聖旨,那也應該還ok。不過這種東西很難說會有什麼變化,所以這邊不可預測性就很高了。當然啦,有些時候就是一些零零碎碎的修改讓人覺得討厭。要做的東西都不會是做不出來的東西,可是就會覺得,哇勒!你幹嘛不早講。

做那種小修小改的東西最磨人的耐性。今天改一個字,後天改一個顏色,大後天加個欄位。你要說這是什麼很大的變化嗎?那當然不是。跟requirement有多大的關連嗎?我覺得還ok。可是叫programmer去改,改久了,他就會覺得,我難道學了這麼久的java,苦讀j2ee,就是為了要改這麼沒有營養的bug嗎?我的成長在那裡?我的未來又在那邊?

像這樣的東西,有時候,也會被叫做是requirement不清楚。Big Smile雖然,我覺得這根本就跟requirement不是那麼地有關。


reply to postreply to post
作者 Re:客戶100%對的專案=100%失敗的專案? [Re:RR]
adoo





發文: 87
於 2005-08-01 22:47 user profilesend a private message to userreply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
我只知道 扣掉成本 8 成是淨賺
可惜的是 之前公司虧太多 所以都拿來貼補
我是剛好本來就是總部呆過
所以知道怎跟他們打交道
當時我主管不敢負責任 把案子都交給我規劃
自己跑去coding 我反而負責規劃需求跟規格 與專案規劃
等到 驗收完成後 檢討會議時 卻跳出來說 這些都是他的功勞
往事真是不堪回首

RR wrote:
哇!那專案獎金想必不少吧...真羨慕。
我們的案子總金額也超過20M的。
可是老闆不僅小器且膽子很大,
這樣的案子只有兩個人在Handle,
其中一個是不怎樣的Leader...

不過,要換掉他很難。因為它是老闆的紅牌。
可以在時間內硬幹完成大頭目要看的demo...

所以,一個好的PM真的是最重要的。
好的SA可以讓專案好過些。
好的Leader要懂得去Handle問題,
可是,這一切都集合的機率想必比中樂透低吧。
尤其是對方是公家機關,大頭一堆又沒個主見時...
真不知如何是好∼

附註:託大家的福,這篇竟然置頂放精華了∼Sleepy


reply to postreply to post
作者 Re:客戶100%對的專案=100%失敗的專案? [Re:ianhong]
singlelog

換回來



發文: 416
於 2005-08-01 23:59 user profilesend a private message to usersend email to singlelogreply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
ianhong wrote:
這個有混淆的狀況. 是我們在開發系統 不是客戶在開發系統. 客戶想要的是我們的協助來導入系統, 不是他們自己導入系統.
(biz logic -> system requirement 不應該是客戶的義務, 是SA或顧問公司的義務)

我同意你的看法,所以我說的是客戶可能很清楚他們的商業邏輯是什麼,不過他們並不了解,商業邏輯->requirement->design之間的對應關係。因為requirement document,並不是把user的語錄整理出來就ok的。所以客戶有可能可以提出很多規則,可是他們並不"知道"他們真正需要的是什麼?

ianhong wrote:
每件事情都有它的原因跟理由. 如果你不知道因果, 那就只是依樣畫葫蘆. 當user要推翻時, 你也不會知道原因, 就只能照做. 在這你太仰賴user了. 且你也太害怕user了. 以上你講太多名詞了, 就好像一些死讀書的高材生 只會套用公式去解決問題, 但是很多實際社會問題變數更多. 並非一兩個公式可以解決的. 與其抱怨客戶變來變去, 還不如先思考客戶為什麼會變來變去. 更去思考客戶實際想要的是什麼.

如果是以以前專案的特性, 主要都是在抓點(需求,requirement)做成功能, 但不知道面(需要, 亦solution). 所以很容易發生兩個點湊不成一條線,甚至一個面. 以我之前講的barcode案例, 如果我只單純依照客戶說的做, 最後會因為實際成果不如客戶想要的就全部被推翻掉. 然後再去測試下一個可能方案, 直到客戶自己滿意為止.

在這邊我只是嘗試為客戶為什麼會在專案進行的過程中,提出完全不同的需求做解釋。當然,很多時候做案子的人不見得是這個domain的行家,我在RR的例子裡面看到的是,有人堅持一定要達到某一個feature,然後又把它全部推翻掉。

當客戶堅持的時候,也不是仰賴或害怕,那就看你是不是有辦法說服他了。你要是說服不了他,你還想不想結案呢?

ianhong wrote:
你是指網路購物產業嗎? 還是電子流程應用?

我看你想要講應該是新興產業. 任何新興產業都有一定的風險. 這些風險不是我們的責任. 如果是以網路購物來講, 這必須經過一定的評估跟研究. 但在軟體供應商來說, 我們在乎的是提供怎樣的平台給user.

事實上我不太清楚你是指怎樣的產業. 不過我感覺你非常仰賴客戶給你答案. 如果你完全配合user做他們想要的, 最後做出來的就只是隨便拼湊的拼裝車. 問題自然就多了. 分析需求是你們應該要思考的問題.

你可能沒遇過這種狀況,某個大公司,大老闆說,現在大家都在e化,我們也來e化。好,你們去找顧問公司來寫proposal。

顧問公司寫完proposal了。大頭說,好那就發包出去,就照proposal去做。

你拿到的東西就是一個很奇怪的proposal。客戶的PM說,我看過了,這裡面的東西不合我們用,可是前面的人讓proposal結案了。我們要做別的系統。scope是A,B,C,D,E

你們公司缺錢,所以決定去包這個案子下來做。A...我要是不靠客戶給我答案,那誰要給我答案呢?

我們去做了需求訪談,客戶說,我們以前也沒搞過e化,事實上大老闆想e化,可是我覺得做不起來。這邊的作業流程我們也還在討論。下一次告訴你。

下次告訴你時跟第一次又不一樣。等到要驗收時,又跟告訴你的不一樣。做到一半,客戶可能又有一個大頭說,那以前的那份proposal呢?花那麼多錢去找顧問來規劃的呀。怎麼沒有把它的精神納進來?(唉,那裡還有精神呀?整個東西都不一樣,還要有什麼精髓?)

在網路很熱的時候,這種事我遇過不少。

ianhong wrote:
關於小修小改的東西, 忽然覺得iterative比waterfall好太多了. hahaha.

小修小改我們通常也就是在UAT的時候去改它。哈哈哈。不會比iterative多啦。

不過光改一次就會讓人覺得很機車了。為了要上線可能會多demo個幾回,那有可能就會改來改去改幾遍。


reply to postreply to post
我的書:專案管理Happy書!

我的網站:diggirl.net

my blog http://tinyurl.com/36gcye
作者 Re:客戶100%對的專案=100%失敗的專案? [Re:singlelog]
ianhong





發文: 2
於 2005-08-02 01:30 user profilesend a private message to userreply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
Post is deleted

ianhong edited on 2007-04-26 15:14
reply to postreply to post
作者 Re:客戶100%對的專案=100%失敗的專案? [Re:ianhong]
singlelog

換回來



發文: 416
於 2005-08-02 01:55 user profilesend a private message to usersend email to singlelogreply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
ianhong wrote:
試想你是一個企業經營顧問, 你要去說服老闆. 你應該不會空手去.
無果你知道那是不可行的, 那你一定有理由. 如果不是不可行, 而是自己辦不到. 那你應該接這個案子嗎?

去包一個做不到的case, 還去包那一定有問題. 如果因為缺錢, 去包一個賠錢的案子, 那那家公司一定要倒閉.

ianhong一直認為做專案的人,可以主導整個案子的scope是什麼。可是這並不是always happen。很多做專案的人並沒有辦法挑客戶,況且,scope不清楚,requirement不清楚,很多專案一開始就都是這樣。不過,這並不表示不賺錢。

ianhong wrote:
你這裡還是一樣, 有問題就要跟客戶談. 如果有問題還硬要答應, 那是你們SA或PM不夠盡責. 客戶會有要求是常態, 但是分析是你們該做的. 可以做的, 不可以做的 還有怎麼做 是你們應該分析的. 客戶要給你什麼答案? 她給你的不就只有企業營運模式, 文化, 跟他們想要的. 而不是跟你講系統怎麼作.

就算是顧問公司提的 proposal 也並非不能推翻. 很多顧問公司也是很混的. 問自己你敢不敢挑戰董事長跟總經理講的話. 如果你不敢, 那你就只能附和. 我看過傳統產業的公司就是因為員工一直附和總經理的話, 最後整個企業越來越下滑. 結果問題本身就是總經理跟整個企業文化. ok 對應到SE, 應該就是team的文化跟能力.

你太依賴客戶了, 我不敢幻想客戶會給正確答案. 我自己會去思考他們的問題, 看他講的是不是就是他們需要的. 不過我也不是很專業, 失敗的還是很多.

我只能說,可能每個人遇到的case不一樣。Big Smile

很多東西,並不是說不能改。也不是說做不到。客戶要我們把電腦咬碎再吞下去,我們當然做不到。可是客戶要你東改改西改改,你說你真的做不到嗎?Big Smile不過很多時間跟力氣就這樣消耗掉了。我不會去挑戰客戶講的話,我只會去導引他們的想法。

至於很多人有各式各樣的想法,想要在這個專案裡面實現,這在大公司裡面也是正常的。當然不管客戶內部怎麼說,都是要以正式會議記錄為主。不過你遇到客戶的大頭講話,很多時候就是要賣人家的面子。因為把跟你對口的人弄死了,讓他被大頭盯,這一點好處也沒有。

我遇過不少客戶對於business logic瞭若指掌。他們的規則非常清晰,思緒也很清楚,也就是說,他們講的就是正確答案。你光讓系統可以照著正確答案走,就是他要的了。

ianhong wrote:
UI 還有小地方通常是最快被找出來的地方. 如果一開就知道user要的style, 你之後還被挑UI的機率就比較低. 且你也不需要等到UAT一次被全部挑出來. 一開始就被挑出一點點, 那還會犯相同的錯誤嗎?

哈哈哈。我遇過那種在挑message全半形符號的人。也遇過那種wording字斟句酌要改作文改到一百分的啦。這種東西多半我們在做UT/IT都不會挑出來。可是UAT時,常常會今天改一個詞,後面有人看不懂,就再改一句話。然後一路改下去。雖然大部份都是改properties就搞定,不過改這種東西,調欄位寬度位置...實在很少programmer會覺得很營養。

ianhong wrote:
光改一次?? 好像很多PM會把在user那裡的氣 拿回到公司發洩給組員. 但是這並不能提高效率, 反而會降低效率. 在我的經驗裡面 被請去debug我並不會不爽, 被逼去debug才會. 只有PM會被客戶逼去debug, 但實際debug是工程師. 怎麼去管理好這個關係鍵很重要. 我覺得你們覺得機車是因為PM把壓力轉送給你們才會如此.

這位老兄,哇係PM啦。所以我都會想想,這個人如果整天就改這個,會不會下個月就給我遞辭呈了。這跟PM把壓力給誰都無關。人難找,怎麼把人keep住很重要呀。


reply to postreply to post
我的書:專案管理Happy書!

我的網站:diggirl.net

my blog http://tinyurl.com/36gcye
作者 Re:客戶100%對的專案=100%失敗的專案? [Re:singlelog]
ianhong





發文: 2
於 2005-08-02 03:23 user profilesend a private message to userreply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
Post is deleted

ianhong edited on 2007-04-26 15:14
reply to postreply to post
作者 Re:客戶100%對的專案=100%失敗的專案? [Re:RR]
singlelog

換回來



發文: 416
於 2005-08-02 13:49 user profilesend a private message to usersend email to singlelogreply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
耶,有言詞笨拙的問題嗎?不要太激動吧。Big Smile讓我們回歸到問題的本質吧。

1.客戶知道不知道他們要的是什麼?
我遇過兩種人,有些時候,一個案子會同時出現這兩種人,不過大多數情況,只會有一種:
1.1客戶很清楚的知道他們的商業邏輯,scope也很清楚,所以你要把他們的規則轉化成requirement。不過即使是這樣,我也不預期就會做出一個跟客戶期待相同的產品。

1.2客戶不清楚,只是被指派出來開發一個專案,專案的scope很不清楚。這種人,有很高的機會還是主管。

不管是那一種,你都要引導他們。因為他們有可能不了解,商業邏輯->requirement->design之間的對應關係。所以這是SA的工作。

引導客戶的想法<>客戶會同意你提出來的各種作法,我個人不認為,你可以去主導什麼是應該要做的且怎麼做。很多案子都有RFP。RFP表示了客戶想要做的系統是什麼。或許這個地方是我跟ianhong觀感差比較多的地方。我認為,你不管要怎麼樣變化,都會受合約,雙方開發時的會議記錄,這些東西來限制系統的 scope。他們說一定要做的東西,你要怎麼引導到不要做,這需要很高深的技巧。我自己是沒有學會這一塊。

2.會不會有creeping requirement?擋不擋得掉?
我個人認為,做專案的時間越長,對user大頭的demo越多,很有可能會有一些原本沒有認知到要做的requirement偷渡進來,而這些requirement有很多是沒有辦法回絕的。因為很多時候,這些需求來自高層。

當我講說你要考慮你對口的窗口,其實也就是要幫對方想想。他提出的新需求,是新的需求,或是需求變更。你可以選擇拒絕新需求,或是拒絕對方做需求變更,也可以選擇接受。不是把問題推回去給窗口。

3.被逼去debug才會不爽 vs 被請去debug會不會不爽
我聽過各式各樣的壓力來源。每個人不一樣。

有些人,會對客戶不斷地修改小bug不耐煩,他會覺得,他學了那麼多,不是為了要改這些東西的。我待過員工常常離職的公司,也有方法讓programmer在我的team裡面活得很快樂,離職率很低。這邊的關鍵是,你要為每一個人去考量他的需求與想法。

有些人,是你請他去改bug,他就願意去改。有些人,是你請他去改bug,他還會想很多,生命價值的問題。每個人對工作有不同的期望,也有不同的個性。

我說我是PM,其實是要講,我並不會把在user那裡的氣,拿回到公司發洩給組員。通常我會覺得,一起陪組員去罵很爛的user比較爽。從這邊我只能推測,ianhong大概受了不少PM的氣。Big Smile


reply to postreply to post
我的書:專案管理Happy書!

我的網站:diggirl.net

my blog http://tinyurl.com/36gcye
作者 Re:客戶100%對的專案=100%失敗的專案? [Re:ianhong]
roway





發文: 0
於 2005-08-02 17:58 user profilesend a private message to userreply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
ianhong wrote:

你的意思是把問題推回去給窗口嗎? 我的意思是把問題解決掉. 如果他提出的需求就是個問題, 那是要去解決. 而不是推回去給窗口.


個人覺得有些問題可以把它推回去給窗口,特別是在窗口自己也沒有很清楚自己的需求的時候.


reply to postreply to post
作者 Re:客戶100%對的專案=100%失敗的專案? [Re:RR]
RR

~Nintendo64~



發文: 686
於 2005-08-02 19:11 user profilesend a private message to userreply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
弟覺得這類型的案子,客戶本身有沒有覺悟要讓企業隨著ERP系統一起成長...
我們的客戶啊...就是那む開機後會自我測試め的東西啊∼
(超明顯的暗示了)Sleepy

而我們的客戶就是這樣八股,組織層級架構很大。
這樣的公司多半不願意為了ERP去改變一推人已經習慣的作業流程。
加上該公司資訊處權限也不太夠,又有一堆等退休反對改革的老賊,
所以這案子餅畫的很大,可是淺如我都覺得這案子最後一定會失敗!
哪有人ERP這樣搞的...Orz

公司又不斷強調:我們會和客戶直接接觸,要做好關係。
所以,面對這樣的客戶,想む稍微め不太贊成對方的要求
都會受到強大的壓力關切...
終於政治與人情壓力還是永遠凌駕於專業之上Dead

唉∼這個案子可能會成為我專業生涯上的一個污點吧。Sad


reply to postreply to post
go to first page go to previous page  1   2  go to next page go to last page
» JWorld@TW »  交流、聊天、灌水

reply to topicthreaded modego to previous topicgo to next topic
  已讀文章
  新的文章
  被刪除的文章
Jump to the top of page

JWorld@TW 本站商標資訊

Powered by Powerful JuteForum® Version Jute 1.5.8