workbook.pod

名稱

The Workbook Project

版權

傲爾網 <members@ourinet.com> 版權所有，2001 年。

此文件是開放文本；你可以依 Open Content License 以數位形式進行傳佈及更動。

請參見 http://opencontent.org/opl.shtml。

作者序: This is beta software.

這本書是許多人共同學習的筆記。這群人彼此差異甚大，少數的共同點是：1)網路是生活與工作的重要部分、2)與其聽從他人指示做事，更傾向於自己決定自己負責，以及3)覺得自發性的合作是解決問題的好方法。

2001年初，「身為獨立接案者，至少應該知道哪些事情？」這個問題激起了大家的興趣，於是就分頭找資料、採訪、辦討論會，寫下了這本書。

既然是一篇聯合創作的作品，這篇「作者序」自然無法概括所有參與者的意見，而兩位筆者也不打算這麼做。這裡祗打算將我們平日的溝通所形成的某些共識告訴大家；其她作者各自的看法, 妳可以透過網路上的各種管道來認識，或是加入我們每週日下午兩點在紫藤蘆（台北市新生南路三段16巷1號）的聚會.

這本書的撰寫過程裡，我們嘗試了「分散式網路團隊」這種工作型態：成員之前彼此沒有隸屬關係、沒有外在獎懲制度、自己掌握工作進度，而幾乎所有溝通都透過網路進行、對外界完全透明，歡迎任何人參與。

實際運作起來，工作的效率連我們自己都感到喫驚。當然，許多大規模的開放原始碼（Open Source）計劃，早已確立了藉由網路社群執行工作的前例。但是在親身領略之後，面對未來藉由「虛擬辦公室」的工作方式與流程，這本書為我們帶來更大的信心。

我們自己知道，這本書的內容並不完美；以軟體的品質而言, 祗相當於測試版（beta version）而已。但是，基於「儘早釋出, 儘快釋出」（Release early, release often）的精神，我們還是將它呈現在妳面前，希望能拋磚引玉，激發網路上更多相關的討論和交流。

作者們會在 http://elixus.org/workbook/ 持續不斷地增修內容，逐漸結集更多過來人的經驗，增加它對新手的價值。如果妳有獨立接案的經驗談，願意接受訪問／幫忙訪問，或覺得書裡的任何文字有瑕疵或不足之處，歡迎妳寫信到 workbook@elixus.org 參加這個計劃的運行。

將自己手上的資源開放給所有人分享，一直是為作者們所認同的觀點。因此，我們遵循《黑話檔案》（Jargon Files）等網路著作的傳統，自動放棄了電子出版物的獨家重製權。也就是說，妳可以在前述網址下載這本書的完整內容，也可以在不更動作者名稱版本和內容的前提下，在網路上任意轉載這篇文章。（完整的授權條款，請參考網站上的資訊）

但是，如果妳覺得這本書的內容有些參考價值，我們還是建議您購買印刷版本：由商智出版社在 2001 年印行的《獨當一面 - 數位獨立接案的規畫與管理》。這並不是為了我們的荷包，因為所有作者都不支領版稅；主要原因是，商智出版社願意與開放原始碼的創作方式合作，在台灣是件首開先例的創舉，讓我們非常感謝。如果這本書賣得不錯，或許能鼓勵未來更多結合網路創作和實體傳播的計劃，讓讀者能自由地參與創作和對話，也讓出版者獲得應有的報酬。

獨立接案者在台灣的路雖然不能說是剛開始，但是距離成熟顯然還需要許多努力。在世界上的每個角落，積極而自主的知識工作者一向是資訊交流和創新的前鋒, 也對台灣軟體業界的存續有直接的影響。既然我們還有相當長的路要走，就從彼此的溝通、分工和互信開始吧！

1. 簡介: 獨立接案這一行

在資訊業界，獨立接案者主要的工作內容在於提供客戶服務。服務項目則包含電腦硬體配備、軟體設計、網路架構及資料處理等相關的各種事情。妳可能是幫客戶組一台電腦、架一個伺服器，也可能是設計一個網站或是規畫撰寫一套行政流程系統。視客戶需求與妳的個人能力而異。

翻開這本書，妳的第一個疑問可能是，何謂獨立接案者？一個獨立接案者要做些什麼事、面對哪些問題、該如何定位自己等。這一章裡，我們將對獨立接案者做概略的描述，讓妳對這個工作有基本的認識。

1.1. 獨立接案者是什麼

獨立接案者的工作時間並不固定，妳可能長達一年的做為一個專案的專案管理員，也可能同時負責六個工作而每個工作的時限只有一個月。工作地點因內容而異，可能是到府服務，到某個大型企業或是自己在家工作。身份也非常多變，可以是一間公司暫時的員工，也可以是獨立的外聘人員，跟公司內的特定團隊合作與溝通。

此外，身為獨立接案者意味著妳必須同時處理多種不同的課題。讓客戶瞭解妳的服務內容、妳能幫客戶解決什麼問題，以何種方式讓她們看到成果等。面對不同的專案，妳會需要不同的技術以及相關的管理技巧；判斷並且提供方法解決技術上的問題。

獨立接案者跟一般公司的雇員有何差別呢？到公司工作的話，妳的職位、工作內容與方式就是固定的，由公司的制度決定。有張專屬的辦公桌，基本的上下班時間，在公司規定時間內完成妳的工作。合約部份，妳跟公司簽長期的僱約，半年、一年或更長。福利方面，則享有公司提供的各種福利，勞健保、員工旅遊、公司社團活動、年節獎金、紅利股票等。

若是獨立接案者，妳與客戶的關係就不是那麼絕對。合作模式由雙方溝通後決定，妳通常要訂立自己的工作時間表與工作內容。合約也依工作方式有所不同，妳要自己準備。跟公司之間可能是外聘人員，或是臨時僱員。一般而言，外聘人員不享有公司提供的員工福利，臨時僱員還有可能。妳會有比較大的自主性，但是相對的，也需要花時間和心思來處理這些事情。

1.1.1. 怎樣的人適合接案?

清楚一個獨立工作者的性質之後，接下來要思考的就是，自己到底適不適合從事這個工作。這邊的意思不是說妳是否具備足夠的技術能力，而是妳個人的人格特質是不是適合。技術是可以經由時間跟經驗累積起來的，然而，人格特質卻較難藉著後天的訓練來改變。在一個分工的體系下，有些人就是喜歡在公司裡面任職，而有些人覺得當獨立工作者比較愉快。這中間沒有優劣之分，不過是人格特質上的差異。

在這一節裡，我們就要來談談在獨立工作者身上常見的人格特質有哪些。

獨立、自主性強

團隊工作的時候，除了聽從負責人的決定之外，還會有自己的想法與判斷。面對問題的時候習慣自己決定而非只由她人決定。獨立工作者並不意味著妳的工作量會比別人少，只是妳對自己的工作時間與內容有較大的主控權。不需要朝九晚五上下班打卡，但是工作一樣要做。沒有人告訴妳什麼時候要做什麼事，妳必須自己決定一切。若是缺乏良好的自主能力，無法自己安排時間的話，最後可能會流於懶怠以致一事無成。

積極的行動力

獨立工作者要能為自己尋找各種工作機會。對於資訊，不只被動接收，還要有主動蒐集的能力。對事物有一定的敏銳度，可以快速判斷這是否為妳有興趣的工作，主動爭取。

樂於溝通

一個專案從開始到結束，獨立工作者的工作內容並非只是單純的撰寫程式碼，溝通佔了很主要的部份。如果生性不好與人交談，那麼從事這個工作就會比較辛苦。

追求多樣工作狀態

每個人對工作內容的要求不一，若妳希望的工作是只要做好自己份內的事，穩定的拿薪水，不需要做其她額外事情的話，獨立工作者這份職業對妳來說可能就太刺激。如果妳不喜歡單一重複的工作內容，追求改變。對事物持高度好奇心，不排斥學習新東西。那麼，當個獨立工作者就會蠻愉快的。

安於不穩定

獨立接案者的工作收入與生活方式並不固定。妳沒有一定的工作時間與固定薪水。對一些人來說，這會造成不安全感。妳必須考量自己是否可以接受這種生活方式。

說了這些東西，並不是說一定要具備以上條件才能當獨立工作者，只是說有這些傾向的人可能會比較喜歡這份工作。真正要知道自己適不適合其實很簡單，實際做一次就知道了。

1.1.2. 常見的工作形式

由於獨立接案的機動性極高，不同的專案需求，往往會衍生出相應的工作形式。除了底下所列四種最常見的方式之外，如團隊電子通勤（telecommuting team）等新的模式也不斷被提出；如果能靈活地運用不同的工作形式，在執行交付的專案時必然能事半功倍。

一人公司

以個人名義獨立工作，動態地接各種案子，與客戶聯絡、談需求、訂合約。個人的工作模式通常是：獲得到案子的資訊，然後妳跟案主聯絡，確認實際需求，評估個人的接案意願與能力，決定是否接案。接下來，跟客戶談定合約細節與合作方式，工作、交案。

小型工作室

小型工作室是由固定幾個人組成的工作團隊，以團隊名義接案，各人有較明確的分工。會有人負責聯絡與溝通，有人做程式撰寫，這種工作型式對於不習慣凡事一把抓的人來說會比個人獨立工作來得適合。合約方面，如果工作室有登記的名稱就以工作室名義與客戶簽約，或是由一人出面簽約，不需要每個成員都單獨與客戶簽約。

暫時的開發團隊

一群個人，為解決某個特定計畫動態產生的開發團隊，在計畫完成後就解散，沒有固定的合作關係。這種開發團隊的形成是非常動態的，通常是一個人接了案子，發現自己做不完，然後找人幫忙，有意者加入，形成團隊。每個人各自與案主簽約。另一個情況是，案主只跟團隊的負責人簽約，其她成員是由這個人找來的。此時這些成員就是跟負責人談而非案主，或許會簽約，也可能只是談好合作與付錢的方式而不簽約。

公司外聘人員或臨時僱員

一組人或個人在合約期限內與公司配合，與公司內的特定部門合作，完成公司的專案。或是，以外聘人員的身份為公司提供特定的服務，顧問通常就是這種型式。這種情況的話，妳可能會需要配合公司的制度上下班，在公司內有暫時的工作位置，看客戶公司的要求以及合約而定。

1.2. 委外市場現況

想要成為獨立接案者的人都會有一些疑慮，就是關於這個市場的成熟度如何，我到底是否可以藉由接案來維持正常的收入。那麼我們就先藉由一些數據來看看現在委外市場的情形如何。

Gartner Group在2000年所做的調查顯示，所有的公司都面臨到以現有的人力無法負擔資訊服務的需求，而有73%的企業願意將公司內的資訊系統委外。也就是說目前大約四分之三的企業都希望能將公司內的資訊系統委外開發。

而近一年來雖然全球經濟發展趨緩，MIC對台灣企業應用軟體的成長率調降，但是卻依然維持約28%的成長率向上成長。而且全球的資訊委外市場也將在近幾年會有大幅度的增加，台灣也會緊跟在這股風潮中。

在資訊系統委外需求的比例上，大約可以分為金融（35%），政府（23%），製造（20%），電信（15%），至於接下來幾年預估成長最快的系統將是供應鏈管理（Supply Chain Management; SCM），客戶關係管理（Customer Relationship Management; CRM） 企業資源規劃（Enterprise Resource Planning; ERP）軟體等；這些部分也將成為接下來企業委外的重要類別。而每年企業應用軟體委外開發的金額約有一百多億，並預估以每年28%的速度增加。

從這些數字就可以看到，接下來企業資訊委外將會成為一種趨勢，對於希望進入這個產業的人而言，將會是一個很好的進入點。

1.2.1. 為什麼有人要委外?

「委外」這樣的詞彙對於一般人也許並不太熟悉，但是這樣的觀念絕對不算是一種創新的觀念，其實大部分的人每天都有許多事情是委外進行的。如果以這樣的看法來思考「委外」這件事情，顯然會讓我們感覺容易、也親切許多。我們不妨回憶一下我們手上的哪些事是經常委外，而且為什麼需要「委外」，那麼我們就很容易可以發現為什麼企業中存在著許多需要委外的專案。

我們隨便舉幾項個人委外的實例：許多人總是經常因為某些原因無法回家裡吃飯，而必須在外用餐，在這樣的情況下委外就產生了。或是如果你選擇搭乘捷運，以某種角度來看，當然也可以納入委外的範圍內。

當然，以公司經營的角度來看，委外顯然也是非常好的方式，有時甚至可以說是不可避免的方式。舉例來說，如果你是一家出版社，那麼除非你所出版的書籍數量多到需要一家印刷廠，否則你又何必自己經營印刷廠呢？

這樣的委外情形在許多產業中都已經算是行之有年，也已經有了相當不錯的上、下游關係及還算健全的制度。在台灣，我們經常聽到某些公司幫國外的電腦、手機等等大廠代工，這顯然也是一種典型的委外狀況。其他像會計師、律師都是很好的例子，這些人並非是公司的員工，一般的公司也並不常需要這樣的人才，但是在必要的時刻卻是完全不能少的，於是委外的情形就發生了。

從剛剛所提到的內容看起來，公司在許多情形下會很容易有委外的工作產生。當然，我們想要了解的是一般企業在哪些情況下容易會有將自己的需求委外，如果我們可以清楚的知道這件事情之後，那麼也就可以藉由對這些情形的分析，知道在資訊技術方面有沒有這樣的機會讓企業將自己的系統委外；或者對於業者來說，他們也可以解除一些對於自己是否應該將資訊系統委外的疑惑，並加強企業對於資訊系統委外的確認與信心。

首先，我們應該想到，對於每一家公司幾乎都需要的會計師或律師而言，為什麼卻大多委外給會計師事務所或是律師事務所呢？這個問題並不難回答，因為一般公司對於會計師或律師的需求並不足以需要僱請專用的會計師或律師，何況這兩種人才物以稀為貴，也不是一般中小型企業的人事費用所負擔的起。

既然如此，當然在需要時以委外的方式比較方便、也經濟許多。類似的情形也發生在軟體、資訊技術方面，一般公司在目前、或是可以預見的未來對於資訊系統的使用需求將會有急速的增加，但是資訊系統無論在系統架設或是軟體設計方面都不能算是一項長期性的工作，仔細想想，如果一家公司聘用了三、四位系統開發的相關工程師，那麼當他們花費了幾個月將系統開發完成後，公司在系統開發方面的需求已經降低或是結束的時候，這些工程師將無法再被賦予適當的任務，這無論對公司或員工都不是一件好事。

因此對於這些並不算是長期的需求，將這些系統委外顯然是比較經濟以及實際的作法。其實資訊顧問也經常是以這樣的方式存在，他們並不是公司裡的正式員工，而僅僅在公司的資訊系統發生問題時提供解決的方式與建議，這當然也是資訊系統委外另一類明確的例子。

事情顯然不只是這樣，讓我們看看台灣在資訊硬體部分的例子。台灣的某些硬體產業非常發達，經常可以在合理的價錢下可以製造出品質優良的產品。這對於許多國外大廠而言是非常具有誘因的，因為許多產品在國外製造的生產成本太高，而品牌行銷、設計的利潤遠大於勞力密集的生產製造，因此這些國外大廠就把他們所需要的產品委外給台灣的代工廠代工。

類似的情形也會發生在軟體相關的部分，也就是一些規模較大的軟體廠商對於手上的案子評估，如果是人力不足，或為了降低成本，提高利潤，於是就將接到的案子轉包給其他小型工作室或個人接案者。

上述的情形幾乎是目前一般公司或專業的資訊公司會利用委外來進行軟體開發的原因，當然，其他還會有一些不同的因素，但如果以比例來觀察，因為其他情形而委外的案子顯然在比例上而言是顯著比較少的，有些不同也只是上述的這些原因以某些不同的形式衍生。 讓我們嘗試舉一些其他的例子來解釋，不久前網路產業曾經流行了一陣子應用軟體服務提供的服務，也就是利用一般公司不必要為了使用某些軟體而僱用程式開發的人員，並且因為大家共同租用而可以降低成本。在某種程度上，這樣的模式就是利用了一般公司對於軟體需求的特性，其他的一些考量當然在於使用效能，隱密性等等，不過這並不在我們討論的主題中。

就以上述的一些觀點來看，目前一般企業對於軟體的委外似乎雖然已經慢慢出現需求，但是卻由於一些客觀環境的發展緩慢，讓軟體委外還不足夠成熟到可以讓大多數的人能放心的進入這個領域。但是可以預期的是接下來所有產業對於資訊化的需求將會持續的增加，對於系統開發者的需求當然也會跟著成長，那麼將會不斷刺激軟體委外市場的發展，對於目前現有的軟體產業或是軟體自由創作者的結構也會有關鍵性的變化。而事實上，目前軟體產業也持續在改變之中，自由工作者的發揮空間也逐漸變大。

1.2.2. 哪些專案比較容易委外?

經由上述的討論我們可以更容易的去了解企業為什麼會有委外的想法，如果我們從這些想法之中去思考會有哪些專案會委外顯然就變的容易許多了。簡單的說，一般企業中需要以專案的方式去進行資訊化的部分，由於他們並不願意，也沒有需要特別聘請固定的員工來進行，那麼專案委外就成了一種容易而且重要的方式了。當然，目前有許多企業的e化過程中更容易產生許多委外的專案，接下來我們就將針對這一個部分來進行討論。

在幾年前，一般的企業進行資訊化的流程大多以財務為主，而且會進行資訊化的也都是規模還不算小的公司。而且資訊多屬封閉，所有的資料都幾乎只能由財務或高級主管才能獲得。所謂的資訊化的工作只要在於幫助財務人員作帳務的清查與計算，嚴格說起來也並不能算是流程的資訊化，而只是比較方便的試算表。

在這個階段，企業委外的系統其實是非常的少，而且有一大部分是落在規模較大的軟體公司手上，對於接案者來說是非常的辛苦的一段時間。這樣的情形在最近幾年有了相當大的改變，最近幾年來由於網路快速竄起、資訊流通快速等等的因素，使得不但企業委外的方向有持續增加的趨勢，也使得更多企業（甚至包括許多的中小型企業），產生更多委外的需求。而委外的軟體也不再只是以財務管理的專案為主，相反的，資訊e化、網站規劃、架設都是近兩年來委外專案中成長較快的。而網站架設的部分則包括了Internet與Intranet，Internet中例如CRM （客戶關係管理）或是電子商務的部分都是委外相當熱門的項目。而Intranet中則有EIP（企業資訊入口）或KM（知識管理）等，其他有一些和電子流程相關的專案也是頗具有吸引力的。

如果我們仔細觀察這些熱門的商品，大概歸納出一些值得參考的方向。首先，由於有許多企業對於資訊系統的需求在於能夠幫他們處理為數不少的資料，因此絕大多數的系統和資料庫必然有不可分離的關係。接下來我們也可以發現，網路程式顯然是近幾年的趨勢，所以企業要求以Web當作統一的介面，也幾乎快要成為另一種常用的標準。而電子郵件的使用也日漸頻繁，因此應用程式和電子郵件的溝通也是不可或缺的。網路程式中和使用者之間的各種互動顯然也是最近軟體委外的當紅炸子雞，幾乎所有委外的網站中都包含了這些功能，甚至於就是網站的主要功能。

至於許多過去經常委外的軟體種類，也大多改用Web作為使用者介面，而成為企業內部網站的其中一部份，其中例如人力資源管理、倉儲管理等都屬於這一類型。如果你是從大公司的手上轉包一些案子，那麼你也許會接到一些比較龐大的系統，目前比較熱門的系統包括了ERP（Enterprise Resource Planning）、EIP或KM等等。其中又以ERP是比較複雜的，因為他經常包含了公司內部的進銷存管理、金流、物流等等，由於複雜度較高，牽涉的範圍較廣，案子的金額也比較高，所以一般的接案者接觸的機會比較少。

1.2.3. 接案者的一天

「SOHO」族，這樣的工作形式聽起來似乎是讓人羨慕的，但是實際狀況到底如何？是否就跟大家想的一樣：「錢多、事少、離家近，睡覺睡到自然醒」呢？我想答案當然很明確，這樣的工作大概只有在作白日夢時想想吧！那麼一個接案者到底需要作哪些事，不是只有寫寫程式而已嗎？關於這一方面，相信有許多人都相當好奇，既然如此，那麼我們就來看看接案者的一天，讓大家更了解接案者的生活到底是如何。

早上 8:30

鬧鐘響了，「睡覺睡到自然醒」的願望顯然沒有辦法達成。九點半和張經理約在他們的辦公室要做Review Meeting，這是一個知識管理的網站，已經接近結案了，所以最近要開始作 Review，希望接下來可以輕鬆的交貨。

早上 9:30

Review的狀況還算不錯，除了張經理又提出了一些新的需求之外，程式部分應該都可以運作正常了，不過已經告訴他幫他解決這次的需求了之後，下次就沒辦法了，否則不就掉入了無限迴圈了嗎？再不結案的話，錢就一直無法進帳了！

上午 11:00

今天開了一個半小時的會，比起上個案子動不動就是三個小時的會顯然輕鬆多了，不過還是不懂，就是一些小的需求，直接用E-Mail聯絡就好了啊！為什麼一定要開這麼冗長的會？或是電話不是也很方便嗎？還是沒人注意到效率問題… 該準備一下下午要給雜誌社的Proposal，希望可以接下這個案子，畢竟他們要的功能都有現成的套件可以用了，這樣接起案子就輕鬆的多了。

中午 12:00

民以食為天，就算再忙也不能忘了吃飯的時間，畢竟辛苦工作之外，也要好好的照顧自己的身體。反正一點半才要去簡報，輕鬆吃個飯的時間還是有的。

下午 1:30

這家雜誌社已經來了第三次了，希望這次的簡報可以讓他們滿意，那我就有希望可以接下這個案子，他們要的上稿系統都已經有了開放出來的套件，只要修改成他們要的功能就容易的多了。完全展露出軟體重用的好處，而且我建議他們使用的也都是開放原始碼的系統，省下那麼多錢，他們的總經理應該很高興吧！

下午 2:30

剛剛看他們的表情，看來這個案子應該沒什麼問題了，這個月應該 確定能不能接，如果一切順利的話，下個月就可以交貨了。顯然，接案者也要具備業務員的功力，否則都沒有案子可能也不是件好事。該回去開始作業了，還有一堆事情要做。

下午 3:00

怎麼一回來又看到這麼多E-Mail，上次幫吳總他們寫的程式掛了，應該是系統負荷過高，晚上再檢查一下他們的系統。上個月交貨的聊天室系統終於把錢匯給我了，看來晚上可以慶祝一下。只是不知道手上的東西能不能趕完，否則這個禮拜週末沒得放假可就慘了。

下午 4:00

要幫小趙介紹的那家貿易公司寫系統規劃書，他們只要架設公司的網站，公司裡又沒有MIS的人，建議他們用主機代管的方式好像是比較好的，否則到時候問題可又不少，只是預算方面又是另一個問題。不過比起我上次幫那家紡織公司做的案子似乎還容易的多，他們用那種舊型的資料庫，資料的轉換還讓我花了一番功夫，下次這種傻事還是少作為妙。

晚上 9:00

看來今天的工作終於要告一段落了，寫完了系統規劃書，也幫吳總把系統修好了，看來還是要降低系統的負荷，否則機器很容易掛掉的，我可不想整天維護那套系統！他想要好一點的效率，就叫他多買一部機器，也該讓他簽下維護合約才行。早上張經理要的功能也都加上了，發了mail 給他，如果測試都沒問題的話，應該下禮拜就可以交貨了，不過希望不用再去開那種讓人頭暈的會了。雜誌社的報價單也傳過去了，我想應該很快就會有回應，所以手上的案子要先結束掉才行。不過時間不早了，現在還是先休息一下。

接案者的工作顯然並不像一般人所想像的那麼單純，要把原來由許多人做的事全部自己完成，還會因為所面臨到的企業規模、文化的不同而產生不同的工作。但是其中的自我學習、成長卻也是有趣的，如果你想成為一個獨立接案者就必須有這樣的認識。當然其中還包含了許多部分，例如自己時間的調整、分配，自我的學習都是重要的挑戰，也是作為一個獨立接案者吸引人的地方。

1.3. 踏出接案的第一步

獨立工作者一開始時容易碰到兩個瓶頸：無法找到足夠多的客戶養活自己，或是本身的專業能力不足。解決第一個問題可以從發展有用的自我行銷技巧著手。很快地，妳就會發現，發掘客戶是所有非技術性工作中最重要的部份，其她所有的商業技巧都比不上如何成功地將自己推銷出去這件事重要。在這一節裡，我們就要告訴妳幾個常見的接案管道，接案時要如何選擇案子，以及一些幫助妳成功完成專案的小秘訣。

1.3.1. 從認識的人開始

僅管妳已瞭解自己定位、做好心理準備，也具備了基本的技術能力，在案子尚未到手前，仍稱不上是一名獨立工作者。然而，正如同錢不會自動從天上掉下來，案子也不會自己跑來找妳。想接案子，就要自己去找。

對想接案的新手而言，透過人際關係是比較容易開始的方法。妳可以從周遭在相關領域工作的朋友、學校系所上的研究室問起是否有需要人手的專案計畫，表達妳想參與的意願，請她們幫妳留意相關資訊。若是這些人正好有需求又覺得妳可以試試看的話，就會把案子轉介給妳，或是讓妳加入開發團隊幫她們做其中一部份。

比起直接去接陌生人的案子，由認識的人中介案子，對獨立接案者有這些好處：

有人可供諮詢

身為獨立工作者所應具備的不只是技術能力，聯絡、溝通、管理、行銷等也是重要的條件。要馬上就把這些技巧學會可說是不可能的事，尤其，當接下案子的時候，妳無法預知在整個專案發展過程中將會遇到什麼問題。遭遇困難的時候，有個熟悉狀況的人在旁提供意見跟經驗，會讓妳輕鬆不少。

提高互信

朋友會介紹給妳的客戶，至少是她認為可以信任的。雙方在合作之初存在著善意。妳比較不用擔心會被欺負或是案子出了意外最後變成做白工。此外，因為是認識的人，妳會比較容易放下身段向她請教問題，得到的答案也較誠懇客觀。

降低溝通成本

從友人處妳可以獲得到比較詳細的資料，增加對客戶的瞭解。減少溝通過程當中，與客戶之間因陌生而造成的溝通成本。

一個人馬上獨立接案是很辛苦的，為了避免在起步就困難重重，我們會建議妳從加入小型開發團隊作起，與認識的人合作對新手而言有些額外的好處：

良好的學習環境

初學者開始最需要磨練的就是技術，團隊合作提供一個分工的環境。妳只需要專注地把自己負責的部份瞭解清楚實做出來就好，不用花費心思在其她的人事溝通或系統設計領域，遇到問題時也有管道可以迅速找到人支援。在這樣的環境底下，妳可以把基礎的實做能力練好，往學習其她技巧的領域邁進。

更有保障

認識的人通常比較不會虧待妳，彼此會有較廣的談價空間。否則，經驗不夠的新手總是比較容易吃虧。比如，對行情不夠瞭解的話在談薪水的時候就就可能變成廉價勞工、技術稱不上專精卻承諾難度過高的功能。在團隊中，這些工作會交給有經驗的專案管理者負責，妳不用去擔心。

順暢的溝通管道

熟人之間總是比較好講話，事情可以坦白說而不需要像跟陌生人應對一樣客客氣氣地修飾文字與用語。而且，彼此之間已經有了基本程度的瞭解跟默契，在溝通的時候也相對輕鬆，節省不必要的時間浪費。

有前輩照顧

完成一個專案等於是上了一堂作中學的課，在最初的學習過程中有人帶領總比自己摸索要來得容易。參與團隊，一方面妳可以看到完整的專案開發過程，另一方面也可以學習其她人處理事情的能力。萬一出了意外，也會有同伴提供經驗幫助妳把問題解決。

儘管人際關係幫助妳在開始時候比較輕鬆，然而，也有相對的責任要承擔。前面提過，對方會願意把案子轉介給妳，是基於人情，也是基於信任。如果案子沒做好，影響的不只是妳的個人信用，也會連帶影響到客戶以後對介紹人的信任。除了對客戶難以交代之外，對朋友也說不過去。

此外，在心態上也要警惕，不要因為有人介紹就以為自己擁有特權。人情並不能永遠幫妳，妳自己的技術能力和表現才是真正讓人評價的地方。

1.3.2. 開發其她案源

