前些年在我第一次接觸到Scrum的專案管理方式，我發現確實比傳統的瀑布模式還更能產出最符合客戶需求的產品。(雖然說在這之前的開發也沒真的遵從瀑布模式就是了) 所以我就努力的去瞭解一下Scrum的概念。
簡單說明一下，Scrum的特色在於產品擁有人(Product Owner)固定每個週期都跟客戶開一次議並提交一個進度，好確認需求是否有跑偏掉。團隊(Scrum Master, Product Owner, 及開發者們)內部每一兩個星期也要開一次衝剌(進度)會議，以確認上次衝剌會議所交辦的任務是否有明確完成。同時檢討目前手頭上任務的先後順序是否需要重新調整，等事項。更精實一點，每天團隊都要開一個10至15分鐘的站立會議(站著開會，免得不小心開太久)，好確認一下當天要做的事項以及可能發生的問題，所需的資源等等。這一切的一切都是為了一個目標，那就是：
專案必需在不偏離客戶需求的狀況下被完成
在這看似美好的專案框架，或許在歐美的文化下能順利的被完成(或許吧，我不確定)。但這放在台灣的華人文化底下去運行，簡直找死。Orz…
首先我的認知是，華人文化都有一種「先做再說，後面再來調整」的心態。這對於不斷的規劃卻一直踏不出下一步的創業家或公司營運來說，確實是一帖靈丹妙藥，但對於接案或外包產業，卻是一場災難。如果客戶清楚的知道自己要的是什麼，那一個專案的開發上，我當然很樂意保有彈性的讓客戶稍微的調整需求。又或者有部分客戶都不清自己要的是什麼，但可以再經由充份的溝通後，定義出相對完整的需求，這樣也很好。但好多客戶都是有個基本的概念就急著找外包做開發。
傳統上，我們定好需求文件(或叫規格書)之後，就會根據這份需求文件下去簽約。需求要改變，那就加錢加時間。(通常為了和氣生才，適當的改變不會加錢或時間，這部分的拿捏就很吃經驗了)，中間除了報進度之外，很少討論需求以外的事，如果有要改需求，是的，加時加價。這對外包似乎還是比較有保障一些。但做出來的東西就很容易跟客戶要的不一樣。因為一開始談定的需求文件，畢竟只是抽象的需求，客戶在看不到成品的狀況下，只能靠想像的方式去推測這是不是他要的結果。
為了更好的服務客戶，也為了讓自己的作品免於養蚊子，這時候我想說推動Scrum來接案看看。沒想到還真的是一場災難。上述提到Scrum的特色就是在開發過程中不斷的跟客戶開會確認需求。這就意味著客戶會根據我們在開發的半成品，來確認做出來的東西是否符合他們的需求並提出修正。但這也代表著，客戶如果跟你說這不完全符合他們的需求之後，他就會提出「他認為」的需求。
「他認為」！是的，整個災難就是從這三個字開始的。還記得我提到華人文化都有一種「先做再說，後面再來調整」的心態嗎。沒人知道「他認為」的需求是一開始在簽約時就談好的，還是開發到一半時不曉得從哪或得什麼新資訊，結果半途加進來的。他們總是會想，先做出來之後「後面再視狀況來調整」。或許我們可以跟客戶說，這次的需求修改跟最開始談定的需求差太多了，但你會發現客戶在跟你簽約時所定的需求都只是一個「大概」。這些後面補上去的需求都是細節，這些細節卻可以隨他改來改去的。而且改了需求，也不一定讓你拉長專案時間。並且總會出現一句「這案子的時間很趕，那就再拜託你了」。
這時又會有人說，那在一開始就把需求訂細一點不就好了嗎？其實一直以來都很多需求分析的方式，可以明確的定義客戶的需求，但那需要花費相當多的心力去進行。最重要的是，這個時間點的你還沒跟客戶正式簽約。在簽約之前，客戶幾乎是不太會付錢給你，因此會有很大的概率發生你辛苦花費了非常多的時間跟心力去幫客戶分析需求，最後他們會以你報價太高為由不跟你簽約，這樣你就作白工了。這就算了，如果你還發現，你整理的需求文件，直接被他們拿去給下一個外包廠商估價的話，你應該會氣死。
Scrum的另一個特色就是定期開會，確認需求。這會讓客戶有更多機會調整他的需求，如果一個月開一次會，那這可以逼得客戶想清楚他要的需求後，下個月再跟你討論。如果是一個星期開一次會，他差不多一個星期就能變一次需求。不跨張，我真的遇過，這是經驗不是幻想。有時候開會的時間間隔稍微拉長一些，讓客戶好好的醞釀一下自己的想法，也不失為一個辦法。
如果是公司內部本身在實施 Scrum，那Scrum或許就是個不錯選擇。如果外包人應要用上Scrum嘛，那只能將所有希望寄託在跟客戶溝通的人身上了。(在台灣的話，通常是業務；硬要找一個Scrum團隊的話，那應該會是立場最接近Product Owner的人)
補充一下：Scrum 需要整個團隊去運作，我只有單人接案，所以是一人身兼多職的採用Scrum的概念。勢必會有運作上的缺失及經驗上的錯誤。如果有我不知道問題，還請您跟我說一下，互相學習。這篇的重點在於，客戶在需求上的反應，如果搭配了Scrum的特色的話，這點應該不會差太多才對。
