<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0" 
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:atom="http://www.w3.org/2005/Atom">
<channel>
<title>從這次博客來的個資問題來看網站程式設計的困境</title>
<link>http://blog.roodo.com/genehong/archives/4432799.html/</link>
<description><![CDATA[我在前幾天就知道這件事情了, 但不是因為新聞, 當我看到時, 並沒有想到這件事會多嚴重, 畢竟這樣的事, 是蠻常見的, 甚至是屬於真的很難解決的疏失, 甚至我在四年前也犯過相同的錯誤, 而這次就比較嚴重了, 但我想到的是, 以一個網站程式設計師來看這個困境.]]>
	</description>
<language>zh-tw</language>
<generator>Roodo Blog System</generator>
<copyright>All Rights Reserved</copyright>
<atom:link href="http://blog.roodo.com/genehong/archives/4432799-comment.xml" rel="self" type="application/rss+xml" />
<item>
	<title>回應：從這次博客來的個資問題來看網站程式設計的困境</title>
	<description><![CDATA[給事實上我不知道 "YouKnowWho" 的人:

太感謝您跳出來說話了...:)
我的確對金融界狀況不夠了解, 有一個了解的人出來說話就太好了, 因為我都是因為朋友的關係才會知道, 並不是親身體驗..

因為我們一直被金融界的人笑, 說我們的系統是由一群少數人來寫, 且用的是很少的時間與週期, 文件與測試都不夠詳盡, 所以我才會這樣說...

但我大概說一下, 我知道金融界的程式一年改個 30~50 次不算甚麼, 但我說的這邊網路界是一年要開發 30~50 個功能或系統...

我偷偷跟你講一件事情, 像金馬影展從確定主辦後, 離開賣的時間是不到一個月的, 我不知道在金融界有沒有可能從規劃到寫程式, 到測試, 執行, 上線, 是在 10天內完成, ....

這個問題在我開始接觸時就感觸很深, 我知道網路界若要改變這個現實, 人力資源要增加 30% 到 50%, 且時程要延長 50% 到 70%, 我在五六年前還認為這是應該的, 但我要說的網路現實是現在做的是在兩個月前沒想到的, 現在做的半年後也不見得能用, ... 

我不否認博客來的管理疏失, 但我只是想說的是這是網路現實結構面, ....

我常說, 一張網路架構圖在網路公司的時效性是三天到五天, 所以通常是須要用的時候再畫, 且當要求者看到的時候事實上已經是不一樣了...

但我承認您說的一句話: "以資源不對等作引子，導出程式產品品質的差異為合理，小弟個人覺得真是胡扯", 這真的是要改變的... 因為我也真的很希望網路公司能夠有 "複數" 人去負責一隻程式, 只是好像都是一個人去擔負 "許多" 系統與程式, ..... 唉~~~

我想你聽到應該很難想像吧, 我也承認是管理的問題, 但管理最主要是安排資源, 我也知道程式一定要 "檢查" 阿, 但事實是只有一個人要在一天內完成時, 真的問題可能是要歸咎為甚麼只有這麼少的時間與人力吧? 

btw, 你真的確定我 "YouKnowWho"?]]>
	</description>
	<link>http://blog.roodo.com/genehong/archives/4432799.html</link>
	<guid>http://blog.roodo.com/genehong/archives/4432799.html#comment-14973279</guid>
	<author>gene@urs.tw(黑貘)</author>	<category>文章回應</category>
	<pubDate>Mon, 12 Nov 2007 11:43:33 +0800</pubDate>
</item>
<item>
	<title>回應：從這次博客來的個資問題來看網站程式設計的困境</title>
	<description><![CDATA[通常一個金融系統, 大約 2~3 年才會更新系統一次, 而每次更新系統動用的人力與週期, 大約是以千萬到億的資源預算來計算, 但很不幸的, 網站更新或製作新系統約是 1 年 30~50 個左右, 每個系統可動用的資源大概不到是百萬的計算, 若是說要有相同的除錯檢查水準是不可能的.

不知道貘兄以上的說法是有什麼直接證據, 業界經驗或只是”想當然爾”??

金融資訊系統其實不如您想像中的預算龐大，您講的更新週期二到三年也是錯誤的，小弟碰巧在金融資訊業服務，對內情略知一二，舉這兩個例，然後以資源不對等作引子，導出程式產品品質的差異為合理，小弟個人覺得真是胡扯

以台灣為例子，因為政府金融法令及政策修改頻繁，加上使用者需求不斷變更，以小弟經手的金融資訊系統而言，幾乎都是處在不斷的修改過程中，從系統上線交付驗收完成開始就不斷的在作變更修改，金融資訊系統一年修改 30 ~ 50 次也不是沒發生過，系統整套或許是千萬或數億來計價，但是別忘了銀行是很摳門的，後續因法令修正或使用者需求變更而造成的系統程式及流程修改，平均單價並沒有您想像中的多，講不客氣一點很多時候甚至是沒有錢可以拿的，金融資訊業也是毛利率很低呀，因此拿這兩個相比然後說金融資訊業除錯水準高事屬應然而博客萊毛利低資源不足犯錯可以理解完全是想當然爾的講不通

基本上我贊同不應該苛責寫那支程式的 pg, 但是負責那個案子的 pm 及博客萊絕對是該死，程式變數應清除而未清除基本上只有兩個解釋"粗心"及"偷懶", 什麼東西用完該清不該清對 pg 來講是 common scense, 沒清也許是因為過去經驗都是如此而沒事所以就沒清，但絕不代表這是一個合格的 pg 應該作出來的事，也不代表博客萊沒有檢查到事屬應當

pg 之所以寫出這樣的 code 完全可以視為管理上的嚴重疏失，pg 犯錯就算了，pm 也未盡到監控的責任，過失殺人也是殺人，絕不是輕飄飄的用"這是大家都會犯的錯"來帶過就好，更毋論這並不是所謂"大家都會犯的錯"

出來吐你槽對我個人沒什麼好處，只不過看的人或許會因為您"想當然爾"的一廂情願想法而被誤導，同時非業界的網友因不瞭解內情也許會覺得您講的沒錯而不會去發現這個基本上乃是管理上的嚴重疏失，不是什麼"大家都會犯的錯"]]>
	</description>
	<link>http://blog.roodo.com/genehong/archives/4432799.html</link>
	<guid>http://blog.roodo.com/genehong/archives/4432799.html#comment-14972753</guid>
	<author>ykw@someplace.com(YouKnowWho)</author>	<category>文章回應</category>
	<pubDate>Mon, 12 Nov 2007 10:09:20 +0800</pubDate>