在熟悉了接案的基本流程之後，妳就可以開始利用網路找案子了！委外仲介網站是個不錯的開始。就像從求職網站或職業介紹中心找工作一樣。妳登入會員，留下個人資料、專長、欲尋找的工作內容與聯絡方式。公司經由妳填寫的資料幫妳尋找符合需求的專案然後將案主資料寄給妳，同時也把妳的資料寄給案主。或者是，妳可以線上經由網站資料庫尋找妳有興趣的專案與案主資料。

專案的合作細節與雙方交涉的過程，通常仲介公司並不干涉。委外仲介公司只是負責為有發案者跟有接案者提供一個取得資訊的統一管道。

公開網站的徵人廣告與BBS站上求職徵人版也是可供利用的管道。案主會在這些場所貼上專案資料，所需人才能力，若是妳覺得自己適合，可以主動跟案主聯絡，尋求雙方合作的可能性。

既是由委外仲介跟徵人廣告找到的專案客戶，獨立工作者就要有心理準備，所有的溝通、談判、簽約合作等事情都要一把抓。不過，雖然都是要由自己處理各項事情，仲介公司通常為會員提供與專案相關的額外服務。如會員專屬線上討論社群，讓新手可以在上面發問，尋求幫助；法律咨詢信箱幫使用者解決合約上的疑問。此外，仲介公司多了一層過濾的功能，登記的專案案主至少在仲介公司留有資料，比起自己搜尋來得有保障。而有個單一的資訊來源也可以省掉到各個網站跟BBS站收集資訊的時間。

除了被動地在網路上尋找專案外，妳也可以主動出擊，把自己的履歷貼上去，讓別人看到妳。或是評估妳覺得可能有需求的商家，一家一家拜訪推薦自己，告訴店家妳可以做什麼詢問她們是否需要。比如跟餐廳老闆說妳可以幫餐廳架網站做網路宣傳。

自我推銷需要相當的勇氣與行動力，在語言表達能力上也不能太遜色。有些商家或許根本沒考慮到這方面的需求，妳可以跟她們聊天，告訴她這樣做可能帶來什麼潛在的好處。不需要像恐怖的超級推銷員那樣咄咄逼人或勢在必得，妳的行為不過是讓別人瞭解妳所具備的能力，日後當她們有需求時，就有可能會找妳。

除此之外，確定妳周圍的朋友都知道妳現在是個獨立工作者，而且，總是在尋找接案的機會。將接案的收入撥出少部份（如5%）做為仲介費給朋友、請朋友吃頓飯看場電影，或是送份禮物，都是妳表達謝意的方式。如此一來，妳的朋友比較會願意持續積極地幫妳介紹工作。

有可供展示的作品通常能提供客戶對妳的信賴。這些可能是妳曾經寫過的作業、或是閒暇時的即興作品，稍作包裝之後放在網頁上、電腦裡或做成平面檔案。跟客戶接觸的時候可以展示出來，讓她們相信妳是真的有能力。

最後，如果妳是學生的話，還可以從學校工讀找起。學校的計算中心以及各單位的行政與教學部門，都會需要有人幫忙做程式設計或系統維護的工作。像是寫網頁、行政流程自動化程式之類的。多跑各處室詢問或是勤看公告欄，都可以幫妳找到這方面的工作機會。比起外面社會，學校的工作環境比較單純。通常也不需要談合約的手續，工讀生薪水或許不高可是相對的壓力也較小。妳也不用為了案子多花時間在外奔波。在接觸過的獨立工作者中，不少人的第一個專案都是從學生時代在校工讀開始的。

1.3.3. 從哪些案子開始接好呢？

什麼樣的案子適合初學者呢？我們分兩種工作模式來談：參與團隊開發與個人獨立接案。兩者各有不同的考量點。

參與團隊的話，案子的選擇權其實不在妳手上，而是由專案管理者決定。妳要決定的是，什麼樣的工作內容。一個專案的分工通常有專案管理、系統分析，跟實作三個大項。

站在磨練基礎技術能力的立場，新手一般是從實作部份做起，也就是，實際地用程式寫出某些功能。這時候，妳可以思考自己比較想從事哪部份的實作，這個功能或是那個功能。在工作內容的選擇權上，除非證明妳在哪方面的能力特別好，否則，新手很難主動要求別人把特定的什麼部份讓妳做。當然，若是妳來頭大有名氣就另當別論。

專案發展使用的語言與開發工具，可能是妳接觸過，也可能是妳完全不知道的。是否願意為了一個專案去學習新的語言、開發工具和技術，這也是當妳在決定是否參與專案時，所要思考的問題。

若是個人獨立接案，則又另當別論。對沒有實際經驗的新手來講，建議從規模較小的案子做起，因為在剛開始妳需要的是訓練自己的能力跟建立自己的商譽，規模小的案子較容易掌握，出錯的機會也比較小。規模大的案子系統架構通常較複雜，需要足夠好的系統分析設計能力才可以做，這對新手來說，並不容易，也不是一朝一夕之間就能馬上學會的。

接案子不是只要會技術，還要對客戶方的專業領域有瞭解才行。自己一個人的話，剛開始不要接牽涉到太多客戶專業領域的案子。因為在對自己的專業技術都還不夠熟練的情況下，還要去熟悉客戶的專業領域是很辛苦的事。在接案初期，「不懂的領域不要碰」是很重要的守則。

從技術難易程度來看，大部份的人從簡單的網頁設計、Javasript 應用開始。然後是與伺服器端連結的應用程式，如CGI、ASP跟PHP。接著是資料庫相關的規畫、應用程式撰寫。熟練這幾樣技術之後，大多數案子所需要的能力妳就大致都具備了。可以試著去接比較大型的專案，或學習其她領域的知識。

很多知識與能力是由時間與經驗慢慢累積而成的，不需要急著在起步的時候就把所有的東西都學會。盡量抱著學習跟自我磨練的心態，多和有經驗的人溝通，相信妳的接案生涯就能順利的展開。

2. 溝通: 達成最佳共識

地點：某工作室
時間：早上10點
「喂」（^_^）
「呀，吳先生你好」（^o^）
「什麼，你說還要開一個討論版的功能」（?_?）
「好呀，沒問題」（^^;）
「啊，還要聊天室」（>_<）
「可是吳先生，你不是要做庫存管理系統嗎…………………」（^_^|||||）

相信有過接案經驗的開發者都會承認，在開發過程中，最艱難的部分不是在實際開發程式或系統本身，而是在開發時接案者與案主之間對開發內容的協調與認定。案主對於需求常常表達得不夠明確，模糊的需求對於接案者而言，是非常困擾的。案主偶爾的福至心靈，看到或想到他們覺得更好的主意，然後以各種方式，軟硬兼施，想辦法讓接案者乖乖就範，達成更改需求的目的。

不知道案主確實要什麼樣的東西？需求一直變更讓開發變得困難，因為規格一直不停的變更，往往業務方面為要討好客戶傾向接受，而工程師因開發的麻煩而傾向抗拒。就這樣在一來一往之間就把時間浪費時間，結案也總是因為這些不期然的因素不是馬虎交貨不然遙遙無期。相信身為一個接案者，或多或少都曾遭遇過類似的問題，抱怨歸抱怨，問題還是得解決，探究之所以會有這些問題的原因，便是在與案主互動的過程中，沒有充分達成有效的共識，總歸一句話，這些問題的癥結就在於溝通。

有人會說，「那是你們笨，這些東西你們簽約時寫清楚不就好了嗎。」但現實上，契約不是一蹴可及的，契約訂立的任一方，都會想追求自己最大的權利，責付對方最大的義務，這中間不免發生利益衝突，或有疑意不清的地方。這些問題的解決，都必須靠雙方的協調與讓步。「法律是死的，人是活的。」通常法律是最後的手段，往往也是最糟的手段，因為真正動用到法律時，耗時耗財，最後的結果常常是得不償失。「簽約」事實上只是表達雙方合作的誠意，並將溝通的結果載明於文件上。因此，真正大部份問題的解決與預防，還是得靠事先良好的溝通。

溝通的目的在於明確表達案主及接案者雙方的想法，達成雙方均可接受的共識，讓雙方的認知一致，以減少因誤會而導致的各種沉沒成本，避免開發過程中雙方投注大量的心力，卻開發出無用或不適用的成品。溝通不良或認知不一致除了影響開發的時程，也將影響開發的品質，更甚者，將導致案主與接案者感情的破裂，不但案主心疼白花錢，自此不信任外包，造成外包市場規模的縮小，對接案者而言，除了浪費時間及滿肚子怨氣之外，也有可能因此一案而砸了品牌，沒了形象。

溝通在專案執行過程中的重要性可見一般。然而，由於溝通是一種人與人之間互動的方式，溝通的成效僅能用結果來衡量，沒有所謂的定理存在，只有經驗的傳承與累積，前人種樹顯得格外偉大。如人飲水，冷暖自知，有了這些笑淚交織、活生生的經驗所整合出來的一般性原則及建議，最多也只能提供接案者殷鑑不遠的參考，真正有效的溝通只能透過接案者的親身體驗而進一步內化成自己的葵花寶典。

以下這章是專為獨立工作接案者或者是工作團隊的接案代表（簡言之，就是業務）而寫的，主要談的是如何對你的案主（也就是客戶）進行溝通，第一部份談的專案溝通時一些基本原則，是適用整體專案流程，接下來談個別階段的溝通，從事接案前的接觸、溝通、訂價、規格到進行時狀況及結案動作，我們會有一系列完整的介紹。如果你是個菜鳥，這章你應好好細讀，如果你是個老鳥，可以對照一下自己的經驗。

2.1. 專案溝通的基本原則

溝通在字面上的意義是雙方資訊及意見的流通，事實上，溝通包括兩個層面，一個是議價能力（Bargaining），一個是協調技巧（Negotiation）。在專案流程的溝通中，兩者往往交互使用的過程。你的議價能力取決於你本身的條件，而你的協調技巧取決你的臨場做法。

通常而言，議價能力直接影響到最終的價碼；議價能力較強的一方，通常可取得價錢優勢，相反的，議價能力弱的一方，通常在價錢上就只能乖乖的配合，否則就做不成生意。對接案者而言，議價能力的大小取決於個人技術能力的強弱、個人品牌知名度的高低以及個人接案形象的優劣，這些都是靠以往工作經驗的累積。倘若接案時案主知道他所找的接案者其技術能力夠強，知名度夠高，過去的開發成果具有一定的口碑，則在進行專案溝通之時，便較能獲得案主的尊敬及信任，進而使得溝通的進行較為順利。因此，一個成功的接案者在平常就必須好好的經營自己，累積自己的技術能力，建立自己的名聲與專業形象。 至於協調能力則與專案工作能否順利完成有關，一個協調能力好的接案者，會迅速判定誰是主要的溝通對象，以專業、誠懇的方式與案主進行洽談。在洽談的過程中能科學地分析客戶的需求，給予適當的建議，並能引導接案者接受自己的想法，避免可能爭議的發生而非等到爭議發生時，再將爭議平撫下去。

我們常聽到一句老話「預防重於治療」，最好的溝通，並不是指在衝突發生時能調和鼎鼐，折衝樽俎，而能夠針對進行狀況可能發生的問題，事先規範，避免日後爭議發生。因為，等到爭議發生時再處理，不論最後的結果如何，至少有一方認為自己吃虧，進而影響下一次合作的機會。所以，在一般委外專案中，不論有理無理，往往是接案方步步退讓，儘量滿足案主的需求，理由就是他不想破壞下一次的合作機會。

2.1.1. 技術能力

具有一定水準的技術能力不但可讓接案者在與案主溝通時具有相當程的自信，也能夠迅速理解案主所提出的功能需求並判斷各項需求的的可行性。技術能力除了可提供接案者評估是否接受專案委託的標準，在溝通的過程之中同時也是案主評估是否外包給接案者的考量因素之一。

技術能力可由技術的深度及廣度來衡量。所謂技術的深度是指對特定某項技術的專業程度，舉例而言，某位接案者對Java語言特別熟稔，可提供案主Pure Java的Solution；或是某位接案者對於多媒體技術特別擅長，可提供案主效果最好的即時影音播放（Real-time）或是隨選視訊（VOD）的Solution。

技術的廣度則表現在接案者對於某項領域技術的專長。例如某位接案者對於各種資料庫都頗有研究，從Oracle、SUN到MySQL，均有相當程度的了解，可提供案主資料庫相關的整合應用或資料處理的Solution；或是某位接案者對於各種HA（High Availability）的技術均十分熟悉，可提供案主關於流量分散或是容錯處理的系統設計建議。

面對具有技術背景的案主，接案者的技術能力更是不容輕忽。技術能力代表的是接案者是否有能力可以接受專案開發的委託，代表的是案主是否可以信任接案者而將開發的重責大任交付給接案者。愈具有技術深度及廣度的接案者，愈能受到案主的尊敬及信任，在溝通過程之中除了可以減少因不信任所增加的額外成本，也可提高溝通的效率及效果。在與案主協商的過程中也較有立場或地位堅持一些開發的基本原則，在開發前即確立開發需求，並適當的拒絕案主不合理的需求變更要求。

2.1.2. 品牌知名度

品牌知名度，指的是接案者在外包市場上具有某種程度上的名氣，這個名氣可能來自於接案者參與實際開發的技術能力，也可能來自於接案者在某個技術領域上的專業性與權威性。舉例而言，某個接案者曾參與研發過頗具代表性的無線網路應用技術，在無線通訊領域中享有盛名；或是某個接案者是開放原始碼（Open Source）產業的推動者，在開放原始碼領域中具有特殊的領導地位。這些接案者在特定領域中就像明星般具有高度的知名度及影響力。

不管任何行業，身價和名氣是呈正相關的，因此你想要提高工作的報酬及可信度，「成名」是個值得努力的方向。當然，要成為家喻戶曉的大人物是有點運氣的，不過至少你該應努力經營自己。想辦法取得一些證照來證明自己的實力。

通常而言，證明自己的實力方式有下列三種：

比賽

通常分二大類，一是網頁設計比賽，另一種是程式設計比賽。前者機會比較多，不止學校，像企業也會舉行類似比賽，例如像友立為了推廣PhotoImpact，就有舉行網頁設計比賽，社會人士也可以參與。後者多偏在學校、內舉行。不管什麼比賽，如果你能得名，把獎狀印一印，這張紙將是顯示自己能力一個有力的證明。

認證

各類軟體公司為了推廣及軟體都會有一些認證，如微軟認證（MCP，Microsoft Certified Professional，最主要是MCSD，Microsoft Certified Solution developer）、Java認證等等，證明你在這方面確實是一個專家，有了這些大公司的保證與背書，對客戶而言，心理上會覺得交給你來做，比較有保障。

作品

這是最實際的東西，給客戶看你所做的作品，好作品的說服力遠比比賽與認證還有用。但唯一不同的是，在初期而言，比賽及認證資格比較容易提高你身價（因為有市場行情），好的作品則很難，但是作品可以大幅提高客戶對你能力的信任。

儘管你是一個自由接案者，但接案和應徵工作並沒有什麼兩樣，要好好準備自己的履歷，告訴你的案主你做過什麼事，甚至包括被什麼單位應邀演講之類的，這些都是增加自己可信度的重要條件。但要注意一點，要針對不同的個案要好好強調你相關工作「技術」經歷與背景，對案主而言，他們才不管你當幾年的獨立接案者；事實上，案主根本希望你是一個商業白痴，但是他們會十分在乎你的專業工作能力。

具有品牌知名度的接案者，在議價能力上便具有相當程度的優勢，所提出的言論或建議也具有某一程度上的可信度，在與案主溝通的過程中，在一開始即可因接案者的知名度而省下不少相互摸索的成本，由於案主早已知曉接案者的專業技術及名聲，因此毌須重新認識或調查接案者的背景及能力，而接案者也可減少推銷自己的時間成本，一開始與案主洽談即可直接切入主題。

一個具有品牌知名度的接案者，就像一個擁有許多專業相關人士背書的技術開發者，可以讓案主放心的將專案委託交付，相較於一般的接案者而言，也可具有較多的接案來源，進而累積更多的開發經驗。身為一個在特定領域中具有品牌知名度的接案者，通常也會因為該領域的人脈擴展而有較多的經驗分享機會，在良性循環中累積創造自身的價值。只要曾經有過參與某個技術社群的經驗，相信便可深切體會到社群所創造及分享的力量，那些技術社群裡的意見領袖，在在可做為具有品牌知名度的接案者代表。

由品牌知名度所帶來的效益，除了降低初次的溝通成本之外，也使得接案者在與案主洽談時，能夠具有較為平等的地位，在協商過程之中也較易能夠維持某些基本的權益。

2.1.3. 形象及口碑

接案者過去接案的成果，是接案者彰顯自己能力的最佳證明。良好的配合度、順暢的互動過程、傑出的技術能力以及完備的開發成果，均是案主在衡量合作對象時的重要指標。具有良好形象及口碑的接案者，等於有了免費的宣傳工具，藉由輿論的口耳相傳，可帶來較多的委託需求，進而增加許多的選擇機會，讓溝通時的議價能力提升。

形象及口碑是接案者有力的背書，透過形象的建立及口碑的宣傳，可讓案主對接案者具有較佳的初次印象，如果介紹者或引介者是具有相當地位的人士，如案主的朋友或是技術專家，則接案者將可獲得案主相當程度的信任及尊敬，在專案開發的過程中也可獲得較大的自主性。

以上所提到的這些個人優勢，可以創造出一個對接案者較為有利的溝通環境，然而，要達成有效的溝通，尚需佐之以高明的談判與溝通技巧，以及對一些溝通細節的掌握及注意。牢記溝通的目標在於協調雙方認知的一致性，時時提醒自己在溝通時是否忽略了某些重點，而這些疏失足以影響未來開發以及驗收的進行。

2.1.4. 表現專業

要建立別人的信任感，表現「專業」是第一要素。特別是對素未謀面的案主，在一開始，他唯一評判可以的標準就是你的行為表現。要記住，雖然你的客戶不會寫程式，也許連電腦也不會用，但是這些人大都有一定的社會歷練。因此如何讓他感受到一你是一個箇中老手，有能力達成他的工作任務，是一件很重要的事。一個表現不專業的人，基本上很難贏得信任，你很難接到案子，如果接到了，價格也無法提高，並且花在與案主溝通的時間上會比你做事情的時間還多，因為你要對一個不懂技術的案主，花費許多口舌去解釋為什麼那麼做，以取得他的信任。

儘管人家說「內在比外在」重要，但佛要金裝，人要衣裝。拜訪案主時，適當的衣著是很重要的。同樣是學生，一套西裝可以馬上提昇你的社會年齡，常有學生團隊穿著夾克，午仔褲，球鞋就去見客戶，這樣的印象馬上就暴露自己的身份；相同的道理，如果你是穿著金金亮亮全新的阿曼尼西裝出席，太過隆重，也會犯了相同的毛病，都是向你的客戶傳達一個訊息，「我是新手上路」，這種人通常是從此不再聯絡，不然就是當待宰羔羊，任人宰割。當然，西裝不是唯一選擇，你也可以學習蘋果電腦總裁賈伯斯高級襯杉加牛仔褲的穿法，畢竟你是技術專業人員，而非服務業從業員，服裝上沒有職業性講究，唯一的原則就是挑一些成熟一點的衣服，顏色不要花綠，記住，千萬別穿球鞋。不可諱言的，建立專業形象是要花點銀子的，你不必花大把的鈔票花在這上面，但適度的投資顯然是必要的。

當然，適當衣著只能抵擋客戶銳利的評審眼光五分鐘而已，你的動作談話仍要得體，不然一下子黔驢技窮，可是馬上會被老虎吃掉的。至於要不要有名片？我的建議是最好能夠有，但如果你是獨立作業，沒有也什麼關係。名片的好處是可以節省對方抄寫你聯絡方式的時間，當然，如果有Palm可以交換一下相互的名片檔也是不錯的選擇，在拜訪的一開始，如果能順勢向客戶討教一張名片，通常可以從名片上了解對方的基本背景，例如公司名稱，客戶的職稱，進而判斷如何與其溝通。

你能帶著NoteBook或者作品資料向你的客戶簡報你以往的工作經驗，及能夠有系統的詢問對方的工作需求，那就更優了。資料作品可以客觀的佐證你的專業能力，這點不證自明，無需贄言。那什麼是有系統的詢問呢？簡單來說，就是有點像填表格的文件，除了基本資料外，你會細詳性詢問他的要求，例如先確認一下客戶公司使用的電腦硬體及作業系統（相信我，還有公司是在用486配合DOS系統在作業），然後再確認公司目前使用那些軟體，是否有Database系統或者是財務管理系統存在（考慮到資料銜接問題），及公司目前上網的情形（Moden，ISDN、ADSL或專線），最後再針對上述的狀況提出說明及你的看法。

這樣有系統地分析出客戶目前狀況會顯得你的接案經驗豐富；就算你事實上沒有足夠的實地經驗，參照別人的經驗，能夠組織性詢問客戶或介紹自己想法，會增加你的權威感。如果能夠事先得知客戶公司或個人的基本資料，花點時間加以研究，並且在談話表達一下對相關看法（當然是正面的），都有助於與客戶溝通，提昇客戶的信賴感。

2.1.5. 態度誠懇

儘管溝通是門藝術，需要經驗的磨鍊，但這也絕不表示在溝通時你應該表現的像隻老狐狸一樣的與你的案主談話，要知道通常你所面對的案主大都是有一定社會經驗的人，如果你不誠懇或想裝腔作勢，事實上，馬上會被識破的。

誠懇並非坦白，但也絕非欺騙。懇誠是顯示你很有誠意去爭取這個客戶，並且在溝通的過程中突顯自己的優點，儘量去避免提及自己缺點（如自己接案經驗不足），除非自己的缺點將會導致無法完成客戶所交付的任務（自己明明不會Linux，硬說自己會）。如果客戶發現你的缺點時，「小伙子，你是第一次出來接案吧！」你也不妨緬腆一笑，大方承認，反而會博得對方的好感。

前面說過，案主通常是不懂的IT技術的人，因此在與其面談時，絕對不讓客戶覺得自己很笨，儘量以案主的角度及語言去解釋，不要露出瞧不起人，你不懂技術，或是連這個你也不知道的態度。在溝通的過程中，絕大部份的案主會因不了解電腦或網路而會問許多非相關專案的問題，例如，如何收E-mail，Outlook要怎麼使用等等，此時，千萬別在語言中透露出你的不耐。另外，在解釋時請儘量白話，少用專業術語。要記住，他們生長的世代與你不同，許多IT產業的四、五十歲高級主管在通E-mail用英文，理由不是他們留過洋喝過洋墨水，所以愛用英文，而是因為他們不懂中打。

2.1.6. 找對的人溝通

在接案的過程中，接案者要能迅速地判斷你所面對的客戶代表是不是具有拍板定案的權力，這點非常重要。畢竟，談案子的目的是要求個結果，能談成是最好，如不能配合，早聚早散，將時間好好準備下一個案子也是不錯。而且，公司內部隨著決策位置不同，往往對事情的要求也不一樣，客戶代表說的，往往和真正客戶的要求會有所差異，因此趁早弄清出誰是具有拍板定案權力的代表，直接直搗黃龍，容易事半功倍。

但是，這不代表你就可以忽略一開始的客戶代表，畢竟沒有他們的推薦，你是無法見到幕後大老闆的。但如果和客戶代表談了二、三次還沒有見到真正決定者，那麼你就要小心，也許你只是成為客戶代表比價參考的對象而已。另外，客戶公司裡的其他人也要注意，特別是客戶裡的IT方面的主管，因為客戶本身也會想聽聽自己人的意見。通常，這類的人對你案子是「成事不足，但敗事有餘」。基本同行相輕的心理上，他們對外來接案者在態度上會比較敵對，除非你本身是由他們所推薦的。

另外，為了確定溝通管道正常，過濾發案方內部的要求，避免雜音干擾，或重覆要求，在大型專案中，合約中可以指定發案方與接案方的聯絡人，一方面可以明確責任，一方面也可以保障溝通訊息正確。

在商場上，難免會碰到一些不講誠信的人，如何判對一個人誠信與否，是需要經驗累積的，這樣的過程是只能意會不能言傳的。但是這裡可以提供一個經驗法則是：不要被對方的外表或態度所矇蔽，唯由行動才能判定一個人的誠信。根據經驗顯示，所謂是騙術家，往往是最親切的人。無論你的合作對象態度再好，一旦沒有依約按時履行義務，你就必須小心注意。

2.2. 專案執行前的溝通

在專案正式簽約之前，大約可以分成洽談、需求分析、訂價、正式提案等四個階段。這張表列出了各個階段的要點及溝通內容：

+------------+----------------------------------+----------------------------+
|專案執行階段|內容                              |要點                        |
+------------+----------------------------------+----------------------------+
|洽談階段    |溝通內容：初次見面，請多多指教    |* 了解案主的基本資料        |
|            |溝通目標：爭取接案機會            |* 思考或草擬解決方案的想法  |
|            |溝通結果：口頭或意思表示進入需求  |* 不要做超過自己能力的承諾  |
|            |          分析階段                |* 引導案主說出需求          |
|            |                                  |* 提供案主可能解決方案      |
+------------+----------------------------------+----------------------------+
|需求分析階段|溝通內容：基本需求                |* 以圖文說明輔助溝通        |
|            |溝通目標：了解案主的基本系統及    |* 適度的幫案主釐清需求，    |
|            |          功能需求                |  而非幫案主規劃需求        |
|            |溝通結果：基本提案書及報價        |                            |
+------------+----------------------------------+----------------------------+
|訂價階段    |溝通內容：系統開發報價            |* 了解行情制定合理價格      |
|            |溝通目標：配合正式提案確認價格    |* 溝通重點應放在替客戶「解決|
|            |溝通結果：正式合約                |  問題」和「滿足需求」，而非|
|            |                                  |  價錢本身。                |
|            |                                  |* 試著提出二種以上報價      |
+------------+----------------------------------+----------------------------+
|正式提案階段|溝通內容：系統開發內容            |* 於正式提案書內確實載列專案|
|            |溝通目標：配合報價，向案主確認    |  的各項系統功能            |
|            |          開發內容                |* 於系統開發時程規劃書中規範|
|            |溝通結果：正式合約                |  系統開發時程              |
|            |                                  |* 以 Prototype 呈現系統全貌 |
+------------+----------------------------------+----------------------------+

2.2.1. 洽談階段

* 溝通內容：初次見面，請多多指教 
* 溝通目標：爭取接案機會
* 溝通結果：口頭或意思表示進入需求分析階段

洽談階段是指案主與接案者最開始的接觸期。雙方接觸的方式有可能為案主透過查訪或有人引介而主動聯絡接案者，也有可能為接案者透過管道得知案主有系統委外需求而自動毛遂自薦，或是雙方透過仲介者相互聯絡到對方。

了解案主的基本資料

初次見面最重要的是第一印象，接案者在與案主聯絡見面之前，最好能夠先了解一下案主的背景，包括公司的基本資料，發展動態，未來方向等，這些資料可由公司網站，新聞稿，朋友或是報章雜誌取得。所謂知己知彼，有了這些消息做基礎，不但有了與案主的閒聊話題，接案者也可因了解案主的基本資料而較能切入問題核心以及案主的實際委外需求。對案主而言，也將會對接案者的認真負責與勤作功課而印象深刻。

思考或草擬解決方案的一些想法

除了案主相關的基本資料外，預先針對案主所提出的一些需求作準備，在與案主見面之前對這個案子的難度、開發時間、開發方式……等問題先在心裡有個譜，在與案主溝通時，將較能掌握案主所要開發的系統全貌。切記千萬不要期望案主在第一次見面時即將需求非常明確的表達出來，案主通常會透過與接案者的溝通過程而將需求明確化，因此事先預作準備可以輕鬆的應答案主所提出的相關問題，也可藉此建立案主對自己系統開發能力的信任度。

不要做超過自己能力的承諾

身為一個系統開發者或程式設計師，常常存在著一種使命感，就是要開發出一套當下最完美的系統。對於案主所提出的需求概念，接案者往往有許多解決方案，甚至還想出更棒的點子。通常這些很棒的點子是可以開發出來的，但重點是需要花費多少的時間及成本，接案者必須仔細衡量自身的時間及成本限制，千萬不要不管案主提出什麼樣千奇百怪的需求，均拍著胸脯保證絕對可以達成，之後卻耗費大量精力在研究及評估開發方式及可行性。做超額的承諾一開始可能可以獲得案主的讚賞，甚至獲得開發委託，但在實際執行時卻將面臨將花費大量時間成本的問題，倘若無法達成，更會影響接案者本身的形象。

案主說不清楚怎麼辦

