挨踢項目求生法則-需求篇

知道什么是挨踢項目吧？什么！不知道？那IT項目知道了吧？為了不讓客戶踢、不讓老板踢、項目組成員之間不互相踢，俺為大家分享一些減少被踢機會的心得體會。就算不能讓項目成功，也至少不會死得那么慘吧！我將分戰略篇、團隊建設篇、需求篇、設計篇、編碼篇、測試篇、實施篇和計劃篇為你分享。

摘要：

知道什么是挨踢項目吧？什么！不知道？那IT項目知道了吧？為了不讓客戶踢、不讓老板踢、項目組成員之間不互相踢，俺為大家分享一些減少被踢機會的心得體會。就算不能讓項目成功，也至少不會死得那么慘吧！我將分戰略篇、團隊建設篇、需求篇、設計篇、編碼篇、測試篇、實施篇和計劃篇為你分享。

 

作者：張傳波
www.umlonline.org/school/

 

由“我要吃飯”的故事想到的

某天某客戶跟你說：“我要吃飯！”

你非常關注客戶這個需求：“請問您要吃中餐還是西餐呢？您想吃什么呢？”

客戶非常開心，一下子說出了很多想吃的：
“西餐嘛，不錯，聽說那個菲力牛排很不錯，配上紅酒更加美味！”
“不過聽說某某路的那個潮汕牛肉丸火鍋，牛味很濃，牛氣沖天……”
“哎呀，最近上火，還是不吃這些上火的東西了，吃日本壽司吧，聽說那里有日本菜自助餐，有生蠔，正啊！”
“啊，不行哦，最近日本核輻射，海鮮還是不吃了”
……

最后客戶說：
“你還是先弄一頓給我嘗嘗吧，見到菜才能提出具體需求啊！”

遇到這樣的客戶，你可能想找10個饅頭塞到他嘴里面，讓他撐飽，搞定！

以上故事純屬虛構，如有雷同實屬不幸！

這個故事是軟件項目需求工作的縮影，客戶的表面需求似乎很多，而且變來變去，很可能是因為我們沒有抓住“我很餓”這個根本需求。客戶可能提出很多匪夷所思的需求，提出一些超出自己預算范圍的需求，如果我們能抓住客戶的根本需求，讓客戶認識到自己的預算限制，再加上我們高水平的發揮，我們是有可能做出能滿足客戶根本需求，并且符合預算的軟件系統。 

 

需求分析與需求管理

我們可能經常聽到一些關于需求方面的說詞，如：需求開發、需求分析、需求調研、需求管理等等，下面將這些概念稍微梳理一下。
1）需求分析：
其他說法：需求調研、需求開發
關注點：如何獲取和確認需求？
2）需求管理：
“雙贏”：客戶能贏，我們也能贏！在“雙贏”的基礎上，處理以下問題：
    a）如何簽署需求？
    b）如何處理需求變更？
需求驅動地工作。
    a）用需求指導計劃、設計、編碼、測試、實施等工作。
    b）不做或少做與需求無關的事情。
需求分析和需求管理的工作，我統稱為需求工作。需求工作中的問題有些是需求分析的問題，有些是需求管理的問題，或者是兩者兼而有之。

法則1：搞清楚需要

解決肚子餓的問題，是客戶的根本需求，客戶的根本需求或者說需求之源泉，我稱之為需要！如果客戶是公費吃喝的，嘴饞想吃東西，那么滿足這個需要的做法又不太一樣了。
客戶一般不會直接說出需要，往往提出的是他自認為能解決這個需要的某種解決方案。“我要吃飯”只是表面需求，透過這個表面需求，找到需要是需求工作的根本！我們需要思考：客戶為什么有這樣的要求？客戶希望解決什么問題？如果找到客戶的真正需要了，那么我們需要進一步思考：有什么簡單的方法可以滿足客戶的這個需要？
客戶的需要其實很少會變的，變的是那些表面需求，多問問我們自己：我們抓住了客戶的需要沒有？有些客戶對自己的需要很清楚，但有些客戶可能只有朦朧的想法，我們需要總結出客戶真正想要的東西并與客戶確認。

法則2：搞清楚限制條件

10塊錢解決肚子餓的問題，和100元解決肚子餓的問題，差異可以很大，所謂的看錢吃飯！
如果我們能搞清楚客戶的需要，其實10塊錢也可以有比較完美的解決方案的，可以去大排檔吃個面、炒粉之類的，不是不可以的。某牛筋丸湯粉，才10塊錢，但有8個牛筋丸，味道好極了，而且可以飽肚子！
除了預算，系統的技術條件限制，需要與第三方系統接口等其他限制條件，也需要事先搞清楚。需要、限制條件要和客戶高層達成共識，一起努力找出在限制條件下可以滿足需要的需求解決方案。

