第一次寫文字，還有點不知所措，那么我就說一下工作當中的遇到的一些事，或許對帶項目的經理，或者小組的組長有一些幫助，其次本次所說明的觀點，也是本人在與其他人的交流中，體會到的，當然也有項目組開會討論需求時，領導的一些觀點，我覺得可以借鑒一下，畢竟咱們是小兵，許多沒有想到，還請不要見怪：
1.項目前的準備工作，在參與現在工作的時候深有體會，我們項目開始的時候，其實是有談論需求的，而且談的時間不短吧，整整一個月都在談論需求，畢竟項目比較的大，小說也有三百萬的工作量，幾乎每天都在談判桌上談論需求應該怎么明確，但現實遇到的確實，每回談論需求都是在一群嘰嘰喳喳中度過，需求銀行那邊都沒有做過項目，許多人你發表一句，我發表一句，沒有一個總的敲定需求的人，而真正敲定需求的人又經常有事，前期工作沒有做好，時間就已經過去了一個月，所以我想說的是，如果跟甲方談需求，一定要有一個需求確定人，而且人數不能太多，一個最好，這樣，問題容易集中解決，不用這個問題出現，誰都是負責人，既耽誤了時間，又浪費了精力。
2.項目的實施，這時候就得說說項目經理的作用了，其實項目經理的定位不僅僅是一個技術大咖，其實也是一個專業填坑的人，因為一個項目程序員看見的知識眼前的問題，但是項目經理確可以看見以后項目會出現什么問題，怎么在最大的程度避免因出現問題而耽誤項目的實施，說白了，就是提前預防，其次項目經理是唯一的對外接口人，項目問題都可以匯總出來，去和甲方的人去確認，同時甲方要改什么需求也是通過項目經理，來給程序員分配任務，因為只有項目經理清楚組員內部人員應該怎么調整工作，其次也是一個過濾一些過分需求的閘口，確保項目正確的，按時的完成。而不是一味的縱容任何一方，如果縱容甲方，那么就容易造成項目的無限延期，如果縱容實施人員，就容易造成不必要的沖突。
3.項目的調試，在第二點上其實已經說了一些，這里再做一個補充，甲方的人找組員改需求，這樣對于甲方來說無可厚非，但對于項目人員來說確實一個大問題，因為你不知道誰會過來讓你改需求，我們的提議是，組員完全有權利去拒絕改需求，可以讓甲方去找項目經理，畢竟，如果能把需求彈回去，咱不是也可以輕松點么，其次就是我們對于書面上的東西都很少去寫，甲方如果有什么需求需要改，可以寫一份變更需求單，這點很重要，這樣甲方就需要對自己所說的事，所說的話負責，而不是就一天一個樣，需求改過來改過去，最終項目也延期，需求也改的不成樣子。
以上就是我工作當中總結的吧，算是一點愚見，畢竟技術大咖都在這里，我就不賣弄了。