要知道，所謂的客戶大都是非專業人士，他們通常只能說出一個模糊的形象，並且以為你就能馬上化腐朽為神奇，完美地的呈現在他們眼前。因此適當的引導與事先的說明是很重要的。以成品的「修正」問題為例，這是幾乎每一個接案者都會遇見的問題，不論是做程式還是做視覺的，都會有此困擾。特別是做美工視覺的接案者，畢竟每個人的美感經驗不同，只能意會，無法言傳。相同地，追問這個問題產生的原由，絕大部份的接案者會說，問題的發生是在於「案主並沒有事先明確告知其想法。」面對此一情形，你可以去引導他：問他有無偏好的網站？或者將他的要求轉換成規格化的術語說出來：你是指要設一個E-mail伺服器？重要的是要以你的專業知識去引導他「自已」說出想要的形象。

如何拒絕案主的提議

要記住，案主找你是為解決他的問題，而不是花錢買教訓。在接案溝通時，切忌去否定客戶的想法，這一個很重要，絕對不要脫口而出說：「做不到。」不管有心無意，此話一出口就代表兩個意思：一是自己能力不行，二是案主的要求太過份，這是對案主和自己的雙重否定。是最差的溝通詞句。不管理由為何，如果你想勸案主打消主意，而是應該從案主本身的立場，從你「專案」的眼光幫他分析：如這總做法會超出預算，或者是會讓使用者失去耐性，或者不利員工的工作習慣… 等等的理由，反正是站在案主的角度方式去勸說才比較容易溝通。

站在案主的立場去思考

在提出解決方案，儘量不要加入個人的偏好，如硬體上我就是要用SCSI架構，或者非用Linux Solution不可。在解決問題的前提下，通常案主的考慮有幾項，一是預算，二是否能銜接舊有資料，三是使用習慣，四是維護問題。所以，在早期溝通時，如果能對上述幾點做成不同案子的分析，會令人印象深刻。就算現實情形是自己只擅長單一的架構，但是在向案主溝通時，針對上述幾個項目做出說明，將你所推薦的架構包裝成較好的方案。

2.2.2. 需求分析階段

* 溝通內容：基本需求
* 溝通目標：了解案主的基本系統及功能需求
* 溝通結果：基本提案書

初次見面後，如果雙方均有意願繼續進行下去，則進入需求分析階段。需求分析階段主要的目標在於根據案主所提出的基本需求，提出一份簡單但完整的基本提案書，一方面將案主需求具體化，供案主釐清需求，另一方面接案者也可藉以確認是否有誤會案主關於整個系統的想法。如果有不只一位接案者競逐開發機會，則基本提案書尚可做為案主衡量評選接案者的參考。

需求分析階段視案主需求的明確程度而有不只一次的溝通機會。

以圖文說明輔助溝通

基本提案書要儘量具體完整表達出案主所提出的需求，除了文字描述之外，最好佐之以圖形說明。舉例而言，在提到介面功能時，除了列舉說明外，如果能加上功能之間的架構運作圖示，將有助於表達各個功能呈現的樣貌。

基本提案書沒有一定的撰寫方式，主要的目的在讓案主能夠以書面的方式輕鬆了解需求具體化後的成果，由於每個專案的性質及大小不一，因此基本提案書的架構需視專案需求而做適當的調整，一般基本提案書所會提到的重點有：

*

前言：簡單說明這個系統規劃的目標或目的。

*

介面功能規劃：先依主功能分項，再按介面動線描述該主功能項下的各細部功能。這是使用者所看到及所使用的功能。

*

系統功能規劃：所有介面功能背後都有相關的系統功能，此章節即在按系統功能項目分類，逐項描述各系統功能項下的細部功能。這是系統管理者所看到及所使用的功能。

*

系統架構規劃：簡單說明開發本系統的軟、硬體規劃，如開發平台、相關程式語言、資料庫及整體系統架構的設計。

*

開發團隊：說明開發本系統所須花費的時間及人力。

*

開發時程規劃：說明開發本系統的階段性時程規劃及各階段雙方相互應配合的事項及方式。

*

簡單報價：按功能項目逐項報價。

*

版權聲明：聲明本基本提案書的著作權。

其中介面功能規劃為案主需求具體化的呈現，系統功能規劃為系統因應介面功能所須配合開發的項目。

適度的幫案主釐清需求，而非幫案主規劃需求

前面說過，許多案主常常只有一些模糊的概念，並未對專案的需求有很明確的規劃，因此希望接案者可以針對一些需求大綱，為案主提供明確且可行的建議。對接案者而言，提供建議不啻是一個彰顯本身能力的機會，案主在佩服欣賞之餘，也可建立對接案者的信任度及認同感。

但需注意的是，案主是否有誠意與接案者進一步合作，還是只是希望藉由與接案者的溝通及互動，來獲得原來需求不清楚的答案。有些案例即是如此，當接案者興致勃勃的提出各種建議及規劃，案主了解之後，發現可以自行開發，或是最後卻委託其他接案者來開發，結果接案者只有白白提供苦心的規劃，到頭來卻一無所得。

有一人得標，其他人落馬，這是參與標案必須有的心理準備，基本提案當然要規劃的完善，才有機會在多人競標的場合中勝出。然而何謂完善的提案﹖過與不及均非好事，這需要適當的拿捏。接案者可以藉由與案主討論需求的過程，觀察案主的心態及誠意，最好是針對案主本身所提出的需求來做基本提案書的規劃，如遇不明確的需求，則羅列不清楚的問題，向案主尋求解答，由案主自己來思考並提供答案，切記提出需求是案主的責任，接案者最好不要幫案主規劃需求。

這裡所指出的是接案者在提出基本提案時可能遭遇的問題以及一般性原則上的建議，並不是絕對的執行方式，接案者可以視與案主的互動狀況或是專案性質而定，如果必須幫案主規劃或建議需求，則接案者也可以利用其他彈性的方式，來保障自己的規劃被不當的剽取，例如透過合約的擬定或是收取部分的諮詢費用等。

2.2.3. 訂價階段

* 溝通內容：系統開發報價
* 溝通目標：配合正式提案，確認價格
* 溝通結果：正式合約

如何訂價

人生在世，錢不一定萬能，但沒有錢卻萬萬不能。一個人之所以願意離開公司體制，進入沒有固定月薪保障的自由接案者生涯，最大的吸引力之一就是「報酬」。因此你的訂價策略將會攸關未來生活品質與心情。但是開高了，可能會嚇包客戶，開低了，可能會苦了自己。那麼你會如何訂價呢？以美國的例子而言，基本是以時薪計算，其他實體開銷另計。基本上他們收費的原則是先預今年合理薪水是多少，如果是七萬美元，那麼他一個小時就會收七十美元。

對照到台灣而言，接案者工作薪酬市場的價格是一片混亂，並沒有明確的市場行情資訊可供參考。建立一個網站，有人從五千元到五百萬元的價格都有，當然這還牽扯技術的難度及規模的大小。就算是一個相同規模的網站，其價差的範園依然很大。不過，時間一久，所謂的價格慢慢的也有行情出現。但是這中間還有層次的差異。決定價格差異性因素包括，接案者的性質（兼職的學生團隊和全職專業的價格當然有差），技術難度（做HTML、ASP、JSP及PHP都有不同），是否個人化（專為案主設計的原件），趕工要求等因素，有所不同。

以價格比較公開化的網頁視覺設計而言，都常如果是找學生或個人來做的，首頁的價格（不包括Flash動畫功能）平均價格約在五千元上下，便宜的，有人喊三千，也有人喊七八千，當然視接案者的能力（如是否得獎，曾做過大型網站）及案主的要求而定。內頁的部份通常是首頁價錢的一半，甚或更低。如果是找專業公司，或美術工作室，製做首頁的價格可能再高，八千至一萬應是行情價，再高的也有，其餘的價錢如上述。

至於做後端程式的部份，價格就比較混亂。但對接案方而言，評估成本的方式通常是事先評估工作人數及其工作時數。通常難度愈高或愈煩雜的技術，所耗的工作時間愈多，「天」應是計算的基本單位。台灣一個合格程式工程師一天（指工作八小時）的薪水是三千元，依這個為基礎，再參照其他因素，如稅賦的問題，技術權利是否買斷，是否為臨時趕工，再加上你其他開銷（如送機器，架網路線），最後加上利潤參數（就是純粹利潤空間）所決定出來的就是價格。

以上是現行專案基本開價的算法。在以往，很多接案者會對案主以數量的方式來計價，尤其是網頁設計工作。不過，現在絕大部份的接案者在面對案主報價時，都是以一個案子來計算，連同其他的開支價格如硬體支出部份，合併報價。理由很簡單，這樣比較有利潤，在一方虧的錢，可以在另一方要回來。不過現在市場現實是，台灣有愈來愈多的年輕接案者投入這個市場，因此這行競爭十分激烈，價格上也拼的很兇，但所幸的是，相對的市場需要量也十分龐大。對一個聰明的接案者來說，除了要增加更多附加價值外（如維護），在開發時一定要能建置模型化的工具，換言之，你所寫出的網站程式或素材，一定要能重複再利用。如此才能真正的創造出利潤空間。

與客戶報價

通常在你了解客戶的需求及估算你大概的成本後，接下來就是對客戶進行報價。無論你一開始想應該賺多少，都只是空中樓閣。這裡的價格才是你真正的報酬。

很多人誤以為和客戶談價格是一門很重要的臨場技巧，事實上並非如此，等到你與客戶實質報價的那一天，價格談判的實質意義已經不大。客戶能給你的報酬，早在一開始雙方接觸就已可以推測個大概，這些都歸因於前述你的技術能力、品牌知名度和客戶本身的需求。試想，一個專找學生團隊的客戶，基本上就是抱著「便宜又大碗」的心態，不言可喻，價格是愈低愈好。但是一個一年要做五千萬生意的客戶，那麼價格也許不是重點，重點是你的服務品質是否能達到他的需求，也許是要介面方便，也許是要系統穩定等等要求。真正決定成案價格的最主因素，是接案者對客戶的需求的了解。因此，如果你真想賺大錢，也許一開始，你就應該選好你的市場定位，鎖定你的目標客戶，而非利用客戶的無知企圖想海削一筆。

回歸正題，報價溝通的重點應放替客戶「解決問題」和「滿足需求」上，而非價錢本身。在報價單遞出去的同時，上面明細列的不應該是你用了多少個工程師每人收費多少。比較好的報價方式是，在通盤了解客戶的需求後，而是根據他的要求，你會提供什麼樣的服務，每項服務多少。試著去區格化你的服務項目，準備出二，三種以上的報價，讓客戶選擇。除非你是採低價戰術或客戶要求，否則在進行報價溝通時，不必刻意強調你的價錢多有划算，或者一項一項算給他看我這樣做的成本是多少，這樣只是提醒客戶去斤斤計較你的價錢。對客戶而言，找你的首要目的是在解決問題，而不是製造更多的麻煩，價格是次要考量。

當然做生意難免碰到客戶殺價的情況，但如果你開的價錢會被客戶猛砍，這也許證明你溝通不夠，不了解你的客戶需求或事先的預算。如果並非如此，而是客戶不了解狀況時，經過溝通還是無法改變客戶的心意，那麼就放棄吧。一來，如果用過低價格接下這件案子，將會對不起僱用你的其他客戶；二來，客戶會負擔相當的風險，畢竟要另起爐灶，又會浪費一段時間成本，也許倒頭來並不划算。不過，假如你覺得這件案子是關鍵性案件，譬如你的第一件案子，或者是簽了這個案子後，其後將有長期穩定的案源，或者日後的維護性收益極高。如果你判斷是屬於關鍵性案子，價格方面不妨讓步。

當然在實際商場運作上，也有不同的行銷手法可以學習。台灣許多軟體公司事實上是搭配者IBM和Sun的機器，當他們的軟體支援商過活。因此也有很多軟體公司仿照這種手法，利用賣硬體的手段，將自己軟體包裝進去，例如採購一台伺服器電腦加四台PC一共十五萬元，送網站、E-mail Server等等。也有的是因為案子價格夠高，會直接買台新電腦，將軟體灌好就免費送給客戶。畢竟，對傳統客戶而言，他們會比較相信硬體而非軟體。

付款方式與請款

當案主同意接案者的報價時，通常很快會進行正式簽約，以便早日完成工作。當簽約時，通常會詳述付款方式。通常付款時間，依各家習慣不同，依工作時程分為二次到五次不等，如以三次為例，通常是簽約付三成，完工付三成，驗收結案付四成。至於付款方式則會明定如現金匯入帳戶或開立一個月內對兌之即期支票。偶爾廠商會因現金調度的問題，要求開立較長期支票，此時必須小心評估廠商情況。另外，如果廠商拖延不依約付款者，也要小心注意。

至於請款，在合約簽定後，請依請款日期逕自案主的會計單位請款，如果有問題，再向案主反應，除非案主並無會計人員處理或已事先約定，不要一開始直接向案主請款，這會顯得不太禮貌。

2.2.4. 正式提案階段

* 溝通內容：系統開發內容
* 溝通目標：配合報價，確認系統需求
* 溝通結果：正式合約

與報價息息相關的是正式工作內容，因為對案主而言，工作內容決定接案者的報酬。對接案者而言，報酬決定了工作內容。通常到正式提案階段同時亦為簽約階段，你所揭的正式提案書常常是合約的附件之一，內容為雙方同意開發的系統功能，接案者是根據正式提案書所載明的系統功能內容進行開發工作，而未來的系統測試或驗收也是根據正式提案書所載的功能來進行。至於合約如何製定，我們會在另一章討論。這裡主要討論形成一份正式提案書的溝通事項。

附件一：正式提案書

正式提案書記載的是實際要開發的各項功能，羅列的愈明確，對案主和接案者雙方保障也愈多，因此無論案主是否要求，都應主動將正式提案書列入合約中。

正式提案書的內容除了系統功能之外，所有與專案開發相關的事件也須同步在正式提案書中進行規範，包括需求變更﹑驗收﹑保固以及後續維護的程序等，當合約簽訂之後，在系統開發過程中，雙方的互動均需按照正式提案書及合約所載來進行。

一般正式提案書所提到的重點有︰

*

前言／摘要：說明這個系統規劃的目的及目標，並摘要整個系統的各項功能。

*

介面功能規劃：先依主功能分項，再按介面動線描述該主功能項下的各細部功能。這是使用者所看到及所使用的功能。細部功能必須以字面描述的方式，詳盡到資料輸入及輸 出的結果。

*

管理系統功能規劃：所有介面功能背後都有相關的管理系統功能，此章節即在按系統功能項目分類，逐項描述各系統功能項下的細部功能。這是系統管理者所看到及所使用的 功能。細部功能必須以字面描述的方式，詳盡到資料輸入及輸出的結果。

*

系統架構規劃：說明開發本系統的軟、硬體規劃，如開發平台、相關程式語言、資料庫及整體系統架構的設計。

*

系統變更及處理原則︰規範系統開發過程中，如遇需求變更﹑介面功能修改等各項變更時的各項相關處理程序。

*

開發團隊：說明開發本系統所須花費的時間及人力及工作內容。

*

驗收程序︰規範系統驗收的程序以及驗收方式。

*

維護﹑保固及支援的相關辦法︰規範維護﹑保固以及支援的內容項目與時限。

*

附件二：系統開發時程規劃書

假設接案者已經預見到該專案在未來很可能將因各式各樣的原因而延遲，我們會建議將開發時程及交貨日期等項目獨立出來，在合約及正式提案書外，另簽訂一份系統開發時程規劃書。這本系統開發時程規劃書亦為合約的附件，視同合約，之所以不列在合約裡，為的是萬一雙方因需要必須修改開發時程，便可較容易依據現實狀況做修正而不需更動到合約。

系統開發時程規劃書可以載明各開發階段的工作內容﹑執行時間﹑雙方應配合交付的事項等，當階段性工作完成或目標達成時，案主需分期交付的價金也在此份時程規劃書內規範。簡而言之，系統開發時程規劃書內應包括︰

• 開發階段的劃分

• 各階段的時間劃分

• 各階段接案者的執行項目

• 各階段開始前案主應交付的資料

• 各階段結束時接案者應交付的成果

• 各階段結束後案主應交付的價金

以Prototype具體呈現系統全貌

除了書面的正式提案書外，如果行有餘力，還可以用Prototype的方式將案主需求呈現給案主過目，讓案主可以實際操作整個系統使用者及管理介面，並藉由介面的操作來達成雙方對於系統的共識。透過Prototype的操作，案主也可以更清楚系統開發後的功能全貌。Prototype一旦經雙方認同之後，接案者即可根據Prototype來進行後端系統的開發工作。

2.3. 專案執行階段的溝通

好不容易，接案者與案主達成共識簽約。基本簽約以後的的溝通會比較輕鬆，畢竟合約是雙方的共識，有爭議時可以檢視合約解決。因此接案者此時的溝通目的是確保雙方會跟著合約走，防止意外的情形發生，順利結案。

基本上，整體專案執行流程可按階段性目標或所謂的里程碑（Milestone）分為幾個階段，每個階段內的溝通內容及溝通重點均有所不同，所要達成的共識也有所差異，若在每個溝通階段皆能掌握各個溝通要點，適當達成各溝通階段所應達成的溝通目標，將有助於專案開發的執行，並避免因認知不一致所導致的開發時程延誤或系統驗收無法完成等因溝通不良所衍生的各種問題。

專案執行階段的溝通內容及要點大致如下：

+------------+----------------------------------+----------------------------+
|專案執行階段|內容                              |要點                        |
+------------+----------------------------------+----------------------------+
|開發階段    |溝通內容：開發過程中雙方應相互配合|* 訂立系統規格書            |
|            |          的事項                  |* 站在案主的立場協助解決問題|
|            |溝通目標：確認開發過程中雙方的權利|* 適當堅持原則              |
|            |          義務                    |* 記得修改系統開發時程規劃書|
|            |溝通結果：修正後的開發時程規劃書或|                            |
|            |          進行測試                |                            |
+------------+----------------------------------+----------------------------+
|測試驗收階段|溝通內容：測試驗收內容及方式      |* 以書面確認雙方均認同此測試|
|            |溝通目標：同意測試驗收時程、內容及|  及驗收程序                |
|            |          方式                    |* 驗收報告書內需詳盡的羅列驗|
|            |溝通結果：驗收報告書              |  收結果                    |
|            |                                  |* 確認雙方均已在驗收報告書上|
|            |                                  |  簽字                      |
+------------+----------------------------------+----------------------------+
|維護階段    |溝通內容：維護需求                |* 以書面確認維護的內容範圍、|
|            |溝通目標：維護的時間及方式        |  保固期間以及維護價金      |
|            |溝通結果：維護合約                |                            |
+------------+----------------------------------+----------------------------+

2.3.1. 開發階段

* 溝通內容：開發過程中雙方應相互配合的事項，決定是否訂立系統規格書
* 溝通目標：進度說明，確認開發過程中雙方的權利義務
* 溝通結果：修正後的開發時程規劃書或進行測試

在開發階段時，所有與系統開發相關的細節均已大致底定，在正常狀況之下，開發過程應是順利並且按照開發時程規劃書所訂定的開發時程進行。這時溝通的重點除了定期聯絡告知案主開始進度外，另外應開始著手準備系統規格書，做為結案時說說明文件。另外，在開發過程之中常有一些不可預期的因素發生，讓開發時程一再順延，有可能是接案者在開發時遇到瓶頸，也有可能是案主變更需求或是延遲交付相關的資料而影響後續的開發工作。當遭遇到這些問題時，必須重新修正開發時程規劃書，以符合現實狀況，保障自身的權益。

訂立系統規格書

當正式合約及正式提案書簽訂之後，接案者即可正式開始進行程式開發的工作。在一些大的專案中，接案者本身會製作系統規格書，主要目的是在程式開發之前，必須先訂定一些程式開發所須依循的準則，當作接案團隊內部的工作標準，減少接案團隊內部的溝通時間。另外，這裡頭的內容整理出來，最終會成為結案報告的一部份，在結案時一並交給客戶，供其日後進行程式維護時使用。

在系統實際開發之前，必須先做好系統分析工作，以利後續的程式開發。好的系統分析可以有效率的開發系統，並確保系統開發結果符合實際使用者的需求。系統規格書的主要內容為系統分析的結果，包括︰

• 資料的輸入及輸出結果︰包括欄位大小﹑屬性等細部資訊的定義。

• 系統執行時產生的訊息資料︰包括錯誤訊息﹑確認訊息以及出現這些訊息的前因後果等 細部執行細節的規範與定義。

• 資料的運作流程︰說明整個系統運作過程中，各種資料的流動及相關性。

• 功能的執行流程︰說明整個系統運作過程中，各項功能的運作流程及相關性。

• DB Schema的設計︰定義整個資料庫的細節。

使用的工具可以包括︰

• Context Diagram

• 資料流程圖（DFD）

• 實體—關係圖（ERD）

• 狀態—遞換圖（STD）

系統規格書主要在方便接案者進行整體系統的開發工作。由於整個專案可能過於龐大，而有不只一位的接案者參與開發工作，透過系統規格書的訂定，可以讓各個接案者了解整體系統的開發方式，並透過系統規格書裡所規範的開發細節，同步進行程式開發工作。此外，透過系統規格書的訂定，也可讓後續進來的程式開發者省卻大量與工作團隊面對面溝通詢問的時間，利用書面的溝通即可以最少的時間進入狀況。

接案者在進行專案開發前的系統分析工作時，可以順便將一些常用或一般系統必備的功能獨立出來設計開發，在未來再接案時，如果要需要類似的功能，便可以將這些已開發完成的功能拿出來再重覆使用，在初次開發時即將重用性納入考慮，如此將可避免未來重覆開發的問題。

站在案主的立場協助解決問題

在專案進行的過程之中，有時會牽涉到需要案主配合的部分，相關的規範雖已明訂於開發時程規劃書內，但有時案主因為自身的困難或其他原因，不一定能如期交付應配合項目，例如頁面或是相關資料庫連結的欄位及設定值等，造成後續專案工作無法進行，使接案者的時間受到拖延。這是接案者無法控制的局面，由於案主延遲交付的原因大多為沒有時間或是受到其他更重要的事情所拖累，建議可嘗試的解決方式有：

• 詳細列出需要案主提供的東西，最好提供選擇題的型式，讓案主選擇而非提出問答題讓案主花時間回答。舉例來說，如果需要案主提供會員資料庫的欄位及設定值，則可具體提出自己要求的欄位及設定值供案主決定好或不好，而不是讓案主自己提出欄位及設定值。

• 技巧性的探詢案主困難之所在，貼心的提供協助。

• 不要咄咄逼人，造成案主的不耐煩。

• 親自拜訪案主，讓案主花個會議的時間來解決或提供所需的資料。

• 親身站在案主的角度，體會案主的難處，並提供有限度的配合。

• 適度提醒案主，這樣的做法會造成完工時間的延遲。

• 平時在開發時，即與案主互有生活上或工作上的往來問候，建立除工作之外的情誼，較可避免拖延的狀況發生。

為避免開發時程受到案主或其他非可自身控制因素的影響，最好事先溝通清楚，並在訂定時程規劃書時，想辦法將需要案主配合的項目獨立出來，如遇案主拖欠應交付事項之時，便可先開發其他獨立的功能，待案主交付東西後，再回頭來開發相關的程式。

適當堅持原則

如遇案主提出需求變更要求時，應按照正式提案書內所規範的需求變更程序執行。先評估需求變更的影響，並根據評估結果決定是否接受變更要求。如果評估結果是不應變更，則應以委婉的態度以及書面的評估報告告知案主無法配合的原因，如果案主堅持變更，則告知勉強配合所會造成的後果，並由案主自行決定並負最後的責任。

一切程序應按正式提案書以及合約規範來執行，任何在系統開發過程中所作的與合約或正式提案書不符的事件，均需以書面方式，由雙方簽名認可並留存備查，千萬不要因為嫌麻煩或是重人情而忽略一些執行上的細節，或是放棄原則盲目答應案主的所有要求。

記得修改系統開發時程規劃書

不論是案主延遲交付應交付的事項或是案主於開發過程之中提出需求變更的要求，只要有影響系統開發時程，均須記得修改系統開發時程規劃書，以符合實際開發現狀。

2.3.2. 測試驗收階段

* 溝通內容：測試驗收內容及方式
* 溝通目標：雙方同意測試驗收時程、內容及方式
* 溝通結果：案主簽收驗收報告書

當階段性功能完成時，雙方即可針對該功能進行測試工作並進行驗收。在進行測試及驗收之前，必須有一個雙方都認同的測試及驗收流程與方式，這個流程與方式即記載在測試及驗收說明書內。

以書面方式確認

測試驗收階段是專案開發的最後階段，一旦通過案主的驗收程序，此專案即可蓋上完工的印記。測試及驗收是一個相當繁雜的工作，由於系統開發的合格與否總會牽涉到見仁見智的問題，為了讓測試及驗收過程順利進行，協調好測試及驗收的項目後，最好以書面方式載明。測試及驗收項目可依據正式提案書所羅列的項目來執行。內容主要包括三部分：

* 測試的時間地點。
* 測試人員。
* 測試的項目。
* 其他：包括系統軟硬體的運作狀況、系統調校的成效……等。

確認雙方均已在驗收報告書上簽字

驗收報告書的內容主要為測試實際執行清況。報告書應羅列進行測試及驗收的項目、方式及測試結果。當雙方均在驗收報告書上簽字，即表示系統驗收完成，亦即接案者開發專案的責任已了。此後接案者便根據維護合約的規定進行系統維護工作。

如果案主有問題

通常專案溝通最容易出問題的兩個階段，一個是簽約前的規格開發，另一個就是測試驗收階段，案主抱怨成品不符需求。通常到此時，不論接案者或案主任一方的抱怨，都必須回歸到合約內容本身去檢視，此時就會突顯正式提案書及開發時程規劃書的重要。但常有的情形是該項功能合約並沒有規範到，或者是雙方認定有差距。遇到此類爭議，可以撰擇的溝通手段甚少。解決方式都是先評估依案主要求修增加自己的多少成本，如果只是順手修正，如在原有存量管理上，另增加一個安全存量警示，那麼不妨順應案主要求。如果超出成本，只好將以往文件調出證明當初案主對接案者提案並無異意，委婉說服客戶，如果再不能接受，只好依合約規定接受仲裁。

結案報告

在整個專案完工後，接案者應將這一段時間和案主溝通相關的文件（如合約，驗收報告），連同前述的基本開發規格或在合約中規定應交付核心程式、相關測試資料等等匯集在一起，做成結案報告交給案主。

2.3.3. 維護階段

* 溝通內容：維護需求
* 溝通目標：維護的時間及方式
* 溝通結果：維護合約

維護合約的訂定主要視案主的需求而定，如果原先合約並沒有納入維護的規定，而案主仍需要接案者負責系統後續的維護工作，則雙方便可就後續的維護方式進行溝通，並明訂在維護合約之內。

以書面確認維護的內容範圍、保固期間以及維護價金

與案主充分溝通並確認系統開發後所需的後續維護工作，並簽定維護合約明定維護的內容範圍、時間及價金，以在有保障的基礎之下進行下一階段的維護工作。

溝通的方式有很多種，在專案委外及系統開發的領域中，接案者除了面對面與案主直接溝通之外，有很多部分是必須仰賴書面的互動及規範，這也是為什麼在系統開發過程中需要各式文件的原因，文件可以將接案者與案主雙方的言語溝通化為書面文字，除了將虛無縹緲的對白予以明確化及具體化外，還可留作憑證以供必要時參考。

良好及有效的溝通可以提高專案執行的效率，並有助與開發成果品質的提升。然而溝通是一門沒有定理的藝術，雖然有了前人經驗累積的建議，最有成就的還是親身參與其中所獲得的學問。

身為一個接案者，也許在時間上更自由，再也不必理會辦公室裡的勾心鬥角，但這不代表可以隨心所欲，因為接案者永遠不知道你下一個客戶是什麼的人。在和別人談案子之前，必須做好心理建設。自由接案者是個獨當一面的專業工作者人，不單純只是一個技術人員，他必須學習和接受商場上的一些範規，穿著整齊，待人以禮，尊重客戶，儘量滿足他們的需求將是一個好的開始。

誠然「顧客至上」是一項好的經營理念，但這不代表者「顧客永遠是對的」。遇到一個斤斤計較的客戶，常常會讓人「痛不欲生」，偏偏台灣的大宗案主，很多的是中小企業主，而這些人往往在經營的個性上容易斤斤計較。因此，如果事先溝通不好，日後往往容易發生問題。

