雲端工作術
各類應用示範
案例故事
逃離惡夢
關於 Ragic
正在為團隊尋找 SaaS 工具嗎？市面上的 SaaS 工具數量非常龐大，每個工具著重的功能也有所差異，「如何挑選工具」本身就是一項學問。
如果你腦海只有一個朦朧的概念：「想要更換通訊工具」、「想找一個雲端 CRM」又或者是「好像需要更好用的專案管理軟體了」，但心中沒有一套具體可行的步驟來釐清需求、決定篩選標準、縮小範圍，手邊也沒有前人經驗累積的注意事項，協助你做判斷時考量更全面，只好憑直覺關鍵字任意挑選，那麼，事後發現不如預期的機率很高。
在這篇文章，我們就想協助解決這個問題。我們根據過往經驗與專家說明，擬定了六個建議步驟。步驟 1 到 4 協助你將原本模糊不清的痛點，轉化為具體可行的「需求列表」，並且將常見的外部限制列成清單方便你快速檢查；步驟 5 和 6 提醒你「測試」在軟體採購評估的重要，並提供具體的測試項目建議。
希望這份 SOP，能縮短你摸索挑選的時間，提高成功率！
挑選工具的第一步，你不需要一開始就跳進工具海裡研究各家功能，而應該先好好釐清自己與團隊目前遇到、希望工具可以解決的問題。以「專案管理軟體」需求為例，你和團隊成員為什麼會想要這樣的工具呢？想必是既有的工作流程有讓你們覺得不方便、沒效率的地方。
（如果原本的流程沒什麼問題，那我們會建議你不要為找而找。）
舉例來說，你們的困擾可能是：原本專案的進度協調沒有任何紀錄，大家都在通訊軟體上談定而已，各個專案各自推進到哪了？有哪些待辦事項？沒人講得清楚。
此時，大家針對「專案管理軟體」的需求，主要就是有個所有人能共同查看資訊的地方，能統一列出每個專案底下該做的事、讓大家簡單註記完成項目更新狀態即可。
又或者另一種情況：你們本來就用了 Excel 或 Google 試算表紀錄專案資訊，看得出大致進度，但資料太散亂，不太容易區分權責、也看不出是不是分工不均。此時你們對專案管理軟體最大的期待，是除了基本的資訊呈現外，也要能讓權責區分與工作量分配更清楚。
藉由回頭反思團隊痛點、想解決的問題，理出「希望有統一查看專案資訊與管理進度的地方」、「希望有工具明確區分專案權責與工作量」等不同的目標，相比起最一開始「需要一個專案管理工具」這樣的念頭就顯得更清晰了。
這部分你也可以特別注意的是，如果你的團隊較大、跨部門、成員職務類型差異較大，那麼整個團隊所有人的需求未必是完全相同的。此時為了確保有掌握到真正的團隊需求，你甚至可能會需要訪談團隊內不同的成員，以便了解每個人不同的顧慮。
釐清了團隊的痛點、確認想解決的問題後，第二個步驟我們建議你先針對這個初步釐清的痛點，來研究市面上的工具。此時「研究」的目的，不是要馬上篩選出一份「評比清單」，而是要讓我們對自己需求的「可行性」有更深一層了解，可以提出更具體可執行的需求。
舉前一個步驟「專案管理軟體」的其中一個例子來說，你可能大概知道「專案管理軟體」可以讓專案資訊比較井井有條、可以看狀態、甚至好像可以讓工作指派分配更清楚，因此覺得它可以滿足這樣的需求 －－「希望有工具明確區分專案權責與工作量」。
但是，在這個階段，除非你已經是個專案管理軟體專家，否則你對相關功能應該還缺一些具體理解。如果你想讓工作指派分配更清楚，看過幾個主流專案管理工具相關功能後，可能會發現功能有「只能指派單個使用者 / 可以指派多個使用者」「無法指派群組 / 可以指派群組」等區別，大概知道這些區別，並與自己的原始需求比對後，你就可以得到更具體的進一步需求。
又比方說如果你掌管業務團隊，需要專案資訊有比較細密的權限區分，可能多看幾個工具的相關功能之後你會知道，各種工具的權限區分可能包含幾種角色類別：
．可做所有設定操作與看到所有資訊的「系統管理者」角色
．可以看到所有資訊但不見得可以做設定的「管理者」角色
．只能看到自己建立或被指派的資料，不能看到其他人建立或被指派的資料
其中 1 和 2 很常見，但 3 則不一定。
此時回頭比對原本的痛點，有可能你可以進一步釐清自己需要的是：「希望能讓業務主管看到所有專案資料，但個別業務只能看到自己建立的資料」，並且更確定自己想要的需求規格裡，「只能看到自己建立或被指派的資料，不能看到其他人建立或被指派的資料」這一項是重要、需要列入評比的。
這個「理解功能 → 更具體列出需求」的過程，並不是只有需求包含比較複雜深入的功能細節時才需要，有時候多看幾個工具、建立對這個類型工具的了解之後，還可能改變你的思考框架。
舉例來說，你的需求如果像前面提到的，只是希望「有個所有人能共同查看資訊的地方，能統一列出每個專案底下該做的事、讓大家簡單註記完成項目更新狀態即可」，那麼在看完幾種主流專案管理軟體之後，你可能會發現你的需求算是相當基本，多數軟體都能具備，因此不一定要深入細究功能細節。而同時，你可能也發現，有些軟體功能強大，但操作過於複雜，可能不太好上手，而有些軟體則主打「簡潔至上」，同時包含必備功能。
這時，透過對這些軟體的初步了解，你就可以改把需求重點放在「介面越簡單越好」，像是 Trello、Todoist 這類工具，而濾掉一些功能很多、但菜鳥不好上手，團隊也正好不需要這些強大功能的工具，例如 Wrike 或 Jira。
做這些初步研究時如何下手才不會大海撈針呢？有幾個方法，首先你可以根據初步的關鍵字，來我們介紹過的專業軟體評比網站看看相關資訊，這些網站通常已經幫你做過一些統整，關於特定類型的軟體共通包含什麼功能、通常有哪些功能類型、可能相關的軟體類型是什麼（有時候你以為你需要專案管理工具，但其實需要的是共筆軟體、任務清單管理），資訊都很清楚，有需要時也可篩選特定功能來看看有多少軟體，可節省大量時間。
當然中文資訊部分也推薦可以參考看看我們曾經寫過的詳細介紹與評測，例如專案管理軟體需求的 6 大面向或 7 種專案管理工具（實際列出功能）。
在這裡，我們也建議把需求再細分為「必要」以及「加分項」，先基於必要項廣泛搜尋適合的工具，例如「必須要有財務功能，如果專案的陳列方式是看板會更好」，最後再一層層檢查，將對團隊效益較少的工具慢慢剔除。
這個時候，你就可以透過更進一步的功能需求繼續搜尋，建立備選清單了。
你可能會覺得只要在「目前已經找到的工具」裡面篩選就沒問題了，導致最後整個備選清單裡只有大約 4 ~ 5 個工具，但這樣反而會錯失很多可能更適合你的選擇。
因此，先列出一個比較長的清單，將那些原本沒機會研究到的工具也一起考量，更能確保最後選擇的工具是真正合用的，但是如同先前提過的，網路上的 SaaS 工具數量非常龐大，如果要節省時間話，應該怎麼做呢？
其實，在 G2 或 Capterra 這類評測網站，都會藉由象限圖、系統推薦清單，或是列出相似工具的方式，讓你可以一次將大量的工具納入考量清單內，像是在 Asana 的頁面，就能看到 Jira、Monday.com、Wrike 等等工具也一併被列出來比較。
因此你可以試著從研究起來覺得適合的幾個工具出發，藉由網站上列出的替代選項，盡可能拉出一個長清單，並且將自己看重的因素（例如團隊的需求／功能支援程度、易用性、價格、客服等等）登記在清單上，提供後續比較的標準。
列完清單之後，再藉由前面列出的易用性、功能性與價格等因素，在清單內做出大致的排名後，刪減掉排名在底部的工具，就能初步篩選真正適合的工具囉！
根據自己需要的功能列出清單、進行初步的排列之後，為了進一步篩選工具，你會需要回過頭來檢視團隊本身的限制，例如需要遵守一定的資安規範、團隊的預算額度，又或者是本身有其他特殊考量，更有效地讓你迅速整理出最後需要測試的工具清單，例如：
資安規範：
．目前國際通用、廣泛且足夠嚴謹的標準是 ISO/IEC 27001。
．如果團隊會經手來自歐洲的資料，就必須要確認供應商是否遵守歐盟的《一般資料保護規則》。
．強調資料必須在公司自有的伺服器處理的話，可以詢問供應商是否有提供讓工具在私有主機運作的選項。
預算限制：
．除了固定額度的預算之外，也可能採用投資報酬率（ROI）計算。成本可以是研究工具、轉換工作流程的時間，以及購買授權所需的金錢，報酬則因應工具的不同而有各種計算方式，例如 CRM 工具的報酬就可以直接以銷售額的變化進行計算，其他工具則以省去的流程、時間為主。
．如果發現預算怎麼樣都很吃緊，可以再另外研究工具是否提供簡易版方案、組織優惠，選擇正確的方案，也可以在保持工作順利運作的同時，省去用不到的功能以及不必要的花費。
特殊考量：
．對於較大型的企業而言，工具上線時必須考量到教育訓練的必要性，這個時候供應商或外部提供的教材是否夠多，也會大大影響轉換時的難易度，進一步影響需要支出的時間與學習成本。
將團隊需要符合的規範、自有的限制或者是特殊的要求，組成一個檢查清單：
．一定要通過 ISO/IEC 27001
．每個月的支出要在 15 美金以下
．必須要有全中文的使用說明
．…等等
藉由這些檢查項目，套用在剛剛列出的工具備選清單，更能有效、快速地幫助你剔除不合用的工具。
不管是什麼樣的產品，你應該都會體驗過那種網路上一致推薦、官方頁面看起來也毫無弱點，但實際上手之後才發現產品根本不合用的情況。
因此我們強烈地建議你一定要在做決定前好好把心儀清單上的工具測試過一遍，套用到你的工作流程上，看看是不是有什麼鮮少被他人提到，但對你而言十分致命的缺點。
所幸 SaaS 工具的供應商也都深知測試的重要性，因此有一大部分的工具都會提供試用期，或是直接推出有一定限制的免費版，讓使用者能夠先以免費版大致認識工具的架構，需要進一步的操作再開始試用來完整體驗運作流程。
為了幫助讀者選擇適合的 SaaS 工具，我們建議先從工具的易用性上進行測試，而基於 SaaS 工具一般不採用專案、專人服務的特性而言，我們推薦使用以下的基準來評估一個工具是不是足夠易用：
・介面的直覺度如何？初步操作上容易卡關嗎？
・卡關時透過說明文件或客服能否迅速且精確地解決問題？
・與其他程式的相容性為何？可以順利導入或串接嗎？
會建議從這些角度下手是因為 SaaS 工具的使用者在多數情況下都需要自行透過文件解決問題，也不一定會有專人服務，因此遇到障礙時通常只能寄信聯繫客服並等待回應，在得到回應之前，出現問題的工作就只能停擺。
另外也是因為 SaaS 工具的用途通常比較單一，時常需要配合其他軟體、工具完成工作。如果一項工具的擴展性不強，甚至與團隊熟悉的工具有相容問題導致增加許多不必要的轉換步驟，就不推薦繼續使用了。
在進行功能測試的時候，我們建議你再擬定一套適合的情境作為 SOP，例如在通訊工具上模擬過去的溝通狀況、在專案管理上將過去完成的事項再搬到各個工具上從頭運行一次，這樣你就能夠得知同一套工作流程在不同工具上需要怎麼執行，減少測試時的不確定性，也避免如果工具不合用時還需要將進行到一半的項目導出的風險。
在很多情況下，一個人是很難將整個工具的功能完整測試過的，團隊中每個人上手工具的速度和會遇到的困難也可能不盡相同。因此除了自己進行測試之外，也要再與團隊內部多加溝通，並共同測試以模擬實際導入之後的工作流程。
我們建議藉由封閉、焦點團體式的測試，搭配平時的工作事項來模擬正式工作時的狀況，一次性釐清所有成員可能遇到的問題，也可以更快速地整合團隊的意向，避免需要多次與個別的成員花時間測試、來回討論。
例如測試專案管理時，直接在辦公室約定在特定時段中共同測試，藉由協作專案測試、熟悉權限管理、指派工作或子工作、共享介面（例如日歷或看板）以及個別人員標示工作進度（死線或已完成）這些功能的操作。
與團隊介紹並測試工具之後，可以藉由回填調查表、個別訪談或是舉辦團體會議，取得大家對於工具的感想與熟悉程度。
由於挑選出的 SaaS 工具在未來會與團隊朝夕相處，因此除了工具本身的功能之外，也可以著重了解成員之間在使用工具時的心情，例如在使用時覺得很方便，或者是覺得特定步驟很冗餘、用起來很煩躁，都是後續應該要順帶考慮的問題。
經過這些步驟，相信你可以選出最適合團隊的工具，但是為了避免後續可能慢慢浮現出的各種不合用，在導入的前期，你可以先以月付的方式來使用工具，確定一切穩定、上軌道且大家都熟悉操作了之後，再考慮季付、年付這類的付款週期喔！
