需求調研不充分是一個“坑”“泛項目”注定項目失敗

項目管理是一種實踐，其本質不在于知而在于行；其驗證不在于邏輯，而在于果。

項目干系人（特別是發起人Sponsor）往往會對項目團隊成員說“這個項目任務你跟進一下”、“這個項目任務要在一個星期之內完成”。

但“跟進一下”是什么意思？項目干系人并沒有把要“跟進”到什么程度給項目團隊說清楚（不遵循SMART法則），在執行過程中，我們不能奢求每個干系人都能把“跟進到什么程度”說的很清楚，但是作為專業項目管理者我們能決定的是，自己會用怎樣的態度去對待這個任務：如何理解這個需求、如何安排這個任務、如何監督這個任務的執行工作等。

項目的任務必須滿足SMART法則。所謂SMART法則，即目標必須是明確的（Specific）, 必須是可以衡量的（Measurable），必須是是可以達到的（Attainable），必須和其他目標具有相關性（Relevant），必須具有明確的截止期限（Time-based）。而且這五個原則缺一不可。

關于這個法則，在我的相關著作、博客、網站上都有詳細的探討和實例，讀者可以參考。這里我主要探討項目任務執行的過程中需要注意的問題。

一．“泛項目”注定項目失敗

現實的項目中，真正能夠理想化地將工期、費用和質量目標在啟動前就能夠定義清楚的項目、能夠完全按照商業合同來規范啟動的項目只是少數。

更多的是我們可以稱之為“泛項目”的項目，即不能預先將項目目標、范圍等定義清晰、只能大致明確其目的的項目。

伊拉克戰爭就是“泛項目”，人們在發動前只能確定它的開始時間，不能確定其結束時間，也不能確定其費用、WBS、Gantt圖等規范項目管理中需要的數據和方法；同樣，新產品研發（如抗SARS藥物的研制）也是“泛項目”，人們無法預知該項目將遇到何種技術難題、它們究竟需要多長時間才能攻克。

“泛項目”占了各類組織項目中的大多數，真正能夠規范定義的項目在數量上只是少數。通常“泛項目”不像大型的、正規的商業項目那樣引人注意，但由于其數量極多，如果不加注意，它們會像《笑傲江湖》中任我行的吸星大法一樣將組織的資源消耗殆盡。

二．需求調研不充分是一個“坑”

在軟件行業，在界面設計沒有正式展現給客戶之前，所有的工作都處于需求調研階段。其實房地產行業已經給我們做好了先例：客戶買房子之前是先要看看樣板房和模型的，什么都看不到這房子你敢買么？除非你不是自己住！

我們的軟件工程模型中，也有三個階段：需求調研、需求分析、概要設計。

在客戶把他們想要管理的業務模塊以及與之相關的業務數據、流程、表單交付你的時候，你千萬不要把這個階段定性為需要調研結束，認為寫出《需要規格說明書》就可以了。大量的實踐證明，在概要設計階段所衍生出來的需求工作量是之前的5~10倍，甚至更多，因為這要看設計人員的業務溝通能力和建模水平。

有實施經驗比較豐富的項目管理人員總結說，在中國實施軟件項目，必須以咨詢方式展開：要推出自己的方案，而不能完全按照客戶來提需求作項目。這是一種很好的解決思路，但無法解決所有實施項目的難題。這種解決方案的前提，要么項目實施者有成熟的業務模型，要么有成熟的產品(包含了成熟的業務模型)，否則是不可能做到的。但如果沒有3~5年在同一行業，同一領域的實施經驗和理論總結，沒有哪家IT企業能達到這樣的前提要求。

其實得出這樣結論的深層原因，是因為國內多數企業管理思想不成熟，更談不上完善的業務模型，所以客戶的思維一定程度是發散的，還未形成系統。甚至還有些客戶的領導，腦子中有很多新鮮的點子，他都有可能想在企業信息化的實施過程中加進來，這對把控項目范圍和項目實施效果來說，都可能是災難的開始。

所以，要做好實施項目，實施者必須有很好的業務建模能力，快速的給客戶展示合理的軟件原型軟件Demo。

根據多年的項目實施經驗，軟件實施項目，一定要給用戶看到樣板房軟件Demo，才算需求調研結束！

三．確認需求并執行到位

項目干系人在提項目需求的時候也許沒有明確說明他想要一個什么樣的結果，但是作為項目經理必須要明確你要給干系人一個什么樣的可交付成果他才會滿意。

如果你只是想要盡快完成項目需求，卻不去考慮要做到一個什么樣的程度、驗證標準、提交時間等，那絕對是對項目管理工作的一種褻瀆。項目經理應該有能力幫助干系人將需求明確到符合SMART法則的程度。

任何一個需求，只要雙方確認了，就有責任把執行到位，第一次就把事情做到100%，讓自己滿意，讓干系人滿意。