做項目負責人的總結



之前一直是做游戲開發,雖說也算是項目負責人之一吧,但是基本只是負責后端架構和后段邏輯,只要做到兩點,1:服務器可以承載一定用戶量,2:邏輯沒有問題就好了,剩下的諸如流程交互頁面畫風之類的,全不在自己的考慮范圍內,對,還有進度,也不在考慮范圍內,因為一般都是客戶端是瓶頸,服務器不是瓶頸,甚至有點閑。
來到新公司之后,既要負責技術,也要負責項目,前兩三個月有點吃不消,也有點不適應;因為要統籌安排美工和程序協調開發,並且要保證業務邏輯流程的順暢。難免要經歷一個難產期,或者陣痛期。索性,索性,堅持過來了。


說一說剛開始時候的不適應吧或者說剛開始時候做的不好的地方吧。
首先說說寫需求:
1:首先是總是丟需求,這一點也是總監跟我說了n次的地方,可是仍舊是在這里犯了n-1次錯誤;拿最近這個商城來說,因為是基於微信,所以需求中要體現對微信的接口和約束;更要體現如果去管理微信公眾號,這塊確實是被我忽視了,的的確確的被忽視的,完完整整的丟掉了;而沒有這塊就無法接入微信,切記切記;后來在讀一本書的時候,提到了約束,如果丟掉了約束,可能就會導致最終的產品進行大返工,切記切記。
2: 需求不完整,一些活動的需求,無法形成閉環,或者說有疏漏的地方,這里確實要再文檔成型之前,對每一個模塊,每一個功能,每一個需求,每一個流程做一個頭腦風暴;雖說無法避免疏漏的地方,但是一定要避免無法形成閉環,無法形成閉環,無法形成閉環,重要的事情說三遍,切記!


說說整體架構這塊:
1:首先是一定要多視圖;因為利益相關者不同,架構設計文檔要給到程序,運維,老板,其他架構師等不同的角色看,所以架構設計要從不同的視圖來體現,比如給程序的,要從模塊划分,層次划分的角度來;給運維的,要從不同機器之前聯系的角度來,等等,總之要多視圖
2:拋出難題,或者說風險控制,總之把風險全部拋出,分析那個風險最大,那個所需要考慮和投入設計的精力也就最多
3:考慮擴展,考慮分布,考慮負載
4:考慮客戶端,這塊一直是疏漏,總監也總是提醒我,要多關注些客戶端,客戶端不可太大,否則加載會很慢,考慮壓縮,考慮框架的選取,以輕,穩,簡為原則,這塊的的確確是疏漏的


我們再說說做計划:
1:可能是對這種javaweb的項目不熟悉,所以最初也就是賈哥給了一個泛泛的計划節點,就是demo版本的deadline;現在熟悉了,切記切記,要做計划做計划,分解計划,做到周計划。
2:根據開發進度調整計划,在實際的開發過程中,常常發現缺界面,丟邏輯之類的事情,雖說可以通過前期需求和設計避免,但是這樣又需要在需求分析和概要設計上花費太久時間,所以需要補充的功能之后,要調整計划,調整計划,切記狂加班消耗開發熱情。
3:美工的計划要早於開發,工程師在開發任務的時候,切記切記,美工已經把界面給到,這樣就需要保證美工的計划要早開發一個星期左右的時間,這樣才能保證開發順暢的進行。


年前寫的文章,寫了之后一直不肯發布,是因為覺得錯誤犯的有點低級。年后雖說舊項目還在維護,也同時開啟了新項目,現在再做需求基本能做到完整完善,並且使用面向對象的方式,做設計也能考慮的比較全面了。就不必藏着掖着,就把這篇文章發布好了。


注意!

本站转载的文章为个人学习借鉴使用,本站对版权不负任何法律责任。如果侵犯了您的隐私权益,请联系我们删除。



 
粤ICP备14056181号  © 2014-2020 ITdaan.com