協同作業軟體面面觀

定義

從影音會議（video/audio conference），線上論壇（on-line forums），電子郵件(emails)，到專案管理系統（project management）很多軟體系統都聲稱自己是個協同作業軟體；從個別角度來說，這些軟體的觀點都對，因為它們都多半是兩人以上共同完成某些事情的軟體系統。但是如果我們能夠將協同作業的本質定義清楚，那麼不但能幫助分類，也能夠產生新的觀點、新的願景。

協同作業（collaboration）傳統上被視為有幾個軸：溝通（communication）、協調（coordination）、合作（cooperation）[1]。「溝通」專注於讓互相合作的人們可以有效交換資訊，目的在避免錯誤認知與假設；「協調」主要是讓各樣的工作能夠井然有序的進行，目的在加強效率；「合作」是要讓共同作業的成員能好好相處，目的在合諧。當然，有效合作需要有效的溝通；很多溝通需求就要用好的協調機制來管理；協調機制會安排有利合作的工作分配。如此複雜的循環，就會讓一群共同工作者想要有個系統來輔助他們。

就語意來說，協同還是有異於溝通、協調與合作：協同是要藉由資訊產生新的東西，不只是溝通而已；協同是要激發出各樣的新觀點與新發現，不只是協調而已；協同是要在人的異議中成長茁壯，不只是合作而已。所以Michael Schrage 定義它為[2]
[...] 協同是共同創作（shared creation）的程序：兩個或更多有互補技能的人經由互動（interacting）產生一種從來未有，也不能獨力產生的共有體認（shared understanding）。協同作業產生對程序、產品、事件的共同意義（shared meaning）。

由此可以看出：協同作業尤其重視的，是讓群體匯集力量，一起創造出新的東西。就是因為這種特性，科學研究、技術研發、軟體系統開發都有很大的協同成分在內。

幾個角度

就人們互動的模式來看，協同有同步（synchronous）與非同步（asynchronous）兩種。在技術上，同步的互動與協同作業比較難做，這是由於使用者可以同時修改同一個物件；在設計上，它們通常要在同一個協同背景（collaboration context）下控制。然而，在web 的架構底下，我們會很訝異這種同步與非同步的界線並不是那麼清楚；主要的原因可能是因為HTTP 是沒有狀態的（stateless protocol），所以很多都是利用定期回詢（periodic polls）的方式製造假象，但也有人用像Comet 這樣的技術在小規模的網路裡克服這種障礙。

就計算的模式來看，協同作業起碼有訊息（messages）或是共用物件（shared objects）兩種。像電子郵件、線上聊天（含即時訊息軟體）等系統，通常是訊息導向的，雖然它們在是否同步上有所不同。內容管理（含Wiki）、線上辦公室軟體（如Google Doc）、廣義的案件處理（含公文或表單簽核）系統重視的則是共用物件。
從組成人員大小來看，大而鬆散的叫社群（community），小而緊密的叫群組（group）。社群的組成，通常是基於共同興趣、共同利益；大學社團或是網際網路網站討論區就是明顯的例子。群組的組成，一般是因為工作分配；系統開發的專案團隊則是我們比較熟悉的例子。

社群軟體系統在乎的，是讓人很快加入、註冊、感覺受歡迎、快速進入狀況、瀏覽所有相關資料（含其他成員及規則）、受到踴躍發言與貢獻的鼓勵。更多的社群軟體功能也包括隱私保護、上線狀態、專家身分等等。通常社群的宗旨是長久經營與提高個人貢獻、然後才能維持人氣。這類軟體的一般技術要求不是很高，重要的是可使用性（usability）與內容呈現的方式。社群軟體的功能已經漸漸滲入很多現有網站裡，以加強使用者之間的互動。比方說，網路拍賣巨人eBay 裡，就有討論各式各樣議題的區域；網路CRM 巨人salesforce.com 內有從使用者到程式開發者的社群。這類社群中的討論，如同幾乎已消失的Usenet 一樣，都變成很多人貢獻知識、尋求解答的好地方。

群組軟體比較複雜。由於組成人員少，又大多是由於密切的共同工作使然，所以對彼此溝通的即時性，有不一樣的要求。由於成員之間的互動比較緊密，所以可能的應用更多：共同編輯（shared editing）、共用應用程式（application sharing）、線上聊天（online chat）、影音語音會議都是比較有名的例子。群組軟體最重要的事就是群組目的（group goal）、群組焦點（group focus）、共用產生物（shared artifact）和共用工具（common tool）；所以這種軟體設計的要則之一，就是要在整個工作過程中，讓參與者能持續注意群組焦點，但是個別的處理方式可以有很大的自由。共用應用程式目的在提供有效的群組工具；共同編輯是在群組焦點導引下，合力完成群組目的的行為；線上聊天或是會議都是達成交換產生物的手段。群組軟體通常有很多可以共同工作的物件，所以通常會有個共用儲存（shared repository）來控管共用物件（shared objects）；而因為有許多共用物件，顆粒（grain）比較小，所以對並行（concurrency）的技術要求比較高。

組織協同軟體

由於技術的進步，我們在溝通與協調上有更多的輔助工具-- 同步溝通的應用如影音會議系統與即時訊息（instant messaging）系統，加上現有屬非同步的電子郵件系統，都有助於排除空間的障礙。這類工具雖然非常方便，但它們至少有以下缺點：(1) 共同創作無法經由它們完成(2) 沒有結構，沒有來龍去脈，所以使知識累積困難，也不利於日後查詢。在軟體思維上，雖然在協同的觀點上無誤，但是在長久累積組織資產的觀點上，這類系統造成的效益不大。

自從Web 2.0 的觀念與技術散佈開來後，很多內容或文件管理的系統都加上了一些協同的功能如共同創作、加讀者評論（comments）、讀者定等級（rating）與推薦、或是下標籤（tags）等等。這些都為現有的應用加上了參與的色彩，也讓使用者變成了新內容的資源。叡揚的產品Vitals/KM 就具備了這樣從使用者出發的功能，在文件為中心（document-centric）的主軸下，鼓勵協同的行為。

叡揚的另一個產品teamKube 則是從作業的觀點出發，把人們的協同作業行為拉出來，是一個以活動為中心（activity-centric）的系統。從活動出發，所有計畫、決策、執行、考核中牽涉的人事時地物等，都有了想像的空間；也可以從各種維度切入，把人際關係網路（social networking）、專案執行考核（project management and tracking）、時間與資源安排（time and resource scheduling）等等，都變成組織或個人協同思考的擴展空間。

從互動模式來看，teamKube 是個混合型的協同作業系統。從線上開會的觀點上來看，那個像是線上聊天的介面，如同MSN一般，重視的是即時回應現在發生的變化，反應給所有在線上開會的人。從會前準備到會後交辦與會議紀錄的整理上，這是個非同步協同作業的系統。從計算模式來看，teamKube 也是混合型。不論是個別交辦或是會議，所有執行中的複雜活動，加上相關的產出，都有訊息與共同物件。所以在技術上的挑戰，是將各種訊息牽涉的通訊管道納入，將未來可能出現的新共同物件，用好的架構預先騰出空間。這些都是在協同作業系統開發上有趣與豐富的議題。