通常，接案者最容易在兩個地方與客戶發生爭執，一個是完成品的「修正」問題；另一個是「付款」問題。為了預防這種問題的發生，立訂「契約」將是一項好的解決方案，將所有可能產生爭議的地方，儘可能的預先用文字說明清楚，以降低未來產生爭議的可能性。

然而訂了契約不代表不會產生問題，重點是要能詳述解決方案。以完成品修正的問題為例，除了修改時間與次數，驗收方式亦要註明。至於付款的部份則是要說明，付款的時間及付款的方式。至於一份合約應該注意的事項，後文將陸續提及。簡言之，為了確保自己的權益，也是確保客戶的權益，一個好的接案者應該要注意相關法律，稅務的規定外，並事先對你的客戶加以解釋。這樣才能減少將來發生問題的可能性。

3. 分工: 專案規劃與執行

當你看到這裡的時候，我們必須恭喜你，相信你已經有承接專案的基本能力。或者你的手上正準備或已經接下一個專案，而要正式邁入開發的地步。不論你目前打算獨立開發或和其他夥伴合作開發，甚至你將以專案經理的角色煮到這個專案，千萬不要忘記，所有你之前的準備都將在這裡付諸執行，也就是說，執行能力的好壞與否將完全影響你未來能否成為一個稱職接案者的絕對因素。

至於我們在這裡所提到的一些接案者或專案經理的例子，由於他們對於專案的掌握方式各有所不同，也絕非放諸四海皆準，對於每個人的行事風格及專案屬性的差異都會影響專案開發的方式，我們希望能提供更多樣化的資料來增加本書的參考性。其中包括資深的接案者，以工作室方式經營的團隊，以及大規模軟體公司中的專案經理等等。

當然，藉由這之間規模的差異，以及所承接專案屬性的不同，我們也可以看出專案執行中的差異。也更能了解作為一個自由接案者或專案管理者所應該具備的基本能力，而能更容易的掌握專案的進行。

3.1. 規劃你的專案

對於一個技術人員而言，經常會有一個迷思，總是認為一個程式，或一個專案的成功因素取決於程式中艱深的技術以及令人目不暇給的功能，但是事實上卻非如此。好的技術應用的範圍主要在於使系統能夠更貼近使用者的需求，一般的產品如此，軟體產業顯然也非例外。因此，當你開始要為你的客戶進行軟體的設計時，不要急著坐在電腦前埋首於程式設計，而要試著和你的客戶多溝通，了解他們目前作業的流程與細節。

3.1.1. 確實了解你的客戶

就像大家所理解的，大部分企業所寄望於資訊化的目的在於利用電腦處理更多的資料，簡化原有的人工流程。也就是說一套好的軟體必須能讓客戶更輕鬆的處理他們手上目前的工作，而非因為電腦的引入而讓工作變得更複雜。所以如果要讓一個專案成功，第一步就是必須真正的去了解客戶的需求。

了解你的客戶，聽起來似乎並不是一件非常困難的事，或是你認為你對於你的客戶已經有了相當程度的了解。但是我們所說的並不只是一般表面的了解，而是應該深入的去了解你的使用者中，他們一般作業的流程為何？怎麼樣才能在不影響使用者作業方式下，讓他們能夠更方便的使所有的作業進入自動化、資訊化。從一些比較具有經驗的接案者的口中我們大約可以了解，深入、有系統的訪談是必要的，這樣的訪談可以讓系統分析師藉由了解的過程中設計出適合的系統流程。

而從實際的經驗中我們知道，訪談的技巧在於如何去讓使用者描述出他所需要的流程。一般來說，使用者經常可以非常清楚的告訴訪談者許多關於他們工作上的流程，但是這些流程通常並無法滿足系統開發的完整需求，因此能夠精確的由使用者的口中問出所需要的問題就顯的非常重要了。

舉一個簡單的例子，如果你的使用者告訴你關於他所管理的簽呈流程是由他送給副理，之後是經理、協理。那麼你應該想到什麼呢？第一、是否所有的簽呈或公文都是依照這樣的流程，或是以簽呈的重要性來決定簽呈的流程。另外，如果簽呈沒有通過，那麼他被退回的流程也是階級式的，或是直接給這一位承辦人員呢？當然，如果承辦的人員不在，那麼代理制度應該如何，應該直接由系統設定代理人，或是由承辦人決定代理人？簽呈的送核時間應該是多久，如果沒有受到核准，那麼簽呈本身是否應該做任何處理等等。這其中的所有問題都包含了將來你在進行系統分析，包括資料庫分析、流程分析時的重要依據。同樣的，這之中如果有任何的遺漏都有可能讓你系統在未來所必須修改的部分更多、更複雜，顯然這樣的訪談並不是特別容易的事。

3.1.2. 系統分析的重要

如果你曾經真正的承接過系統專案或在系統開發中和你的客戶有任何互動，你將更能明顯的感受到系統使用者和程式開發者之間的差距。由於一般開發者在進行系統開發的時候，所面對的使用者大都只熟悉於個人的專業領域，但是對於如何將自己工作上的流程轉換為軟體系統，卻完全必須依靠系統分析的進行。

因此，如果系統分析無法利用自己的專業領域將所有的流程作精確的判斷的話，那麼系統開發的資料與分析完全以使用者所提出的問題為基準，當真正要開出系統規格時，就很容易發現許多的問題。其實仔細想想，由於系統上資料的連結與交換經常都在私底下進行，因此實際作業上許多資料交換一般使用者不容易察覺，如果系統分析沒有清楚的了解到這一點，當實際訂定系統規格時就會發現這樣的問題。但是有更多的問題是會在實際寫程式時遇到的，那時候對於整個系統的規劃影響更大，所浪費的成本也就越多。從這簡單的道理，就很明顯的看出如果沒有好的系統分析，即使勉強可以讓系統產生，卻在接下來會更容易產生出讓人無法收拾的問題。

這樣說起來好像也並不是太難，只要你在作使用者訪談、系統分析時小心、嚴謹，就可以長保百年無憂了。但事實顯然並不可能會有這樣的情形，也就是說除了你盡可能的小心外，還是會有一些時候是因為客戶的需求有些許的改變，而這樣的改變會讓系統作某種程度的改變、或重寫某些部分。不過這樣的情形在某種程度來說是勢在難免的，簡單的說，幾乎大部分的使用者都會對於系統有某些意見，希望作某些修改，所以，要寄望藉由好的系統分析而不需要作任何系統修改還不如在作系統分析時，能針對可能會有疑慮的部分，作彈性的調製，而且這樣的彈性能讓你的系統有更大的可重用性。

或者應該這麼說：你最好讓你的模組適用於許多專案，而只需要對個別專案進行小幅度的修改。因此你在作模組設計時就必須特別注意這一方面的需求，那麼你的系統可重用性就能夠繼續往上提昇，這也就表示，即使使用者希望要求修改系統的規格，你也可以減少這種改變的成本支出。至於如何能達到這樣的目標，主要在於對於系統的了解、對流程的掌握。也就是你必須累積豐富的系統分析經驗，而且必須藉由非常深入、仔細的使用者訪談來提昇自己的實力。

3.1.3. 確立系統中資料與流程的進行

就如我們不久前所提到的重點，一個能夠滿足客戶需求的系統遠比功能強大的系統要來的重要。而想要達到這樣的目的，我們也提到了系統分析的重要性，事實上，系統分析的主要作用就在於確立系統中所需要的資料與流程的進行。也就是說，當我們利用系統分析對系統所需的資料結構了解後，我們就必須將所有資料的相互關係作系統性的整合，並找出他們之間的關係。

當然，從這些關係中我們就能夠釐清整個工作的流程、資料的走向。其實在實務的經驗中我們經常可以發現，藉由對資料結構的掌握。我們很容易可以找到隱藏在後的系統流程，而這些流程也經常左右著系統的成功與否。反之，如果在系統分析的過程對於資料結構的規劃不夠清楚時，在系統開發的過程就非常容易發生許多無法預知的結果。其實目前我們最常接觸的委外專案還是以流程的自動化或資料處理的電腦化為主，所以能夠清楚的把握資料的進行對於專案的開發有著絕對的益處。

3.2. 專案的管理

當你完成了系統分析的工作，無論你的系統分析內容如何，暫且也不論你分析的方式是否夠成熟，畢竟那樣的工作是需要練習的。現在請拿出你對系統分析後的規格與流程來跟著進行接下來的步驟，也就是準備開始進行系統的開發。當然，我們並不準備告訴你程式寫作的技巧，因為這應該是你在準備成為接案者之前就該養成的基本技能。現在，我們將告訴你如何能有系統的開始你的系統開發。

3.2.1. 確定工作的內容

你不必在完成系統分析後便急於一頭栽進寫程式的程序，而該先將你的系統流程檢視一次，看看是否存在著流程上的瑕疵。或是自己還存有疑慮的部分。在解決了所有的問題後，就可以確定了整個專案的工作內容，例如是否應該設計使用介面、是否需要管理介面，系統是否可以使用或必須另外開發哪些模組等等。確立工作內容對於工作的安排或是個人工作的程序都會有莫大的幫助，也可以讓工作效率明顯的提昇。

這樣的說法對許多人也許並不容易理解，最大的原因可能在於許多人都認為他們對自己的工作內容在系統分析候已經非常的明顯了，所以確定工作內容似乎是多此一舉，完全沒有必要的事情。但是事實卻經常是由於對於工作沒有通盤性的考量，因此常常東拼西湊的把專案擠出來，也就造成了系統結構有問題，程式重用性太差、或完全無法重用等等的狀況。

在我們所訪問的一些專案經理或接案者中，他們也都承認對於專案開發的過程中，並無法完全的讓許多模組可以完全的重用，但是好的規劃系統卻依然是不可少的，因為系統規劃可以讓相類似的模組一次做完，而不會讓不同的工程師作許多重複的工作。而且一些和系統相關性小的模組，重用的機會是非常大的，也因為存在這些重用性的問題，在通盤規劃系統資源時就顯得特別重要。

投資在工作了解、規劃的這件事情報酬率是相當高的，你只要在正式進行系統開發前多花一點的時間就可以讓你自己減少工作量、增加可重用性、提昇開發效率等等，不管從哪一方面來看都是划的來的。當然，所謂規劃工作是有一些技巧性的部分，我們假設大家對系統開發都有相當程度的了解，那麼我們舉一個例子來看看這其中的關鍵。比如你的使用者要求他的系統必須作個人行事曆的功能，也要求另一項功能是會議室管理系統，那麼這兩個系統聽起來似乎有些雷同，你在進行系統規劃時就可以將這些功能寫成同一個模組，而其中的差異只在於使用時作些許的調整就可以了，這樣聽起來是不是省事許多呢？

3.2.2. 個人 vs. 團隊

以一個專案的開發而言，個人與團隊的開發方式上確實有些不同，因此工作的分配上必須非常恰當，否則不但會讓開發的速度降低，也會嚴重的影響開發的時程。如果你經常是獨力作戰的個人開發者，那麼對於工作劃分雖然也會有些許的感受，但無論如何卻不容易會因為這樣的原因而讓系統開發遭遇到過多的困難。但是好的分配方式確實增加生產力的重要方式，畢竟所有人對於必須一再重複進行類似的功能設計是不會太有興趣的，因此即使你只是個人的開發者也應該藉由你所累積的專案而讓你的個人模組函式庫不斷的增加。這一部份無論是哪一類型的開發者都應該有計劃性的擴充，當然，你也可以尋求各種開放的資訊。例如國外的許多網站都有許多穩定而又容易使用的模組，甚至是許多開放原始碼的套件可以下載。也就是說，許多時候你只要將你所找到的程式加以修改就可以符合需求，那就像是你有一個模組的開發小組，而這些小組的成員是來自世界各地的程式菁英。

而如果你們現在是由幾個人所組成的工作形式，那麼良好而精確的工作的配顯然就更具有重要的地位了。其實我們都可以想像，如果有三個人都分別具有一定程度的工作能力，當三個人共同開發一個專案時，工作的效能並非等於三個人工作效能的總和，而工作效能的發揮完全取決於工作分配的方式。我們可以舉幾個簡單的例子來說明這個觀點，例如一個專案的開發對於模組使用的觀點非常的薄弱，也就是說一個專案中有許多部分的功能是相近，甚至完全相同。但是他們卻並未採用模組化的方式來解決，反而讓相同的程式碼分布在各個區塊，那麼不但在寫程式時顯的非常不夠經濟，如果發現這段程式有錯誤時，對於程式除錯所花費的時間更是難以估計。

也許你另外還曾經遇過這樣的情形，當你所承接的專案是關於網站的架設，於是你的客戶或是你自己設計了一些十分亮麗又吸引人的頁面，當然，在這些頁面上你加上了一些伺服器端的Scripts ，而程式的結果也讓人相當的滿意。但不幸的卻是你的客戶要求對於頁面作大幅度的改變，甚至要全部換新。如果你當初的規劃足夠完善的話，這樣的要求顯然並不困難，相反的，你也可能被這樣的情形難倒，而原因就是在於你的工作規劃和系統規劃都產生了問題。

如果你目前還是個人開發者，也不要忽視這一方面能力的培養，因為當你的專業能力能夠受到讚賞，你將會慢慢的接觸規模較大的專案，也許就會有機會以分工的方式來進行專案的開發，那麼這時候工作掌握的能力就佔有重要的地位。

3.2.3. 專案經理的角度與工作

在這裡，我們假設你已經有必要以分工開發的方式進行專案，但實際上即使是個人開發，也可以藉由這樣的方式來檢視自己對專案的掌握，也就是必須以專案經理的角度來檢視專案開發的流程、進度與品質。但是至於一個專案經理應該以什麼樣的眼光來看待手上的專案呢？簡單的來說就是掌握進度、控制品質以及成本控管。這樣的說法或許不難理解，但實際的內容到底有哪些呢？我們將要更深入的來檢討。

專案經理對於產品交貨的時間，也就是對於合約的履行是必須非常注意的，畢竟能夠確實的將產品交到客戶手裡才能讓整個專案有實質的意義。但是進度的掌握其中實際上包含了對於專案內容、客戶需求的了解，對系統架構作完善的劃分以及合理、有效的進行工作的分配。

這個過程的進行並不是非常的容易，因為這表示專案經理必須對系統的架構與程式的開發有一定程度的了解，而就如同我們不久前所提到的，好的工作規劃能夠大幅提高整體的工作效能，專案經理的重要性在這裡就可以明顯的看出。專案經理第二個工作重點就在於品質的管制。

當一個系統交貨給使用者之後，系統的品質是讓使用者對於系統開發的專業性進行評斷最好也最直接的方式與媒介。雖然有些系統開發者以為如果發現系統錯誤再來進行除錯的工作也許方便許多，但是對於開發者的專業形象卻是一大傷害，因此專案經理對於系統的品質控管更是不可忽略。

接下來要談的有關成本控制的部分對於比較具有規模的工作室，或是一般軟體公司的專案經理特別需要注意，至於個人工作是由於在承接專案時便已進行過分析的工作，而工作的進度與成本也容易控制的多，所以不易產生這樣的問題。相反的，在略具規模的工作室而言，許多瑣碎的事情都很容易造成開發成本的增加，例如由於客戶對於系統規格的不了解而拖延開發的時間計劃，或由於開發技術上的瓶頸而導致成本的浪費等等。

我們當然都希望可以藉由專案的開發來增加收益，所以從系統規劃，簽約乃至於開發的過程中都必須確實有效的對成本做最有效的利用，而避免進行太多浪費資源而又沒有實際效益的工作。以上所提的種種也就是身為一個專案經理所必須執行的工作，而專案經理的工作方式與能力對於專案的成功與否有著舉足輕重的影響，因此如果你即將面對規模越來越大的專案，那麼讓自己了也如何成為一位優秀的專案經理確實是一件非常重要的課題。

3.3. 系統開發

一個專案的系統開發時程經常取決於系統的規模與複雜程度，也就是說一個專案的開發時程從幾週到幾個月都是非常可能的，有些更困難的專案也許需要更長的時間。但是就一個接案者而言，一般經常接觸的案子也大多約莫需要一個月左右的時間，也就是說當你從簽約到交貨大約有一個月的時間進行系統分析、開發、測試以及最後的驗收。

我們之前已經提過一些關於系統分析時的重要性、進行系統分析時必須注意的重點。所以我們接下來將針對系統開發的過程進行一些討論，因為在這個階段，你將要從無到有的將整個系統建構起來，這顯然並不是一件容易的事，為了檢驗你的系統分析是否完善，以及將來交貨時的過程更加順利，系統開發的階段將是一個重要的關鍵。

3.3.1. Prototype的必要性

對於專案開發的方式，也許每個人都有各種不同的想法與做法，但是有一個部分卻是必須讓人非常注意的，也就是系統Prototype 的開發。有一些的系統開發者對於系統開發方式非常的專精，他們能詳細的了解客戶需求與系統規格，而將這些規格轉換成許多小部份的模組。

簡單的說，他們可以把一部車子拆解成由許多無數小零件組合而成的綜合體。而他們就利用自己倉庫中已經有的零件，或其他可以經由其他管道所取得的零件來架構出理想中的系統。但是經常發生的狀況在於發展或修改模組的期間，他們的客戶經常無法窺探自己所委外的系統進度如何，或是客戶也想知道整個系統是否能向他們所期待的一般。並且他們也希望在系統發展的過程中也能參予意見，以便隨時修正系統開發時所造成的誤差。

但是如果系統開發的方式不夠完善的話，很可能在這一方面就會發生問題。也就是說系統開發者也許可以在合規定的時間內正確的將系統交貨給他們的客戶，但是卻也是在最後一刻才能讓他們的客戶了解到整個系統的全貌，當然這是大部分的客戶所無法忍受的，也就是說幾乎所有客戶都希望可以在專案發展的過程中也能看到他們自己委外的情形。從這裡我們當然就能領略到Prototype對於系統的開發是具有其絕對的必要性。

事實上，如果你已經開發過幾個專案，那麼也許你已經能輕鬆的調整自己的工作方式，而能說服你的客戶相當放心的和你一起配合進行專案的開發。但是如果你目前正打算承接你的第一個專案、或是你剛接下你的第一個專案，那麼千萬不要忽略這一部份。

如果你的客戶並沒有對於Prototype 提出特別的需求，我們也建議你不可省去這樣的工作模式，相反的，你最好從開發的初期就建立好系統的架構，並要求你的使用者和你一起檢視系統的架構。那麼你將會發現系統發展的過程也許會有一些麻煩，但在最後交貨的階段將會輕鬆不少。而如果你的客戶對於Prototype 並不特別重視，而你在確立規格也從此埋首於系統的開發，那麼最後你可能會發現，某些在系統分析時沒有注意到的小細節，到了即將結案的時候卻是影響系統流程是否正常的重要關鍵，而你也許面臨著必須將整套系統作大幅調整的窘境，這樣一來不但延長了你的開發時間，也讓成本提高了許多，對於系統開發者而言，是非常嚴重的傷害。所以和你的使用者保持著密切的溝通是非常重要、甚至是絕對必要的，而溝通的過程中Prototype 將會是一項最具體的溝通工具，所以千萬別忘了，要進行細部的開發前，千萬要把你的系統架構先建構完成。

3.3.2. 羅馬不是一天造成的

對於某些系統開發的技巧，其實我們在前面也曾經提起過，而在這裡我們會更詳細的提醒大家應該要注意的事項。首先當然是進行系統模組的規劃，在你完成了系統分析、確認了系統的規格之後，接下來你應該要知道你的系統中應該分為哪些部分，也就是說系統中將會用到哪些模組。在這裡大家應該注意的是不要將你的模組規格訂定的太過於死板，有時候你會發現你的系統中某幾項功能看起來雖然有一些差距，但卻是非常接近，那麼你可以讓他們使用同樣的模組，而你要做的只是讓你的模組可以更具有彈性，讓所有相關的功能都能輕易的使用，而且也許你會知道，將來你將會有更多的專案需要使用同樣的模組。

舉個例子來說，如果你曾經開發過社群網站，那麼相信你對討論區這樣的東西必然並不陌生，事實上現今大多數的網站都將這個功能列為必要的基本功能之一，而如果你每開發一個新的網站就必須重寫一次那麼似乎太不經濟了。而仔細想想，有些網站上的留言版之類的功能所做的事情似乎也是大同小異，那麼似乎也可以考慮重複使用，這麼一來，系統的開發是不是顯的容易的多了呢？

接下來我們來談談不久前才提到的Prototype，我們剛剛已經了解到開發系統的Prototype是多麼的重要。但是真正在進行系統開發時又該怎麼做呢？事實上這一部份並不如想像中的困難，我們當然假設你對系統的架構已經有了相當程度的了解，那麼先把整個系統的所有功能都先簡要的提出吧！如果你的使用者需要會計系統，那麼就給他會計系統吧！也許只能做簡單的試算，但你已經給了他會計系統了，不是嗎？這麼一來，把所有的功能都簡單的畫出輪廓，你就有了一個還算完整的架構了，接下來要做的，便是把所有該有的功能補齊，你將會發現，系統將會一步一步趨於完整，而你也可以隨時和使用者討論整個流程，並確認系統是否正確、你在系統分析時是否遺漏了任何該注意的事項。

3.3.3. 選擇開發的工具

我們並不打算花太多的時間來說明如何幫助你選擇開發的工具，因為這之中不但包含了太多的變數，而且使用任何一種程式語言來進行開發並沒有絕對的優缺點，而我們所希望表達的只是希望任何一位開發者都該善用手上的資源，也就是不論你選擇了哪一種程式語言作為你的開發工具，都應該要了解它的特性並發揮它最大的功能。

如果你經常上網瀏覽網路上相關於程式語言的討論，那麼你應該會經常看到對於如何選擇程式語言進行開發的討論。但在實際的經驗中，卻包含著很多的變數，例如你必須考慮到客戶使用的作業平台，專案的種類與特性，當然開發者對於程式語言的熟悉程度也是另外要考慮到的重點。

其實不論你最後決定使用的開發語言為何，發揮它的最大功能才是你真正必須在意的。例如目前在網站開發經常被使用的PHP 你就可以找到許多可供使用的模組或套件原始碼，Perl則不管在系統管理或是網站應用 都有不錯的評價，而更方便的是你在網路上可以找到相當數量的資源可供應用，或是目前它對於和其他各種語言的橋接也有相當程度的著墨。而最近紅透半邊天的Java所極力推廣的EJB或是Java 的跨平台特性也是可以加以運用的。所以不管你根據專案特性、客戶需求或其他任何的因素選擇了何種的工具，能夠善用你的工具將能使你的開發事半功倍。

3.3.4. 品質控管

程式的除錯也是開發過程中一項重要的工作，所有程式開發者都知道要開發出一套系統並非太過困難的事，但是要開發出一套完全沒有錯誤的系統就絕對不是一件容易的事。因此程式的除錯確實是一件不容易，但卻非常重要的工作。因為如果你的程式發生不可預知的錯誤，那對於系統使用者來說將可能造成無法彌補的損失。

當然，在系統的發展過程中，你可能會因為程式的無法正常執行而發現一些程式中的錯誤，但扣除掉這些錯誤之後，你還必須很小心地去找出表面上看不出來的錯誤，尤其是一些邏輯上的錯誤或是一些流程上的錯誤。一些系統的測試是必要而且重要的，在你系統的發展過程中千萬不要忽略這一項重點，能夠交出穩定而無誤的系統對於你的專業將會有絕對的加分效果，自然也能幫助你獲得客戶的信賴。千萬不要抱存著系統交貨就等於合作關係結束的想法，替你的客戶建置一個穩定而又正確的系統將是一件重要的課題。

像許多知名的廠商，不管他們是屬於哪一種行業，品質的控管都是非常重要的，他的重要程度甚至應該高於新技術的研發。如果只能在這兩種選擇其一，則一般委外的廠商必然願意花同樣的錢買到穩定的系統更甚於有高深技術的系統。而且好的品質也是一種行銷上的利器，能讓使用者信任你的系統品質，必然可以為你帶來更多的利潤。

3.4. 愉快的交貨

交貨對於一件專案絕對是重要的，也代表了某項專案完成的里程標意義，實質的意義當然也代表可以讓客戶進行驗收、收取貨款。但是交貨絕對不在於最後一個星期的匆促準備，而是你必須在系統分析的階段就和你的使用者建立好溝通的默契。換句話說，你必須從系統分析時就讓你的使用者清楚的了解到你將會讓這一套系統以什麼樣的方式呈現。當然，在系統持續的發展過程你也需要和你的使用者有良好的互動。也就是說，當你已經準備交貨時，你的系統使用者已經隨著你的發展過程對系統流程有相當的熟悉，那麼到了最後的交貨階段你就可以節省許多的力氣。接下來，我們分成進度掌控、交貨清單以及結案三個階段，討論交貨時應注意的事項。

3.4.1. 確實掌握進度

對於一個專案而言，控制進度的重要性確實是不言可喻的，而且所謂的進度控管絕非從程式開發階段才必須注意的事，而是從你一開始接觸這一個專案就必須完全掌握，因為接下來你所做的一切動作都將影響你的規劃。說的更明白一些，你的進度控制甚至在你還沒拿到合約前就必須有一些盤算，你必須從和客戶的對談中了解他們的需求，評估自己的能力等等。從這些條件中去決定是否應該接下這樣的專案，並估算所需的時間、成本。如果經過自己的評估認為無法勝任這一個專案或無法得取利潤時，就應該即時煞車。

專案從你和客戶的正式合作開始，做好專案進度的規劃更是影響你的成本計算，你必須準確而確實的依據你所規劃的時間表進行。常常有些專案的管理過分專注於程式開發的時間，而忽略了其他的部分。我們絕對不否認程式開發的掌握確實是十分重要的一部份，但事實上，所有的流程卻是息息相關的，如果你和客戶間的溝通無法在計劃的時間裡成功的進行，系統分析的工作則必然將會延遲或無法精確的進行，而沒有良好的系統分析結果，又怎麼可能在計劃的時間內寫出符合使用者需求的系統，就像我們前面所提到的，不夠完善的系統分析常常會讓系統開發繞回原點，因此時時掌握對於時程的控制與內容確實是系統開發的重要議題。

緊接著，我們還想要提醒你，要仔細評估系統開發的時程計劃。我們也曾經提到，專案的開發時程和整個專案的成本有著絕對的影響，也就是說如果你開發的時間越長，那麼你所必須負擔的開發成本勢必也會跟著提高，利潤也當然就越低。因此一些接案者或專案經理就壓縮自己正常開發所需要的時間，以為表面上的時間壓縮就可以在短時間內結案，進而獲取更高的利潤，但實際卻經常發現許多失敗的案例。

事實上，當你壓縮自己正常應有的開發時間，則代表你必須超時工作或你必須降低品質，但後者絕非我們所樂於見到的情形。於是假設我們必須超時工作以便按時交件，如此一來可能會有一些情形發生：首先，我們必須使用便捷的方式來進行系統開發的時間，而這樣的後果可能會造成系統的延展性不夠，對於系統開發者的重用性不足，也讓客戶將來要做系統的擴大時也會發生問題。或是可能發生系統開發者在壓縮的時間內準時的將系統交出，但卻因為無法做完整的測試，導致交貨後問題叢生，反而需要花費更多的時間去進行除錯。

第三種也就是系統開發者無法在時間內交貨，而致使違約或必須和客戶商情延期交貨。無論是那一種情形，所得到的結果不但無法達到降低成本的期望，反而使自己專業的形象受損，得不償失。因此我們反而希望各位在做時間規劃時應該預留安全的時間，那麼你不但可以比較輕鬆的提早完成，也可以在專案的後期階段，開始準備下一個專案的預備工作。

3.4.2. 交貨清單

除了我們剛剛提到的注意事項，在交貨前是不是還要做其他的準備呢？其實以大部分人的經驗來說，Paper Work是十分無聊而且相當煩人的工作，但是在某些時候卻是非常的有用，所以我們也建議各位進行專案開發的接案者能善用這樣的工具。許多大型的軟體公司或許是內部流程需要，或許是ISO認證的原因，對於詳細的文件紀錄相當的要求，如果是對於個人接案者 或是小型工作室而言當然沒有必要那麼巨細靡遺，或根本可以說是繁雜。但是對於客戶系統訪談紀錄，新的需求提出等等關鍵的部分不妨可以留下一些紀錄，不但算是某一種的資料整理，對開發者和專案委外商兩方面也算是某種保障。

另外，系統所需的一般文件當然也是不可少的，其中以資料庫規劃、系統說明、操作手冊等等都是可以你在交貨前必須準備齊全的。除了文件之外，切記你最重要的東西就是你辛苦開發的系統。因此在交貨前，先確認你要安裝的版本是不是已經更新為最新的版本，以免到時候發生任何意想不到的錯誤。接下來，你應該確認客戶的機器已經準備好，並架設好適合的環境，這對於系統的安裝是非常重要的，如果無法有良好的環境來進行系統安裝，或是安裝環境太過複雜的話都有可能讓你辛苦開發的系統無法正常運作。

