摘要：需求是一個項目的根本，是用戶所要求最終要實現的功能，一個偏離需求的項目，即使你做得再完美，也只能是一個失敗品！如果你不能很好掌握需求，帶來的將是項目開發中無窮無盡的改動。
由于換工作到原因，到現在公司的時候，項目已經啟動。但我們手上掌握的需求，卻是聊聊無幾。除了幾個大功能點的概述，其余均空缺，用戶的意思是：你們先做，做出來我們再來提建議修改。由于項目組是新成立的，且當時我們人員尚未全部到齊。使得整個項目組缺少一根主心骨，在一切都還不確定的情況下，項目就這樣開始草率的動工了。所的需求都是在開發過來，得到一些零星的描述，整個項目也未成從整體上進行設計。至今日，已有3月有余，已經超過了客戶商定的日期數日。至昨日起，用戶方才開始對整個系統進行全部測試，測試的結果是令我感覺到汗顏和無語，整個結果在意料之中，情理之外。不錯，客戶對很多功能，流程表示不滿意，提出新的功能需求，突然覺得自己好像已經踏進了一個無底洞，沒有一份需求的合同，這意味著：客戶可以無限制，無條件的讓你加功能，無休止的和你糾纏。沒辦法，為了項目尾款，我們只能硬著頭皮上，誰叫顧客上帝列？
因為工作環境的原因，之前公司開發流程之規范，與現在公司的開發流程簡直是天壤之邊。這是我所史料未及的。帶來的教訓當然也是很慘痛的，以后相當長的一段時間，都將生活在與客戶的糾纏中。
第一：項目開發之前，要盡可能細的挖掘用戶的需求，與之確認所有細節問題（用文字和UML來搭配描述），并與客戶簽訂需求合同。如遇后期更改，需雙方再次確認，并商議項目資金問題。
第二：項目開發之前，一定要進行詳細整體的設計，并需要項目組多次開會討論設計的合理性和擴展性。切不可臨時抱佛腳，做一塊設計一塊，茍延殘喘。
第三：與程序員的溝通問題，確認各自模塊的流程時，除UML外，一定要有詳細文字性說明。
第四：跟客戶的交流，要把握好尺度，不可過于牽就，亦不可過于自我，一方面要細聽用戶需求，對合理的部分要進行挖掘，細化。對不合理的要求，要給予否定。