<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>「為何工程師無法發現問題？」的迴響</title>
	<atom:link href="http://www.lifeparty.idv.tw/blog/archives/1232/feed" rel="self" type="application/rss+xml" />
	<link>http://www.lifeparty.idv.tw/blog/archives/1232</link>
	<description>君子學以聚之,問以辨之,寬以居之,仁以行之</description>
	<lastBuildDate>Wed, 21 Jul 2010 05:43:23 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0</generator>
	<item>
		<title>由：arithmandar</title>
		<link>http://www.lifeparty.idv.tw/blog/archives/1232/comment-page-1#comment-9291</link>
		<dc:creator>arithmandar</dc:creator>
		<pubDate>Mon, 31 Aug 2009 09:07:21 +0000</pubDate>
		<guid isPermaLink="false">http://www.lifeparty.idv.tw/blog/?p=1232#comment-9291</guid>
		<description>「為什麼工程師無法發現問題」，簡單提供不同的看法。
原因可能會包含：
問題回報不夠明確，沒有詳細的問題重製步驟，因此工程師無法重新產生使用者遇到的問題
以家電產品而言，這些工程師往往是專門的維修工程師，而不是像軟體業往往是把問題回報到開發團隊。當然大型軟體公司諸如趨勢科技等也是會有配置專門的軟體維運工程部們，負責處理產品上市後的維運與保固。
個人認為，工程師的難處往往在於無法輕易重製問題，如此第一步就跨不出去了。我自己也常有朋友丟問題來給我，可我卻常常無法解決，因為我連問題重製都有困難了，往往得再三詢問詳細步驟、環境、前因後果等等，待問題可以重製之後，才有辦法去找問題的所在，以及如何解決。

有時候比較難的是當問題是偶發的，其實不是偶發，而是真正會造成問題發生的因素尚未明確，這時基於時間因素，不僅使用者很難找出一定會出錯的操作方式，在工程師那一端也會有同樣困難，如此後續的修復更是難上加難。

不過，顯然，若真是因為PAL/NTSC的因素，照理說若是工程師無法重製問題，只因傳輸線的差異，理論上收到的維修報告應該是「經查，功能正常」（Not Reproducible），而不應該是修復。</description>
		<content:encoded><![CDATA[<p>「為什麼工程師無法發現問題」，簡單提供不同的看法。<br />
原因可能會包含：<br />
問題回報不夠明確，沒有詳細的問題重製步驟，因此工程師無法重新產生使用者遇到的問題<br />
以家電產品而言，這些工程師往往是專門的維修工程師，而不是像軟體業往往是把問題回報到開發團隊。當然大型軟體公司諸如趨勢科技等也是會有配置專門的軟體維運工程部們，負責處理產品上市後的維運與保固。<br />
個人認為，工程師的難處往往在於無法輕易重製問題，如此第一步就跨不出去了。我自己也常有朋友丟問題來給我，可我卻常常無法解決，因為我連問題重製都有困難了，往往得再三詢問詳細步驟、環境、前因後果等等，待問題可以重製之後，才有辦法去找問題的所在，以及如何解決。</p>
<p>有時候比較難的是當問題是偶發的，其實不是偶發，而是真正會造成問題發生的因素尚未明確，這時基於時間因素，不僅使用者很難找出一定會出錯的操作方式，在工程師那一端也會有同樣困難，如此後續的修復更是難上加難。</p>
<p>不過，顯然，若真是因為PAL/NTSC的因素，照理說若是工程師無法重製問題，只因傳輸線的差異，理論上收到的維修報告應該是「經查，功能正常」（Not Reproducible），而不應該是修復。</p>
]]></content:encoded>
	</item>
</channel>
</rss>
