P2P理財項目四個月開發總結

目前項目狀況

        這個項目從元旦開始開發到如今已經有四個多月的時間了，上線期限也是一拖再拖，從整個項目開發狀況來看形成項目延期的緣由有不少，簡單分析和總結一下這個項目的優缺點，以及在這個項目中的成長。

項目進展分析

      需求方面

         需求變更在緣由裏面佔用20%，經過我的感受這個項目需求變更形成的時間浪費在20%左右，通常項目在代碼寫了一部分後基本上需求是不會再變了，但是這個項目再開發了兩個月以後，需求又大變了一次，致使不少代碼從新開發或者重新編譯，開發重複勞動情緒也收到影響，固然項目慢也不能徹底推給需求，需求變畢竟是正常狀況和正常事件，若是需求大變一次能夠走需求變動流程，各個負責人一塊兒估算變動帶來的影響，所以，需求就不過多的談亂。

        設計不當

               數據庫表結構

       數據庫結構正常狀況肯定好以後就不會再有大的改動，可是咱們項目中數據庫老是在變，數據庫若是變化從底層mapping文件到界面都會跟着改變一次，改動仍是比較大的，另外我以爲這種雖然是按着敏捷開發的方式開發，但沒有達到那樣的效果，尤爲前端頁面與後端分開來開發如此一來咱們每一個迭代每月都看不到本身開發出來的成果，開發的比較盲目，這樣時間一長沒有開發出東西來會讓你們感受有一種疲憊感，不如換一種開發方式每月都會有成型的東西出來，讓你們對本身作的東西有種成就感。

除此以外，應該有一我的控制需求和數據庫變動，通常不要改變數據庫以及需求，就不會帶來這個變更影響開發的狀況，萬一需求變了項目延期須要評估是否合理，不合理就不給於變動。

項目開發已經快結束，可是發現都沒有數據字典，不少下拉列表直接返回給前端的都是數字或者英文字母，不知道表明什麼後期集體添加數據字典這個功能，這個前期沒有考慮進來；有些公共的技術點沒有提出來並加以整理，好比控制事務、緩存失效時間、登錄、安全、代碼格式等等，本身寫本身的沒有人控制；每一個人都是負責本身的模塊部願意參與別人的模塊設計，也不肯意幫助別人解決遇到的問題，想的都是把本身那一塊問題解決完，保證本身的那塊不出問題便可，可是這種系統耦合性太大基本上很難把幾我的負責的任務分開，致使流程走的不暢。

                任務分配

        任務分配存在不合理的狀況，並無按照能力好一些的負責業務複雜一些的模塊，水平差一些的負責相對簡單一些的模塊，這並非說有的能力不高只是爲了更好、更有效的完成項目中的任務，合理利用資源的問題，有時以爲某些人特別忙、某些人就比較閒的狀況，P2P不論是前端仍是後臺管理走的是一個數據流程、其餘大多數軟件都是在走數據流程，有的節點稍微複雜一點有的節點就簡單一點，咱們不該該讓前面的流程制約後面流程的開發，換句話說做爲項目負責人或者經理應該就每一個流程以及各個流程的銜接處的數據變動有較清晰的思路和認識，而後，對於每一個人完成每一個模塊須要多長時間有一個總體認識，只有這樣整個項目纔不會延期。

在軟件設計師考試中，曾經記得有項目有向圖、無向圖等圖，清晰的記得整個項目的時間每一個節點都受前面節點限制，而整個項目期限取決於時間最長的一段路線，所以項目工期應該考慮最可能出問題的那個組合；分配人員時應該把前面節點作完的人員分配到後面沒有完成的節點上面，不形成資源的浪費，這樣是最理想的狀況。

在前天開技術討論會的時候，咱們總經理提到了咱們那個項目，問咱們那個項目五月一能不能上線，問某某人回答是：取決於誰作哪一塊，明顯顯示出分配任務不合理的狀況。

                開發氛圍不和諧

        團隊的開發氛圍對於整個項目開發是有影響的，開發中有前期有十幾個開發人員這幾我的一組那幾我的一組，造成了小的團體以本身小團體爲準，我以爲咱們開發組素質都比較高，開發任務也比較快很快完成了開發任務，在開發中公司招的的確啥水平的人員都有有的人，開發一個功能好幾周還總問別人，問幾回你會告訴他可是時間長了就沒有人願意告訴了，領導也不是看誰不行就說說誰，沒有賞罰錯誤你們作多作少都同樣，因此，你就沒有必要總幫別人弄，時間長了你們都光顧本身那一塊了，同別人交流的比較少，技術好一些的代碼思路或者風格，以及好的實現也不肯意分享出來或者告訴其餘人，水平相對薄弱的人也只能本身摸索着寫，團隊之間幾乎沒有知識共享無論好的技術仍是很差的都沒有人主動分享或者提出將要出現的問題，領導也不能及時發現可能存在的問題，若是你負責那一塊那麼這一塊的全部內容都有本身來負責，完成任務的前提是每一個人必須對本身租的那一塊有清晰的認識和必定的經驗纔能有質有量的完成。

               責任不明確

         在公司裏面工做常常涉及到責任問題，有不少實現和涉及思路或者方案是須要領導或者經理來肯定的，由於這裏面會涉及到責任問題不少開發人員本身都不能確認是否應該這樣，可是不少這樣的涉及問題應該經理來拿主意的事情，經常讓幾個開發人員來本身確認這樣一來誰都不會確認方案，由於確認方案若是出了問題都會推到某人身上，這樣一來就形成了開發會感受比較累，實現的同時還會考慮不少責任問題牽扯到開發鍾來。

總結：

         總之，項目進展的好壞與項目設計每一個方面息息相關，不要忽視每一個方面對每一個方面也不可以掉以輕心，做爲經理以及管理人員不可只安排人員去處理問題，須要提早預算這個問題的產生，以及對每一個人的每日進度以及每一個人的總體進度有把控才行，對每一個人的開發狀況瞭如指掌才能對整個項目進展有明確規劃，而不是出一個文檔告訴開發人員按着這個寫，而後本身就啥事情也沒有了，若是達不到本身預想的標準就是不行，項目經理應該跟進每一個人的狀況。