接下來我們建議你，如何在交貨時可以讓使用者和你都輕鬆上手，而不會沒有方向。當然你可以建立一些屬於你自己的表格，例如你可以將合約書或其他紀錄規格文件中所提的各種功能都寫入清單中，那麼客戶可以一項項確認，並且也可以作為驗收的文件。這麼一來，你不但可以確認交貨完成，也可以讓客戶同時進行驗收的工作，這樣子同時進行可以讓交貨、驗收顯得更有效率，如果發生問題，也不需要每次驗收都重新開始，而僅需針對某些有問題的功能。這樣子聽起來，你會不會覺得交貨顯得容易的多呢？當然，交貨的過程中還有其他一些比較繁瑣的事情，但是如果可以掌握住這些大原則，就可以讓你更輕鬆、放心的交貨。

3.4.3. 順利結案

當你已經完成了系統開發，也讓你的客戶相當程度的了解並熟悉他們所期盼的系統之後，相信你在交貨的過程上並不會有太大的困難。如果是這樣的情形的話，那麼非常的恭喜你，你已經可以在這個專案畫下一個休止符，完成了一個重要的段落。當然，我們都相信事情並非經常都是這麼容易的，因此我們將有可能在這個階段遇到某些狀況。

由於許多專案委外的廠商對於資訊系統的熟悉程度是相當不足的，所以他們也擔心一但交貨後，系統開發者將會揚長而去，對於許多接下來可能發生的問題置之不理，面對這樣的恐懼，他們便不肯輕易的交貨驗收。也就是讓你的客戶產生對你的信任是非常重要的工作，而在這樣的基礎下，你不但能在專案的進行上更加的容易，也可以讓你的客戶為你帶來更多的客戶。

另外，千萬不要自己存有交貨就等於所有工作結束的心態，雖然一般而言，系統開發的合約上都會有保固期的約定，但是開發者對於系統的實際重視程度才是真正維護系統正常運作的重要因素。但是就我們經常發現的案例卻經常是由於系統開發者常常帶有交貨後就沒有責任的心態，甚至連應該修正的程式錯誤也置之不理。其實這樣的處理心態不但對系統開發者的專業形象有絕對的影響外，也讓許多人對軟體委外產生疑慮，進而打擊這個產業的發展。

也許某些接案者曾經遇上無理的客戶，不但對於系統的開發百般刁難，甚至在系統開發階段或交貨的階段提出某些相當無理的要求，那麼我們所整理對於客戶訪談、需求申請等各式書面資料將可以保護系統開發者。就某種程度而言，這並非是系統交貨的理想方式，但卻是可以避免開發者本身受到傷害的其中一種方式。畢竟系統開發到了最後階段如果無法順利的交貨對於接案者而言是一種非常嚴重的損失，所以如果你所承接的專案有某種導致無法結案的情形發生，你就必須用某些方式來保障自己的權益。

專案的開發對於系統委外的廠商或是專案承接的接案者而言都是非常重要的事，在這樣的前提之下，兩者相互之間的配合與互信是讓專案能順利結案的重要關鍵。而這樣的信任機制能被有效的建立之後，才能讓更多的廠商願意將自己公司所必須的資訊系統進行委外，建立一個良好的產業分工。讓整個軟體產業進入一種良好的循環之中，接案者也可藉此建立起結構更完善的軟體委外產業，或許對於軟體分工的簡單、透明化也會有所增益。而不再像目前的狀況，廠商擔心軟體委外的品質，不願意輕易地將公司企業內部的資訊化工作委由個人接案者或工作室，而接案者只能藉由口耳相傳去找到他們能承接的專案，資訊的封閉與信任度的不足，完全阻礙軟體產業的發展。

3.5. 發生意外並不意外

看到這樣的標題不知道會不會讓許多徘徊在軟體委外門口的接案者或打算成為接案者的人相當擔心，到底為什麼「發生意外並不意外」。相信許多對於軟體委外有興趣的人都曾經自己設計過一些軟體系統，那麼你們不妨回想一下，在你自己設計軟體的時候是否曾經在系統完成了七成以上忽然想重寫或改寫系統的某一部份呢？我想許多寫程式的人都曾經幹過這樣的事，既然如此，那又更遑論對於系統流程架構完全不太熟悉的使用者單位。因此即使你的系統分析做的多麼精準，總是會有一些遺漏的部分，而會遺漏的細節總是不容易引起注意的，既然如此，那麼你的使用者會無意間將它們遺漏也不需要太讓人訝異，不是嗎？所以意外的發生當然並不值得讓你那麼意外了。

話雖如此，但是盡量避免意外的發生，或是完全降低意外發生時所帶來的影響卻是必須在事前有所準備的。而這樣的意外防護措施，有相當大的一個部分是必須藉由系統開發者的經驗而來的。譬如你經常進行某種產業的系統資訊化工作，那麼對此一產業必然有了相當程度的了解，如此一來你對於系統分析時所注意的問題就會更為深入，自然能大大的降低了系統開發時所可能遇到的意外狀況。就以新聞上稿系統來說，我們都知道，新聞上稿系統對於流程非常的講究，也就是某一種程序性的系統是非常嚴謹的，對於層層關卡，如果你沒有經驗，你可能會因為一個審稿的步驟忽略而造成系統流程的錯亂，這樣的結果當然可能會有重大的影響。但是如果你曾經掌握住這樣的作業流程，你就可以非常清楚的了解內部的資訊流程與開發方式，那麼你自然可以減少意外的發生或降低意外發生的影響性。

另外一種意外發生則可能肇因於程式的錯誤，程式的錯誤絕對不是一個好現象，但是卻也可以稱的上是不算意外的意外，因為就像我們所說的，要寫出一個完全沒有錯誤的程式真的不是一件非常容易的事。既然如此，程式開發者便應該時時提醒自己，自己的程式是否在某些部分是存在一些錯誤的，以便進行更完整的測試，以期許讓程式能更加的正確無誤。

如同我們所知道的，我們雖然將意外的發生視為絕對可能存在的事實，但是就是因為抱持著這樣的態度才能減少意外發生的可能性。當然，也可能有一些讓人完全無法預料的意外，例如硬體發生的意外，系統設定或是系統衝突的意外。種種可能發生的意外，確實讓人難以掌握，畢竟很多的狀況並無法在我們的可以預見的範圍，也就是這樣的因素，對於意外的發生我們才能沉著的去解決意外，也才能更有效的讓系統正常的恢復運作。學習好的危機處理也是身為一個接案者所必須具備的條件，也就是必須想盡各種方法讓自己不必另外多花心思去照顧所有的系統。

3.5.1. 搶救意外

現在我們知道，在系統開發的過程中，某些狀況的發生幾乎是在所難免。所以如何在意外發生的時候做最妥善的處理肯定是成為接案者必修的一門課，而且也會是關係一個專案能否圓滿結案的重要依據。根據前面所提到的，我們會發現某些比較可能發生在專案過程中的意外情形。或是根據其他人的經驗來說明這些意外狀況的處理方式，至於其他隨時可能發生的其他意外情形，就必須根據每個人的經驗來作當下的判斷與處理。

程式的錯誤幾乎是每個人都會遇到的狀況，也因此，幾乎所有的系統開發者對於程式除錯都有每個人基本的方式。我們並不打算統一的規定大家一定要如何進行程式的除錯，當然這也不可能做得到，其實只要大家能有效率而又正確的達到除錯的效果，那麼所有的方式都是可行的。但是有一種意外是比較不容易發現，但是卻又非常嚴重，那就是所謂的邏輯錯誤。

這樣的情形之所以會特別嚴重的原因在於通常這樣的錯誤會被發現必須在系統運作了一段時間後，也就是已經有部分、甚至大量的資料已經被操作、利用或計算。當然，我們可以清楚的了解，當資料在錯誤的邏輯下會產生更無法預測的錯誤，但是有些時候使用者卻不太容易察覺。所以當這樣的意外發生時，會讓客戶因為這一套系統而承受相當大的損失。而當發現系統有這種邏輯上的錯誤時，由於並非系統無法運作所導致的錯誤，也就是說，我們通常會得到一些經由不正確邏輯下產生的資訊，而這些資訊也就是我們修正錯誤的最大線索。我們必須利用手上所獲得的訊息，依據系統目前的邏輯關係，一步一步反推回去，找到錯誤發生的地方，才能解決這種邏輯性的系統錯誤。

當然，你還有可能遇到的意外情形在於使用者採用了錯誤的資料，你可能無法理解，錯誤的資料產生錯誤的結果有什麼問題呢？其實關鍵在於錯誤資料的判斷，也就是如果是不正常的錯誤資料，在某種邏輯下可以檢查的規則，應該在系統進行第一道關卡，也就是儘量不要讓絕對錯誤的資料進入系統運作。例如我們最常見的就是月份必然為一到十二間的數字，那麼我們就會檢查使用者輸入的月份是否符合這樣的規則。同樣的道理，系統應該儘量替使用者事先剔除掉一些不必要的錯誤，以避免一些人為的疏失而讓系統的運作產生問題。

硬體的問題也是在進行系統開發時會遇到的困擾，有時候我們會遇到版本不相容或設定上的更改，這個問題雖然並非系統開發時的問題，但安裝時卻經常會產生這樣的狀況。雖然最直接的辦法就是要求客戶以最簡單的環境來進行安裝，但是有時候卻並非那麼容易，所以我們所能做的只是確認是硬體的相容、設定錯誤或是我們所開發的系統所發生的問題，並且慢慢的追蹤錯誤的發生，才能解決系統無法運作的問題。

3.5.2. 增加意外

「增加意外」，這樣的說法或許讓人不容易瞭解，但是我們所希望的就是讓大家能增加意外。事實上就是我們必須在系統開發、測試時就把我們預測到的問題避免掉，或解決所有我們可以事先想像到的錯誤。

一個有經驗的系統開發人員不但應該讓系統的錯誤降到最低的程度，也必須要有能力讓所有可以想像出來的問題在系統上線時完全解決，也就是當意外發生時必須讓人有訝異的意外感。如果一個系統開發者能抱持這樣的觀念，那麼不但可以讓系統的錯誤相當程度的降低，也可以藉由這些意外來訓練自己本身對於的經驗值。而不會持續在解決一些重複發生的問題中，對於個人在系統開發的經驗絕對會有正面的累加效果，也才能不斷累積個人的專業領域方面的資產。而這方面的經驗不但對一為系統開發者將來對於系統分析、系統測試、除錯上可以更精確的達到，也可以成為自己生涯規劃上的另一個目標與方向。

3.5.3. 危機專家

接下來，我想要談的是「危機專家」，當然，所謂的「危機專家」並不是指只會製造危機的專家。雖然在某種程度上，要成為這樣的專家也曾經製造過許多的危機，或面臨過許多各種不同的危機。而在這許多的經驗中，學習到如何處理系統開發遇到的問題。那麼這樣的經驗可以在自己開發系統時避免遇到相同的問題，更重要的是可以利用這些經驗來為其他的系統開發或企業內部擔任「救火隊」的工作，也就是以顧問的方式來進行系統診斷或系統測試、諮詢。這對一個系統開發者是另一種思考的方向，或說是一種可以努力的目標。

要成為一位系統開發、諮詢的顧問絕非一件容易的事。不但要對系統設計流程、開發方式、可行性分析都有很深入的認知，對於危機的處理更是不可或缺的能力。我們必須清楚的知道如果在系統運作中產生任何問題，對於系統使用者的損失必然會是最嚴重的，而絕非在系統開發過程中的任何系統錯誤。因此對於能夠快速了解、並解決系統危機的專家是必須經過非常長時間而且嚴格的訓練，以及累積足夠的經驗。而在一位系統開發者的角色中，任何在進行系統分析、開發、交貨或維護時所產生的問題，都必須仔細考慮，確實的解決，作為對自我的訓練，而期待成為一位危機專家。

3.6. 創造雙贏

毫無疑問，想要成為一位好的系統開發者絕非只在於某一個專案快速的結案，或是有強大的程式寫作能力。當然，這些是一位稱職的專案開發者所必須具備的條件。但是如果你是一位接案者的話，你必須直接面對客戶，也就是說你會接受到客戶所提出額外的需求。

這樣的情形幾乎在所有的專案中都會發生，至於該如何拿捏客戶所提出的這些需求，決定是否該接受這些需求，以及選擇恰當的服務態度和行銷方式，是訓練自己成為一位成功接案者的基本課程，也是這一節要探討的項目。

3.6.1. 正視顧客對於需求的修正

對於一般軟體公司的系統開發者或許也會有這樣的經驗，也就是當你在系統開發的過程中，或是系統已經接近交貨、驗收的階段時，忽然收到上司的要求修改某一些部分的規格。程式的難易程度顯然在這個時候只是次要的問題，相反的，對於系統規格的確定總是讓人苦惱的。

然而如果身為一位接案者，你將會親自面對客戶來討論這樣的一些議題。也就是客戶經常會要求新增或修改某些系統的規格，你當然可以依據合約上的規格來作某種堅持，但是一般我們希望對於一個開發者而言，我們必須正視使用者的需求。也就是在合理的範圍內，我們應該以最方便的方式來讓使用者能更滿足他們的工作流程。或是對於某種技術上或流程上具有某些困難性的需求來說，我們則必須和客戶進行訪談、溝通，並儘量為他們找出好的方案來幫助他們讓工作流程能更加順暢。

這樣的過程其實包含著一些意義，第一個意義在於一位接案者的服務精神與態度，這一方面我們稍後會比較詳細的談談它的重要性，其次就在於個人的學習。雖然我們是為使用者設計他們所需的資訊系統，但某種程度上而言，我們也是藉由這樣的設計過程而了解到某些領域上的專業知識，這樣的知識在我們想要接下其他相同或類似產業的專案時會減低我們的進入障礙，增加我們設計的效益，降低我們的成本，換另一個角度來看就是某種程度的提高了我們的收益。因此這樣的學習過程是有用的，也就是在一些合理的範圍內我們應該能仔細了解並評估客戶所提出來的需求變更，至於所謂「合理的範圍」定義怎麼判斷就取決於所有接案者個人的狀況、能力與智慧了。

3.6.2. 好的服務態度

正視顧客對於系統的需求是建立接案者個人形象的第一步，因為接案者的長久經營和一般的公司在某些方面是非常接近的。也就是說，要如何讓客戶對接案者或某些工作室產生信任，最主要的就是要能夠讓客戶安心。而要達到這樣的目標最好的辦法就在於服務的品質，畢竟軟體是解決問題的工具，所以要能夠替客戶真正的解決問題的關鍵在與是否能提供好的服務。

軟體服務的觀念對於一些系統開發者而言還是相當陌生的，因為許多人都將軟體當成是一項產品，因此將系統交貨之後，就像貨物賣出一樣，除了應該有的維護、保固之外，其他的各項要求就沒有必要去了解。甚至有些接案者對於基本的維護都沒有很有效的執行，即使程式產生了問題也因為客戶已經驗收而不予理會。那麼對於接案者本身或是軟體外包的產業其實都是很嚴重的打擊，畢竟一般企業並非資訊產業的專業，許多企業也大多只有少數幾位MIS 的人員，對於外包的資訊系統沒有獨立維護的能力。如果遇到這樣不願意維護系統的接案者，就會讓系統無法繼續正常的運作，那麼接案者和客戶的關係勢必會處於相當低落的情況，對於接案者而言，所面臨的就是一個「商譽」的問題。

和客戶建立良好的合作關係除了對於系統開發的方面之外，我們剛剛提到，由於一般的企業對於IT的了解並非十分深入。因此一但你開始對他們內部的資訊系統有所了解之後，他們通常會希望你可以為他們進行一些諮詢方面的服務。當然，專業的顧問方式是需要被收費的，但是基本的諮詢不但可以為你和你的客戶間有良好的互動，或許也可以藉此讓你因為其他的需求而承包相關的專案，或是藉由你的客戶而介紹其他的專案。從我們訪問一些接案者的過程中也經常發現這樣的情形，許多比較資深的接案者的案子有許多是經由原來的客戶介紹，或是原來客戶公司中的其他專案。也就是說，一般的廠商當然對於熟悉的開發者比較具有信心，或是比較能夠接受由認識的人所介紹的接案者。這也就是建立個人的品牌，從行銷學中的基本理論來看，在客戶完全不熟悉的狀況中，如果有讓人信服的品牌，確實比較容易進入市場，讓客戶願意使用有經營品牌的產品。

善於經營自己的人，確實比較容易有成功的機會，而想要讓自己成為成功的品牌，主要在於建立你和客戶間的良好溝通管道，好的服務態度也是另一項重要的指標。這樣的經營，確實是一個接案者製造自己與客戶雙贏的一種絕佳契機。

3.6.3. 接案者行銷

提到行銷學，總覺得似乎學問很大的感覺，但事實上我們剛剛也提到了一些關於接案者個人品牌的問題，所以我們就緊接著來看看個人行銷學，也就是怎麼擴展個人的市場。其實有一些接案者對於個人的品牌經營已經有一點成績，雖然他們並沒有特別對「行銷學」這樣的議題進行研究與深入的探討。我們舉個例子來說，我們將常會看到許多的接案者從一個人開始做起，也經常都是從某個朋友介紹案子開始做起。但是他們卻會有某種形式的個人工作室，於是名片、網站、各種宣傳自己所必須用到的東西都紛紛出籠。這就是非常重要的個人行銷，藉由許多附加的物品來提昇自己的曝光率，讓更多有程式想要委外的人或公司可以找的到自己。

這樣的例子應該就可以很明顯的表現出其中的精神所在。這其中當然有幾個不同的層次，第一個部分是為什麼大家會想要找你，在這個範圍內，大部分都是其他人介紹，這代表的意涵在於對你知道你有這樣能力的人夠多，或是你曾經開發過一些系統也得到不錯的評價，要有這樣的條件並不是特別容易，要有相當的經營。

當然，也有另一種情形是你曾經作過大量的行銷，也就是曾經昭告大家你對於系統開發有能力，那麼即使沒有透過其他人的介紹也知道你的聯絡方式，這樣的情形我們經常可以在BBS 上看到，也就是一種主動的行銷。但是這樣的方式實際上回收率卻是有限，也就是大家互信的程度還沒建立起來之前，一般想要委外的廠商並不太能夠相信接案者本身的品質。

當然，如果你曾經設計過許多系統，也獲得不少好評，或是你曾經有過一些代表作的話，那麼如果有類似的案子要委外時，廠商就會主動的找你，希望你可以幫忙，這樣的方式是屬於剛剛所提的最後一種方式，也是不太容易建立起的一種行銷，但是可靠度卻是相當的高。但是其實不論廠商基於什麼樣的立場、看法希望你替他們開發系統，能夠建立容易溝通的方式也是不可忽視的。畢竟許多廠商對於系統的時間都非常的緊湊，如果你不容易連絡上，很可能會喪失掉許多機會，這絕對是非常可惜的，因為要獲得專案的機會本身並非相當容易的事情。這些方面是一個接案者基本的行銷方式，卻也是建立個人專業形象所必須的行銷方式。如果可以以最少的成本來獲取最大的助益，我們有什麼理由拒絕呢？

成為一位好的接案者並不單單只是一味單純的承接專案、系統開發、交貨、驗收的過程，其中還包含了種種可能發生的特殊狀況或是和客戶之間的互動。其實所有可能或必然會發生的情形和一般的工作室、甚至軟體公司間並沒有太大的差距，這三者之間的差距某方面而言只是因為專案的大小所造成的工作流程上的不同。

但是對於一位接案者來說，他卻必須一個人負起所有的責任。從一開始的談判、簽約、訪談到接下來的系統分析、系統規劃、開發，最後階段的系統安裝、交貨、維護等等，沒有一項可以假手他人。

因此當一個接案者確實是相當辛苦的，不但個人的專業能力是必要的，而且肯定要有相當的毅力。我們在這裡所提醒大家應該注意的事項，並不是希望可以減低任何一項工作的負荷，相反的，我們希望所有人都可以將所有該做的事都能注意，並且嚴謹的做好。但是藉由我們的提醒，也許所有的接案者可以經由我們所提到的經驗經由更具有效率的做法來完成。

4. 互信: 合約訂立與維繫

為什麼要訂合約呢？如果我要求訂合約，發案者是否會因此而覺得我吹毛求疵呢？訂了合約就能完全保障我的利益嗎？合約中到底應該訂立哪些東西呢？在回答這一連串問題之前，我們必須回到一個最基本的問題：究竟什麼是合約？

究竟什麼是合約？許多人也許會回答，做生意的兩方，將談判的結果：比如說價錢、商品的數量、交貨的時間地點等等事項，寫成白紙黑字，並在紙上簽名或用印加以確認的文件，就是合約。的確，這樣的書面文件是合約沒錯，但如果雙方間對彼此間要怎麼合作的種種細節都談了，也確認了，只是缺乏一份將這些細節加以文字化的文件，雙方難道一點也不受到之前所作的種種口頭承諾的拘束嗎？中國人所說的：一言九鼎，一點法律上規範的作用都沒有嗎？

其實不然，根據民法的規定，合約是指雙方就做這筆生意所必須討論的最根本的問題達成協議，在多數的情況下，法律並不要求一定要就契約的內容作成書面文件。去傳統市場買過東西的人，也許有過下列對話的經驗「老闆，這個蘋果一個多少錢？」「六個一百塊。」「可不可以算便宜一點阿？」「好吧好吧，快收攤了，算你七個一百元好了。」「好，那給我七個吧。」在這短短的幾句對話間，其實你已經與賣東西的小販間，訂立了一個買賣契約。雙方間有任何書面文件嗎？沒有。但買賣契約中最根本的幾個要素，商品內容、價錢、商品數量等你們都已經達成協議了，甚且，根據合理的推測，雙方將非常明快地當場履行根據這個「蘋果買賣契約」所必須擔負的義務：身為買方的你，將錢從錢包裡拿出來交給水果攤老闆，身為賣方的水果攤老闆，則將七個蘋果包好交給你。由此可見，不具書面形式的契約，在日常生活中，其實是隨處可見的，數量遠比白紙黑字寫成的合約要多的多。也由此可見，與他人訂立具有法律效力的契約，其實早就是我們生活的一部份，實在沒有恐懼的必要，反之，應該善於利用契約協議的過程，對雙方所關心的種種事項充分的討論，如此不但有助於減少日後發生爭議的可能，更能夠有效建立雙方互信的基礎。

4.1. 如何訂立一個有效的合約?

經過買蘋果例子的分析，相信大家會對契約如此容易成立留下深刻的印象，但也許有人會問，既然只要雙方談定價錢及工作內容，為什麼要耗費周章來對並非契約成立要素以外的事項加以研究討論呢？這樣不僅耗費時間，萬一雙方在一些小地方上無法達成協議，那不是徒增困擾嗎？事實是，不僅站在法律的角度來看，讓雙方歧見早點浮現，有助於減少損害擴大，根據資深專案經理的經驗，「醜話說在前頭」事實上有助於一個專案順利完成。讓我們再回到買蘋果的例子。

買了七個蘋果回家之後，你興高采烈的馬上洗來吃，但是：「哇，好難吃」，七個一百塊的蘋果不僅不甜又不脆，仔細審視之後，甚至可以發現有幾個已經有嚴重損傷，怒氣沖沖地你考慮馬上拿到市場去退貨，到底能不能退貨呢？這時我們必須回過頭來看看你與水果攤老闆所達成的契約內容，在那短短幾句話中，雙方顯然沒有對蘋果的應該具有的甜度、脆度等方面有任何討論，雖然你對這樣的品質並不滿意，但對水果攤老闆而言，「一分錢一分貨，七個一百塊的蘋果應該有的甜度和脆度就是這樣喔，否則你當初就應該買旁邊放的一個兩百元的富士大頻果阿。」好吧，甜度和脆度算我過分要求，不應該賣有嚴重損傷的蘋果給客人，應該是賣水果的基本道理吧？雖然當初沒有明講，難道對哪幾個已經有嚴重損傷的蘋果，我也不可以要求退貨嗎？

因為當初合約中沒有明講，我們就只能寄望民法中是不是有相關的規定可以適用。民法債篇各論買賣一節中，對商品的瑕疵擔保確實有所規定，對那幾個具有嚴重損傷瑕疵的蘋果，根據法律規定，買方可以要求賣方「減少價金或另行交付無瑕疵之物」，因此你可以要求水果攤老闆算的再便宜一點而你保留那些有瑕疵的蘋果，或是在原來定的價錢下水果攤老闆換幾個沒有損傷的蘋果給你。這種情況中，現行法律並不提供「退貨還錢」法律基礎，因此除非水果攤老闆同意，否則你無法單方面的要求他這麼作。

我們可以再舉另一個例子來作比較：「老闆，這個西瓜多少錢？」「一斤五十元。」「甜不甜阿？」「甜甜甜，當然甜。」「問題是有多甜阿？有你旁邊試吃的這麼甜嗎？」「有啦有啦，我保證。」「好吧，給我這半邊，如果不甜的話我要退貨還錢喔。」「好啦好啦。」如果買回去的西瓜不甜的話，根據雙方間的約定，理論上會產生非常不同的法律效果，顯然西瓜的甜度是買方所非常關心的一個因素，雙方也就萬一日後發現商品沒有達到預定品質應該如何處理，達成協議，雖然法律原則上並不提供「退貨還錢」法律依據，但契約雙方有特殊的約定，因此雙方在西瓜不夠甜時，就必須照著當時約定的，依據「退貨還錢」的方式來處理。

前面例子中的蘋果和西瓜，可能換成汽車、機器甚至軟體。訂定契約的過程均是雙方發出願意締約的訊息，雙方就合約的內容加以協商，最後達成協議，而這個契約並不一定要作成書面文件才具有法律效力。接下來我們要討論的是，在一個軟體外包的開發專案中，牽涉到哪些要素，現行法律有哪些相關規定，身為一個接案者，在與發案者的談判過程中，應該要如何保障自己的權利，並經由談判的過程達成雙方互信的基礎。

仔細回想日常生活中的各種經驗,我們可以會清楚的發現,根據我們對交易的重視程度,交易的內容,牽涉金錢數量的多少,我們願意花在談判以至與交易的他方達成協議的時間及精力也會有非常大的差別。到市場買水果也許只需要三分鐘的時間就能夠完成交易，高高興興的提著水果回家，但在買車的狀況中，很少有人能第一次與車商接觸就付下訂金，事實上根據經驗花上三個月去看車的大有人在。在買水果的情況中，除了極度吹毛求疵的人，很少人會多花幾分鐘的時間和水果攤老闆討論西瓜應該有多甜，如果不夠甜可不可以退貨云云，畢竟西瓜的價錢不過一兩百元，如果考慮和老闆進行協議的交易成本，多費唇舌似乎反而因小失大。但如果是購買大量的商品，大概所有的買方都會不辭辛勞的要求看樣品，並仔細討論如果收到貨品時，發現品質不及樣品時，應該如何處理。買西瓜時，我們充其量只會在意甜度夠不夠或斤兩足不足，但如果牽涉到的是跨國性的商品交易，那麼除了商品本身的品質數量價格應該如何決定外，買方和賣方也許更會仔細討論要選擇什麼樣的方式來運送，運送的費用應該由誰負擔，運送過程中所產生的風險應該由誰承擔等等。

經由以上的討論,我們可以知道下列幾件事:

• 合約並不以書面為必要。

• 在合約沒有明定的情況下，需以法律規定為補充。

• 除非法律有強制規定外，當事人間的約定可以取代法律的規定。

既然口頭的承諾即有法律上效力，雙方沒有討論到的地方，仍有法律的規定作補充，那麼，還有必要大費周章的討論各種細節，並將之形諸文字，甚至要求專業的律師審閱相關的文件嗎?在下一節中，我們將談到為什麼法律不要求書面契約的情況下，一份形諸文字的書面文件仍將是保障雙方權益的重要工具。

4.1.1. 需要訂立書面契約嗎?

回答這個問題前，讓我們回到一個更根本的問題：契約的作用究竟是什麼？透過前面討論到的兩個例子，我們可以看出，契約對當事人而言，主要包括兩種作用：

透過履行契約的行為，達成交易的目的

在買蘋果和買西瓜的例子中，雙方先是就交易的貨品內容價格達成協議，然後按照雙方合意的契約內容各自作出能完成交易的行為：買方根據雙方合意的價錢交付價金，在此同時，賣方按照合意的內容和數量交付貨品，當這兩個行為都完成時，交易的目的就達成了。

