我於上一編文章中講述了在軟體開發專案初期，由於各種原因會產生需求迷霧。任由這些迷霧的存在，客戶在實際使用系統時，必然會發現系統並非自己所想或缺乏某些重要的功能。其結果是專案團隊將在用戶驗收階段才作應對。由於系統已經完成所有功能的開發，此時對系統中的某一功能作修改，可能會影響系統其他功能，要解決這些複雜的問題，其修改成本必然比最初未開發前更高。此時專案將陷入兩難局面，即為了客戶的滿意度繼續修改，還是為了讓專案不陪本而止損。
縱上所述，專案團隊必須盡快打破需求迷霧，確認專案開發出來的產品是客戶所需的。於這一編文章，我將概述我和我的團隊是如何挖掘客戶的需求，讓專案在正式開始前，能盡可能跟客戶達成一定的共識。
Gen by AI
打破迷霧的過程
要打破需求的迷霧，需要對客戶的業務作詳細的調研，才可能清楚對方所需。以下是我和我的團隊調研的步驟及當中一些注意點：- 團隊成員先了解客戶和專案範圍相關的業務流程，如果團隊中有對相關行業有所認識的業務分析師，則能加快了解對方業務流程的速度。但請不要跳過此步驟，要記住即使行業相同，他們的工作流程也不會完全相同。因此請好好了解對方所使用的工作流程。
- 如果專案的產出是以新系統取代客戶使用中的系統，並非在只優化原有系統的話，則在了解客戶的工作流程時，請花時間了解他們是如何使用現有系統（使用Word 或 Excel也是系統哦）。團隊需要知道例如某部門的用戶在什麼時候在系統中輸入資料，又會在那種場合下查閱數據。
- 通常在上述的步驟中，團隊即能了解客戶的需求及痛點，如果對方業務真的異常複雜，則我會要求業務分析師到客戶實際的工作環境中查看，以便更能理解對方在現實中所遇到的各種情況。
- 所有需求在記錄及收集後，身為專案經理的我會再次核對專案的範圍及收集回來的需求，並把疑似範圍外的需求先作標注。以便在後續過程中和客戶協商實施此需求的必要性。例如系統需要對接客戶現有的人力資源系統，並自動獲取員工資料，可能並非項目原定的範圍。
- 以業務分析師為主並和專案團隊對需求作分組。把同一部門性質相似的需求整理到一起，以便後續軟體功能的設計。例如人力資源系統中，相似的需求可能有：如果新員工未提交所需文件，系統能提示人力資源部門、新員工需要知道入職時需要提交那些文件，並能上傳對應的文件到系統中。
- 在對客戶的需求有一定的理解後，下一步就是對理解作回應。我們的回應方法是使用系統原型圖介紹系統的樣子及操作方式。所使用的原型圖是根據對方的工作流程設計的，即在介紹過程中盡可能貼近對方實際的工作情況。其次，原型圖中也會顯示一些數據變化的過程，盡可能讓用戶理解並想像他們未來是如何跟系統的互動的。需要注意的是，即使使用原型圖展示系統功能，也需要跟開發團隊確定是否真的能實現，防止在後續開發過程中影響「承諾」的兌現。
- 當用戶看到系統原型圖及介紹後，會引發更多他們在工作中所發生的 “奇怪情況”或在工作時碰到的問題。例如一般來說，銷售訂單在客戶下訂後，貨品應該被鎖定給該客戶，並不能發貨給其他客戶了。但實際上如果其他客戶訂購同一種貨品，並且前一位客戶不急於要貨，則客戶會先把貨發給後來建立訂單的客戶。系統可能需求滿足以上的情況。
- 確認新反饋情況的重要性：雖然用戶在看到原型圖後必然會引出大量的思考，但並非全部情況都需要設計獨立的功能來處理。例如於非工作時間，員工不可以繼續使用系統，以保證數據的安全性。要滿足這個需求，公司能通過行政措施來阻嚇員工訪問系統，而不需於系統開發新功能來禁止登入。
- 對每一個新的反饋，團隊會回到第5步，整理並對原型圖作出修訂，並再次展示修訂後的系統原型給客戶，這個過程會一直重覆，其至雙方理解方案可接受並確實能解決客戶的問題以止。
- 方案在確認後，商業分析師會把詳細的方案寫成《軟體需求規格說明書》，並請對方回顧及確認。此一份文件有雙重的意義，一是以文字記錄的戶式讓客戶再次審閱較早前各個會議中所討論及確認的內容，以此為後續專案工作的基准。另一方向也是開發團隊工作的依據，開發團隊能按照此一方案對系統作更細緻的設計及開發工作。
以上就是整個打破迷霧的過程了。
變化才是不變的真理
上述流程的目標是為開發建立基礎，並讓團隊能在較為確定的情況下開展工作。但我們需要記住，世上永遠沒有不變的情況，變幻源自永恒。因此即使再確認的方案，也有變更的必要。
例如系統交付給用戶使用時，因為業務的調整因此原來的某些邏輯不再適用，因此系統需要作出一定的調整才能滿足相關的變化。作為專案經理，管理及接受變更是很重要的，而不是拒絕變更。管理變更的意思是把問題交給合適層級的人作決定，且作出決定的人能有足夠的資訊支持其決策，僅此而已。
盡早提供系統給客戶測試會更好嗎?
有一派的人認為上述需求收集方式浪費時間，使用敏捷的方式早一點提供系統給客戶使用會更高效。我對此抱持懷疑態度。如果客戶是以新系統取代現有系統的話，更早交付部份功能的軟體並不代表對方會重視。
在客戶的角度，此可能只是一個半成品，若不能滿足他們日常的工作流程，即使再早提供系統給客戶，他們可能會在空閒的時間嘗試系統的功能，但並不會認真對待。
其結果就是當所有認知上的系統功能開發完成，並讓用戶實際使用時，所有業務流程上的問題才一次過爆發，團隊為了應對這些爆發的問題而疲於奔命。且由於沒有建立任何基准，則難以定義用戶提出的需求是新需求還是原來基准內的需求了。
相反，如果只是改善現有系統的一部份，此方法可能更能達到目的。
需求及方案是專案在最初階段中最重要的基石，它為後續的各種活動提供了基礎，因此不要輕視此一階段的過程。請確保團隊成員能按照設定的流程完成有關的工作，並讓客戶明白在確認需求及方案後是一切後續工作的基礎，最終目標是讓客戶明白專案團隊是為了改善客戶的痛點而存在的。
