摘要：
知道什麼是挨踢專案吧？什麼！不知道？那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
挨踢專案求生法則 設計篇
摘要 知道什麼是挨踢專案吧？什麼！不知道？那it專案知道了吧？為了不讓客戶踢 不讓老闆踢 專案組成員之間不互相踢，俺為大家分享一些減少被踢機會的心得體會。就算不能讓專案成功，也至少不會死得那麼慘吧！我將分戰略篇 團隊建設篇 需求篇 設計篇 編碼篇 測試篇 實施篇和計畫篇為你分享。什麼叫挨踢專案？it...
挨踢專案求生法則 計畫篇，計畫趕不上變化！
摘要 計畫趕不上變化，計畫還要不要寫呢？專案工期限死，估算有什麼價值呢？只有專案經理緊張專案，其他人是打工心態，怎樣辦呢？pmp的知識能搭救專案嗎？如何才能做出乙個按期交付的完美計畫呢？所有問題，將在這一篇中大爆發！說明 什麼叫挨踢專案？it專案，特別是軟體開發專案，都屬於 挨踢 專案的範疇。挨踢專...
挨踢專案求生法則 計畫篇，計畫趕不上變化！
摘要 計畫趕不上變化，計畫還要不要寫呢？專案工期限死，估算有什麼價值呢？只有專案經理緊張專案，其他人是打工心態，怎樣辦呢？pmp的知識能搭救專案嗎？如何才能做出乙個按期交付的完美計畫呢？所有問題，將在這一篇中大爆發！說明 什麼叫挨踢專案？it專案，特別是 軟體開發專案，都屬於 挨踢 專案的範疇。挨踢...