專案製作隨感

1.責任到人

2.可量化工作量

1.知已：知自己團隊的戰鬥力是多少

2.知彼：要做的專案難度是多大

在此時，能把要做的技術活，變為純粹的體力活，就是本事

1.兩會

需求會開完會後，回去思考4小時

再開前後臺對接會

兩會之後，再估時間

2.量化工作量的三大類

（1）腦力勞動

s a b c 只是工作難度

c 無腦鋪板子，互動也只是跳轉

b 有一些互動，後台的資料簡單處理，與後台資料發生簡單互動等

a 有一些複雜的演算法，但是網上能找到一些例子，比如電影選座位，處理一些後台的複雜資料

s 複雜演算法，且網上找不到什麼參考例子，如用原生js編寫個分層氣泡圖，拓撲圖的企業祖譜，用到紅黑樹，四叉樹遍歷等，寫個智慧型ai，alphago

關心的點：做的這個功能的人，之前有沒有做過類似的，有就可以認為時間和風險可控，沒有就認為不可控，需要重點觀注一下

（2）體力勞動

直接灌資料，雖然是體力活，但要是資料多，細節多，肯定也要花不少時間，還要比格外細心

（3）對接後台勞動

前後臺人員的溝通成本，兩人聯調時，前台傳參是否正確，後台資料過來是否正確，發現問題時的修改時間

3.估時間的尺子

（1）c級：1小時，b級：4小時，a級：8小時，s級：看個人能力了，有可能就無窮個小時了

（2）6條變化顯示的資料，1小時

（3）乙個介面，3小時

4.要批判的思想

我在網上看過，按人/天，來算專案時間的方法，這個演算法最大的問題是忽視了每人具體人的工作能力差異

如：毛科做乙個專案，他需要30個工作日做完，也就是30人天，但不能簡單的認為，6個人一起做，就可以在5個工作日完成，要看這5個人的個人能力是不是和毛科一樣強，還有人多後的溝通成本也要計算在內，所以肯定5天完不成

5.難點

（1）不真正做時，沒感覺，也不知道**會出現問題，俗稱「餡」

（2）技術經驗不足，是新手，或是粗心大意，在寫**過程中一些不是問題的問題，也成了問題，一不留神自己寫的**就是坑，掉進坑里，沒幾個小時，爬不出來

（3）在最開始，前後臺，也交流不出來什麼，都是摸著石頭過河

穩定性，流暢性，可配置性

專案，必須是穩定的，bug少的

再有就是，與使用者互動不卡，渲染不慢，是流暢的

編寫的**，關鍵部分的設定，都是可以通過外部來設定的

定型期1.打包處理

2.配置的常量

3.從後台得資料，到把資料渲染到前台的套路流程，一般是用建父類的方法

（不是告訴大家，什麼能做什麼不能做，而是告訴大家只可以做什麼）

5.後台介面返回值的結構，約定好一些事情，如：有個狀態值，如果後台執行有錯時，前台如何顯示，在前台基類中統一處理

6.路由，模組的英文名字

7.所有的常量，如資料，文案，都應該在乙個常量檔案之中,避免在邏輯**中，有文案直接出現

重在：定套路

擴張期根據已經形成的套路，乙個頁面乙個頁面的去做

直到都做完，準備提測

重在：按套路狂寫**，遇到問題解決問題

衝刺期1.bug

2.產品對需求的改變

3.濱習上線過程，模擬上線環境，遇到問題解決問題

重在：溝通每個人得到結論，修改**

理想很豐滿，現實很骨感

知易行難，落地困難

團隊優勢：每個人的主觀能動性都很強

團隊加強：整體流程，預做之事的事前溝通，同事之間的配合,尤其是跨部門做事之前的溝通

做專案時：

最大的痛：警惕在專案中，做無用功

小痛：天天平地摔，還有暈頭暈腦掉坑里，要好幾個小時才能爬出來

提高工作效率就是句虛話，能落地的是把你手裡的技術活，變為純粹的體力活(幹的活，都變為死套路時)，就方便量化工作量，並且可以對專案進行掌控了

團隊一起開發，人員搭配，最好是一對一，（如：乙個前台對接乙個後台）或是一對一對一（如：乙個前台對接乙個後台，此後臺又對接乙個資料庫人員），都是一條一條的線，最忌，多對多的形式，又亂又容易出錯，還要不停切換思維，導致效率很低

領導層的巨集觀注意力應該放在**，一是提公升每個員工的戰鬥力，二是提公升整個團隊的凝聚力和戰鬥力，不斷優化配比與流程

專案製作隨感

專案製作隨感

專案管理隨感

專案隨感專案風險

專案製作隨感

專案製作隨感

專案管理隨感

專案隨感 專案風險

相關推薦

專案隨感專案風險