條件的情況下派專人去現(xiàn)場，隨時記錄關(guān)鍵性的需求，即使不能去現(xiàn)場也盡可能的獲取盡可能多大信息，不要指望開發(fā)后去獲取什么有價值的東西。那么是否應該做個原型給客戶看看？我是覺得這不大合適，因為如果項目周期短的話，等你做好原型，黃花菜都涼了。但我覺得等到需求做到差不多的時候可以做用戶界面，所謂用戶界面就是用戶接口，是和用戶打交道的地方，所謂一圖解千言，有了界面用戶會清楚自己所買的東西在未來會是個什么樣的東西，再者開發(fā)幾個有說明性都界面倒是不會暫用很多時間。等到需求確定下來后就要整理成文檔了，這個是很重要的一步，是做設(shè)計時候的重要憑證和依據(jù)，這個文檔就是用戶規(guī)格說明書，所謂規(guī)格就是有規(guī)范的格式和內(nèi)容。
3 需求評審
我們已經(jīng)有了較正規(guī)的文檔了，那么下一步就是召集所有開發(fā)人員開會，最好有客戶代表參加，盡管我是很厭煩開會，但該開的會還是要開到，因為之前我遇到這種情況，開發(fā)人員根據(jù)設(shè)計文檔寫代碼，可是他并不知道自己在開發(fā)什么，站在自己的角度想一下，如果自己都不確定自己做的東西，即使有再完備的設(shè)計，也會對開發(fā)毫無興趣，只會讓自己覺得自己是個代碼機器。所以所有人員參加需求評審是讓大家知道自己在做一件有意義的事情，自己正在滿足社會的需要，自己在為和諧社會做貢獻，即使你從沒那么想過，那你敢保證的你的潛意識沒那么想過嗎？人是要有社會滿足感的吧。另外開會前一定要準備關(guān)鍵有價值的議題，據(jù)我觀察需求評審會最容易扯到不著邊的話題，所以主持人要控制話題，會議控制在2-3個鐘頭，最好做成幸運52的形式，所有人員一定要互動起來，否則就變成了個人演講。需求也做了，會也開了，那么要求客戶簽字吧。
4 需求管理
需求管理是在開發(fā)開始之后進行的，這也是另所有人頭疼的一件事，之前做完一個項目后，客戶經(jīng)常打電話找我們，改過來改過去，后來我聽到電話，血壓都要升高50個百分點，后來索性就不接電話，客戶就在網(wǎng)上找我，搞的我連QQ都不敢登，但躲是躲不掉滴，客戶直接打我手機，丫的真煩人，見過難纏的，沒見過這么難纏的。后來轉(zhuǎn)念一想，難道這種情況真的不能避免嗎？至少是可以大幅度的緩解的吧。這就是我們需求管理中的變更管理沒做好，改了哪些地方自己都忘記了，最后是跟著感覺走，拆東墻補西墻。在這里我建議要建立需求跟蹤矩陣表，有了這個表我們至少可以對要修改的地方有了依據(jù)，迫使我們?nèi)フ{(diào)查到底是改什么地方，怎么改，最后改成了什么樣?？赡苣銜f客戶需要大幅度修改原有計劃，很難跟蹤到具體某一項需求，那么我覺得這是由于前期的需求開發(fā)沒有做好，在后期客戶進行實質(zhì)性的修改的幾率是很小的，比如客戶要求我們做個OA系統(tǒng)，最后總不會要我們改成個門戶網(wǎng)站吧，在舉個例子，在比如你開發(fā)一個ERP系統(tǒng)，客戶自己的業(yè)務流程不會輕易的改變吧，總不至于把盤點這個業(yè)務改成一個報表系統(tǒng)吧。如果真是這樣，我們完全有理由告訴客戶，你丫乖乖掏銀子，我們再給你們開發(fā)2期工程，要改，沒門！
二、項目規(guī)劃和項目監(jiān)控
上邊我簡要談了項目管理中的需求開發(fā)和管理，那么在這里就和各位以閑話家常的方式討論下項目規(guī)劃和項目監(jiān)控。項目規(guī)劃、項目監(jiān)控其實也是項目管理中比較核心的工作，也是很多開發(fā)人員最敏感的話題，因為這兩個東西與公司的領(lǐng)導和員工關(guān)系都非常的密切。
先從我以前的學校說起，以前我們學校有片荒地，當時的領(lǐng)導覺得學校應該搞綠化，于是組織在荒地上植樹，不到一年換了一個校長，這位校長覺得學校應該抓體育運動，決定再造一個足球場，于是把樹移走，造了一個足球場，再后來北京奧運會來了，學習為了迎合綠色奧運的理念又開始植樹，這就是沒有規(guī)劃和監(jiān)控的典型例子，結(jié)果是勞民又傷財。當