2 需求分析
為了得到用戶的金錢，我們總是在說，用戶是上帝，用戶永遠是對的，盡管背地里在說客戶端壞話：“你丫錢給的倒不多，要求還真少，這需求根本不合理，是正常人的邏輯嗎?”，如果你想活下去，最終我們還是要想方設法滿足用戶的要求。用戶是個外界因素，我們是無法控制的，那么我們只有盡可能改進需求分析的方法來盡量減少不必要的麻煩。那么我覺得日本人做法倒是可以借鑒，在有條件的情況下派專人去現場，隨時記錄關鍵性的需求，即使不能去現場也盡可能的獲取盡可能多大信息，不要指望開發后去獲取什么有價值的東西。那么是否應該做個原型給客戶看看?我是覺得這不大合適，因為如果項目周期短的話，等你做好原型，黃花菜都涼了。但我覺得等到需求做到差不多的時候Cye.com.cn可以做用戶界面，所謂用戶界面就是用戶接口，是和用戶打交道的地方，所謂一圖解千言，有了界面用戶會清楚自己所買的東西在未來會是個什么樣的東西，再者開發幾個有說明性都界面倒是不會暫用很多時間。等到需求確定下來后就要整理成文檔了，這個是很重要的一步，是做設計時候的重要憑證和依據，這個文檔就是用戶規格說明書，所謂規格就是有規范的格式和內容。
3需求評審
我們已經有了較正規的文檔了，那么下一步就是召集所有開發人員開會，最好有客戶代表參加，盡管我是很厭煩開會，但該開的會還是要開到，因為之前我遇到這種情況，開發人員根據設計文檔寫代碼，可是他并不知道自己在開發什么，站在自己的角度想一下，如果自己都不確定自己做的東西，即使有再完備的設計，也會對開發毫無興趣，只會讓自己覺得自己是個代碼機器。所以所有人員參加需求評審是讓大家知道自己在做一件有意義的事情，自己正在滿足社會的需要，自己在為和諧社會做貢獻，即使你從沒那么想過，那你敢保證的你的潛意識沒那么想過嗎?人是要有社會滿足感的吧。另外開會前一定要準備關鍵有價值的議題，據我觀察Cye.com.cn需求評審會最容易扯到不著邊的話題，所以主持人要控制話題，會議控制在2-3個鐘頭，最好做成幸運52的形式，所有人員一定要互動起來，否則就變成了個人演講。需求也做了，會也開了，那么要求客戶簽字吧。
|