交易過程中出現爭議時，可以根據約定的方法和程序處理善後

當契約雙方無法順利解決爭議，而必須求諸第三人來判斷時，該第三人也必須根據契約內容來作判斷。因此口頭契約雖然具有法律上的效力，但如果當事人雙方對契約內容有所爭議時，顯然會陷於眾說紛紜莫衷一是的狀況。因此口頭的契約雖然一樣具有法律上的效力，但缺乏紀錄及保存雙方協議內容的效果，日後發生爭議時，將缺乏客觀的紀錄來作為檢視雙方嫌譯內容的依據。

此外，在將口頭協議形諸文字的過程中，雙方在字斟句酌的過程中，常會發現原本以為已經溝通清楚的條件，事實上各自有不同的解釋，必須再加以釐清，因此訂定一份書面契約事實也有使雙方對契約內容更加慎重討論溝通的作用。

綜上所述，我們可以了解，書面契約至少有以上兩種好處。

4.1.2. 如何完成一份書面契約?

在這一節中，我們所要討論的是，一份書面契約在形式上必須具備哪些要素，才能發揮法律上基本的作用：作為要求雙方履行契約的依據以及作為爭議發生時解決紛爭的基礎。我們將依次討論簽名、日期、合約份數、應準備哪些合約附件、簽約前臨時要修改合約要怎麼辦等項目，最後我們也將談到目前公司業務執行上常見的以傳真或電子郵件來完成交易的方式，由法律角度來看有何利弊得失。

4.1.2.1. 由誰簽名才有效?

契約既然是用來拘束締約的雙方當事人，那一份書面契約最重要和根本的要素，就是必須能夠明確辨認，這份契約所要拘束的當事人是誰，同時也必須能夠明確的辨認出，這份契約是經由那些當事人所同意而訂定的。因此在這裡，我們必須注意兩件事：在書面契約中是否正確而適當的寫明契約當事人，以及契約是否由法律上可以合法代表該當事人的人簽名了。

正確而適當的寫明當事人，乍看之下是件再簡單不過的事，不過就是把我的名字和對方的名字寫上去阿。大多數人應該都會這樣反應。但我們也許會忽略的是，在法律所建構的世界中，可以作為契約當事人的，除了有血有肉的人之外（在法律上稱為自然人），還有以依據法律規定所設立產生的法人，也就是大家耳熟能詳的股份有限公司，有限公司等等。但這些法人，固然在在法律上可以作為契約當事人，而在法律上依據契約內容負擔一定的權利義務，但在合約洽談的過程中，仍然必須由自然人洽談，因此務必辨明究竟是由公司或是個人來負擔契約上的權利和義務，尤其是在你是次承包商的情況中。

至於在書面契約中是否一定要用蓋印章的方式，才符合法律的要求呢？其實不然，依照民法的規定，簽名和用印同樣具有法律上的效力，只是依照我國一般業界習慣，當以公司為契約當事人時，通常會以文件上是否蓋有公司印來判斷該文件是否由具有合法代表權限的人所簽署。

簽名和用印的位置

我國民法並未規定，在一份合約中，簽名和蓋印應該在何處才具有法律上的效力。雖然理論上，雙方當事人可以簽明和用印在契約上的任一處，但實務上。雙方當事人通常會將簽名置於所有契約條款之後，這是為了表示雙方當事人已經閱讀過之前所寫的所有契約條款，並同意接受這樣的條件。

是否必須蓋騎縫章呢？

騎縫章是雙方在合約文件的頁與頁間簽名或用印，主要的作用是為了避免合約文件中的任何一頁遭到抽換。騎縫章並非法律所要求的形式要件，除非整份合約在形式上容易遭到抽換，或是你確實擔心合約的某一部份有遭到抽換的可能，否則並不需要大費周章的蓋上騎縫章。

應該由誰簽名和用印呢？

如果您是以獨立接案者的個人身分接案，對於因為這個案子所發生的債務，在法律上，您必須以個人的身分負無限責任，這時合約自然應該由獨立接案者個人來簽名或用印。

有些獨立接案者會獨力或與幾個朋友合夥成立「工作室」，並為這個工作室取一個響亮的名稱，借以行銷並建立品牌聲譽。當接案者以「霹靂工作室」名義接案時，如果霹靂工作室是由接案者一人獨資成立的，那麼在簽約時除了表明霹靂工作室的名稱外，同時也應寫明獨立接案者的姓名，並由其簽名。如果霹靂工作室是由好幾個朋友合夥成立時，則應該由執行職務的合夥人簽名。執行職務的合夥人是由所有出資的合夥人同意所產生，他對外執行職務的結果對全體合夥人發生效力，也就是說即便是只有執行合夥人一人在合約上簽名，但實質上他是代表所有合夥人進行這項交易，因此所有合夥人必須均必須對此項交易的結果負責，如果合夥人出資所成立的合夥財產，尚不足以負擔因此所生的債務時，則合夥人個人就必須以個人所有的財產來清償。

獨立接案者成立公司來接案的狀況或許比較少見，但因發案者多半是以公司企業為主，因此我們也必須就當事人是公司的狀況來加以討論。目前商業實務上比較常見的是有限公司和股份有限公司。這兩種商業組織型態與前面所提到的「工作室」相較，在法律地位上有顯著的不同：有限公司與股份有限公司在法律上具有「法人格」，也就是說在法律上可以作為負擔權利義務的主體，因此，合約上當事人必須標明是該公司，且應由可以代表公司的人簽署。在實務上，合約上通常會蓋上公司的大小章，也就是公司印及負責人（或經理人）印。

4.1.2.2. 要寫上日期嗎?

明訂日期與否，並不影響一份書面契約在法律上的效力。但因為許多法律或雙方當事人於契約條款中所約定的權利行使，涉及期間的計算及契約的訂立或生效日，因此在書面契約中寫明日期，能有效避免日後就契約成立日期發生爭議。

雙方不必在同一天完成契約簽署的動作，但必須特別注意：如果契約雙方沒有在契約中另行約定契約生效日，則契約必須等到所有的契約當事人，均完成簽署後才成立生效，並對所有契約當事人發生效力，換言之，任何一個當事人，在他完成簽署前，不受契約效力的拘束。

在祗有單方簽署而對方不簽署的狀況下，已經簽署的一方會受到他已經簽署的契約內容的拘束，此時契約生效與否的決定權將繫於對方。

4.1.2.3. 要簽幾份書面契約呢?

究竟應該準備幾份書面契約，需視契約當事人有幾人而定，每個當事人最好均保留一份由所有當事人簽署的契約原本。在簽署前，請確定每份契約都附上所有附件，且所有文件：包括契約本身及附件的內容完全相同。因此，建議所有的文件在確定內容後一次印出來，如果列印後簽署發現有任何錯誤或修改，請把所有的文件銷毀後，再列印新版本。

最重要的是，當你拿到簽署完成的契約原本時，請妥善保管，否則當發生爭議，必須拿出契約作為雙方解決爭議的依據時，如果找不到契約，就白忙一場了。

4.1.2.4. 什麼是契約附件?

為了使契約本身專注在法律上最根本而重要的事項，避免契約規定顯得過分龐雜，建議將所有雙方間所商訂的細節，例如軟體開發專案的規格書，或是平面設計的基本規格和樣式，以契約附件的方式來訂定。使用附件能使契約本身較為簡潔而易於閱讀。

當有附件時，應該注意下列事項：

• 如有一份以上附件時，請將之編號。

• 請於合約文末依序標明附件編號及其名稱。

• 請於合約本文中，訂明附件內容經雙方同意，並且屬於合約之一部份。

• 附件不需訂明日期或由雙方簽名。

4.1.2.5. 臨時要修改契約內容怎麼辦?

當合約文件已經準備好後，雙方卻在完成簽署前臨時決定修改合約內容時，要怎麼辦呢？雖然，最好的方法是修改原始檔案，並重新列印一份，但這樣的動作雖然看似簡單，但在實際業務執行上卻會拖延合約完成簽署的時間，特別是獨立接案者所面對的是組織較複雜有一定控管程序的公司時。這時，雙方可以在溝通並確定修改後的條文文字後，由持有合約原本的一方在紙本上直接進行修改，並由所有簽署契約的當事人在修改處簽名用印。如果修改處沒有經過所有當事人的簽名，日後可能會發生該項修改，是否對所有當事人生效的爭議。

4.1.2.6. 傳真或電子郵件契約有效嗎?

經過4.1.1中的解說，我想大家應該都能輕易的解答第一個問題，經由傳真或電子郵件溝通的內容如果經過雙方的同意，在法律上具有拘束雙方當事人的效果。但為了避免雙方最後達成的協議內容為何發生爭議，應將雙方最後達成的協議內容整理成一份最後版本的合約，由雙方簽署確認。

在使用傳真的情況中，雙方可以在簽署後將文件傳真給對方，這樣雙方都可以保有一份經由他方簽署的傳真文件。但因傳真文件在現在的科技下，非常容易偽造，因此如果他方日後爭議該傳真文件並非他所簽署，那舉證上將會發生重大的困難，雖然這樣的狀況實際上並不常見，但如果要避免這樣的狀況發生，最好的辦法是雙方將簽名的原本郵寄對方保存。

使用電子郵件時，雙方可以考慮利用加密電子簽章的方式，來達成與簽署相同的效果。

4.2. 一般委外契約應該具備的條款

在這一節中，我們將談到在一個外包合約中應該包含哪些條款，在訂定這些條款時，應該注意哪些事項，以及在這些事項上，要如何與客戶進行溝通。

誠如我們之前所提到的，合約條款無非是將在溝通過程中所提到的種種細節，以書面文字紀錄下來並且定義清楚，因此訂立合約絕對不是單純交給律師去作的事，而是接案者和客戶雙方都應該充分的去就雙方所在意的事項進行討論，儘管不是所有在整個外包案件，都必須巨細靡遺的去討論所有的項目，但是建議您應該把所有的條款都至少閱讀過一遍，如此一來，你會對可能發生的狀況有所了解，也能夠比較有條理，有系統的與客戶進行溝通。

但在開始看接下來的內容前，不論您是否有過接案的經驗，都請您先拿出一張紙來，把所有您認為在訂立合約時所應該要寫明的項目寫下來，再與後述的內容作比較，也許您會發現，您對合約所應該訂立的內容，其實並不如您想像中的那麼陌生。

4.2.1. 工作內容

在一個外包專案中，最根本的問題就是發案者要求接案者完成什麼樣的工作，也就是工作內容究竟是什麼？如何經由有效的溝通來界定工作範圍並釐清雙方間的認知差距，在前一章中我們已經有詳細的敘述。當您要將雙方所談妥的工作內容形諸文字時，作為書面合約的一部份時，應該注意下列事項：

描述工作內容時應著重在發案者所要求的成果的敘述，而非完成工作的方法或程序為何。身為獨立接案者而非發案者公司內部的聘任的員工或雇員，對工作內容如何完成，應該採取何種方法或程序，您應該有主要的決定權，特別是所完成工作的方法或程序也許涉及您專有的技術或知識，就此您並無告知發案者的義務。而發案者所關心注意的將您所完成的工作是否符合他的預期。

當爭執發生時，雙方所約定的工作內容將會是雙方爭執的主要重點。如果工作內容相當複雜，必須以一頁以上的文字敘述，例如軟體開發專案中所方所商討的規格書，則請以附件的方式處理。

4.2.2. 工作報酬

獨立接案者的計費方式，主要可分為兩種：

按件計酬

在按件計酬是指，就整個案子計價。對發案者而言，按件計酬的好處在於在簽約時，他即能知道就這個案子他必須付給獨立接案者多少報酬。對一個有經驗的獨立接案者而言，按件計酬的方式也可能使他獲得極大的報酬，因為他能精確的估算完成整個案子所需要的時間和費用，並有效率依照預估的時間完成工作。然而在按件計酬的案子中，如果獨立接案者低估了完成專案所需的時間和費用，那麼他必須自行吸收因此所產生的種種風險，包括實際收取的報酬低於所付出的精力和時間，以及為了完成這個專案必須放棄其他專案的機會成本。

獨立接案者在決定採取按件計酬的方式時，應確定工作內容已經界定的足夠清楚。

按時計酬

按時計酬對獨立接案者而言，能夠確保他所花費的每一秒鐘，均獲得應得的報酬。但顯然不是發案者所樂意採用的方式，因為他們無法預估究竟會花費多少成本在這個案子上，同時發按者也會擔心按時計酬方式本質上所隱含的道德風險：亦即當獨立接案者無足夠案源時，他會以較慢的速度完成工作以便賺取較高的報酬。發案者在採用按時計酬方式時，有時會要求預設收費上限，亦即當工作時數超過收費上限時，就超時部分的成本獨立接案者必須自行吸收。這種情況下所採取的按時計酬制度事實上隱含著按件計酬的影子，獨立接案者應確定工作內容界定的足夠清楚，同時能夠在預設的時數上限內完成工作。

4.2.3. 付款時期及程序

付款時期通常可以分為一次付款及分期付款。

一次付款

採用一次付款時，多半是以工作完成時為付款時期，但實際收款的時間將視雙方約定的付款程序而定。

許多獨立接案者也許會理所當然的認為，如果是一次付款的話，自然應該是在工作完成後才付款。事實上究竟何時付款需視雙方所簽訂的合約性質。在專案開發的合約中，基於一手交錢一手交貨的觀念，雙方多半會將付款的時間定在工作交付之後。但如果雙方所簽定的是技術諮詢顧問合約或是維護合約，且是採取按時計酬收費的話，則通常會約定在雙方簽約時即將一定時數的金額付清，再由獨立接案者依照實際執行的工作時數，定期或依次填寫工作記錄或報表向發案者報告。在這種情形中，要特別提醒獨立工作者的是，在雙方約定的工作時數即將額滿前，即應預先告知發案者，並預先安排續約或第二期預付款給付事宜。否則在預付款扣底完畢但獨立接案者仍繼續執行工作時，呆帳發生的機率就大大提高了。

分期給付價款

在雙方約定分期給付價款時，固然可以簡單明瞭地約定確定的付款日期，但在工作時間較長或較大型的軟體開發專案中，若能將應完成的工作適當地切割為幾個階段，將各階段工作完成時訂立工作里程碑，並約定在各工作里程碑完成時，依次給付部分價款，這種做法具有某程度進度控管的作用，如此一來發案者對獨立接案者進度掌握的能力會比較信任，而分階段檢討工作進度的壓力，事實上對獨立接案者是有正面幫助的。

當採用這種方式付款時，應明確區別各期的工作內容，各工作里程碑所應完成的工作項目，以及其相應所需支付之合約價款數額或百分比，以表列或條列方式標明，並將之以附件方式訂定。建議以附件方式簽定的原因，除了避免合約內容過於龐雜難解外，主要是考慮到在實際專案開發過程中，若需調整專案進度及付款日期時，雙方僅需重新就附件內容簽定即可。

按時收費

若雙方採用按時收費的方式，則雙方應約定結算的期間，結算期間可以案件的性質約定為按月或按期，當期間屆滿時，獨立接案者應將所花費的時間作成工作紀錄，交給發案者，作為收費的依據。

付款程序

發案者和獨立接案者除了應該討論付款的時間外，也應就付款程序加以溝通。特別是在發案者是公司組織時，通常會有其特定的作業程序和付款日，獨立接案者不論是否有成立公司組織，都應該問明發案者公司的相關作業程序，以便能夠充分控制收款的時間，避免造成困擾。

4.2.4. 費用開銷

為了完成專案，接案者可能會有長途電話費，影印費或是至外地開會洽談事務的旅費等，如果對接案者而言，這些費用支出是可以預估或金額不致過大的話，建議直接將之放入整體案件報酬或按時收費的基數中計算，如此一來可以避免必須留存各種繳費收據甚至電話紀錄，並整理以便向發案者報告請款的麻煩。但如果預期為了完成工作需要對某些金額較高的開銷，例如差旅費等，究竟應計入接案成本由接案者自行吸收，或是由發案者依實際支出另行支付，雙方應該就此加以討論，並將之訂入合約中。

4.2.5. 硬體設備或資材

就完成工作所需要的一些材料和設備，在多數的情況下，均應由獨立接案者自行採購。但在軟體開發專案中，可能會由發案者將硬體設備交由接案者保管，以便利接案者進行測試。在這種情形中，發案者對硬體設備應善盡保管責任，否則如果為了完成工作原本即預期硬體設備會有所損害的話，也應就此加以寫明。

在多數的軟體開發專案中，通常是由發案者自行購買所需的硬體設備，建議合約中應寫明接案者不就硬體設備所可能發生的問題負責。如果是由獨立接案者經手機器設備的購買時，應就這些機器設備購置另行訂立買賣契約。

4.2.6. 稅捐

稅捐種類將依交易內容有所不同，4.2.2中所規定的合約金額是否包括因此所產生的稅款，雙方應該加以約定清楚。

4.2.7. 合約有效期間

合約有效期間是指合約開始和結束的時間。除非合約條款中另行訂明合約開始日期，否則合約將自簽署之時生效。

如果獨立接案者與客戶並非同時或同日簽署合約，且合約中條款中並未另行訂明合約生效日期為某年某月某日，則合約將自所有合約當事人簽署完成時起生效。

如果合約當事人為了保存的理由，準備了一份以上相同內容的合約紙本，則只要所有當事人均在某份紙本上簽署時，合約即生效，例如締約雙方各持一份內容完全相同的合約，則合約將在雙方均簽署時即生效，但為了避免日後爭議，雙方應立即將自己保有的合約紙本交寄對方簽署後留存。

合約的生效，意味著雙方自此必須接受合約條款的拘束，亦即必須依合約所規定的內容照章行事。但這不是說獨立接案者必須自合約生效日起立即開始工作，您仍然可以依照手上接案的狀況和時間表進行工作，只要你確定能在合約所訂的交件日期或各工作里程碑如期交付工作。

4.2.8. 合約終止

締結合約之所以如此令人害怕，也許是因為大家十分擔心在締結合約之後，從此以後即需受其拘束，永無解套之可能。事實上這是未曾深入了解所造成的誤解。

雖然合約當事人在合約生效後，即負有遵守合約內容履行一定行為的義務，但合約的拘束性並非百分之百絕對的，在多數的情況下，當事人在締結合約之後並不會就此失去控制合約效力的權利，合約既然是因當事人意思合致所產生，自然合約隨時都可以因締約雙方的相互同意而終止。

合約中也經常規定在某些特定的情況下，合約一方當事人可以不經他方同意即終止合約。

合約終止，是指合約自終止日後即不再對雙方當事人具有拘束力，但雙方在合約終止日前的種種行為仍舊必須受到合約條款的拘束。通常狀況下，就接案者在合約終止前已經進行的工作，發案者仍應支付報酬﹔而在接案者如果在合約終止日前，有任何合因故意或過失而導致發案者受到損害時，即使合約嗣後終止，接案者仍舊必須負責，換言之，雙方因合約終止前所負的損害賠償責任，不受合約終止之影響。

4.2.9. 爭端解決機制

當爭議發生時，我們的建議是先與發案者進行溝通，尋求一個雙方都能夠接受的解決之道，因為這通常是最有效率且最節省成本的解決方法。即使從雙方協調所的數目看來，您有所虧損，但把採用其他方式所需花費的精力成本考慮進去，也許還是比較上算的。

在這個階段的溝通，除尋找雙方皆信任的中間人居中協調外，雙方以可考慮由鄉鎮調解委員會進行調解。鄉鎮市調解條例所稱之「調解」，係在各鄉鎮市公所設置調解委員會，由鄉鎮市長推薦具有法律知識、信望素孚之公正人士送請鄉鎮市民代表會同意後聘任為調解委員，直轄市及省轄市之區則於區公所設置調解委員會，調解委員由區長報請市政府提經市議會同意後聘任之。民眾如有紛爭可以免費聲請調解，如經調解成立，將調解書送法院核定後，如為民事調解即與法院之民事確定判決有同一效力

但若溝通結果，雙方根本無法達成任何協議，此時，就不得不求諸第三者來為雙方間的爭議作一個決定。（參見 http://www.moj.gov.tw/f4_11.asp）

仲裁法所稱之「仲裁」，係指當事人以書面訂立仲裁協議，約定將有關其現在或將來依法得和解之民事爭議，交由獨任仲裁人或單數之數人組成之仲裁庭仲裁，以解決爭議的制度。當事人將爭議事件提付仲裁，經仲裁庭作成判斷者，其仲裁判斷於當事人間，與法院之確定判決有同一效力，原則上經聲請法院為執行裁定後，得為強制執行，具有迅速、經濟、保密及專家判斷等項優點。目前台灣尚無針對資訊產業爭議糾紛解決的仲裁組織出現，因此雙方如欲約定採用仲裁程序解決爭議時，歷史悠久的商務仲裁協會仍應為首要考量。

4.2.10. 通知送達方式

在工作進行中，雙方也許會對合約的存續或進行方式有重大決定，而需告知他方，這在法律上稱為意思表示的送達。你所作的決定必須合法的讓對方知悉，也就是必須將這個意思表示送達到他方時，這個決定才會對對方發生效力，比如說在你決定終止契約或修改契約內容時，均需對對方送達。

明確規定送達方式，包括地址，收件人及寄送方式，能有效避免因郵誤或溝通困難所發生的爭議。

4.2.11. 合約轉讓或繼受

在一般狀況下，合約的簽署人通常會是完成工作的人。但法律並不要求必定如此。為了顧及商業活動所要求的彈性，法律並不要求合約簽署人一定必須是完成合約所訂工作的人，也不要求在合約有效期間不得脫離合約。因此，合約當事人可以在合約中約定，在何種條件下，合約當事人一方得自己在合約上的義務，轉嫁給其他人去完成，甚至亦可約定在何種狀況下，當事人一方得將合約中所規定的權利義務，轉讓給原本並非合約當事人的第三人，而自己脫離合約的拘束。這兩種不同的做法，分別是合約轉讓和工作轉包。

工作轉包與合約轉讓的差別在於，在前者的情況中，合約當事人並無變動，只是當事人將合約的工作交由第三人去完成。但如果第三人所完成的工作成果不如人意，則還是要由原來的合約當事人負責。而合約轉讓的結果，將使合約當事人發生根本上的變動，原來的合約當事人將變成與合約執行完全沒有關係的第三人，而新的合約當事人必須繼受被繼受人因合約所生的一切權利義務，包括被繼受人在轉讓合約前的一切行為所產生的法律上責任。

4.2.12. 準據法

準據法是指當雙方因合約發生爭議，於解決雙方爭議時所應該適用的法律是哪一國的法律。除非接案者與發案者有特殊的考慮，否則在多數情況下應為中華民國法。

獨立接案者在時最關心的自然是接案所能獲得的利益，但因此所發生的風險也是獨立接案者所不能忽略的。在軟體開發專案中，接案者所面對的風險除了無法將工作完成所必須負擔的損害賠償責任外，較不顯著但卻可能引起更大傷害的是軟體運作錯誤的潛在性風險。對軟體開發人員而言，有程式就有Bug似乎是眾所皆知的定則，在盡力除錯以提高軟體品質的同時，軟體業界事實上早已形成與程式中隱藏的蟲子是必須容忍之惡的共識。但這樣的共識對客戶而言未必是那麼理所當然，尤其是對軟體開發毫無概念的客戶而言。

5. 展望: 如何精益求精

「在真理的高山上，攀爬總非徒勞； 
  今天若不能到達更高之處，
  就是在為明天的登頂
  訓練自己的力量。」 ── 尼采

到目前為止，這本書討論的都是如何以妳現有的能力，透過溝通、分工、互信、執行等不同層面的技巧，成功與案主合作，獲得自己效率和財務上最大的滿足。

但是「人無遠慮，必有近憂」；如果只關注實務層面的執行，而忽略長期的職涯規劃，進修方式，或如何更有效的取得資源，那麼往往容易陷入事業無法擴大的瓶頸，重複以相同的效率，做一樣的事情，賺一樣的錢：花兩個月完成一個十萬元的案子，第二次，第三次做同樣的事情還是花兩個月… 不但會很快失去學習新東西的新鮮感，也會很快被新的技術，趨勢或經營方式所淘汰。

這一章裡，讓我們退一步來看接案工作的發展，以回答「我如何做得更好？」這個問題。我們將從學習，投資，資源運用，後續發展各個面向分析目前的狀況，以作出持續性的個人發展規劃。如果妳想要長期經營自己的委外事業，這些課題就像不同角度的鏡子，能協助妳建立完整，全面的接案策略。

我們也會看到如何參與線上社群；除了拓展人際關係，取得技術資訊，更能用來建立信譽，讓自己的團隊能接到更大規模的案子。當然，自行籌組或加入定期聚會的工作組織（如藝立協）也是十分有效的辦法。

此外，雖然前面幾章的焦點都放在資訊專案規劃及執行，獨立接案者和工作室常常有別的收入來源，包含教育訓練，寫作，出版，軟體行銷等等。如果妳尚未跨足這些領域，可以藉由本章的介紹建立一個大致的概念。

5.1. 確立核心競爭力

自從網際網路的廣泛應用開始，資訊產業的遊戲規則已經歷經許多次的改變。今天無論是汽車，書藉，影片，軟體，都有許多網站提供消費者鉅細靡遺的比價資訊。無論案主本身從事哪一種行業，都面臨了跨國界的競爭局面。

電子商務的廣泛應用，使得效率及成本控制的壓力更加提昇，也創造了大量專業人士的委外需求；但是，接案者必需先具備比案主公司內部人員更強的專業能力纔行。

當然，資訊流通的便利也影響了委外市場。案主能取得的資訊越多，就越難被技術名詞或華而不實的宣傳騙倒。隨著專案委外經驗的增加，案主對於技術之外的能力（如團隊工作，溝通，策略提供）會更加看重，使得接案者必須發展多方面的核心競爭力。

好的接案者不僅要跟得上最先進的技術，也得具有商業，溝通，專案管理等方面的素養，纔能逐步為自己爭取優勢，而不至於一直做相同的低階工作。

如果妳之前沒有職涯規劃的經驗，可以試著將自己的接案能力想像成一個承包的軟體專案，利用相同的步驟進行加強：

分析現況

從自己的履歷表或報價單開始，逐項列出在技術，商業，溝通，管理等方面的經歷，所受的訓練，以及所能提供給案主的服務。這能讓妳從客戶的眼光來看自己。

列出需求

接下來，客觀的列出自己需要加強的部分。最有效的方式是直接詢問客戶或朋友的意見，看她們覺得與妳共事時有哪些不滿意的地方，或是未來會需要的能力。

規劃方案

列出現況和需求間的落差。依照優先順序排列，尋找提供相關訓練的資源。這份「進修方案」應該時常更新，作為評估是否接下專案的參考。如果某個案子價錢不特別高，又無法補足妳需要加強的經驗，就不用虛擲自己的時間了。

確立時程

再好的規劃如果不付諸執行，也祗是一紙空談。好的時程規劃會把工作和進修結合在一起。舉例而言: 如果想要拓展對各類資料庫的知識，手上又有相關的專案，妳可以強迫自己使用之前不熟悉的品牌（如 MySQL），讓學習和交案的動機彼此加強。

進行驗收

妳可以每個月花一天重複上列動作，對照上一次的現況，需求及方案，以更新自己的「功能列表」。

循著這樣的程序，無論是個人或團隊，都可以藉此分階段列出目標，定期加深、加廣所提供服務的廣度及深度。

接下來的兩節，我們順著分析、規劃、分項執行等順序，列出相關的技巧，以及應該注意的事項。

5.1.1. 分析技能及列出需求

接案者的職涯規劃是自己的責任；案主不會出錢請諮詢師幫妳提供建議。因此，想要確立核心競爭力的人必須以成熟、誠實、自覺的態度面對自己，以確定哪些是自己的優勢技能，哪些是亟須加強的項目。

客觀地評定自己並不容易，往往需要其她值得信任的人協助。不過，妳可以先問自己幾個問題：

* 在接案時，哪些事情最常為妳獲得良好結果?
* 接案時，妳最多的時間「卡」在哪裡?
* 妳覺得案主最看重哪些能力與技巧?
* 接案過程中，妳最喜歡做哪些事情? 最討厭做哪些事情?
* 妳覺得自己有哪些人格特質有所幫助? 哪些沒有幫助?

這些問題能協助我們把焦點放在過去的成功/失敗經驗上，讓接案者能比較清楚的列出自己的核心競爭力所在。舉例而言，妳也許喜歡進行系統疑難排解，卻討厭寫企劃書或討價還價；或者妳認為過去的案主看重面對面的溝通能力，自己卻難以忍受對一群人做簡報等等。

