化解軟體開發專案初期迷霧：降低風險，共創雙贏

身為主要提供服務的廠商，我們經常會遇到客戶以固定費用的合約來要求我們執行專案。因此，如果在專案開始時沒有好好定義專案範圍，通常到了專案後期會很難修改。這篇文章，我將嘗試詳細說明在一個軟體開發專案開始時，碰到的風險會有那些，及後的文章我再來說明如何作出化解。

專案初期的迷霧

在專案剛開始的時候，客戶心中通常已經有一些目標，以及對未來不同的想像。他們對於我們將會提供的軟體以及軟體具備哪些功能，雖然有一定程度的認知（否則也不會購買），但他們並不清楚這些功能會在什麼時候、以什麼方式幫助他們。

這個過程很像我希望找到一款能記錄筆記的軟體，並在網路上查看相關軟體的介紹。這些網站內通常會詳細列出軟體中許多不同的功能，我也會思考自己將如何使用這些功能。然而，在實際使用時是否真的能幫助到自己，則需要將軟體的功能融入自己的工作流程中並實際嘗試才能知道。

這時候，身為軟體供應商，如果專案前期沒有好好了解客戶的工作流程，很可能會在客戶實際使用軟體時，才會收到各種修改要求，並希望軟體能「盡可能」配合他們的工作流程。這類修改要求勢必會成為專案後期的風險，因此，我有責任盡可能降低這種不確定性。當然，這種不確定性不可能完全消除，但先把大部分內容確定後，對方在使用軟體時發現的問題就存在協商的可能了，而不是對方只要認為軟體「不對」就把其全盤否定。

迷霧存在的原因

這種不確定性我認為是雙向的，其主要的原因是雙方對對方行業認知的不足。

客戶對軟體開發認知不足

首先，讓我直接點出一個核心問題：客戶對軟體開發的認知往往不足。這導致他們很難直接且明確地表達他們需要哪些功能，以及每個功能應具備的細節與邏輯。

取而代之的是，客戶通常只能提出他們所期望的最終結果，以及他們目前的工作模式。例如，他們可能會說：「我希望這個系統能讓我的報表處理速度變快」，或是「我們現在都是這樣人工核對資料的」。這些間接的資訊對於軟體開發並非毫無意義，它提供了我們理解客戶需求的線索。然而，僅憑這些資訊，我們很難將其轉化為一個完整且可執行的軟體功能設計。

當功能定義不夠精確時，我們所開發出來的軟體，就很難真正切中客戶痛點，甚至無法有效地協助客戶改善現有的工作流程。這就像醫生只知道病人「肚子痛」，卻不清楚是胃痛、盲腸炎還是其他問題，如果沒有進一步的問診與檢查，就無法開出真正有效的藥方。軟體開發也是一樣，如果無法深入理解客戶需求背後的「為什麼」和「怎麼做」，即便我們開發出了軟體，也可能無法真正解決客戶的問題，甚至導致後續的修改成本大幅增加。

部門牆造成的局部認知缺陷

當軟體的使用者不僅限於單一部門，而是需要多個部門共同協作時，這種不確定性會進一步升高。一般來說，企業內部常存在所謂的「部門牆」，這會使得兩個或多個不同部門之間的工作人員，難以真正理解彼此的工作方式與需求。

處在各自部門中的成員，通常只能說明他們所了解的內容以及對軟體的期望。然而，軟體作為連接不同部門之間的重要橋樑，必須要各部門的人員相互配合，才能真正發揮其整合與協同的作用。

舉例來說，假設 B 部門的同事在開始工作前，需要收到 A 部門同事發來的申請，並且這份申請中必須包含某種特定的資料，B 部門才能啟動後續作業。但 A 部門的人員可能並不清楚這個環節，因此他們或許會認為這項資料在他們部門內部並沒有存在的必要性，進而要求在軟體設計中刪除該資料欄位。

這種資訊不對稱與溝通落差，正是跨部門專案中最常見的隱憂。如果沒有在專案初期充分協調與溝通，讓各部門理解彼此的工作流程與需求，軟體開發完成後就可能出現：A 部門提交的申請缺乏 B 部門所需的關鍵資料，導致 B 部門無法順利展開工作，進而影響整體專案進度，甚至造成流程中斷。

交付團隊對客戶行業認知不足

從軟體開發供應商的角度來看，客戶對軟體開發的認知不足是普遍存在的現象，只是程度上的差異。舉例來說，人力資源部門幾乎每家公司都有，因此我們的開發團隊對其運作模式會比較熟悉。但如果客戶是建築工程行業，我們可能就對他們的工作方式一無所知。

產業知識不足帶來的挑戰

對客戶所屬產業的認知不足，會帶來以下幾個主要問題：

1. 專業詞彙的定義差異

首先是詞彙定義的不同。我們都知道每個行業都有其專屬的專業詞彙，這些詞彙即使常見，但對外行人來說，其意義可能與一般認知大相逕庭。例如，我曾聽過一個詞彙叫「印單」，它的意思並不是單純的「列印」文件，而是一整套包含「確認銷售訂單」、「列印銷售訂單」及「發出貨品」等動作的流程。如果前期沒有把這些詞彙的真正意義釐清，草率處理，後期很可能會因為理解錯誤而被迫修改軟體方案，造成時間與成本的浪費。

2. 工作流程與細節的盲點

第二個問題是不清楚客戶的工作流程與細節。客戶在說明需求時，通常不會特別指出對他們來說「理所當然」的內容，他們只會說明自己認為需要的功能或期望。然而，在軟體設計上，這些看似「理所當然」的環節卻往往是最關鍵的。因為缺少了這些看似微不足道的功能，很可能會導致客戶的整個工作流程無法順利運作。我們必須極力避免這種情況發生。因此，在需求訪談時，我們不能只專注於表面上的「需求」，而必須深入了解他們現有工作流程的每一個步驟，甚至包括那些被視為「想當然爾」的部分。

3. 產業法規的限制與要求

第三個問題是政府對特定產業的規範。這些法規對客戶的工作流程有著一定的限制，因此軟體可能需要具備特定的限制功能或稽核機制，以符合政府的規定。由於這些規範在不同國家和地區可能不盡相同，如果我們不主動去了解客戶所屬行業的相關法規，軟體設計上很可能會出現功能缺失，導致開發完成後仍需大幅修改。

總結：化解專案迷霧，共創雙贏

綜上所述，軟體開發專案的成功，很大程度上取決於我們能否在專案初期，有效地化解那些看似模糊、實則關鍵的不確定性。無論是客戶對軟體開發的認知落差，或是跨部門協作帶來的溝通挑戰，甚至是產業特有的詞彙、流程與法規，都可能成為專案路上的絆腳石。

作為軟體供應商，我們有責任主動出擊，透過深入的需求訪談、跨部門的有效溝通，以及對產業知識的積極探索，將客戶腦海中那些抽象的「想望」轉化為具體、可執行的軟體功能。這不僅能大幅降低專案後期的修改風險，更能確保開發出來的軟體真正貼合客戶需求，成為他們工作流程中不可或缺的助力。

從模糊到明確，從不確定到（相對）確定，這段過程需要供應商與客戶雙方的共同努力與理解。唯有如此，我們才能攜手打造出真正有價值、能為客戶帶來效益的軟體解決方案，實現雙贏的合作成果。