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

摘要：

知道什麼是挨踢項目吧？什麼！不知道？那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