法則3：持續確認

曾經有人問我，幾十頁甚至上百頁的需求規格說明書，如何讓客戶確認？
我反問：這幾十上百頁的需求文檔是閉門造車寫了n天后，才給客戶確認的嗎？對于客戶來說，該文檔是從天而降，他之前沒有見過其中任何的內容嗎？
需求不是等全部寫出來才去確認的，要持續地逐步地確認。我曾經做過一個項目，連續5天進行需求調研的工作，第5天幾十頁的需求文檔寫出來了，給客戶簽字確認，客戶很快就簽字了！這份文檔的絕大部分內容，在之前的4天他都曾經確認過，第5天只是一個最終的確認而已。
持續確認好處：
1.能盡快發現問題，能幫助我們盡早確認需要，避免后期可能的需求變更。
2.客戶能逐步消化需求。

法則4：不要“二手需求”

曾經有一個某政府部門的項目，系統是各業務部門使用的，但需求只能從信息科那里獲取。信息科的人自認為很牛，對項目組說：“需求向我們要就可以了！”而這個項目上線后，具體使用系統的部門就是不買帳，最后這個系統由信息科驗收了。
信息科提供的是“二手需求”，向客戶調研需求時，一定要避免“二手需求”！

上述案例你可能會覺得有點好笑，其實“二手需求”在項目組內也經常會發生。
某測試人員問為什么要做這個功能？開發說：這個你不用管，你這樣這樣測就可以了……
某實施人員覺得某功能看上去不太符合邏輯，提出疑問。開發說了一大通實施人員聽不懂的技術用語，然后實施人員只能憋著不說話了。
項目組的測試人員、實施人員應該接觸第一手的需求，最好能直接面對客戶，而不是通過開發人員轉述需求。

法則5：成為業務專家

你可能遇到過這樣的情況，客戶經常抱怨軟件不好用，然后我們問：如何不好用？客戶好容易說出了一些要求，我們按照這些要求修改了系統，但客戶總是不滿意，總是說不好用。諸如此類，不斷重復。
客戶說啥，我們做啥，是比較落后的一種層次。我們應該處在客戶的利益，提出超出客戶想法的解決方案。要打造有競爭力的產品或項目，成為業務專家是必須的，不能偷這個懶，不要僅停留在需求調研這樣的層次，而是要引領需求，給客戶帶來更先進的知識和管理辦法。

法則6：需求是“設計”出來的

手機訂餐系統的故事我經常拿出來舉例子，大意是：
某公司有一個訂餐系統，但高層要求在這個基礎上做一個手機訂餐系統，讓外出工作或請假的同事可以方便定午餐。手機訂餐項目組花了九牛二虎之力，終于弄出這個系統，但問題多多。高層領導很不高興：這點小事都折騰這么久！后來有人說：外出工作或請假的同事，打電話回公司，讓前臺幫忙訂餐不就可以了？
“解決不方便訂餐的問題”是需要，而“手機訂餐系統”只是可以滿足該需要的某種解決方案，我們完全可以通過其他更加簡單的方法來滿足需要。我個人觀點：除了需要是來自客戶的想法外，系統要具體做什么功能之類的需求，不是通過問客戶問出來的，而是我們根據客戶的需要，理解了客戶的業務流程后，并根據限制條件，設計出來的！當然客戶提出來的想法，會給我們帶來很多啟發，但我們不應該僅停留在需求調研的層次，而是提供一個高性價比的需求解決方案。

法則7：七分需求分析，三分需求管理

遇到客戶變來變去的情況，我們可能第一反應是：有沒有搞錯！當初就應該讓他簽字！最好就是錄音！
如果我們連客戶的需要都搞不清楚，就去抱怨客戶需求變來變去，那我們的水平未免有點低了。其實真正很難纏的客戶、不講道理的客戶很少的，只是我們水平未夠，不能理解或找出客戶真正想要什么，才讓我們誤以為客戶變來變去。
需求工作可能有很多問題，應該以做好需求分析工作為主，而需求管理為輔，兩者比例大概是七三開。需求分析工作做好了，需求的問題可以減少很多，而且客戶也會非常認可你的專業水平，這樣后續的工作就比較容易處理了。
當然也可能會遇到很難纏又不能繞過的客戶，遇到這樣的情況，建議你看看“挨踢項目管理求生法則-戰略篇”，如果從戰略上判斷該項目有很大問題，那么最好不要做這個項目，如果不幸要負責這樣的項目，那么記住其中一個法則“輸少當贏”。 

 

如果本文對你有幫助，麻煩點擊一下“推薦”，謝謝！

 

作者：張傳波
www.umlonline.org