每次增加新的需求或是功能做變更時
一般的開發流程是：
提出需求（一般是使用者或者策劃工程師）
講解需求（提出需求者或者需求工程師對開發者講解）
開發者理解需求
開發者開發
測試完成驗收。
我經歷過的開發基本就是這樣的步驟，但是做了這麼久開發，我總能經歷到這樣乙個現象：
一般新增需求更明顯一些，那就是當講解完需求後，一般來說很少再開全體會議再次講解需求了。但是當開發者第一次聽乙個新的需求時，可能並不能完全理解這個需求，或者需求工程師也不完全就將所有情況考慮到位了；開發者也不可能在聽完一次需求會議後就完全理解了需求的含義。
所以導致，開發者在聽完需求後，開始著手設計程式，編寫**中，有了需求不明白的地方只好單獨找提出需求者求證，而對於那些幾個人聯合開發的功能就會導致溝通不暢，浪費不少時間進行不斷修改。不利加快專案進度。根據我的經驗，一般耗費時間較多的就是對需求的不明確和理解偏差導致做了很多事情，結果發現出現了錯誤，又返回去修正。
因此我覺得，在第一次需求會議後，開發者消化了需求後，提出需求方再進行一次需求講解。為了避免浪費提出需求者的時間，在第二次需求會議時可以對需求重點講解，或者專門解決開發者的疑惑。這樣比開發者單獨求證需求效果要好，因為大家都在一塊，對於聯合開發的功能在會上就能溝通了。這樣開發者對需求理解的好了，就能一次性設計和完成編碼，避免了錯誤，節省專案的時間。一般來說只要再多占用提需求方的一次會議時間，就能提高專案開發進度，我覺得還是比較划算的。
對於需求的理解是關係專案進度的關鍵，所以一定要在初期將需求講解明白，理解透徹。
原文：
我的第一次專案需求調研
很幸運能在畢業的這一年參加一次專案需求調研與分析。以前在課本和大學的課堂上理解到需求分析是整個專案的基礎，需求分析的嚴謹直接決定專案能否驗收。在參加調研之前，也對這個專案所處行業進行了比較深入的了解，理解一些該行業的規則。需求調研開始的那天，因為抱著一顆想要完美自己的第一次需求調研的心，顯得比較緊張...
我的第一次專案需求調研
很幸運能在畢業的這一年參加一次專案需求調研與分析。以前在課本和大學的課堂上理解到需求分析是整個專案的基礎，需求分析的嚴謹直接決定專案能否驗收。在參加調研之前，也對這個專案所處行業進行了比較深入的了解，理解一些該行業的規則。需求調研開始的那天，因為抱著一顆想要完美自己的第一次需求調研的心，顯得比較緊張...
一次curl超時引發的專案問題思考
最近專案中遇到了一次curl超時，導致了使用者操作寫入失敗的問題 1 curl超時怎樣去追蹤哪乙個步驟導致超時 php 超時原理 一次請求呼叫某個api出現超時的時候我們如何判定是在哪乙個步驟超時了？1 網路原因，請求超時，服務端 未執行，很容易判斷，超時後，服務端無任何操作 2 服務端執行超時，服...