<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	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/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>小狗狗有辦法 &#187; 專案管理、開發</title>
	<atom:link href="http://blog.ezshow.org/category/writeing/project/feed/" rel="self" type="application/rss+xml" />
	<link>http://blog.ezshow.org</link>
	<description>The puppy got a good idea. 遇到問題想辦法解決~</description>
	<lastBuildDate>Tue, 06 Apr 2010 15:57:16 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.2</generator>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
			<item>
		<title>[轉載]開發人員要如何不自廢武功？</title>
		<link>http://blog.ezshow.org/2007/11/08/%e8%bd%89%e8%bc%89%e9%96%8b%e7%99%bc%e4%ba%ba%e5%93%a1%e8%a6%81%e5%a6%82%e4%bd%95%e4%b8%8d%e8%87%aa%e5%bb%a2%e6%ad%a6%e5%8a%9f%ef%bc%9f/</link>
		<comments>http://blog.ezshow.org/2007/11/08/%e8%bd%89%e8%bc%89%e9%96%8b%e7%99%bc%e4%ba%ba%e5%93%a1%e8%a6%81%e5%a6%82%e4%bd%95%e4%b8%8d%e8%87%aa%e5%bb%a2%e6%ad%a6%e5%8a%9f%ef%bc%9f/#comments</comments>
		<pubDate>Thu, 08 Nov 2007 15:50:13 +0000</pubDate>
		<dc:creator>小狗狗</dc:creator>
				<category><![CDATA[專案管理、開發]]></category>

		<guid isPermaLink="false">http://blog.ezshow.org/2007/11/08/%e8%bd%89%e8%bc%89%e9%96%8b%e7%99%bc%e4%ba%ba%e5%93%a1%e8%a6%81%e5%a6%82%e4%bd%95%e4%b8%8d%e8%87%aa%e5%bb%a2%e6%ad%a6%e5%8a%9f%ef%bc%9f/</guid>
		<description><![CDATA[寫的有道理，但實際施行卻有相當的困難，專案考量進政治面時，就增加了很多變數，筆者也正是有了政治面的權力，才得以推行。最近遇到還蠻不好處理的情況，政治面的考量太多，專案人員都想做分析、企劃的角色，卻沒有動力去執行，將執行的事情不斷的外推或粗略的執行，無力感倍增~
 &#8212;&#8212;&#8212;&#8212;&#8212;&#8212;
原文轉載自 CNET
自廢武功無疑是下下策，但軟體開發者在面臨專案的巨大壓力下，要如何不自廢武功呢？顯然忽略設計的做法是不可取的，因此，單單只利用系統實作技能來彌補設計不完整的缺憾往往常會把問題弄得更複雜，這樣做其實是本末倒置。
筆者認為開發者應該重視設計概念的整體性，這樣才能用更簡單而富有彈性的設計來解決問題，而要達到這個目的，開發者必須更專注在問題分析與概念設計的能力。
 
因此，當軟體需求者提出了他們希望軟體應該要有的功能時，開發者還必須深入地思考為什麼他們會希望軟體應該要有這些功能，並深入地探討他們所面對的真正問題是什麼。因為軟體需求提供者只是站在客戶或使用者的觀點來看待軟體，技術並非他們的專業，所以他們對系統功能的理解很有可能並沒有辦法解決問題，因此開發者應該先找到需求者的問題而非功能。因為只有在了解需求者的真正問題後，開發者才能站在問題的角度來思考解決方案，也才能發展出適合的設計概念來解決問題。
筆者舉兩個實際的例子來說明概念設計對解決問題的重要性。有一個在開發中的系統，客戶發現在接收某種訊息時，其資料拆解出現了問題。我們探求其原因，發現在某些特殊tag之後，要跟隨在後面的tag資料都當成那個特殊tag的內容，而此系統的訊息資料拆解設計沒有支持這樣的概念，所以會造成這個tag的資料無法正確處理。
但因為此類訊息是屬於標準格式，而訊息規格卻沒有交代有這種特殊的tag規則，到底這是業界的不成文規定還是某些交易伙伴特有的做法呢？是不是還有其他的特殊tag呢？於是我們向客戶表示，必須要請他們提出更完整的資料，否則我們無法處理這個問題。
我們的回應促使客戶更深入地去探討這個問題，據他們表示，以前的系統並沒有處理到這個問題，因此，得確還有一些特殊的tag沒被注意到，問題似乎並不如一開始所想像的那麼簡單。
然而，如果我們只針對客戶提出的問題來修改程式時，程式碼將會變得更複雜，因為在設計不改變的狀況下，所有接收tag處理的實作都會大受影響。但如果從設計概念上加入註記隨後出現tag都包括在某個tag內容的概念，就不會大幅影響原來程式的實作。只要在接收那個特殊tag處理的實作中設定註記，問題就可以迎刃而解，甚至可以變得更有彈性，例如可以設定某個tag有還原註記狀態的功能。
還有一個例子，在一次專案會議中，某位系統分析者提出一個系統問題，系統在案件的處理過程中，多人重複派送同一個案件會發生問題，她懷疑是因為多執行緒的案件分派機制所造成的，並認為如果讓案件分派不是多執行緒，問題就應該可以解決。
不少開發者也認為讓分派機制不要那麼複雜就可以解決問題了，但他們也了解到，不用多執行緒，案件分派的速度會變慢，客戶很難接受這種做法，所以他們會很希望有人能和客戶協調溝通。
但筆者卻認為多執行緒的案件分派卻並不是問題的成因。雖然，在案件分派機制是多執行緒的情況下才會發生這個問題，但我認為問題較精確的說法應該是問題一直都存在，只是「多執行緒的案件分派」讓它浮現出來罷了。
筆者對提出問題的系統分析者質疑為什麼會有「多人重複派送同一個案件」的情況發生，她提到那是因為客戶的要求，因為客戶希望針對同一個案件，不同單位的人都可以處理同一個案件。原來是因為一開始系統分析者把案件的處理資訊與案件放在一起，但一旦當許多人可能會同時處理此案件時就會發生問題了，因為每個處理都是同一個案件，系統將不知如何分辨它們的不同。
這是一個典型的例子，缺乏整體概念設計的模型常常會讓問題弄得很複雜，系統分析者純粹以技術實作的眼光看問題，而非以問題領域的角度來建模，她把處理案件的案件與原始案件混在一起了，但以業務邏輯的概念來看，對「某案件的處理」本身是另一個案件，它有獨立的案件編號，所以只要用業務的眼光來修正設計模型就可以解決問題了，而不是取消案件分派的多執行緒功能。
從這兩個例子可以發現，分析出問題背後的問題，然後才能在概念上發展出有效的設計藍圖，才能用簡單而富有彈性的方式來處理問題，同時，這樣做也讓人可以容易理解與相互溝通，因為大家是針對問題領域來了解及溝通而不限於特殊技術。
問題分析並不需要花費太多的時間，因為只要找出問題的關鍵剩下的就簡單多了。當然，這需要不斷地練習，才能培養出敏銳地觀察力以及獨立思考的能力，而對於比較複雜的問題，也可以藉由集思廣義的方式來解決。
良好的問題分析與概念化的設計能力才是軟體開發者能否適應環境變化的重要能力。總而言之，軟體開發者如果不去加強分析與設計的能力，專案壓力將會壓得他喘不過氣來，自廢武功往往是必然的結果，這只會耗弱軟體開發者的應變能力呀。但筆者相信只要我們多觀察、多思考、多學習，其實這種宿命是可以打破的呀。
]]></description>
		<wfw:commentRss>http://blog.ezshow.org/2007/11/08/%e8%bd%89%e8%bc%89%e9%96%8b%e7%99%bc%e4%ba%ba%e5%93%a1%e8%a6%81%e5%a6%82%e4%bd%95%e4%b8%8d%e8%87%aa%e5%bb%a2%e6%ad%a6%e5%8a%9f%ef%bc%9f/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>關於大型公共建設軟體開發專案之看法</title>
		<link>http://blog.ezshow.org/2007/08/27/%e9%97%9c%e6%96%bc%e5%a4%a7%e5%9e%8b%e5%85%ac%e5%85%b1%e5%bb%ba%e8%a8%ad%e8%bb%9f%e9%ab%94%e9%96%8b%e7%99%bc%e5%b0%88%e6%a1%88%e4%b9%8b%e7%9c%8b%e6%b3%95/</link>
		<comments>http://blog.ezshow.org/2007/08/27/%e9%97%9c%e6%96%bc%e5%a4%a7%e5%9e%8b%e5%85%ac%e5%85%b1%e5%bb%ba%e8%a8%ad%e8%bb%9f%e9%ab%94%e9%96%8b%e7%99%bc%e5%b0%88%e6%a1%88%e4%b9%8b%e7%9c%8b%e6%b3%95/#comments</comments>
		<pubDate>Mon, 27 Aug 2007 02:52:47 +0000</pubDate>
		<dc:creator>小狗狗</dc:creator>
				<category><![CDATA[專案管理、開發]]></category>

		<guid isPermaLink="false">http://blog.ezshow.org/2007/08/27/%e9%97%9c%e6%96%bc%e5%a4%a7%e5%9e%8b%e5%85%ac%e5%85%b1%e5%bb%ba%e8%a8%ad%e8%bb%9f%e9%ab%94%e9%96%8b%e7%99%bc%e5%b0%88%e6%a1%88%e4%b9%8b%e7%9c%8b%e6%b3%95/</guid>
		<description><![CDATA[起源由從高鐵售票系統談大型公共建設軟體開發專案，當中引起了不少軟體經驗豐富的高手討論…
就經驗來看自已並沒有比這些人來的豐富，但我看到的是，這次的討論不也就代表了目前軟體開發產業中的現象，人人都有自己的一套觀點，人人都有自己的經驗，卻不見得能包容別人的方式、觀點。這個我自己也做不到，相信每人都有自己的專業，但如何在這些專業、經驗中整合出最好的，實在不容易或是可以說做不到，因為就以往的情況看來，最後的結果不是軟體最好的，而是策略上「最好的」，即是大家都可以接受的版本，我想這也是造就這些大型的公共軟體專案問題叢生的問題之一。
大型公共建設軟體專案之讀者討論 「委外分包管理」所提到的問題應該只是很小的一環，文中的前提是主包者可以明確的提出自己的需求，遇過不少的主包者提不出需求，初期要求分包商代替規劃，事後要求分包商不斷修改，這也難保分包商要兩手一攤了，因為根本超過分包商的能力或花費，這樣的主包商何來風險管理？
分析或猜測一事，就高鐵這案來看我想除了該專案開發人員可以實做到分析的事項外，這些的討論都僅能止於猜測問題的所在（實際開發人員有人要跳出來說他的分析情況嗎？），猜測應算是分析的一部份，沒有初步的猜測何來分析？但這當中又有人的問題了，有些人做事只做一半，只做猜測，不做分析，才會有這些問題才是。
如最後 同人 所說，管理是很重要的。管理重要卻困難，特別是在人的管理上面，管理者面臨困難時要如何正確的管理人員來因應，這也是困難的地方，軟體開發人員易尋，好的管理者卻難遇。
]]></description>
		<wfw:commentRss>http://blog.ezshow.org/2007/08/27/%e9%97%9c%e6%96%bc%e5%a4%a7%e5%9e%8b%e5%85%ac%e5%85%b1%e5%bb%ba%e8%a8%ad%e8%bb%9f%e9%ab%94%e9%96%8b%e7%99%bc%e5%b0%88%e6%a1%88%e4%b9%8b%e7%9c%8b%e6%b3%95/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>
