進公司第一個項目經驗總結

項目總結：
1、 需求分析不充分，需求變更頻繁，系統分析人員有時候對問題模稜兩可，直接導致開發人員經常改動工作量增大，無疑給項目執行帶來風險。
2、 需求分析開發方面沒有明確的掌握全域的負責協調溝通的主導人員，各自顧著忙自己手頭任務。
3、 項目品質監控把握力度有待提升，沒有完善代碼審查機制；程式寫完不代表項目結束，只有很好的審查代碼，修改程式不合理的地方，使開發人員改正長期以來可能養成的錯誤習慣，從而讓含後的系統開發品質得到提升實現公司與開發人員雙贏。我們目前都只是功能性測試黑箱測試，沒有對程式碼進行白盒測試，給以後程式使用留下安全隱患。
4、 項目溝通方面不是非常順暢，系統分析人員與開發方面有時候因為理解不一造成最終功能偏差！造成這種原因很多，歸根結底主要原因是溝通技巧問題造成。我的建議開發前使用系統Demo，開發結束使用BugList，這樣可以有效減少因終端使用者－需求分析人員－開發人員三方溝通造成的溝通成本增加。是在每一個BUG出現的地方，抓個圖，如果有可能最好能把操作步驟抓過來。這樣會省去修改人員的很多時間。

Demo:用直觀真實的Demo配以詳實的需求說明代替抽像空洞的文字需求描述或ppt，這樣帶來的明顯好處是，可以在項目開發啟動前跟頭腦中沒有系統展現雛形的使用者/領導進行示範溝通，在前期進行無數次的修改示範直到使用者/領滿意為止，將不必要的需求變更從開方轉移到分析階段，將它扼殺於搖籃之中，等需求敲定時，項目正式進入開發前再給開發人員示範講解，明確最終系統功能及介面要求，而不是扔一推需求讓開發人員跟據自己的主觀意念去開發系統。

BugList:用明確詳細的BugList代替口述或紙質亦或Word文檔的Bug描述；無論誰在想事或做事情時，總是不希望被人打斷開發人員也不例外，BugList這種靜巧巧的提示小助手可以保證開發人員的工作節奏！BugList可以很清楚地將Bug出輕重緩急讓開發人員一目瞭然地知道孰輕孰重，而且Bug提交者也可以通過BugList尋找Bug的修改狀況。而且BugList還可以協助專案經理很好的掌控項目進度及統計開發人員不同等級錯誤的Bug率;BugList可以讓沒有Bug描述經驗的任何人將Bug描述得詳細明確。

規範方面：
1、 缺少完善的開發規範體制，沒有嚴格的強行執行策略。像變數及欄位的首碼lng，lng是長整形long的首碼，確被整形integer使用。
2、 資料庫表設計，不應由開發人員設計！不同人可能資料庫設計水平參差不齊，這樣容易造成系統效能問題。
3、 缺少完整詳實的開發文檔，可能造成人員離職帶來的系統維護成本。
最後建議：
    公司沒有明確的新技術敏感性，大部份系統還處於前幾年的開發水平；開發人員無法將新技術融入系統，以讓系統使用者帶來更好的使用者體驗。建議公司投入小部分人力研究適合我們系統開發的基於新技術的.net架構。