國慶前後一直都在忙，也沒時間繼續寫什麼東西，一直惦記著，怕荒廢了。不知道從何說起，想來想去還是流水賬適合我。
節前主要做了一件事，將《專案管理平台二期建設》的需求做了最後的整理和確認，並且在節前向部門領導作了匯報。來公司乙個多月了，第一次由我向領導做匯報（有另外的同事在場進行補充和討論哈）。事實證明，姜還是老的辣，無論是領導提出的改進思路還是同事討論的深度都比我預想的高出很多。鑑於對業務和產品線實際情況的了解不足，匯報中提出的一些功能點和管理流程的實施將會面臨很大的阻力。匯報過程中，緊張是難免的，入司這麼久直接跟領導面對面交流的次數掰著手指頭都數得過來，更別說當著大家面講解ppt了，好在有驚無險的度過了，以後還是要加強自己思考問題的條理和匯報的節奏。具體的改進情況就不表了，國慶回來已經將需求反饋給廠家等待他們估算工時，進而討論進入商務階段了。
國慶七天假休得很鬧心，現在想想覺得還不如上班呢，導致我節後彷彿更累了。苦就不訴了，繼續說工作。十月開頭，帶我的組長就將節前幾次會議的重點向我們做了傳達，並把任務做了分解落實到每個人頭上，關於我的有以下幾點：1.繼續跟進vp二期建設，爭取月底啟動商務；
2.產品線進度同主計畫的偏差分析；
3.新版演示文稿的改進；
4.年底專案大總結關於進度、成本、資源部分的分析報告。另外還有一些跟進的工作，平時多關注一下即可。
任務1就不說了，持續跟進+主動推進。
任務2，我在本週已將此條產品線的主計畫、20%評審計、vp中計畫、實際進度整理出來並做了對比。問題有四。第一，20%評審只做了2023年的任務規劃，針對今年的合約任務最多延伸到2023年上半年，難以考量該產品線在主計畫中的進度情況；第二，實際完成時間匯報與現實有偏差，比如某個kc在7月完成率已經100%，可在之後又調整為70%，造成這種情況的原因可能是在之後由改變了專案範圍或之前的範圍估計不足，也可能根本就是專案經理的手誤；第三，我發現無論是哪種計畫，對kc、功能點、里程碑以及合約任務的命名都沒有做約定，以至於我在檢視時，想將不同程度的計畫節點做一一對應時十分痛苦。可能這對於專案經理或參與該項目的同事不是個難事，但對於我這樣乙個業務新手，要把kc的中文全稱和簡稱甚至英文縮寫對上號實在是想讓人撞牆。十分有必要在之後的工作中對這一方面做出約定；第四，對於不同詳細程度的計畫，他們的關鍵點之間並沒有建立聯絡，也就是說雖然我不能通過kc的完成程度判斷該產品線在主計畫總的進度，究其原因還是因為產品線之外的干係人對任務中包含的關鍵點、kc不甚了解。因此，在以後做計畫的時，將任務與主計畫不同階段工作建立聯絡，kc明確的同時將其置於相應的任務中，這樣建立一層一層的關聯關係，就能很方便的辨識出主計畫完成率。
任務3，有思路，但是總的來說不是很成熟，而且不了解領導口味也缺乏資料支援，頭疼。
任務4，這個很重要也很有必要，之前做了那麼多工作也都是圍繞它的，我認為除了必要的資料支援，更有意義的是對資料的分析方法和結論，怎樣能體現出我們工作的價值和對未來決策的判斷是我想要做到的，好在不是十分緊急。爭取本月有思路。
流水賬完了，可能因為中間的七天假，讓我覺得雖然時間過的挺長，但是成果很少，令我有些焦急。今天就這樣吧，改天有空再寫。
前後端分離思考
前後端分離的專案開發策略已經不是什麼新鮮東西了，網上介紹這方面的文章非常多。我自己是在14年的時候接觸到的，對這種開發策略一直愛不釋手，不管新老專案都會首先用前後端分離的思維先去思考一番。從14年到現在在前後分離上面也實踐了近3年的時間，專案大大小小的也差不多4，5個吧，但是卻從來沒有乙個是自己覺得...
五一前後OL眾XDJM碰頭會
活動初步安排如下 五月三號下午去k歌，由主持人主持，所有參與的oler互作介紹 k歌結束後，就近找一塊合適的地方，集體 殺人 k歌初步定在錢櫃，下午1點以後至5點之前，每人22元 需攜帶學生證 另自助餐15元 1元，可選 歡迎所有人參加，尤其歡迎 有節目 的朋友。殺人 遊戲簡單好玩兒，在以前的活動組...
前後端開發協同的思考
前後端需要定義一套完整的錯誤碼體系，每個錯誤碼都有其含義，正確響應結果會有乙個code，可以定義為200，跟標準http code對應，容易理解。有些api介面，會使用http標準code返回，告知使用者業務的狀態，例如easyar的介面http 1.1 404 not found 這裡使用了htt...