進入oa部門之後一段時間都在做比較小的應用，ionic1專案新版本，pc端的聊天記錄頁，食譜頁，也就是2三張頁面，3、4個介面這樣，所以雖然開發過程中遇到一些難辦的問題，也並不是不能解決，很長一段時間我也是認為沒有我解決不了的前端問題，正所謂井底之蛙安之海闊天空，管理專案暴露的問題的確讓我重新認識了目前的狀態。
一、產生以為自己可以解決一切問題想法的原因
沒寫過稍稍大一些的專案，以前雖然寫過**類的專案，但那其實是多人合作，基礎已經有人搭建好了，個人只是在基礎上進行開發，所以初期問題並沒有考慮。而之後很長一段時間都是如此。個人開發也都是很簡單的幾張頁面，幾個介面。遇到的問題也可以解決，別人問我的問題我也可以很快定位解決，所以一段時間覺得沒什麼突破的，也就是還沒有真正嘗試過大一點專案造成的。
二、向別人提問後得到的結果
某些功能實現起來可能出現阻塞，這時候可能回去詢問他人，而得到的結果可能是更暈。其實很簡單，說誰都能說個大概，只有真的開發的人才知道難點在哪。所以向別人提問，取得一些思路即可。
三、遇到的問題
1.由於webpack環境是自己配置的，所以出現了object.assign沒編譯的情況，導致了一些手機空。
2.ios用new date取已經格式化了的時間戳，會報nan，不要用空格拆分年月日。安卓會正常顯示無此問題。如+new date('2017 8 26')ios下就是nan，必須使用2017/8/26這種格式劃分。
四、得到的結論
1.前端環境如webpack，如果自己沒有非常熟練掌握原理，不要自己搭建，會出一些忽略的問題，使用外掛程式提供的初始化環境。
2.專案開始的時候要做好分析，清楚頁面的走向，預留判斷。
3.有點大的專案考慮使用vuex
4.資料處理比較多可以考慮使用工具類，如lodash
5.最重要的一點，評估時間。是基於上面4點的基礎上。本次專案評估時間沒考慮其他專案干擾，沒考慮上面四點問題，評估時間是乙個月，但是造成了加班乙個月才剛能出個半成品，專案延期對業績會造成比較大的影響，這就是教訓。
五、專案分析
本專案屬於應用下的輕應用，實際做出來是14張頁面，加3個元件。根據後來總結，其實如果時間比較充裕，是可以將幾張類似的頁面判斷合併，也就是精簡到10張，加3個元件。但是那樣是需要充分的時間做判斷，也就是前期分析不足造成，實際開發的時候有想到要判斷合併，但是後來覺得時間不夠就拆分了，所以有點多**其實是類似或重複的。
又要改bug了。。。
todo.......
專案管理之 會議
會而有備 會而有議 議而有決 決而有行 行而有果才是開會的真正意義所在，任何乙個環節出現問題都會前功盡棄。一 會而有備 我認為在會議前的充分準備是相當重要的，不能因為臨時考慮到乙個點或者拿不定主意就召開會議，必須是從整個專案結構或者公司戰略層面考慮，並且組織會議或者丟擲問題的人，應該對整個會議的內容...
大型專案管理經驗會議總結
僅此記錄作為筆記 專案週報工作的開展，後續可以考慮引進模組開展百分比定量考核制度，對於需求點 修改點，採取權重值乘以工時數衡量百分比，做出波線圖，更加直觀。其次，專案週報方面，個人覺得會議上提到的引入各種工具等等，都有乙個致命的錯誤，不同工作崗位角色的工作週報都是同乙個模板，這樣欠妥，像專案組長 專...
專案微管理23 會議
對於開會，留在四代心中是截然相反的兩種印象 一種是能幫助解決問題，而另外一種是浪費時間。之所以出現這種情況，是因為四代經歷過的一部分會議組織合理，議題明確，步驟清晰，能起到會議所能起到的溝通作用，所以能快速的理清問題，統一思想，得出結論。而另一部分會議組織混亂，議題也沒有乙個明確的中心，一大堆問題雜...