常見的原因之需求問題
需求中的功能點要在prd（產品需求文件）中羅列清楚，業務流程要寫得完整清晰，互動細節要體現在視覺稿中。要組織專案組所有成員參加prd評審，評審時要 針對具體的問題，給出明確的處理意見。暫時不能確認的問題，問題跟進人要在限定時間內給出反饋，專案經理可以制定問題跟進**。
專案進行中 的需求變更，盡量在前期提出。在專案管理的過程中，當前期的需求和計畫都確定後，專案經理不能只顧著跟進開發和測試的進度，也要階段性地和需求方多溝通， 讓他們及時反饋意見。不要等到臨發布時，產品經理跑過來說「我要的不是這樣的，這裡要改一下」。永遠不要把問題留到最後一分鐘，要超前一步，留有餘地。下 面是乙個真實的案例。
案例情景：該項目的整個週期為2個月，有3**能測試。當第3**能測試結束時，也就是即將進入預發布階段時，產品經理才給出使用者反饋並要求按使用者的反饋修改。改動的地方涉及到頁面的樣式、文案、sql語句和校驗邏輯等，總共可能有20多個檔案要被改動。
專案管理問題之需求變更
案例情景 該專案整個週期為2個月 有3 能測試，當第 3 能測試結束時也就是即將進入預發布階段時，需求提出方才把使用者反饋資訊給了我們，要求我們按使用者的要求去改。改動的地方涉及到頁面的樣式，文案，sql語句，校驗邏輯等，總共可能有 20個左右的檔案要被改動。我們建議只改頁面的樣式和文案，其他部分先...
腳印之需求惹禍 聽他的沒錯的？
今天想寫寫該聽誰的這個話題。朋友說有個專案，專案是使用者希望用php基於drupal開發乙個商務 我問使用者是搞技術的嗎？他說不是。我又問那他使用php和drupal是別人給他建議的嗎？他說不是，是使用者自己上網查的。我說使用者提的這個可能有問題，需要梳理一下。朋友說使用者提需求讓你做，你卻告訴人家...
IE載入OCX外掛程式崩潰原因之棧溢位問題
最近遇到乙個問題，乙個部門的同事提供的dll庫使用棧記憶體較大，我這邊使用vs2013控制台程式測試時出現崩潰。崩潰原因是棧記憶體不夠用導致，於是我將vs的棧保留大小設定為100m，然後就可以了。現在需要把他的dll庫整合進ie使用的ocx外掛程式，發現ie在使用到這個庫函式的時候崩潰。實際上ocx...