【PM的人生策略】試試看，喜歡再買?
UAT的概念，不同面向也都會需要這樣的處理方式
在專案管理中的UAT階段，其實是在系統上線前重要的測試階段，主要用於讓使用者在這個階段進行功能驗證，確保開發出來的工項有如需求訪談時所討論的交付。
實務上很常遇到的問題，就在於這個階段測試的過程中，儘管符合當初討論的需求規格，但是客戶用過之後總會發想到其他想做的設計，或是決定摒棄不用原先規劃的流程，這時候就很容易要求廠商協助調整，畢竟以客戶來說，需訪沒能顧及的事情，能在最後一併修正最好。
以整個軟體開發的過程而言，需求訪談算是專案初期最重要的工作，唯有把該做的項目理清楚，後面的開發工作才能按期展開，整個上線的時程也才能夠如期完成。而就如同前面所述，UAT這個階段，其實是在系統上線前重要的測試階段，主要用於讓使用者在這個階段進行功能驗證，確保開發出來的工項有如需求訪談時所討論的交付。
UAT完成之後，概念上是雙方確保開發成果與規格一致，確認沒有不一致以後，也才能夠進行後續的系統部署作業，最後將系統正式上線，客戶正式開始將系統導入使用，整個專案才算是進入結束階段。而如果在這個階段又要調整，肯定得耗費一段時間，更有可能需要花費額外的人力成本開發。
我會建議在UAT階段的問題處理上，問題的收集要能夠按照時程定版，並釐清哪些是真正不符合規格需要處理的bug，哪些是為了讓系統更好用的優化項目，唯有設定好收集的時間以及區分類別，才可以讓這個階段的問題被妥善止住，修好那些真正該修的bug。
我想相同概念，除了在軟體開發外，換作是不同面向也都會需要這樣的處理方式，例如設計師接案時，與客戶定稿的過程當中，也應該確保需修改的範疇與次數，避免過多的調整，透過制定明確的範圍和時間框架，以便管理期望和進度，其他像是市場行銷、產品設計，我想也都需要將定義釐清，才能順利達成所需的目標。
如果你喜歡我的文章，可以按下「拍手」給我支持，或是轉發給你想要一起分享的朋友，拍手除了表達支持之外，也可以讓我知道你閱讀完的感受：- 如果你純粹想支持我繼續寫作，請給我20個拍手。
- 如果覺得這篇寫得還不錯，請給我30個拍手。
- 如果你覺得有收穫，看了很過癮，請給我40個拍手。
- 如果你很喜歡這篇文章，有機會還想再看到這類型的文章，請給我50個拍手。有任何想法或想說的話，都歡迎在底下留言或是聯絡我，很期待彼此能有交流互動:)
謝謝你願意閱讀到這，也感謝所有支持與喜歡的朋友們，
記得Follow我 Jheng-Yu Lee，別錯過任何一篇文章，我們下篇文章再見囉！
