專案製作隨感
核心事情
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.在最開始，前後臺，也交流不出來什麼，都是摸著石頭過河
三性、三期
三性穩定性，流暢性，可配置性
三期定型期
1.打包處理
2.配置的常量
3.從後台得資料，到把資料渲染到前台的套路流程，一般是用建父類的方法
（不是告訴大家，什麼能做什麼不能做，而是告訴大家只可以做什麼）
4.大家共用的常用方法，如：日期格式轉換，訪問cookie等
5.後台介面返回值的結構，約定好一些事情，如：有個狀態值，如果後台執行有錯時，前台如何顯示，在前台基類中統一處理
6.路由，模組的英文名字
7.所有的常量，如資料，文案，都應該在乙個常量檔案之中,避免在邏輯**中，有文案直接出現
重在：定套路
擴張期根據已經形成的套路，乙個頁面乙個頁面的去做
直到都做完，準備提測
重在：按套路狂寫**，遇到問題解決問題
衝刺期1.bug
2.產品對需求的改變
3.濱習上線過程，模擬上線環境，遇到問題解決問題
重在：溝通每個人得到結論，修改**
自己做專案時的感受
理想很豐滿，現實很骨感
知易行難，落地困難
團隊優勢：每個人的主觀能動性都很強
團隊加強：整體流程，預做之事的事前溝通，同事之間的配合,尤其是跨部門做事之前的溝通
做專案時，最大的痛：警惕在專案中，做無用功
小痛：天天平地摔，還有暈頭暈腦掉坑里，要好幾個小時才能爬出來
提高工作效率就是句虛話，能落地的是把你手裡的技術活，變為純粹的體力活(幹的活，都變為死套路時)，就方便量化工作量，並且可以對專案進行掌控了
團隊一起開發，最好是一對一，或是一對一對一，都是一條一條的線，最忌，多對多的形式，又亂又容易出錯，還要不停切換思維，導致效率很低
領導層的巨集觀注意力應該放在**，一是提公升每個員工的戰鬥力，二是提公升整個團隊的凝聚力和戰鬥力，不斷優化配比與流程
帶團隊認識上
就是要讓團隊中每個人明白，自己在團隊中所扮演的角色和肩負的責任。
這就好像，讓兩組團隊，隨意選取撲克牌中的一張牌，然後把所選的牌擺在桌子上。於是，出現了下面的結果：
第一組：方塊a、黑桃2、黑桃5、紅桃6、梅花q……
第二組：紅桃a、紅桃k、紅桃q、紅桃j、紅桃10……
這兩組的結果是完全不同的，第一組是一副雜牌，第二組卻是一手紅桃同花順。為什麼會這樣呢?這是因為，第一組沒有統一的目標，所以大家都按照各自不同的想法來選牌。是一種個人行為。個人行為加個人行為叫「烏合之眾」。第二組有乙個統一的目標，才形成清一色的同花順，這就叫「組織行為。」
如果想要你的團隊拿到一手同花順，就一定要思路清晰，定出整體目標，並且明確共同利益所在。同時在這個目標下，讓每個人知道自己所承擔的責任和要達到的要求，並且給予一定的發揮空間，讓個人能力共同達成組織目標。
工作上上面所說的，是讓成員知道自己在團隊中的作用和要做什麼，這裡要說的是成員做事要做到什麼樣子，對具體做事的要求。要求只有乙個，就是把交給自己做的事情做到位。看似簡單，其實要達到做到位的標準，必須要有高度的責任心，還要有對事情非常認真負責的態度。
例如，我叫乙個同事把機箱上面的乙個螺絲擰緊，過會兒他告訴我已經做好了，我便拿著螺絲刀，到機箱前，把他說擰緊的螺絲又給擰緊了兩釦，然後回過頭來望著他，他也有些不好意思，說是以為擰緊了。像這種事情，可以延伸到工作中的方方面面，幾乎別人告訴你，他已經把一件事情做好了，這個「好了」倒底是不是真的好了，你要是不自己去檢查，而相信他的話，到後來很可能會出現問題。乙個很明顯的例子，就是遊戲測試說測試好了，遊戲沒有問題，但是發布到線上卻發現了很嚴重的bug，給公司造成了損失。如果你不相信測試說的話，又派一批測試去測，那公司的成本會被加大。檢查別人已經完成的工作，要付出的代價也是很大的，有些團隊為了防止這種事情發生，在工作流程中，專門在每一步完成之後，加上了「驗貨」的環節。雖然這個流程有效防止了沒有做到位而出錯的可能性，但也把開發時間給拉長了。
在我心目中，乙個能把別人交給他的事情百分之百做到位的人，就可以稱的上是乙個靠譜的人。要讓做到位的想法，深入每乙個團隊成員的心中，並付諸實際行動。
精神上就是乙個團隊的氣勢，也可以理解為大家的工作積極性是不是很高。我管這種積極做事的態度，叫做「鬥心」。要讓乙個團隊有斗心，第一步是為團隊定下乙個讓團隊完成起來，比較有難度的目標。之所以要定個難以達成的目標，是因為目標太容易達到，團隊成員必然會放鬆，甚至不屑於去做，只有目標對他來說是個挑戰時，才能激起鬥心。第二步，是把大目標分解成諸多的小目標，每當完成小目標後，就及時鼓勵團隊，不斷為團隊補充鬥心，如果不經常鼓勵，大家的鬥心會隨著時間慢慢減退。鬥心的**除了鼓勵，還有公司內外其他優秀團隊的競爭，和團隊人員自發的榮譽感。
團隊中每個人也是需要及時去誇讚的，誇獎乙個人，要誇他所做的具體事例，而不是浮誇其表面，不然別人也會認為你的誇讚很假。有些人認為，管理是應該胡蘿蔔加大棒的管理方式，一味的誇獎是不是不好呀？其實不然，誇獎別人，可以使他的勞動積極性大幅增加，而當你批評某人工作不佳時，對於大多數人只能使他的勞動積極性下降，更有甚者直接離開團隊。所以還是要以讚美為主，如果真的看出此人的問題，也可以採用「三明治」的方式去說出，即先誇後提建議再誇，這樣也使別人好接受。每個人都有缺點，而我們用人是用人的長處，不可以求全責備，要懂得「水至清則無魚，人至察則無徒」的道理。我們要懷有一顆包容他人之心。
物質上...
少點兒雞湯，多些實在的技術分享
百看不如一練，百練不如一上線
感覺用xmind去做東西，條理性比doc要清楚的多
但xmind我在用時，覺得有兩點不足：
1.沒有 子專案「...」 這個設定
2.具體的文字框中的文字，不能單獨變色強調出重點，只能框裡文字都設定顏色
專案製作隨感
1.責任到人 2.可量化工作量 1.知已 知自己團隊的戰鬥力是多少 2.知彼 要做的專案難度是多大 在此時，能把要做的技術活，變為純粹的體力活，就是本事 1.兩會 需求會 開完會後，回去思考4小時 再開前後臺對接會 兩會之後，再估時間 2.量化工作量的三大類 1 腦力勞動 s a b c 只是工作難...
專案管理隨感
從之前經歷的專案隨感如下 一 專案裡，有幾點需要專案經理認知的 1.專案啟動抓商務。這個環節抓商務談判 抓商務 等等。是專案的初始階段，這裡孕育著很多專案機會或專案滾動，同時也關係著部門的收入。3.專案實施抓細節。有的人說，實施就是做些粗活，沒什麼。其實，實施的細節很重要，產品實施的效率和質量，能直...
專案隨感 專案風險
在做專案的過程中，漸漸體會到了專案中的一些風險因素。在專案中參與了很多過程，有的還在繼續著。需求分析，資料庫設計，架構，編碼，測試，維護。也許正是參與的過程多了，在看待乙個專案的時候，就不會僅僅像剛做專案那會，分得乙個模組，按照規範按時做完，提前最好。做完乙個，做下乙個。那時有點 目無全牛 的感覺，...