</item>
<item>
	<title>回應：從這次博客來的個資問題來看網站程式設計的困境</title>
	<description><![CDATA[真是難為工程師了 @@

連續出了兩三次狀況，一般的使用者是會受不了的；
但是，從其中得到的經驗確實能成為未來改進的參考，
如果在這之前能夠進行大規模的測試，
或許情況就會不一樣了吧?

不是很忍心苛責博客來，可這次的表現跟過去相比，
對比真的很明顯啊..]]>
	</description>
	<link>http://blog.roodo.com/genehong/archives/4432799.html</link>
	<guid>http://blog.roodo.com/genehong/archives/4432799.html#comment-14972013</guid>
		<category>文章回應</category>
	<pubDate>Mon, 12 Nov 2007 03:58:40 +0800</pubDate>
</item>
<item>
	<title>回應：從這次博客來的個資問題來看網站程式設計的困境</title>
	<description><![CDATA[siegfy:

但這種話不能對外說阿....

所以可以這樣說: "以業界的觀點是成功, 但對使用者的觀點是失敗"... 

因為業界的人知道問題是出在那邊... 唉~~]]>
	</description>
	<link>http://blog.roodo.com/genehong/archives/4432799.html</link>
	<guid>http://blog.roodo.com/genehong/archives/4432799.html#comment-14967125</guid>
	<author>gene@urs.tw(黑貘)</author>	<category>文章回應</category>
	<pubDate>Sun, 11 Nov 2007 14:18:22 +0800</pubDate>
</item>
<item>
	<title>回應：從這次博客來的個資問題來看網站程式設計的困境</title>
	<description><![CDATA[很久不見
今天我也變成一個差點翻桌的使用者了
我想責任最大的應該是金馬執行委員會吧 XD]]>
	</description>
	<link>http://blog.roodo.com/genehong/archives/4432799.html</link>
	<guid>http://blog.roodo.com/genehong/archives/4432799.html#comment-14965715</guid>
	<author>siegfy@gmail.com(siegfy)</author>	<category>文章回應</category>
	<pubDate>Sun, 11 Nov 2007 04:24:26 +0800</pubDate>
</item>
<item>
	<title>回應：從這次博客來的個資問題來看網站程式設計的困境</title>
	<description><![CDATA[對阿
是人都嘛會犯錯
不要老用放大鏡看事情
有時候為了貪一點小便宜洩露的個資比這種次數還多呢]]>
	</description>
	<link>http://blog.roodo.com/genehong/archives/4432799.html</link>
	<guid>http://blog.roodo.com/genehong/archives/4432799.html#comment-14945183</guid>
		<category>文章回應</category>
	<pubDate>Thu, 08 Nov 2007 09:54:07 +0800</pubDate>
</item>
<item>
	<title>回應：從這次博客來的個資問題來看網站程式設計的困境</title>
	<description><![CDATA[我覺得今天許多人的怒氣，有一大半跟博客來在發生問題之後的處理態度有關。我真的開始對週六劃位更憂心了...]]>
	</description>
	<link>http://blog.roodo.com/genehong/archives/4432799.html</link>
	<guid>http://blog.roodo.com/genehong/archives/4432799.html#comment-14943977</guid>
		<category>文章回應</category>
	<pubDate>Thu, 08 Nov 2007 01:31:15 +0800</pubDate>
</item>
<item>
	<title>回應：從這次博客來的個資問題來看網站程式設計的困境</title>
	<description><![CDATA[這幾乎是所有程設都會遇到的慘痛經驗~
以我們公司來說~
其實QC做的算嚴謹
但畢竟還是少量測試
有時上線偶爾還是會發生問題
又或者開發的Lab環境和線上環境多少也會有差異而導致錯誤的發生~
以上並不是說程設就完全可以撇清責任
只是人非聖賢~這也是難以避免的~]]>
	</description>
	<link>http://blog.roodo.com/genehong/archives/4432799.html</link>
	<guid>http://blog.roodo.com/genehong/archives/4432799.html#comment-14940851</guid>
	<author>chonpin@ms4.url.com.tw(熊瓶)</author>	<category>文章回應</category>
	<pubDate>Wed, 07 Nov 2007 17:58:34 +0800</pubDate>
</item>
</channel>
</rss>