身為打雜工程師，整個軟體開發專案中最令人痛不欲生的莫過於文件 (paperwork)，這一點我想很多工程師都無異議。我碰過很多技術滿強的工程師，有不少人是直接宣告天下絕不寫文件的，也有很多人升級到寫文件的角色以後（例如 SA）非常痛苦天天喊著要回去寫 code，同樣身為工程師我完全可以理解這樣的心情。真正跑過幾個專案以後，寫文件真的是令工程師們愛恨交織的一件事情，我為什麼會用「愛恨交織」來形容呢，之所以恨的原因就不必說了，但是工程師們 你也應該要愛文件，因為 好的文件讓你和客戶都可以上天堂，壞的文件直接讓你下地獄（客戶則不一定） 。

對大多數工程師而言，和電腦溝通永遠比和人類溝通來的簡單直接，人一直是專案中最複雜的因素。但是今天一旦你參與了一個 有著糟糕合約與文件的專案，即使是單純的寫 code，無止盡的更改和遙遙無期的驗收絕對會讓你痛不欲生。非常可惜的是，專案中負責去洽談溝通下決定簽合約的在真實世界中往往是沒有技術力的角色（一般倒霉的狀況下），所以在經歷數次的專案之後我明白了一件事情，就算我自己是工程師，文件中該我負責的部分我還是需要自己審核（當然大部份時候是自己寫啦），就算是極為討厭我也會逼自己做這件事，因為在一個專案中，這是工程師唯一能保護自己（和公司）的機會。

心理建設

心理建設

合約文件這件事情其實可以簡單地把它理解成 醜話說在前頭 (XD)

怎麼會這麼說呢，這雖然是半開玩笑但其實也是真實情況，對客戶端來說，「醜話說在前頭」我付這些錢就是要在這個時間拿到這些東西，對廠商端來說就是「醜話說在前頭」我拿這些錢就是會在這個時間內完成你上面說要的那些東西，老話一句，合約是保護買賣雙方的「最後一層保障」，在雙方決定合作前，其實兩方都做好最基本的心理建設就比較可以減少爭議。

客戶端應該要有的心理建設 -

• 委外這件事只是把事情做完，而不是把事情做好

在我第一次真正和客戶接觸的駐點經驗裡，總是天天為了「這個功能合約裡沒有」，「那個功能需要後續擴充」這種事情費了很多心神，同時話術等級也在那一段時間稍微升級。在我說「合約裡沒有寫要做這一項」的時候就曾經有客戶和我 argue 的一句讓我永生難忘的金玉良言：
「合約裡沒有說要做，但是合約裡也沒說不做啊！」

當下我真是瞠目結舌，不知道哪裡來這麼沒常識的人，那合約裡沒說我不需要掃地是不是我駐點的時候也應該順便掃個地呢 XD

所謂委外這件事，請一定要讓客戶有心理準備，這只是把事情做完，而不是做好，委外廠商如果願意更改客戶無止盡的變更需求那是佛心來著，但是如果不願意，只要有做完合約上面的項目，就可以有憑有據的讓客戶知道「合約的要求已經達到了」，如果需要把事情做到十全十美，請客戶要有自己養一支開發團隊的氣魄。

• 變動規格不是不行，只是要加錢加時間

當然，因為委外只能把事情做完而不是做好，所以變更需求就會變成一件很痛苦但是一定會發生的事情，尤其是常常客戶其實並不知道自己要什麼，導致「真正的規格」會在開發快完成以後出現。有時候客戶人比較好，會覺得自己比較理虧願意用後續擴充的方式去做規格變更，但是有一些比較沒有委外經驗的客戶會以一種以為是簡單的買賣商品的態度或是以為廠商是服務生擺出「你們應該要以客為尊」的態度強逼開發端修改，不改不給驗收，不驗收也就等於沒有現金流而且無法結案。為了減低讓客戶大變身成這種形態的預防針，請務必讓客戶了解這一點。

• 只要合約完成，廠商就應該收到款項，不合意或逾期的話可以最高罰到 20%

因為軟體開發不同於一般以物易物的交易，其實是一種勞務工程合約，這樣的合約形態在
政府採購法與民法有明文的規定，就算客戶不滿意最後的成品，只要有達成合約，就至少會給付到 80% 的款項，因為廠商端已經投入了人力物力下去開發，這一點請客戶一定要有心理準備，不要訂出「完全不給付」甚至「倒扣」讓廠商血本無歸這種罰則出來，因為軟體開發不是在 PCHome 買東西有七天鑑賞期免費退回的。所謂公平公正的合約關係在罰則中可以一覽無遺，如果客戶對付款時間及拒付訂金或不合理罰則條件堅持或者糾纏，請一定要有心理準備接下來要寫許多很精細的文件來保護自己（或是有決定權的話，千萬不要簽約）。

寫完了讓客戶應該要有的心理建設，接下來就是工程師要有的心理建設，尤其在你有一個搞不清楚狀況的 PM 的時候（可以的話順便建設他）。

開發端應該要有的心理建設 -

• 在審查時間之內，小幅更改規格是可以被接受的

所謂的小幅更改規格，就像是客戶想要在整個排版上移動一下搜尋框從右邊到左邊這種，或是可不可以小小加個顏色，類似這樣沒有功能上的調整的事情，「審查時間」之內如果順手就改吧，促進皇城之內的和氣。如果團隊有在使用任何 Issue tracking system (例如像是
Redmine)等等更好，這也是寫文件保護自己的一種方法，因為當客戶修改次數過多的時候你可以拿這些歷史證明出來讓客戶明白：「你已經很盡力了」。

• 拒絕不了的大幅更改，就納入附約（後續擴充）中

把客戶要求的不在規格中的功能記錄下來，建議在後續擴充裡面，這比起在現階段直接拒絕掉來得好許多，一方面來說，即便是委外案，雖然有做完合約向就是盡到廠商的義務，但是交付客戶所真正需要的軟體才是開發者所應該追求的目標，當然這基本上不太可能真正做到，只是一定要有這樣的想法才比較不會因為客戶無止盡的修改造成心理上非常疲憊的開發狀態，另一方面來說，也讓夾在中間的 PM 好做人，往好的方面想這個案子結束以後還有擴充合約可以做。

• 客戶常常是不知道自己要什麼的，PM（甚至沒有技術的 SA） 常常是不了解狀況的，所以應該要寫文件

最恐怖的事情莫過於你覺得完成了合約項，客戶認為你沒有真的完成「他要的」合約項，然後 PM 就隨便地答應一堆客戶要求包免費工程回來給你做，為了保護自己不要掉入無限修改無限保固的地獄，請一定一定要確保 產品規格 與 驗收條件，我相信每一個工程師都願意為客戶的需求做到相對完美的設計，但是很多狀況下是因為無窮的折磨消耗了開發端的耐心與產能，最後演變成客戶與廠商都不得不互相 defense 對方的情況，而文件，尤其是工程師能寫的文件，說不定會是這種狀況的唯一解藥。