<?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/25/feed" rel="self" type="application/rss+xml" />
	<link>http://www.lifeparty.idv.tw/blog/archives/25</link>
	<description>君子學以聚之,問以辨之,寬以居之,仁以行之</description>
	<lastBuildDate>Sat, 14 Jan 2012 03:40:34 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.1.1</generator>
	<item>
		<title>由：同人的生活派對 &#187; 溝通的關鍵時刻</title>
		<link>http://www.lifeparty.idv.tw/blog/archives/25/comment-page-1#comment-7122</link>
		<dc:creator>同人的生活派對 &#187; 溝通的關鍵時刻</dc:creator>
		<pubDate>Wed, 26 Mar 2008 04:34:24 +0000</pubDate>
		<guid isPermaLink="false">http://www.lifeparty.idv.tw/blog/archives/25#comment-7122</guid>
		<description>[...] 因為增加或修改系統功能這件事本身並不是客戶真正的目的，而只是客戶以為可以達到目的的策略。開發者應該要去探詢這個策略其背後的真正的需要，才能發展出可以解決客戶問題的需求，而 CRIB 法正可以協助開發者與客戶達成在對需求認知上的共識。 [...]</description>
		<content:encoded><![CDATA[<p>[...] 因為增加或修改系統功能這件事本身並不是客戶真正的目的，而只是客戶以為可以達到目的的策略。開發者應該要去探詢這個策略其背後的真正的需要，才能發展出可以解決客戶問題的需求，而 CRIB 法正可以協助開發者與客戶達成在對需求認知上的共識。 [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>由：同人的生活派對 &#187; 軟體開發是工藝還是工程？</title>
		<link>http://www.lifeparty.idv.tw/blog/archives/25/comment-page-1#comment-3134</link>
		<dc:creator>同人的生活派對 &#187; 軟體開發是工藝還是工程？</dc:creator>
		<pubDate>Thu, 05 Jul 2007 08:16:04 +0000</pubDate>
		<guid isPermaLink="false">http://www.lifeparty.idv.tw/blog/archives/25#comment-3134</guid>
		<description>[...] 有了這樣的推論，我們可以假設軟體開發是工藝，可是，依同人實務上的觀察，問題好像沒有那麼簡單，尤其是要「把客戶想要的軟體做出來」，說起來簡單，做起來卻很困難。雖然減少了開發者之間了的溝通界面，但這樣一來，開發者就必須直接和客戶溝通來導出客戶需求。開發者往往會發現，導出客戶需求有三大障礙[1]：客戶常常不知道他們真正需要的是什麼、永遠會有需求被遺漏、開發者與客戶之間的不同語言而導致溝通不良。而工藝技術在這方面卻使不上一點力，卻常常會有反效果。溝通在軟體專案的開發過程中，永遠是最重要的呀。沒有足夠溝通，軟體開發很容易造成不知所託或所知非託的現象，而結論都是一樣－導致專案失敗。 [...]</description>
		<content:encoded><![CDATA[<p>[...] 有了這樣的推論，我們可以假設軟體開發是工藝，可是，依同人實務上的觀察，問題好像沒有那麼簡單，尤其是要「把客戶想要的軟體做出來」，說起來簡單，做起來卻很困難。雖然減少了開發者之間了的溝通界面，但這樣一來，開發者就必須直接和客戶溝通來導出客戶需求。開發者往往會發現，導出客戶需求有三大障礙[1]：客戶常常不知道他們真正需要的是什麼、永遠會有需求被遺漏、開發者與客戶之間的不同語言而導致溝通不良。而工藝技術在這方面卻使不上一點力，卻常常會有反效果。溝通在軟體專案的開發過程中，永遠是最重要的呀。沒有足夠溝通，軟體開發很容易造成不知所託或所知非託的現象，而結論都是一樣－導致專案失敗。 [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>由：同人的生活派對 &#187; 委外與流程整合</title>
		<link>http://www.lifeparty.idv.tw/blog/archives/25/comment-page-1#comment-1332</link>
		<dc:creator>同人的生活派對 &#187; 委外與流程整合</dc:creator>
		<pubDate>Mon, 30 Apr 2007 06:38:54 +0000</pubDate>
		<guid isPermaLink="false">http://www.lifeparty.idv.tw/blog/archives/25#comment-1332</guid>
		<description>[...] 以資訊產業發展現況來看，由於經濟情勢的改變，資訊支出軟為保守，企業對資訊的投資趨於精準化，轉向競爭力的思考，大型資訊基礎建置不容易看見[4]。所以，站在「專門包別人的人」的立場來看資訊委外服務，委外資訊服務的策略定位應放在整合既有系統而非建置全新的資訊系統。對於系統分析與設計人員而言，其難度與複雜度更甚於過去。所以，他們更須具備有問題的分析能力，誠如我之前曾說過的： 當客戶告訴我們他所需要的功能時，其實是以為這些功能可以解決他們的問題，但這種假定可能是錯誤的，這也就是系統分析師必須要做的工作，了解客戶業務上面臨的問題，找出他們真正需要的是什麼，然後才提出資訊解決方案；如果我們只是照著客戶提出的功能來開發資訊系統，而沒有進一步地了解客戶需要解決的問題是什麼？他為什麼需要這些功能？當系統開發完成後，客戶會發現他的問題並沒有被解決，也就是認定我們所開發的資訊系統沒有符合他的需要。 [...]</description>
		<content:encoded><![CDATA[<p>[...] 以資訊產業發展現況來看，由於經濟情勢的改變，資訊支出軟為保守，企業對資訊的投資趨於精準化，轉向競爭力的思考，大型資訊基礎建置不容易看見[4]。所以，站在「專門包別人的人」的立場來看資訊委外服務，委外資訊服務的策略定位應放在整合既有系統而非建置全新的資訊系統。對於系統分析與設計人員而言，其難度與複雜度更甚於過去。所以，他們更須具備有問題的分析能力，誠如我之前曾說過的： 當客戶告訴我們他所需要的功能時，其實是以為這些功能可以解決他們的問題，但這種假定可能是錯誤的，這也就是系統分析師必須要做的工作，了解客戶業務上面臨的問題，找出他們真正需要的是什麼，然後才提出資訊解決方案；如果我們只是照著客戶提出的功能來開發資訊系統，而沒有進一步地了解客戶需要解決的問題是什麼？他為什麼需要這些功能？當系統開發完成後，客戶會發現他的問題並沒有被解決，也就是認定我們所開發的資訊系統沒有符合他的需要。 [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>由：Jonathan</title>
		<link>http://www.lifeparty.idv.tw/blog/archives/25/comment-page-1#comment-460</link>
		<dc:creator>Jonathan</dc:creator>
		<pubDate>Thu, 08 Feb 2007 03:16:35 +0000</pubDate>
		<guid isPermaLink="false">http://www.lifeparty.idv.tw/blog/archives/25#comment-460</guid>
		<description>我是06年1月畢業，但是&lt;a href=&quot;http://jonathan-speaking.blogspot.com/2005/08/blog-post_30.html&quot; rel=&quot;nofollow&quot;&gt;2005/08/30上完李國光老師的策略知識管理&lt;/a&gt;之後，我就沒有修課專心跟著黃世禎老師寫論文，我猜，我們見過的機率不大...

屈指一算，你應該也正在拚論文吧！加油！</description>
		<content:encoded><![CDATA[<p>我是06年1月畢業，但是<a href="http://jonathan-speaking.blogspot.com/2005/08/blog-post_30.html" rel="nofollow">2005/08/30上完李國光老師的策略知識管理</a>之後，我就沒有修課專心跟著黃世禎老師寫論文，我猜，我們見過的機率不大&#8230;</p>
<p>屈指一算，你應該也正在拚論文吧！加油！</p>
]]></content:encoded>
	</item>
	<item>
		<title>由：同人的生活派對 &#187; 軟體開發的沒問題症候群</title>
		<link>http://www.lifeparty.idv.tw/blog/archives/25/comment-page-1#comment-446</link>
		<dc:creator>同人的生活派對 &#187; 軟體開發的沒問題症候群</dc:creator>
		<pubDate>Wed, 07 Feb 2007 11:09:24 +0000</pubDate>
		<guid isPermaLink="false">http://www.lifeparty.idv.tw/blog/archives/25#comment-446</guid>
		<description>[...] 這件事情其實透露著我們對問題管理的態度問題－我們是不是該針對問題來規劃與控制，很多程式設計師喜歡想到那裡寫到那裡，然而當問題規模的複雜度已演變到您所無法掌握時，這種變化無常的做法會為軟體開發過程中帶來許多的意外，所以我們必須要針對我們想解決的問題來計劃，並且依照問題演變來控制使事情的結果趨進我們的預期。如果我們找不到問題，卻有解決方案產生，很有可能我們正在以技術來主導需求，然而沒有找到正確的問題，做的事情只是徒然浪費時間罷了，這跟溺水的人胡亂掙扎卻愈弄愈糟的情況有何兩樣呢？ [...]</description>
		<content:encoded><![CDATA[<p>[...] 這件事情其實透露著我們對問題管理的態度問題－我們是不是該針對問題來規劃與控制，很多程式設計師喜歡想到那裡寫到那裡，然而當問題規模的複雜度已演變到您所無法掌握時，這種變化無常的做法會為軟體開發過程中帶來許多的意外，所以我們必須要針對我們想解決的問題來計劃，並且依照問題演變來控制使事情的結果趨進我們的預期。如果我們找不到問題，卻有解決方案產生，很有可能我們正在以技術來主導需求，然而沒有找到正確的問題，做的事情只是徒然浪費時間罷了，這跟溺水的人胡亂掙扎卻愈弄愈糟的情況有何兩樣呢？ [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>由：jim yeh</title>
		<link>http://www.lifeparty.idv.tw/blog/archives/25/comment-page-1#comment-444</link>
		<dc:creator>jim yeh</dc:creator>
		<pubDate>Wed, 07 Feb 2007 06:26:36 +0000</pubDate>
		<guid isPermaLink="false">http://www.lifeparty.idv.tw/blog/archives/25#comment-444</guid>
		<description>嗨！喲哪桑學長，

沒想到在我的網誌竟然也可以碰到學長，真是難得呀，有點令人又驚又喜。

在台科大上課的日子，第一個碰到的老師正是陳老師，第一堂課就讓我印象深刻，他說技術人不太容易成功，而在一個組織中比較容易成功的人有兩大類型，一種是搞行銷企劃；另一種則是搞財務的。所以技術人不要只活在自己的象牙塔中，而要多學習人家的優點，要懂得&lt;em&gt;謙虛&lt;/em&gt;及&lt;em&gt;尊重&lt;/em&gt;。到台科大進修，既然 on the right track，那應該多朝軟性技能多充實。

科技創新管理正是一種 social technology 觀點，除了技術之外，人際觀點更為重要。說不定我和喲哪桑學長見過面，只是互相不知道對方是誰。</description>
		<content:encoded><![CDATA[<p>嗨！喲哪桑學長，</p>
<p>沒想到在我的網誌竟然也可以碰到學長，真是難得呀，有點令人又驚又喜。</p>
<p>在台科大上課的日子，第一個碰到的老師正是陳老師，第一堂課就讓我印象深刻，他說技術人不太容易成功，而在一個組織中比較容易成功的人有兩大類型，一種是搞行銷企劃；另一種則是搞財務的。所以技術人不要只活在自己的象牙塔中，而要多學習人家的優點，要懂得<em>謙虛</em>及<em>尊重</em>。到台科大進修，既然 on the right track，那應該多朝軟性技能多充實。</p>
<p>科技創新管理正是一種 social technology 觀點，除了技術之外，人際觀點更為重要。說不定我和喲哪桑學長見過面，只是互相不知道對方是誰。</p>
]]></content:encoded>
	</item>
	<item>
		<title>由：同人的生活派對 &#187; 軟體設計須面對現實</title>
		<link>http://www.lifeparty.idv.tw/blog/archives/25/comment-page-1#comment-138</link>
		<dc:creator>同人的生活派對 &#187; 軟體設計須面對現實</dc:creator>
		<pubDate>Tue, 09 Jan 2007 08:06:38 +0000</pubDate>
		<guid isPermaLink="false">http://www.lifeparty.idv.tw/blog/archives/25#comment-138</guid>
		<description>[...] 如此設計就可以變得更單純些，等到我們需要區分出不同的客戶的共通行為再運用角色塑模（Dealing with Roles）來增加設計的彈性，這就是用面對問題的方式來設計，而不是以技術實作的觀點來設計，因為後者常常會讓我們離遠使用者需求。 [...]</description>
		<content:encoded><![CDATA[<p>[...] 如此設計就可以變得更單純些，等到我們需要區分出不同的客戶的共通行為再運用角色塑模（Dealing with Roles）來增加設計的彈性，這就是用面對問題的方式來設計，而不是以技術實作的觀點來設計，因為後者常常會讓我們離遠使用者需求。 [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>由：jim yeh</title>
		<link>http://www.lifeparty.idv.tw/blog/archives/25/comment-page-1#comment-13</link>
		<dc:creator>jim yeh</dc:creator>
		<pubDate>Mon, 15 May 2006 03:22:19 +0000</pubDate>
		<guid isPermaLink="false">http://www.lifeparty.idv.tw/blog/archives/25#comment-13</guid>
		<description>&lt;p&gt;我將此文章轉貼在&lt;a href=&quot;http://www.94emba.com.tw/modules/newbb/viewtopic.php?viewmode=flat&amp;topic_id=75&amp;forum=15&quot; rel=&quot;nofollow&quot; rel=&quot;nofollow&quot;&gt;EMBA的班網&lt;/a&gt;，有同學回應：&lt;/p&gt;
&lt;blockquote&gt;&lt;p&gt;
通常it人員不求名，不求利，只求爽!&lt;/p&gt;
&lt;p&gt;公司的設備用最好的，程式寫的很COOL，但也花很多時間。user也不鳥你，因為，做的並非他們想的，原因也可以說是需求不明確，但通常也是系統分析師要特別注意的問題。需求要弄的很完整，實務上不是太容易，這都要考驗sa的功力，我想，要靠許多實務的經驗和理論配合，才能達成，也可以請各位有經驗的同學多多提供寶貴的想法。&lt;/p&gt;
&lt;/blockquote&gt;
&lt;p&gt;同學描述的情景很真確，寫了近二十年的程式，個人也經歷過那種求爽的階段，所追求的是一種創造的成就感；然而，記得在十幾年前，我所任職公司的總經理曾對我說，沒有永遠的程式設計師，最好要多花點時間在領域知識上充實。我當時雖認為這是金科玉律，但真正深切悟到箇中道理卻是最近幾年的感觸所得，關鍵就在於是否做到「不以技術來主導使用者的需求」。&lt;/p&gt;
&lt;p&gt;如果我們沒有先了解客戶希望解決的問題，自然會存在需求範疇的風險，就會很容易發生需求變動的問題。解決之道必須改變系統分析的根本思維，從思考利害關係人的問題找出問題的基本概念與原理，再找出解決方案與驗證可行的方法，這樣便可有效地導出客戶真正的需求。&lt;/p&gt;
&lt;p&gt;當然，&lt;a href=&quot;http://140.118.9.72:8080/ORlab/index.jsp?q=3.htm&quot; rel=&quot;nofollow&quot;&gt;陳正綱教授&lt;/a&gt;曾告誡的科技人員之基本心態也很重要，也就是：&lt;b&gt;謙虛，多讀書，多幫助別人&lt;/b&gt;。謙虛會讓我們更能夠聽進使用者真正要表達的是什麼，這是需求分析所需要的行為（身）；多讀書讓我們了領更多跨領域的知識，這正是需求分析所需要的知識（心）；多幫助別人就會讓我們培養出為人服務的態度，這是系統分析所需要的心態（靈）。
&lt;/p&gt;
</description>
		<content:encoded><![CDATA[<p>我將此文章轉貼在<a href="http://www.94emba.com.tw/modules/newbb/viewtopic.php?viewmode=flat&#038;topic_id=75&#038;forum=15" rel="nofollow" rel="nofollow">EMBA的班網</a>，有同學回應：</p>
<blockquote><p>
通常it人員不求名，不求利，只求爽!</p>
<p>公司的設備用最好的，程式寫的很COOL，但也花很多時間。user也不鳥你，因為，做的並非他們想的，原因也可以說是需求不明確，但通常也是系統分析師要特別注意的問題。需求要弄的很完整，實務上不是太容易，這都要考驗sa的功力，我想，要靠許多實務的經驗和理論配合，才能達成，也可以請各位有經驗的同學多多提供寶貴的想法。</p>
</blockquote>
<p>同學描述的情景很真確，寫了近二十年的程式，個人也經歷過那種求爽的階段，所追求的是一種創造的成就感；然而，記得在十幾年前，我所任職公司的總經理曾對我說，沒有永遠的程式設計師，最好要多花點時間在領域知識上充實。我當時雖認為這是金科玉律，但真正深切悟到箇中道理卻是最近幾年的感觸所得，關鍵就在於是否做到「不以技術來主導使用者的需求」。</p>
<p>如果我們沒有先了解客戶希望解決的問題，自然會存在需求範疇的風險，就會很容易發生需求變動的問題。解決之道必須改變系統分析的根本思維，從思考利害關係人的問題找出問題的基本概念與原理，再找出解決方案與驗證可行的方法，這樣便可有效地導出客戶真正的需求。</p>
<p>當然，<a href="http://140.118.9.72:8080/ORlab/index.jsp?q=3.htm" rel="nofollow">陳正綱教授</a>曾告誡的科技人員之基本心態也很重要，也就是：<b>謙虛，多讀書，多幫助別人</b>。謙虛會讓我們更能夠聽進使用者真正要表達的是什麼，這是需求分析所需要的行為（身）；多讀書讓我們了領更多跨領域的知識，這正是需求分析所需要的知識（心）；多幫助別人就會讓我們培養出為人服務的態度，這是系統分析所需要的心態（靈）。</p>
]]></content:encoded>
	</item>
</channel>
</rss>

