3.3 甲方乙方——商務項目全過程
需求分析已經開始，其中一個業務主管對項目組的抱怨非常大！
事情是這樣的：開發工作分成多個子系統，每個子系統有一個小組在分頭整理需求。但這名主管還要求安排一名人員跨系統統籌，負責統一各子系統業務規范。
比較強烈的一個要求是統一各個業務子系統的代碼表。代碼表是一張參數表，例如，憑證種類中“ 01代表身份證，02代表戶口本”，操作的時候從小鍵盤輸入數字比鼠標操作快得多，能減少操作時間，便于系統存儲和查詢。
但原來各個子系統是由不同廠商開發的，編碼不同，客戶希望改變現狀。但是，項目組的技術人員對這樣的工作不重視，遲遲沒有理會。這讓主管非常惱火，多次在會議上強調這項工作的重要性。
為了應付此事，技術人員出了個評估報告，說明如果真的要統一，不光要花大量時間去梳理，而且會多出很多額外的工作。比如，維護各個子系統的對應關系就需要很大的工作量；如果使用動態的參數表，每次操作都從數據庫中讀取數據可能會影響系統性能等。
客戶的業務主管不是技術專家，對這些解釋聽不太懂，但對這樣的反饋非常不滿，認為都是在找“借口”。小M知道之后找到了這位業務主管進行協商。
3.3.1 需求背后的需求
客戶主管終于等到有人關注這個問題，于是打開了話匣子，向小M說明了提出這個需求的背景。
原來，這是“綜合服務窗口”的要求。以前客戶辦理不同的業務需要到不同的窗口，這樣服務網點里有的隊伍很長，有的隊伍很閑，工作效率低，客戶滿意度也低。而“綜合服務窗口”要求同一個柜員能夠處理多種業務，因此，客戶到任何一個窗口都可以辦理業務，這樣既可以提高工作效率，也可以提高客戶滿意度。
以前，不同業務系統由不同的廠商開發，業務流程和界面差異較大，代碼表也是各有各的標準。但因為一個窗口只用一個子系統，不會有太大問題。但如果改成“綜合服務窗口”，如果有的業務中“身份證”代碼是01，有的業務中代碼是02，則會引起很大的混亂。
小M經常在項目組里聽到“綜合服務窗口”這個詞，不過剛剛才鬧明白是怎么回事。為了獲得更多信息，忙問業務主管在哪里可以看到這些需求的詳細說明。主管很詫異，“這是項目立項的時候就提出的業務流程改進方案啊，你可以去看看招標書，投標的時候你們就承諾了，不會現在不認賬吧？”
小M只看過合同，還真沒看過標書。于是找來了這些文件，發現其中不僅有對”綜合服務窗口”的詳細描述，還有很多其他方面的業務需求。而幾乎所有的功能需求，都是圍繞著這些業務需求提出來的，這些“需求”背后的“需求”，讓小M對很多分歧恍然大悟。
這是因為，雖然甲乙雙方在談需求，但出發點不同，造成了雙方關注點和思維方式不同。客戶關注的是系統如何支持業務流程，背后的需求是“實現業務目標”。技術人員關注的是合理技術方案，背后的需求是“工作量”、“實現難度”和“系統性能”。就拿這個例子來說：
從客戶角度考慮，業務目標之一就是“提高工作效率、提高客戶滿意度”。為了實現這樣的業務目標，流程改進方案就是實現“綜合服務窗口”。為了支持“綜合服務窗口”，就需要業務規范統一，因此提出了“代碼表一致”、“統一維護”和“子系統對應”等需求。
從技術人員角度考慮，上述需求只會影響到“界面操作”，不是一件重要的事情，但付出的代價很大：需要在數據庫保存代碼表，要為子系統作映射表，還要統一進行維護；而為了實現這個技術方案，需要付出額外的工作量、犧牲系統性能、增加了實現難度，如圖3-5所示。
由于最根本的出發點不同，在雙方進行溝通的時候，盡管在談同樣的需求，但是一面的出發點是“提高工作效率、提高客戶滿意度”，另一方面的出發點是“工作量”、“難度”和“性能”，不一樣的思維，不一樣的語言，溝通不暢就可以理解了。
3.3.2 雙方眼中的不同生命周期
甲方、乙方眼中的生命周期有什么不同呢？小M眼中“項目”的起點，在客戶眼中已經是“執行”階段了。因為在小M進入項目之前，客戶的“項目”早已經開始了，已經做了大量的論證和分析工作。這個過程有點像接力賽，但是因為遺漏了接棒之前的信息，所以造成了一些偏差。
小M按照客戶所說的一些項目的關鍵點，結合項目管理中的生命周期概念重新進行了梳理。發現客戶眼中生命周期是這樣的，如圖3-6所示。
第一，啟動項目，目的是識別需求。最初的“需求”是來自業務部門，比如工作效率低、客戶滿意度低等。為了解決這個業務問題，客戶內部對需求進行了確認，提出了主要的改進方法和改進目標，計算投資收益比，分析廠商所應具備的條件，最終完成了可行性分析。根據可行性分析結果，客戶批準了預算，完成了立項，項目就產生了。之后一個小組與咨詢公司一起細化了項目的需求和各種規格，發出了《招標書》。小M看到的很多業務需求，就是這個階段產生的。
第二，組織和準備，目的是確定解決方案。各個符合資質的廠商收到了招標書之后，根據規格提交了《標書》介紹自己的解決方案，以及報價。最終客戶根據公司實力、方案優劣和報價情況，選擇了小M所在的公司，進行商務談判并最終簽訂合同。小M在這之后才正式開始接手項目，這也是乙方眼中的項目開始。
第三，執行項目工作。目前小M要做的就是帶領項目組完成合同規定的任務。這時，項目成敗的責任通過合同轉移到了小M的公司頭上。小M要代表公司與客戶確認項目目標和范圍，制定計劃，協調資源完成需求、設計、實施工作，直到項目順利上線。上線標志著完成了項目交付成果和執行階段的結束，但是，項目并沒有結束。
第四，結束項目。系統上線之后，小M的項目組要移交工作成果，將系統交接給維護人員，結清各種款項。這時對小M來說項目可以結束了，項目的責任又重新回到了客戶身上。但是，對于客戶來說項目還沒有結束。客戶在接受新的系統之后，要使用系統實現原定的業務目標，根據運行的情況評估“工作效率是否提高、客戶滿意度是否提高”，從而確定項目的成敗。
如此看來，小M只是經歷了項目中的一段。由于沒有參加論證階段，所以可能遺漏一個非常重要的信息——客戶“為什么要做這個項目”。客戶一定知道在項目完成之后，“可以解決什么問題，能帶來什么價值”，這才是客戶心中的項目成功標準。
3.3.3 客戶為什么做這個項目
客戶為什么要做這個項目？這是最本質的業務需求。需求分析確定的功能需求，都是從業務需求推導出來的，都必須為業務需求服務。
舉個例子，客戶去買衣服的時候，一定知道自己為什么要買衣服吧？可能是“御寒”，可能是“漂亮”，也可能是“體面”，也可能是因為在打折。
一般的營業員會問客戶顏色、款式和面料等方面的要求，拿到一件就努力說明“這件衣服最適合你”，可能一件一件不停地試，但客戶始終都會挑出其他的毛病。
而有的營業員會努力弄清楚你為什要買，問你什么場合穿。然后，再幫助客戶作出取舍，如果為了御寒會強調保暖性能，并請你適當犧牲漂亮；如果是為了漂亮，就要找款式新穎、顏色流行的，強調價格是合理的；如果為了“體面”就要找面料和做工好的，就要適當犧牲價格；如果是為了便宜就要強調性價比，并對比以前的價格。
小M他們犯的錯誤，是第一種營業員的錯誤。上來就聚焦在功能需求上，一下子扎在了功能需求如何實現上，而忽略了 “客戶為什么做這個項目”。
這樣看來，“按期交付”只是項目的最低要求。交付的成果能“解決客戶的問題、給客戶帶來價值”，才能讓客戶成功，才能讓客戶滿意。
想讓客戶滿意，就一定要站在客戶立場上考慮問題；站在客戶立場上考慮問題，就要了解客戶的業務，弄清楚客戶為什么有這樣的要求；如果弄清楚了這個“為什么”，對于什么是重要的、什么是不重要就容易判斷了。
想到這里，小M和技術人員再次找到了業務主管，認真傾聽了主管的需求，并一起討論解決辦法。討論中發現了一些重要信息。例如，其實代碼表并不經常改動，所以每次從數據庫訪問的方式確實不可取。而比較合適的替代方案是幫助客戶建立一個數據字典管理各種代碼表，并在需求分析的過程中進行維護。而開發的時候，可以通過一個小程序自動根據數據字典產生下拉列表。為了便于項目結束后客戶能自己維護，還專門設計了一個使用方便的小工具。
這個方案開發工作量不大，對性能沒有影響，主要工作由客戶方面承擔，還可以保證客戶的長期維護。因此，客戶的業務主管對這樣的結果非常滿意。其實，項目組并沒有按照客戶最初的要求去工作，但是在了解了客戶真正的需求之后，提供了一個更好的解決方案，達到了雙贏的局面。
3.3.4 經驗與教訓
由于甲乙雙方的立場不同，關注點不同，很多事情會產生分歧。要想獲得客戶的滿意，必須從客戶的角度看問題，了解客戶表面需求背后的“需求”，因為這是客戶判斷項目成敗的標準。