一旦將焦點轉向實際所需的技能（而不是自己個人的缺點），我們往往比較容易決定哪些具體項目需要加強。另外，以下這些方式也值得參考：

列出所有妳之前參與過的專案

無論案子大小或成功與否。仔細回想在執行的過程中，哪些技能或特質最常派上用場? 妳可以從成功的案例中發掘自己的長處，也可以從失敗的案子看到自己尚待加強之處。

想像自己典型的一天。

通常妳每天會遭遇哪些事情，有哪些狀況需要應付? 如果妳有寫工作日誌或日記的習慣，可以用它們作為藍本。詳細列出每種狀況需要的技能及特質，再對照目前自己的狀況。

回顧從接觸資訊業到現在的歷史。

問問自己曾經學過哪些技能，導致了自己價值或效率的提昇? 妳可以順著這個軌跡規劃下一步的目標，以及途中需要增強的項目。

每次分析結束後，應該寫出兩份依照技術，商業，溝通，管理等項目分類的清單：一份是目前具有的能力及優勢，另一份則是需要加強的部份。內容應該避免空洞的大字眼（如「良好的分析技巧」），盡可能詳細確實（如「能在談判後四小時內列出案主需要的項目」）。這份清單應該定期更新，以作為規劃進修方案的基準。

5.1.2. 規劃進修方案

對許多上班族而言，學習哪些新技能往往不是操之在己。公司政策、被交派的任務、所屬部門的方向等等，都直接影響上班族最迫切需要充實或練習的技能。

身為獨立接案者，需要面臨的問題恰好相反。「做自己想做的事」不僅是妳的自由，也讓規劃方向的責任落在自己身上。在妳循著上一節的方式列出了自己的優勢與待加強處之後，接下來要做的就是在妳的日常工作中找尋契合的部份。

技術，溝通及商業技能分成許多層面。舉例來說，開發動態網站需要的技術，和規劃進銷存管理系統就完全不同；說服路邊的雜貨店雇妳幫忙做網頁，跟與數千人的大公司談判需要的溝通技巧也不一樣。如果妳的客戶群大都是教育單位，需要的商業素養和專做法律顧問公司文件控管系統的接案者也差很多。

最有效的規劃方式，是詳細列出妳感興趣（不一定要有能力）的案件種類，再挑最符合自己發展需求的案子接。如果妳已經約好下個月要執行的案子牽涉到Palm平台開發，現在就自然有動機去學習相關的技術。同樣地，專挑大公司的案子進行接觸，也能有效激勵自己鍛鍊準備及執行簡報的能力。

此外，在跟任何客戶談判前，祗要時間許可，都應該上網瀏覽跟客戶本業相關的產業趨勢，專有名詞等等。如果該領域的知識和妳的進修興趣有關，就可以通過客戶介紹取得更詳盡的資源。

總之，進修方案和接案方向越相近越好。「從做中學」，掌握自己的發展方向，是獨立接案者比起上班族來最大的優勢；如果能在這方面充份發揮妳的規劃能力，訂出恰當的優先順序，妳的進步速度會遠遠超過在學校或公司環境裡的技術工作者。

5.1.3. 保持健康、發展興趣

雖然由案主出錢讓妳做自己喜歡的事相當不錯（要是妳討厭這一行，也不會成為獨立接案者了），但資訊業畢竟祗是世界的一小部份。機動的生活型態，讓許多接案者能夠發展多樣的興趣，而非受限於一成不變的工作當中。

對接案者來說，休閒活動和正業是互補的。資訊工作需要敏銳的心智、良好的溝通技巧，以及持續的注意力。保持自己的身心處於最佳狀況，往往比專業訓練更加重要；無論妳能力再強，如果大半的時間在生病或情緒不穩，祗怕也很難維繫長久的接案生活。

良好的運動習慣是一切的基礎。固定的時間和場地有助於調適日夜不分的工作週期，但也有許多人發現隨時可做的體操, 瑜珈等運動比較有效。據黑話檔案（Jargon File）所述，近十年來最受國外資訊工作者歡迎的運動是東方武術；舉凡太極拳、柔道、合氣道、空手道、跆拳道等等，被認為是「結合了能力本位的菁英主義，以及歡迎所有人加入的開放精神，和網路文化有相似之處」。

心理健康也很重要。長時間的壓力和注意力集中，容易激發躁鬱、憂鬱、注意力缺失（ADD） 、耽溺（addiction）等徵狀，影響與其她人的互動。除了向專業機構尋求正確的瞭解、診斷與輔導之外，舞蹈、音樂、雕塑、作畫、攝影等創造性的活動都會有直接的幫助。如果時間許可，非儀式性的宗教活動、冥想、心靈工作坊等等也是可行的選擇。

最後，休閒活動也可以是收入的來源：在妳持續發展某項興趣，累積足夠的經驗之後，往往可以將它轉成副業。這時，妳可以利用獨立接案所累積的溝通和行銷技巧找到買主、善用網路上既有的人脈聯絡同好，也可以向新領域的客戶提供資訊相關的諮詢和建議。

5.2. 如何有效的學習？

雖然以上講了許多結合進修和工作的方式，但事實上兩者往往不能兼得。除非妳擁有很強的溝通技能來說服客戶，大部份案主要的是接案者已經十分熟悉的技術，而不是出學費讓妳學新東西。

此外，接下自己不會的案子，藉著交案的壓力鼓勵自己學習的方式雖然有效，卻很辛苦。除非妳已累積了多年經驗，否則往往難以兼顧學習、案子的品質與時程控制。

因此，從短期進帳的角度來看，每花一小時在純粹個人進修上，就少了一小時的工作時數，也減少了從事休閒活動，紓解壓力的機會。這使得計劃無論擬得再好，在執行時都經常遭遇困難。

但正如之前提過的，如果不想被新的技術，趨勢或經營方式所淘汰的話，接案者必須突破執行上的困難。這裡提供一些可能的技巧：

將進修時間算進接案時數裡

許多接案者在訂價時依賴「行情」，當時的財務狀況，或靠工作時數來估計。除了第三章提到的要訣之外，妳也可以分析自己花在行銷，進修和市場調查的時間，估算出和工作時數的比例，再依比例算進妳的單位時薪裡。除了讓妳認清自己的時間運用之外，也能讓妳比較心安理得地花時間進修。

將社交與進修結合

藉著參與草根集會（如Linux User Group）、獨立工作者協會（如藝立協），或與朋友一起參加教學課程，妳可以在學習新知的同時建立同儕關係，也能增進學習的意願。

給自己實質的獎勵

如果妳相信自己新學的技能對客戶有幫助，妳可以在不危及合作的前提下給自己加薪。有些接案者會參考技術證照的行情，在自己的履歷表和報價單裡同時添上一筆。

當然，學習本身的樂趣是進修最終的驅動力。試著找出妳在怎樣的環境下最能享受獲得新知的快樂，纔能將學習變成自己接案生涯不可或缺的一部份。

5.2.1. 增進技術能力

在成為獨立接案者的初期，讓自己專精某個技術領域、一種語言或一套系統是首要之務。從自己比較習慣的類型開始，連續接幾個類似的案子，可以透過案子的磨鍊，讓自己對使用從熟習進而到專精。

隨著環境及市場的改變，專案需求會越來越多元化，以妳現有的技術與能力無法完全解決。面對這樣的情況，可以有兩種選擇，一是不接，二是把藉此將技術學起來。時常留心市場的實際需求，再配合自己的興趣，就可以大致決定技術學習的方向。

無論妳想學的領域是什麼，英文閱讀能力往往是第一要件。學英文就跟學程式語言一樣，大量閱讀別人的技術文件，多到討論群和IRC上參與討論，自然就會進步了。

學習新技術通常有幾種途徑：

技術及趨勢雜誌

閱讀國內的資訊專業雜誌，以及翻譯來的國際中文版，是瞭解其她人在做什麼的良好起點。雖然有些接案者輕視市面上大量的資訊界新聞及「軟體趨勢」雜誌，它們卻是案主比較可能看到的刊物，因此仍然值得稍微留意。不過，大部份領域的專業雜誌仍然沒有發行中文版。如果妳有信用卡的話，從網上訂閱雜誌其實相當容易；許多雜誌並不加收運費，有些還會免費讓妳試閱一段期間。另外，大學 或較具規模的圖書館也會有不少當期的期刊可供參考。

技術書藉

由於各種各樣的資訊教學書藉琳瑯滿目，妳可以定期逛書店加以比較；通常接案者最需要投資的是技術參考書，放在手邊隨時可以翻閱。同樣的，多看英文書能有效加速妳的學習能力。

研討會

微軟、Novell、Cisco、Sun、HP等公司都經常舉辦研討會、產品發表會、技術發表會等等。如果妳肯花些時間參加，認識這些公司的地區代表，常常可以拿到新技術的相關資訊和試用版。另外，「資訊月」等政府和民間辦的展覽會裡，也有不少演講會，可以視內容自己選擇。

網際網路

對許多接案者而言，網路是獲取資訊的主要管道。各項產品或技術的官方網站可以作為開始，而大部份的參考網站都可以在google.com或dmoz.org上找到。社群網站，BBS ，討論群等（見5.3節）都是常見的資訊來源。

團隊學習

如果妳是工作室的成員，或跟某家公司一起合作執行專案，最有效的方法之一是向彼此學習。試著說服團隊裡的成員互相傳授基本的專長；這樣不但能使團隊間的合作更順暢，也讓每個人都有機會練習彼此的表達技巧。

訓練課程

雖然大部份的時候，自己找資源進修要比上課有效，但如果以取得認證為目標、相關的案子需要有經驗的人（講師）幫忙評估，或是客戶的系統（如金融或特殊的硬體架構）妳不熟悉，也可以考慮參加補習班或廠商的訓練課程。

接案者最不想碰到的情況之一，就是對技術的暸解及不上案主，以至於無法提供令人滿意的規劃。相對而言，能善用先進的技術，為客戶規劃出切實可行的解決方案，應該是接案者最有成就感的時刻了。不斷吸收最新的知識，是維持自主權的基本要素，也是資訊業最具挑戰的特性。

5.2.2. 增進商業能力

許多接案者將自己的工作限制在「一手交錢、一手交貨」的範圍裡，祗對瞭解專案的技術需求、應用範圍感興趣。對她們而言，專案呈現的品質和功能是主要的訴求，而大部份的案主也祗要求這件事。

但是，如果妳能瞭解案主想要經由這個專案達成的目標，從提案到執行的各個階段都能提供策略上的建議，和客戶建立起長期夥伴關係的機會就大幅增加了。任何花在瞭解財務分析、市場趨勢、甚至心理諮商的時間，都能更增加客戶倚重妳的程度。在這方面，不妨儘量研讀跟客戶的領域有關的期刊、教科書和旁聽相關課程。

不過，被倚重是有代價的。接案者最重要的資產──專案形象和聲譽，是建立在互信之上，包括不洩露任何關於案主的財務、個人、或商業機密。很多接案者容易在閒談之間向客戶揭露其她案主的資訊，或是不小心說溜嘴；這會讓客戶對妳作為策略夥伴的信心大打折扣，從而降低日後合作的機會。她們會想：「如果這個人對我說其她客戶的消息，她會對別人說我什麼呢？」

大部份獨立接案者之前都在其她公司工作過，其中很多人曾經位居要職，知道許多公司的機密資訊。對案主的相同保密準則也應該適用於之前的雇主，也就是絕對不要說人壞話，或洩露外界不知道的「內幕消息」。這本書裡完全沒有出現作者所屬公司的業務、資訊，或舉實際的專案作為範例，就是基於這個原因。

當然，有時候談論其她客戶是無可避免的；在列出妳的經歷時，往往會提到之前為其她客戶做的專案。在這些情況下，最好的方式是事先詢問每個客戶，是否願意讓妳提到她們的公司名稱、專案性質，或是引用她們的評語作為宣傳。

最後，接案者經常會同時接到數家相互競爭公司的專案，或是在專案執行到一半時，纔發現跟其她專案有重疊之處。這個時候，為了保持對每個案主在商業上的互信，有幾個原則需要遵守：

做好萬全的準備

首先，在假設妳的客戶會彼此競爭的前提下工作。兩家原本毫不相干的公司，有時候會突然成為競爭對手，而資訊部門往往首當其衝。祗要有任何這樣的可能性，就應該坦白告訴雙方妳的狀況，以及預計的處理方式。

儘早告知案主

最好在一開始接觸時，就先告訴案主妳過去或現在正在接潛在競爭者的案子，但避免提到任何特定的細節。最晚，也應該在系統分析完成前就講清楚。

詢問案主的感覺

妳不但要知道案主在理性上的政策，也應該問她的「感覺」如何。大部份的案主不會介意接案者為競爭對手工作，甚至會因為妳的坦白而懷有好感。

將資訊分開處理

如果妳有能在兩個專案都適用的程式碼和發展工具，當然可以自由使用。可是所有的文件、備忘錄、電子郵件、企劃書都應該存放在不同的位置，在工作時也不該「參考」其她專案的資料。跟案主談論時，對於其她專案的進度、內容等細節都應該守口如瓶。

如果妳能做到這些事項，就會逐漸發現：「可信賴的策略顧問」的名聲，纔是提昇地位最有效的方式，也會使妳日後的談判事半功倍。

5.2.3. 增進溝通能力

直接有效的溝通，就是接案者的產品。如果妳無法向其她接案者、案主、軟硬體供應商傳達需求、能力、目標、開支、時程等訊息，無論其它方面的技術能力再強，也很難有令人滿意的專案。

除了第二章提到的溝通要訣之外，平時多注意「傾聽」是很重要的。這年頭，無數的資訊充斥我們的耳目；商業和個人生活的壓力往往使接案者應接不瑕，祗好把精力集中在必要的技術細節上。我們常常心不在焉，在聽別人話說到一半時，就不耐煩地等著接下一句。不幸的是，這使得我們往往難以瞭解問題的全貌就遽下判斷，或在重要的會議上失去對話的焦點。

從案主的角度來看，接案者能做的事祗有兩件：幫她們釐清問題、提供系統分析，以及實際將專案執行完成。如果案主不確定妳聽懂了她的需求，或提出的方案無法對症下藥，這個案子就算是完了。

有效的「傾聽」可以透過有意識的訓練，逐漸變成一項習慣。首先，妳必須全神貫注在對方的言語上，摒除腦中的雜念，細細咀嚼每一個句子。起初，妳會需要不斷提醒自己，但是隨著時間過去，妳的潛意識就會在適當的場合，自動切換進專注的聆聽模式。

一個有效的方法是「積極聆聽」，也就是試著從對方的角度，將妳所瞭解的狀況重複一次，請對方確認。這能讓雙方快速建立共識，減少誤解的機會。

傾聽祗構成溝通的一半而已。很多時候，並不是妳的理解能力不足或對方表達的不夠完善，而是對方根本沒有把問題想清楚。如果有白紙黑字在手，妳可以一再閱讀，試圖猜出作者真正的心意；但是在面對面交談時，常常沒有這個餘裕。這時，如何提出問題就很重要了。

發問是件藝術。如果對方認為已經解釋得很清楚，是妳沒有認真聽，甚至可能會對妳不爽。如果妳用「剛剛妳說…，可不可以給個具體的例子？」的形式開頭，對方的反應可能會好些。但無論如何，提出愚蠢的問題，總比之後突然冒出個言不對題的主意要好多了；發問時謹慎的措辭、誠懇的態度，都有助於增進雙方的溝通。

5.3. 社群與線上工會

網路不受地域限制的的即時溝通、知識累積、經驗傳承等特性，往往使人流連忘返、欲罷不能。雖然在2000年前後仍然有人預測「線上服務的蕭條」，但上線人口卻完全未曾減少，網路已正式成為妳我生活的一部份。

軟體，科學和文字工作者是最早發現「線上社群」的一群人。不像傳統的製造業倚賴工廠和固定的製程，獨立工作者的生產工具（個人電腦和軟體）是掌握在自己手上的。隨著網際網路的普及，「集思廣益」不再是一句空談；但是，要獲得其她人的支援，妳得先讓足夠多的「益友」認識妳纔行。

在這裡，所謂的「社群」指的並不是提供留言板、通訊錄、即時聊天和線上投票的網站，而是有相同工作領域或關心類似議題的人。各種社會議題、程式平台和工具在網路上都有屬於自己的社群，活動範圍也不限於單一的網站中。在台灣，為數眾多的BBS站（如cszone.twbbs.org、openbazaar.net）、IRC及討論群（Usenet、轉信板和mailing list等）是這些社群互動的主要管道。

當獨立工作者在學習新技術或專案發展過程中遇到難解的問題，而身邊又沒有可供諮詢的朋友時，社群的人力資源是妳可以尋求幫助的管道。妳可以在相關討論版上貼文章描述妳的問題，看是否有她人也曾有類似的經驗，並透過與其她人的討論找到可能的解決方法。 這一節裡，我們會討論常見的三種意見互動場所：開發者網路、討論群、以及實 體的草根集會。

5.3.1. 開發者網路

幾乎所有的開發工具、技術和套裝軟體都有自己的「官方網站」（Official Site），提供討論區或核心團隊的電子郵件位址，直接與使用者互動。有誰會比原作者更瞭解她所推出的東西呢？妳所需要的，只是一點發問的勇氣加上些許的英文能力，寫封電子郵件或是貼篇文章即可。

大型的技術提供者，有時會建立所謂的「開發者網路」（Developer's Network）。除了開放原始碼的OSDN和微軟的MSDN之外，Netscape、Apple、Cisco等廠商也都提供開發者與核心團隊對話，取得最新資訊和技術白皮書的服務。另外，如w3c.org、IETF.org等制訂標準的單位也提供類似的加盟方案.

當然，這類服務很少是免費的。不過祗要妳有足夠的英文能力，又能獨立判斷、不會受過度樂觀的新聞稿影響，那麼加入開發者網路倒是節省時間的好辦法，比閱讀討論群裡的大量雜訊要有效率。

取得開發者網路的會員資格後，可別滿足於定期收到光碟和雜誌而已！妳可以主動挑選會員通訊上妳感興趣的文章，直接寫信與作者討論，或詢問進一步的資訊。同樣地，當妳在接案時有個新的主意或應用方式，也應該積極分享自己的技巧，甚至參與下個版本的部份研發，讓自己能預先掌握關鍵的技術.

就像最先進的技術不見得能滿足客戶的需求一樣，單一平台也未必能契合所有的專案。同時參加許多不同的開發者網路，聽聽競爭雙方的說法，纔是不讓自己淪為「無條件推銷員」的妥善策略。

5.3.2. 善用BBS與討論群

連線討論群（Usenet）、BBS和電子報（Mailing list）等公開的通訊型式，是知識工作者間最方便的討論管道，也是讓新手能花些時間「進入狀況」的主要方式。除了BBS的精華區和電子報的討論紀錄（archive）之外，groups.google.com更是浩如煙海、無所不包的知識庫，在提出任何疑難雜症之前都應該先在裡面找找看。

以討論為主，彼此不轉信的「社群網站」（如LinuxFab、Slashdot、Advogato、Kuro5hin、Perlmonks）比較注重自己獨特的風格，也是討論群的一種，比較適合認同特定文化的支持者彼此交流。

無論溝通的型式如何，貼文章、回答問題，引介資源是建立可信度的唯一方式。在知識社群的「餽贈經濟」（Gift economy）文化裡，一個人的地位不是看她擁有多少，而是建立在妳給出多少。一篇夠份量的文章或回答會在許多地方引起注意， 領域內相關的人也都看得見妳的專業程度.

社群裡的互動，通常全憑文字印象決定對她人的評價，跟說話沒什麼差別。盡量言之有物（如果沒有什麼好講的, 起碼可以幽自己一默）、注意用句遣詞，不要進行人身攻擊。與人討論交流意見的時候，語氣太驕傲，說得斬釘截鐵偏偏內容錯誤，就很容易引起她人的不快；陷入無止境的舌戰（Flame war）就更是浪費力氣了。

雖然「熱情和分享」令人高興，但是要怎樣將討論群轉化成接案和進修的資源呢？這裡是一些具體的建議：

建立點對點關係

人數眾多的討論群是徵求意見的好地方，不過也經常充斥雜訊。想要建立長期的友誼，主動利用電子郵件、電話或即時傳訊軟體聯絡仍然是比較好的辦法。隨著妳在討論群中的付出，妳應該可以逐漸結識彼此信得過的朋友，可以一起計劃手上的專案，而不僅是討論一般的技術問題。

主動幫助別人

不要吝於分享妳的經驗。在回答問題的時候儘量提供實例，而非武斷地表示「這樣做一定比較好」，纔能獲得其她人的信任。另外，撥些時間為社群從事資料整理、翻譯或版主的工作，也能為自己的接案事業提高能見度。

實事求是

高談闊論雖然有趣，對鍛鍊自己的判斷力和技術能力卻未必有好處。BBS和討論群的參與者，往往容易陷入空想式的爭辯，或花大量時間追逐一時流行的議題。要讓自己免於虛擲精力，最好的方式就是專注在瞭解實際的細節上，而不是人云亦云、讓一時的激情主宰妳的發言。

5.3.3. 草根集會與組織

隨著各地資訊社團活動、LUG（Linux使用者集會）和不定期「站聚」、「版聚」的興起，地區性的資訊相關活動有逐漸增多的趨勢。祗要定期在各大BBS和討論群逛逛，總可以看到這類聚會的訊息.

相較於歐洲和印度，美國和台灣的跨公司工會向來不太盛行，使得獨立工作者比較難取得討論和進修的資源。不過相對於以爭取權益為主的工會，美國近來蓬勃發展的「公會」（guild）組織也許可供參考。大部份的公會祗有一個簡單的網頁，列出下次聚會的時間地點、討論的題目、以及可能邀請的演講人。

這些公會大多以介紹工作、彼此支援專案、分享經驗為主，注重相互聯絡而非集體行動。除了每個月或雙週的定期集會之外，有時也出版電子報、簡訊或籌備進修課程；好比說妳手上的這本書，就是自2000年中以來，藝立協的成員每週聚會的討論成果。

作為獨立接案者，結合三兩好友舉辦這樣的集會是有趣的經驗。成本其實很低：先聯絡好寬敞的簡餐店（漫畫王包廂、學校社團也不錯），準備妳熟悉的討論題目，提早兩個星期在常去的討論版上貼出啟示，到時候準時出現就行了。一開始的幾場聚會不用安排太多節目，可以採取讀書會的型式、邀請每個人帶幾本書來分享，或討論比較切身的時事。作為主辦者，最好做一份簽到簿或通訊錄，方便與會者保持連絡。

在私下聚會幾次之後，會逐漸有其她組織或集會的參與者出現，此時便可以考慮結合雙方的資源，形成較具規模的地區性公會。這當然不可能一蹴而及，但卻是發展動能和能見度的好方法。

5.4. 開放原始碼文化

近年來隨著 Linux 的普及，「自由軟體」及「開放原始碼」逐漸取得業界的重視。不但 Apple、Sun、IBM、SGI等大廠紛紛將常用開發工具的原始碼釋出，Apache，MySQL/PosgreSQL，Perl/PythonPHP/Ruby等也快速成為網路解決方案的常見工具。

但是真正驅動開放原始碼品質的，是背後蓬勃發展的互助文化。開放原始碼背後的精神很簡單：如果妳能激發網路上的同好對妳手上的專案產生興趣，彼此閱讀、重新傳播、修改軟體程式碼的話，可以加速許多改良、調校、除錯的過程。

對一個接案者而言，可以分三個階段來利用開放原始碼的優勢：採用既有套件、參與套件研發，與主持新的計劃。

5.4.1. 採用既有套件

最直接容易的，是使用發展完善的套件及平台做為解決方案的基礎。這樣不僅能避免自己從頭開發或購買套件的成本，也能減低除錯及測試的壓力。

大部份的開放原始碼套件，都是以C/C++、Perl、Python或Java寫成的。妳至少要熟悉其中一種語言，纔能快速評估哪些套件符合自己的需求。當然，良好的英文閱讀能力也是不可或缺的。

在跟客戶溝通專案的哪些部份能採用開放原始碼套件時。不要強迫案主改變原來的系統，或恣意批評既有的產品；很少人能接受直接從NT/IIS/MSSQL換成Linux/Apache/MySQL。儘量公平地向案主呈現開放原始碼套件的好處，把能更換的環節換掉就可以了。

大部份的套件都有自己的討論群、IRC、或作者的電子郵件帳號。在確定手上的案子要用到哪些套件後，可以試著用英文描述自己專案的性質和初步規劃，寄到相關的討論區徵求意見；這樣不但可以認識曾經使用該套件進行過類似專案的人，在出狀況時也知道找誰幫忙。

5.4.2. 參與套件研發

經過數次專案經驗的累積，當妳對某些套件或語言相當熟悉時，可以考慮投資一些時間，訂閱該套件的開發者電子報，以關注最新的發展。幾乎所有持續開發中的套件都亟需測試人手：下載最新版，積極回報臭蟲是比較容易開始的一步。

在開發過程中，妳也許會修改某個套件的功能，移植到不同的系統（特別是 Windows 平台），將訊息中文化，或做其她的改進。此時如果能簡略描述自己所做的修正，用e-mail寄給原作者或團隊，往往可以將妳設計的功能整合進下一版裡。

如果妳經常使用Linux、BSD等作業系統，另外一個可能的做法，是將日常專案中會安裝或移植的套件包裝（package）成RPM、Debian、Ports 等格式，再聯絡相關類別的管理人，幫助妳上載傳播給其她人使用。Perl的CPAN也提供類似的機制。

積極參與現有的計劃至少有以下幾個好處:

個人進修

無論是作業系統，語言或應用程式，開發者本身總是最熟悉內部功能的人。藉著參與套件的測試，移植，文件撰寫及研發，妳可以獲取第一手的經驗，提昇自己的專業技能。

預見趨勢

接案者對案主最有價值之處，往往不止是完成手上的專案，而是在系統分析時能夠提出比較先進的建議，主動設計切合趨勢的解決方案。與其靠廠商的新聞稿和技術白皮書等二手資訊進行規劃，親自參與下一版的研發更能讓妳知道接下來會發生哪些事情。

提高名聲

如果一份「IIS 應用認證」能證明妳的能力，那列名在「Apache 作者名錄」裡更能讓案主確認妳的專業。這也使妳更有資格從事演講、訓練、寫作等活動，拓展妳的行銷範圍。

每天規劃出幾十分鐘參與常用套件的開發，可以看作是個人進修的投資。以技術能力而言，這是建立自己獨特競爭力最有效的方式。畢竟，雖然任何人都可以上課學習如何使用開發工具，但是參與這些工具本身的研發，卻是極少數人纔有的地位。

5.4.3. 主持新的計劃

當妳接了不少案子後，可能會累積一些自己的「私房工具」，或突然想到某個從來沒人想過的點子，能夠加強或取代市場上的其她軟體。

身為獨立接案者，開放原始碼是取得注意力的好方法。如果妳的技術能像 Linux、MySQL、Zope 一樣被數以萬計的人使用，不但可以拓展維修、訓練、定製等收入來源，也能號召其她人幫妳測試，移植和撰寫文件。

但是，且慢。主持開放原始碼計劃，並不是到sourceforge.net上註冊一個專案就可以了。許多計劃花了作者大量時間維護，卻一直無人聞問；更多的專案在第一個版本釋出後就無聲無息了。在對外發佈一個新計劃前，妳可以先問問自己這些問題：

有沒有已經存在，持續開發中的專案有類似的功能？

修改或加入既有專案的開發，通常比「重新發明輪子」有效。妳可以先聯絡作者，討論可以一起加強的部份。

套件的應用足夠廣泛嗎？

成功的開放原始碼專案，大都從複製市場上廣泛應用的工具軟體開始。如果祗能給少數人使用，或是功能難以讓人擴充，通常很難造成其她人的興趣。

說明文件足夠完整嗎？

一份完整釋出的套件，至少要準備功能描述、安裝說明、使用說明、授權條款等幾項文件。程式碼裡的註解也應該盡量詳細。

妳撥得出時間回答其她人的問題嗎？

維護專案是很花時間的！應付需求，解決疑難雜症，收集測試報告可能會佔用妳相當多的力氣，甚至影響妳的接案工作。除非妳平時就以相關的訓練或諮詢為業，否則請慎重考慮時間上的負擔。

主持開放原始碼計劃，跟寫共享軟體（見5.6.1 節）相當不同；妳需要先具備大量參與既有專案的經驗，也得先有令開發者（而非使用者）感興趣的半成品出現。如果掌握得當，除了拓展人脈、作為市場調查和行銷工具之外，也能鍛鍊妳的領導、協調及軟體工程能力。

