「老師，我們的供應商說，他們已經改用敏捷方法來開發我們的產品了，而且現在是在做 Prototype，所以不需要、也沒有文件可以給我們了，跟他們說這些文件是最後結案一定要的，他們還是不交，這樣對嗎？我該怎麼辦？」
這是一位學員在我敏捷課程結束後的提問，這個問題其實可以分為兩個層面，一個是供應商的這種說法到底正不正確？另外一個則是更為深層的問題，為何這家供應商膽敢用這樣的態度來頂撞客戶？
我們就先來談談「文件」這檔事好了。
無論是用傳統式或是用敏捷式方法來管理專案，首先我們該建立的正確認知是，專案的各方利害關係人對於文件的需求永遠都不可能消失！理由很簡單，為了溝通和紀錄留存，從幾千年前的甲骨文開始，文件向來就是最簡單的工具之一，只不過，它不一定是最有效率和最有效果的工具罷了。
在我帶領研發團隊的多年經驗裡，各種形式文件的撰寫，永遠都是工程師們最厭惡的工作之一。原因也很簡單，通常就是沒用、形式、浪費時間、資料過時、錯誤百出等等。然而，我們卻無法否認，很多時候，文件的確也發揮了其應有的效益，比方說，某軟體或硬體元件的使用規格書等，沒有這類文件，客戶端就無法了解該如何將你的軟體或硬體元件整合進他們的終端產品。
所以，不管是「文件無用論」的激進派，還是「凡事都得有文件」的保守派，在我看來都過於極端，選擇「該有的文件不能省，不需要的文件就不要寫」這種中庸之道，才是明智之舉。然而，下個問題來了，誰來斷定什麼時候該寫文件，什麼時候可以不用寫文件呢？
就以上述的供應商（乙方）為例來說明好了，你想用傳統式專案管理方法也好，想改用敏捷式方法也罷，那是你家的事，多數的客戶根本就懶得理你，只要你能夠滿足當初合約上制定的ＳＯＷ（Statement Of Work，也就是需求／規格），並準時交付各種合格的成果就好。但很顯然地，這家供應商自以為可以藉由專案工作方法的變更，就可以連合約的要求也一併更改，這根本就是犯了法律上的大忌。
話說回來，為什麼客戶端（甲方）無法用具體的合約條文來規範和要求供應商，僅能一直口頭要求呢？很顯然地，當初合約上對於供應商何時該交付何種成果，應該是沒有夠明確的規範。這也就難怪，供應商敢拿翹不甩客戶了。當然，也有可能是乙方太強勢，而甲方太軟弱之故。
文件的侷限
寫到這裡，我們談的其實是大部分傳統式專案管理的合約簽法，也就是在一開始就制定好所有該被滿足的ＳＯＷ，以及相應的里程碑和最後期限，然後簽完約之後，基本上甲乙雙方就不太溝通，一直等到下個里程碑到來，才去驗收該里程碑的目標是否有被達成。
這樣的合作模式風險當然很高，雙方對於實際產出成果的合規與否，認知差距也往往很大，這也就是許多外包專案之所以會糾紛不斷，合作不愉快的主要原因之一。你也許會問，不是已經有ＳＯＷ文件說明一切要求了嗎？怎麼還會出現這樣的結果呢？
其實關鍵就在於，許多功能特色的驗收條件是無法用文件就能清楚表達的。例如，使用起來順不順手？觸感好不好？配色協不協調？（你有本事寫驗收條件給我來看看．．．）除此之外，還有每個人對於文字的解釋也都會不一樣，人們往往傾向於對自己有利的方向去解讀文字，這是天性，也是無法改變的事實。那麼，到底我們該怎麼辦才好呢？
這就是為什麼敏捷方法又開始漸漸被大家「拿回來」的原因了。之所以用「拿回來」的字眼，是因為敏捷方法並不是什麼橫空出世的新理論或新發明，它其實是早在二、三十年前就已經存在的許多好東西的組合體。想弭平甲乙雙方對於成果的認知落差，最簡單，也是最極端的方法，就是讓甲乙雙方都面對面地坐在一起辦公！
如此一來，雙方有甚麼疑問就可以馬上面對面地溝通；乙方有什麼新成果，甲方也可以馬上把玩、試用、給回饋；乙方收到甲方回饋後，可以馬上討論釐清、進行修正；接下來繼續給甲方試用。幾次這樣的輪迴下來，保證甲方對乙方做出來的成果會滿意到不行。
此外，因為雙方平時就已面對面密集溝通，乙方也因此可以「少做」很多以溝通為目的的文件（不是「不用做」）。等甲方滿意到可以驗收點交總成果了，乙方再把「應該要做好的文件」好好地做好、補齊。此刻，因為乙方已經沒有趕專案進度的壓力了，也就比較不會排斥「花時間寫文件」這檔事兒了。
這樣的合作模式是不是很理想呢？這樣的情境之下所產出的文件，還會不會沒有用？文件內容會不會更貼近最終的實際成果？還會過時無用嗎？我想答案應該已經很清楚了。
文件製作「質」與「量」
所以，要不要寫文件？該寫多少內容？該寫多深？這類文件製作「質」與「量」的問題，都應該回歸到該文件的原始初衷是什麼來思考。如果可以常常面對面溝通，又不需要留存紀錄，那當然就盡量不要花時間寫該類溝通用文件。如果專案目標會一直隨市場變化而變動，功能特色會一直改來改去，那當然也不應該在一開始就花很多時間去刻文件，因為大部分的文件內容可能很快會過時無用，徒然浪費團隊許多時間。但這些都不表示，團隊就可以從此不用寫文件，這完全是大錯特錯的觀念！
回到供應商以更改工作流程為敏捷方法為由而拒絕客戶的文件要求，這根本就是在呼嚨客戶，因為敏捷方法從來就沒有說過可以不用製作文件！而供應商以製作Prototype（原型）為由來拒絕客戶的文件要求則更離譜，因為天底下沒有一種客戶付費的產品原型是可以既不先跟客戶討論，又不提供線框圖（wireframe）文件，就逕行自行製作的！
從為數不少的學員提問當中，我發現到，不少組織在嘗試導入敏捷方法的過程中，就像故事中的那家供應商一樣，總是往「假敏捷之名，行偷懶之實」的方向走，只挑對自己有利的來做（例如，不想寫文件），卻不對重要卻較難推動的障礙加以排除（例如，團隊成員間以及團隊與客戶間都需頻繁密集地面對面溝通），成效當然就容易受限，不如預期。有志藉敏捷方法改善專案、團隊或整體組織績效者，對此不可不慎。
圖片來源：pixabay.com
相關文章：
圖片來源：pixabay.com
相關文章：