5.5. 接案以外的工作

接案者最常碰到的問題，是不穩定的「淡季」與「旺季」。有時候案子會突然多到接不完，不得不拒絕或轉介給別人做，有時又連續數個月沒有確定的進帳。不幸的是，案子不會等人，旺季做不完的專案無法存起來等淡季再做。

因此，大部份有經驗的接案者都會開拓其她的收入來源。如果經營得當，妳可以靠著寫作或發行共享軟體等方式，在不工作的時段也有穩定的收入來源。

除了平衡收支之外，經營副業還有以下幾個好處：

建立名聲及信譽

一般在接案時，通常是妳跟客戶的一對一關係。不論專案執行的再成功，真正知道的也祗有客戶和妳自己。與此相反，一篇精彩的文章或演講往往能讓許多可能的客戶對妳留下印象，讓妳能快速建立口碑。

拓展行銷範圍

如果妳能把之前專案裡設計的軟體系統獨立出來成為軟體套件，公開讓人下載試用，那麼相關的諮詢，訓練，轉售機會可能比原先的專案還要有利可圖。相同的，總結之前的接案經驗累積成書或專欄稿，也能有效增加妳的客戶群。

充實多方面技能

專注在程式設計和硬體規劃訓練的接案者裡，有不少人為溝通能力或文件撰寫能力不足所苦。定期寫作、演講或從事教育訓練能讓妳逐漸掌握這方面的技巧。

一般而論，常見的副業不外演講、訓練、寫作、軟體出版等四種；和培養專業能力不太相關的兼職（如翻譯，打字）不在此處討論之列。

5.5.1. 演講及研討會

1990年代中期，加拿大的獨立接案者Peter Dejager提出了「千禧蟲」（Y2K bug）的議題，很快建立了在這個領域的權威地位。她運用了獨立接案者的長處──思考和分析，獨力將Y2K塑造成全球性的話題。靠著不斷蒐集相關的資訊，獲得全球各地的邀約，成功地塑造了自己的演講事業。

另外，像瑞士的獨立接案者Kent Beck在1999年炒熱的極端程式設計法（Extreme Programming），便是提煉自己的接案經驗廣為發表的結果。首先提出開放原始碼（Open Source）口號的Eric Raymond，也是長於利用演講和研討會的資深獨立接案者。

在臺灣，幾乎每天都有資訊相關的研討會、座談會或課程。學校、民間團體和私人機構都會定期公告活動日期，及公開邀集提案（Call for proposal）的時程。妳可以事先準備好自己所能做的簡報內容，定期觀察網路上的徵稿訊息，再投稿到所有相關的研討會上。

趨勢和技術，是大部份研討會的主軸；如果有專案執行的成功經驗為後盾，就會更受歡迎。如果妳平時在執行專案時，有系統地畫出系統架構或技術藍圖，就可以將它們轉成研討會所用的簡報，以備投稿。

公開進行演講或簡報，對很多人而言是件困難的事。事實上，不少成功的演講者在上台前，仍然會緊張、流汗、臉色發白。要訣是：學著在上台時保持微笑，用正常的語調講出第一句話。通常當妳的注意力開始放在講題上時，焦慮就會逐漸消失。

熟練演講的技能，對平時做簡報和談判也大有幫助。這裡提供幾個技巧，能讓妳調整心情，獨力面對站上講台、面對眾人的壓力：

參加座談會以累積經驗

在研討會上，有時候會安排三到五席共同討論某個主題。這樣的安排對新手而言，通常比較容易放鬆。

事先準備好開場白

練習好一段能讓妳帶入正題的開場白。它可以是一段笑話、最近的親身經歷、相關的時事等等。一旦與聽眾建立了默契，場面就比較容易控制了。

使用輔助器具

利用投影片、單槍投影機、講義、海報或白板，將聽眾的焦點從妳身上轉移到事先整理好的內容要點上。

知道自己在講什麼

最重要的，是選擇一個自己真正熟悉、關心的主題。這不僅能幫助妳克服自己的恐懼，也能使聽眾感受到妳的專業和熱情，也使妳能迅速正確的回答她們的問題。

5.5.2. 主持訓練課程

主持訓練課程的身分可以分為兩種：講師和顧問。

講師通常在電腦訓練班、補習班進行教學，或在「企業包班」的情況下對同一個公司的職員進行在職訓練。這一類的需求目前很高，大部份的資訊訓練中心也都有相關的師資培訓課程。由於各個分點多半自行管理師資，妳可以自己準備相關的作品或證照，向離住處近的分部詢問。

跟學生取得良好關係，對接案者有很大的幫助。學員不但有可能成為妳的工作夥伴或客戶，也可以幫妳打廣告、證明妳的技術能力。但是技術能力高下，跟帶領一堂成功的班級並不相同；更重要的，是如何創造學生製作自己作品的成就感，以及評估學生理解程度的技巧。接案者自己的親身經歷，如果能和學生的工作經驗結合，通常也能加深班級的認同感。

在透過演講和教學累積了一定的知名度之後，就可能會有軟體公司邀請妳當顧問。這通常是對方有專案正在進行，但是欠缺某些關鍵領域的技術或規劃能力。這一類的工作所需的時間比接案要短，報酬卻不少，因此成為許多資深接案者很重要的收入來源。

相對的，從事顧問工作也需要快速的反應力、對技術的自信，以及絕對的誠實。賣弄專業術語或影響既有團隊的程序是大忌──妳自己在接案時，也不會喜歡案主找個顧問來祗批評不做事吧！因此，最好的策略是跟專案經理站在同一邊，主動幫忙蒐集相關的資料，但是絕不干涉她所做的決定。

最後要記得的是，無論是作講師或顧問，自大、傲慢、技術優越感是絕對要不得的。雖然在接專案時也許有必要稍微吹噓自己的經歷，這樣做卻會破壞教學關係中不可或缺的信任感。

5.5.3. 寫作及出版

寫作及出版所提供的益處，和演講相當類似。寫書比演講更有利的地方，是祗要銷路不壞，就能大幅提昇妳的專業形象和知名度。大部份的接案者，都是從為雜誌寫評論稿、技術介紹及專欄開始，慢慢拓展自己的寫作領域。

許多線上雜誌、電子報都對稿件的需求量都很大，也是接案者練習寫作的良好出發點。事實上，這些線上的出版品很多是免費訂閱，以廣告或作為商品的宣傳工具。妳也可以有樣學樣，建立具專業色彩的個人網站和電子報，在上面登自己寫的文章和近日動態。BBS站的「個人版」也能達到類似的效果。

不過，雖然許多人已經習慣從網路上取得資訊，妳的潛在客戶中仍然有不少人習慣讀白紙黑字。數千種的大小報紙、通訊仍然存在，也不會輕易消失。因此，如果妳從個人電子報上剪輯重要的資訊和評論，印成A4大小的傳單，寄給有過聯絡的公司，往往會發揮意想不到的效果──要知道，往往職位愈高的人，就愈習慣看紙張而不是螢幕。

妳可以祗為賺錢而寫作，也可以同時考慮行銷。即使是最知名的作家，偶爾也會為了取得特別重要的版面而答應免費寫稿。有些知名的線上雜誌或學術期刊根本不給稿費。在選擇投稿對象時，不祗要考慮一個字幾塊錢，更重要的是它的讀者群對妳的意義。事實上，妳甚至可以考慮祗為自己辦的宣傳通訊寫作，或要求投稿的出版社尊重妳在網路上的發行權；很多出版社會同意這樣的要求。

大部份人辦的簡訊、電子報和自我推銷沒什麼兩樣，內容多半是接案者自己的經歷、能力、感興趣的事情，而不是針對讀者而寫。但是，最有效的方式往往剛好相反，是以「服務導向」的方式提供對讀者切實可用的技術及趨勢，不論對作者自己的價值如何。這樣不但容易撰寫，對讀者而言也比較有價值。

要準備一份服務導向的電子報或簡訊，可以循著以下的步驟進行：

• 告訴妳的客戶妳在準備這份簡訊，問問她們想看什麼。如果她們想知道XSLT和JXTA技術的發展，就不用計劃寫資料庫的主題了。可能的話，瞭解她們手上有沒有任何需要解決的問題，以及會用到的技術是哪些。

• 考慮妳自己能不能解決這方面的問題。如果行的話，寫篇兩千字左右的文章詳細進行討論。如果寫作有困難，可以試試筆者常用的「高行健方法」──先對著錄音程式講一次，再播出來整理成稿件。

• 到google.com、ask.com、webtechniques.com等網站搜尋相關的背景資料，以及其她人的解決方式。找出兩三份短篇稿件，再寫e-mail問作者能不能轉寄這些文章給妳的客戶；大部份的作者會同意。

• 寫一篇引言，陳述這個問題或趨勢的內容，對這些提供解決方案的文章作簡短的介紹。最好能將不同讀者的名字加在簡訊前面，而不是清一色「親愛的客戶您好」。

• 用電子郵件、網頁、實體郵件三種方式寄出去。等兩三月，再發下一期。

這樣的簡訊，不但能建立起妳的專業形象，也能讓妳有效瞭解客戶下一步會有哪些需求。如果妳祗靠被動接案維生，寫作和出版是爭取主動性的最佳方式。

5.5.4. 軟體包裝及行銷

接案者最穩定的收入來源，通常是為願意出錢的公司或團體寫出符合需求的專案。不過，看到自己寫的軟體被許多人廣為使用的成就感，往往要強得多。除了成就感之外，如果還能作為輔助的收入來源，那就更妙了。

但是，因為撰寫軟體的成本不高、競爭劇烈，再加上有大量功能很強的免費軟體，賣軟體給一般使用者並不容易；一般常用的文字編輯器、瀏覽器、讀信程式、音樂播放軟體等等，市場都已經差不多飽和了。因此除了遊戲之外，大部份能賣錢的軟體都是建立在新的平台上。個人電腦的行程管理系統也許已經飽和了，但是手機、資訊家電和掌上型電腦也許還有可乘之機。

想賣軟體的獨立工作者，一般都以「共享軟體」方式行銷。除了相當無效的「30天試用」方式之外，通常的做法是開發一個免費版本（甚至連原始程式碼一併公開），再同時賣出「加強版」或其她的延伸套件。早期採用這個模式的Real Player和Netscape Navigator就獲致了短時間的成功。

還有一個方式是在妳的軟體上提供廣告空間，出售給廣告商使用；這個策略很多人採行，卻祗有極少數真正賺到錢。此外，也有接受使用者捐助，到達一個定額就推出新版的模式。

如果想要以共享軟體方式行銷，最容易的是使用Yahoo Shop、Paypal、Pilotgear、Kagi或其她的小額付費平台。妳祗要把定價和程式交給她們，這些廠商就會抽一定的比例，幫妳處理掉信用卡認證等等繁瑣的過程。

一旦付費的方式確定，接下來就是散布消息了。因為一般賣給終端使用者的軟體壽命都很短，最好儘速讓她出現在雜誌或軟體網站的報導上。有時候自己寫報導投稿到知名的線上刊物，也能達到相同的效果。

身為接案者，我們對於「軟體是服務業，不是製造業」這回事的體認特別深刻。給末端使用者的軟體通常祗是妳的行銷工具，而不是主要的收入來源。一旦妳的共享軟體開始收不到錢，就是停止花力氣在行銷上，回到接案生涯的時候了。當然，妳也可以將原始碼開放，將它作為開放原始碼專案經營（見5.4.3節）。

5.6. 其她生涯規劃的選擇

如果妳問獨立接案者「妳打算這樣過一輩子嗎？」，不少人大概會回答「一輩子？太遠了吧，想都沒想過。」確實，相較於傳統職場的長期生涯規劃，接案者往往更注重眼前的選擇，以及彈性的工作環境.

這也就是說，「獨立」纔是我們看重的價值，「接案」祗是達到獨立的一種方式。正因為未來的發展掌握在自己手上，獨立接案者的選擇比其她人多了不少，也更能保持開放的興趣、靈活運用外在的資源。

對於能善用組織文化的接案者而言，公司是不錯的外在資源。無論是策略性地進 入公司任職，或是自己經營事業，都是增進團隊工作能力的好方法。這一節的最後，我們還會討論其她適於獨立接案的行業；它們可以作為副業，也可以在妳對資訊工作暫時失去興趣時，作為可能的轉職選擇。

5.6.1. 策略性就職

在開始獨立工作前，許多接案者往往已累積了三四年的職場經驗。不可諱言的，利用公司的環境與提供的豐富資源學習，有時會比自己摸索來得容易。

一般獨立工作者的接案規模較小，容易侷限於較熟悉的少數領域。而廠商在找大規模專案的合作伙伴時，也傾向找大規模的團隊。如果妳想學習團隊開發、系統 分析、系統與專案管理的能力，到一間稍具規模的公司可能是不錯的選擇。

受我們訪問的獨立接案者，大都建議以新公司為優先考量，避免去官僚氣味濃的大公司。新公司比較容易倚重有能力的接案者，可以學到的新東西也比較多，而未來的發展性如何，就得靠自己評估了。

在公司任職的期間，可以盡量參與大型整合專案，藉由專案管理與系統分析的需求，鍛鍊個人工作室較少學到的軟體工程與溝通能力。這些能力可以讓妳在建立自己的小型工作團隊時如虎添翼，未來的工作內容也可以不只局限在程式設計領域，而能往系統分析師或專案經理人發展。

要記住的是，就職是「策略性」的：目的是領公司的錢，針對自己不足之處接受訓練（當然，也得以產出作為回報）。因此，請儘量不要浪費時間在辦公室裡無意義的勾心鬥角，或為了昇遷勉強自己做重複性的苦工。

另外，保持對產業動向，技術和既有客戶的關注也是很重要的。不要讓自己的視野受公司定位的侷限，而應該隨時鍛鍊自己作為獨立工件者的條件。否則的話，在一兩年的職場生涯後，說不定就會發現自己失去獨立接案的能力了。

5.6.2. 自行創業

獨立接案者最常見的工作型態，不外乎自己單打獨鬥，必要時再轉包給其她人， 或是三五好友各有專精，合力以工作室的招牌對外接案。這兩種方式雖然很有彈性，卻往往受到參與者的時間限制，不太能擴展營運範圍。如果沒有明文規範各人的權責，也容易使工作伙伴之間出現摩擦。

在成立工作室或獨立接案一段時間之後，往往會發現需要額外的行銷、包裝、會計、文件撰寫等人力，或是研發出了應用範圍廣泛的技術（也可以代理別人的），值得作為產品來推廣。這個時候，成立一間公司可能是有利的選擇。當然，如果經營順利，對妳的履歷表也有幫助。

剛開始，有合作經驗豐富、彼此處得來的團隊十分重要。妳需要確實知道自己的長處和短處，找到互補的合作伙伴。妳們需要協議清楚公司的名稱、營業範圍及地點、各成員扮演的角色和職稱、每個人的出資額度、薪資和分紅、定期集會時間、各人的權限、誰當負責人，以及如何退出。一開始定得愈清楚，日後就愈不容易出狀況。

接下來，最關鍵的決定是：要自己集資，還是主動尋找投資者呢？

一般而言，除非握有關鍵性的領先產品、需要大量的後勤和行銷支援，否則資訊公司在草創時期的開支並不大；除了員工的薪水外，辦公室租金和網路連線費用完全可以控制在每個月數萬元之內。所以，在尋找金主前，最好先確定自己真的有此需要，也能提出足以服人的營運規劃。

話雖如此，如果團隊經營的業務對出資者的本業有所幫助，或能藉由股東既有的通路來放大效果，接受資金挹注倒也不是壞事。如何讓董事會成為助力而非發展上的阻礙，是工作團隊需要謹慎判斷的課題。

至於如何規劃人力、設定目標、激勵士氣等等，坊間已有許多經營管理方面的書藉可供參考，在此不加贅述。重要的是，如何讓自己的公司成為妳獨立接案生活的延伸，而不是陷入「為別人決定事務」的管理迷陣當中。

5.6.3. 兼職與轉業

對獨立接案者來說，從事許多不同的工作總是常態。就像我們在5.5節討論過的，演講、寫作、軟體行銷等互補的副業，經常是接案生活中不可或缺的部份。

除了資訊相關的副業外，許多接案者也善於將其她方面的興趣轉成收入來源。一般而言，祗要生產工具和經銷管道掌握在自己手上，都可以維持原本接案的生活型態，和軟體工作達到相輔相成的效果。像文字創作、翻譯、音樂、多媒體製作、 視覺設計、心理諮商等工作，都用得上獨立接案所鍛鍊的溝通與行銷技巧。

教學是另外一個常見的生涯發展。累積了多年的實地經驗後，獨立接案者往往對新的技術或潮流特別敏銳，甚至能提出獨到的見解、自成一家之言。因此，無論是開設自己的教學機構，或加入既有的大學系所、研究單位，都是資深接案者可以認真考慮的出路。

在後工業時代裡，長久而穩定的工作逐漸消失；想要獲得令自己滿意的工作和生活，端靠個人的獨立及團隊作業能力、專業素養、信譽和原創力。祗要能認真經營，獨立接案是提昇自己價值最有效的方式，也是社會向「知識經濟」範型轉移（paradigm shift）的前驅。雖然接案也許祗是短期的選擇，但是由此而生的獨立判斷、自我管理、溝通談判等能力，對妳日後從事的任何事業，都會是十分寶貴的資財。

結語: 這本書如何誕生的

寫這本書的想法是從一場又一場喝咖啡、吃晚餐的聚會聊出來的。

與業界朋友多次接觸的過程中，我們發現，臺灣的資訊業界一直有著委外服務的需求。這些工作並不需要長期的合作對象，可能只是暫時的專案開發或是一些簡單的程式撰寫。與其找有規模的公司合作，小型工作室或個人獨立工作者更符合業者的需求。

然而，獨立工作者這種隨著電腦跟網路普及方逐漸被認可的職業與工作模式卻一直不太為人重視。市面上可能會有不少談論上班族的書，供初進入社會的新鮮人做為參考；告訴我們基本的辦公室守則、如何與同事相處、為公司創造客戶建立形象等。卻鮮少有書專門討論與獨立工作者相關的各種事情，使得想以獨立工作者為業的人，常面臨找不到參考資料的窘境。

在與獨立工作者朋友聊這些話題的時候，每個人對於獨立工作者之路，都有自己的一套經驗談。怎麼入門、可能遇到的問題、該注意哪些小地方等各式除非親身經歷，否則難以想像的情形。於是我們想，這些東西，要如何讓其她也想從事獨立工作者的人知道呢？

寫書的想法由此而生。然而，專案委外這件事不只包含一個層面，有發案廠商、接案團體／個人，及中間的流程控管、法律程序等。每個層面都是不同的專業領域，並不是一個人坐在書桌前想想就可以寫出來的。因此，這本書決定以多人合作的方式撰寫，每個人挑選自己專長的範圍，最後集結成冊。

從年初到現在，我們藉由各種不同管道告知她人出版這樣一本書的計畫，希望有興趣的人可以提供意見或參與書寫。另外，也訪問不少獨立工作者，透過訪問蒐集、分析每個人的經驗，找出各種應該包含在書中的內容。然後，整理條列出來的內容，設計書的章節編排，決定要從哪些地方尋找相關資料，請什麼樣的人一起合作。最後，完成了妳手上的這本書。

說到找人，我們的確拉了一堆千奇百怪的人參與：接案賺零用錢的學生、任職於軟體公司的程式設計師／專案管理員、從事委外仲介的朋友，還有遠在美國渡假的律師。

妳或許會好奇的是，這些平日工作地點與物理存在互異的人是怎麼把書寫出來的呢？嗯，這就不得不歸功於便利的網路了。雖說想法是從喝咖啡吃晚餐聊出來的，然而，書的實體架構與內容卻是大家在網路上彼此丟水球死命貼文章討論而成的結果。這種線上合作的工作模式，事實上就是獨立工作者生活常態的一部份。

如果妳對加入獨立工作者行列有興趣，希望這是一本真正對妳有幫助的書。

有任何建議與問題，歡迎透過電子郵件 contact@elixus.org 與我們討論，或到 telnet://bbs.elixus.org 的 Project／WorkShop 板參與後續的活動。

Happy hacking！

藝立協簡介

如果你問，網路時代的特色是什麼？我想，非常明顯的，就是資訊透過網路這樣的技術，達成之間緊密的連結、並且藉由非常低的複製成本、和極快傳播速度來流通。藝立協思考的是，如何在網際網路時代中，將資訊之間高度互動的特色，對應回真實世界的人際關係裡。

目前臺灣的資訊業界，缺乏良好的溝通、分工、與認證的機制。導致你我的生產力無法有效的發揮，專案的需求無法依每個人不同的專長作最佳的分配，因而整體競爭力無法提昇。許多受僱傭的資訊從業人員，或許因為專案各方面的決策未必完全由自己掌握，或許因為不同的組織之間沒有公開的作資訊交換，使得許多其他的團隊也在進行跟自己一樣的軟體研發卻不自知（我們稱之為：「做重工」），因此消耗大量的時間與精力，卻做了徒勞無功的開發。

網路熱潮時出來創業的公司何其多，這些公司很多技術軟體都得重新打造，明明都是關注在一樣的主題上面，大家的程度也都很優異，只是專長的地方各不相同。結果今天同樣的一個技術，同樣的開發工作每一家公司要重複做好幾次。做出來了又要互相廝殺，大家打得頭破血流，弄到最後不歡而散，倒的倒，被併購也人去樓空。生產力不能被有效的放在自己最專長的項目上面，沒有人想過把專長的技術公開出來搶得市場先機，沒有人想過要彼此之間好好談談。埋頭苦幹的最後結果就是被一家又一家資金雄厚人手充足的大公司壓輾過去。

或者我們看看其他的情況：企業或許會想要把某項專案的技術或開發過程的人員訓練留在公司內，而自行組織開發團隊，但是這樣的代價往往過於高昂；若以委外方式解決企業需求，卻也往往難以保證外包開發團隊的品質與效率，也擔心機密被外人得知，喪失先機。以事務流程軟體來看好了，一個案子從開始到完成的流程的大架構也就那幾種，其他細節都是為了特定的公司需求去做特製化的。你有多少的細節會真正的影響了一個企業的生存獲利呢？於是在企業 e化發案的時候東藏一點，西漏一點。結果做出來的東西完全不合用，到最後還要東修西補，效率極差又不符成本，鬧得跟委外人員不歡而散。

以上這些，幾乎都可以歸因於人和人之間溝通不良，專案和專案之間沒有有效的連結。甚至說穿了，就是彼此之間不信任，業界沒有一個貼身合用又富有彈性的分工機制把我們串在一起。這些東西並不光是有開放原始碼的工具就可以達成的，還要仰賴人和人、事務和事務彼此之間，有足夠的透明、坦誠，藉著好用的協定互相合作才能達成。

如果從這個角度切進來看，藝立協定位在提供大家一個良好的分工合作環境。透過同業間一些已經通過試驗的可行經驗分享，提供人在接觸新案子的知識背景；在不同舊案子的歷史軌跡上，我們也提供你可能會需要用到的適當的幾種License 。還有許多自動化的資訊交流系統，更多的開放資源，更多經驗老到的人力。你也可以把藝立協看做是一個創意與人力資源相互交流的場域。如果你不擅長寫文件，那你可以在這邊找到會把使用手冊寫的漂漂亮亮的夥伴；如果你有一個套件，你可以把這個套件丟出來讓大家給你建議，評估要以怎樣的獲利模式才能讓這個套件協助你創造你應得的利潤。如果你缺乏某些方面的技術，可以在這邊詢問到是否有願意一起合作的戰友。當然，如果你是來找值得信任的外包人員，如果你有非常棒的點子希望大家能夠一起來完成，那藝立協這邊各式的相關人員等你來接觸。

我們每個星期日的下午兩點，在台北市紫藤蘆（新生南路三段16巷一號）聚會，討論相關的時事，彼此分享經驗和資源，並規劃可以一起做的事情。歡迎妳加入我們！

各章作者(依中文筆劃序)

王韻筑

台大商研所畢業，資深產品規畫。曾於中國國際商銀信託部服務。是中國國際商銀事業網路化的核心成員之一，有完整的網路銀行規畫及電子商務經驗，對於貨幣制度、交易規則、匯兌市場等金融交易有完整的 domain knowledge 與設計規劃能力。今年二月來到網基科技，負責產品規畫及網站需求分析，其規畫之完整、精確頗獲客戶好評。

侯宜秀

唐宗漢

1981/4/18出生。臺北市人。

學／經歷：

1995: 前任CyberEye電子商務／社群計劃發起人。
1996: 臺北市立北政國中畢業。
1996: 前任資訊人公司技術總監。
1998: 前任明碁公司軟體部門首席顧問。
1999: 前任Gotcha公司技術總監。
1999: 前任Infinita開放原始碼計劃副召集人。
2000: 前任北政國中自主學習實驗班講師。
2000: 現任Elixir資訊社群計劃發起人。
2000: 現任全球Perl Monger組織台北地區代表。
2000: 現任傲爾網公司布衣／總經理。

作品發表：

1993: 《快子‧違禁物品》共同作者，毛毛蟲出版社。
1994: 《壓出一片天空》, 34屆全國科展國中組應用科學類第三名。
1995: 《電腦哲學家》, 35屆全國科展國中組應用科學類第一名。
1995: 《我的電腦探索》共同作者，資訊人出版社。
1996: 《Word 97的使用藝術》編輯，資訊人出版社。
1997: 《姤思》作者，個人刊物。
1997: 《Inforia Quest》, 國家傑出資訊產品獎。
1998: 《乖孩子的傷，最重》共同作者，元尊出版社。

翁千婷

1978/05/06出生。嘉義市人。

學／經歷：

2000/06: 中正大學資訊工程學系畢業。
2000/07: 前任傲爾網公司綠林。

張毅平

簡信昌

1972/01/29出生。基隆市人.

學／經歷：

1990-1994 私立中國文化大學應用數學系
1994-1996 陸軍空降特戰司令部譯電士
1996-1997 Unisys Taiwan, 系統分析師
1997-1999 普洛文化事業有限公司資訊部經理
1999-2000 @Com. Inc., 資訊長
2000-2001 Gurufarm Inc., 專案經理

協同訪問

• grignard

• croak

• macpaul

• faith

• argrace

材料提供

AboutCase網站

網址 http://www.aboutcase.com 信箱 service@aboutcase.com

針對欲發案的企業端而言，aboutcase是一個專業人才資料庫，篩選提供優質的專案承接專業者，滿足企業e化的各種需求。針對欲接案的專業工作團隊而言，Aboutcase是對發案端展示專業能力,達到擴展業務,品牌行銷效果並可與專業社群交流的最佳網站透過網站提供的服務機制，輕鬆搜尋符合期望的專案,還提供專業社群討論及專案管理機制,以及接發案端互評的功能。

鐘慶峰

網址 http://go.to/killbee 信箱 killbeezero@hotmail.com

自介：標準的水瓶座男生，目前仍為學生SOHO，從大學時代邁入網頁製作一行，美工程式各方面均有一定程度，屬於全方位型的工作者。學生生涯中的課外活動相當活躍，曾任系學會會長，並有多次大型活動舉辦經驗。

黃保翕

網址 http://doggy.2y.net/ 信箱 doggy@miniasp.com

張佑誠

信箱 YNJ@os.nctu.edu.tw

高嘉良

信箱 clkao@clkao.org

陳寬憲

信箱 cks6969@ms35.hinet.net

米亞科技

網址 http://www.millionasia.com 信箱 eric@millionasia.com

POD ERRORS

Hey! The above document had some coding errors, which are explained below:

Around line 4:

Non-ASCII character seen before =encoding in '名稱'. Assuming UTF-8

Around line 492:

Expected text after =item, not a bullet

Around line 496:

Expected text after =item, not a bullet

Around line 500:

Expected text after =item, not a bullet

Around line 504:

Expected text after =item, not a bullet

Around line 508:

Expected text after =item, not a bullet

Around line 512:

Expected text after =item, not a bullet

Around line 516:

Expected text after =item, not a bullet

Around line 520:

Expected text after =item, not a bullet

Around line 600:

Expected text after =item, not a bullet

Around line 604:

Expected text after =item, not a bullet

Around line 608:

Expected text after =item, not a bullet

Around line 612:

Expected text after =item, not a bullet

Around line 616:

Expected text after =item, not a bullet

Around line 620:

Expected text after =item, not a bullet

Around line 624:

Expected text after =item, not a bullet

Around line 628:

Expected text after =item, not a bullet

Around line 632:

Expected text after =item, not a bullet