一、我們的團隊
經過半年多的努力，xnote產品即將結案，這期間我們解決了很多當初看似無法解決的技術難題，大家付出了辛勞、汗水和各自的智慧型。在此對大家表示最誠摯的感謝！
這充分說明我們是乙個有戰鬥力的團隊。我們有很多做的挺好的地方，比如品質最終達到了公司嚴格的交付水準、schedule如期完成、qa要求的過程與文件產出物我們都達到了較好的成績、不管是內部溝通還是外部溝通一直比較流暢等。
同時，我們是一支年輕的隊伍，還有很多需要改善的地方和提公升的空間，包括pm、tm、rd、qt和md。說我們年輕，主要指我們以前都沒有在android平板上做類似專案的經驗。年輕就得學習，我們大家重點需要在需求、記憶體資源控制、設計模式、自測、測試等各方面切實提高、落到實處（這些都是我們的短板），只有這樣，才能盡快成長起來。2023年開發過程中出現的bug太多我們可以自己安慰說這是成長和學習所付出的成本，那麼在2023年呢？
二、 做好專案總結
接下來的幾天，我們做專案總結，總結是為了提高，「秦人無暇自哀，而使後人哀之；後人哀之而不鑒之，亦使後人復哀之」，哀即為總結、反思；鑑即為改善、提高。pdca我在這裡給大家解釋一遍。
plan方面，我們有project plan (專案計畫)，另有communication plan (溝通計畫)、quality plan (品質計畫)、estimation plan (預估計畫)、equipment plan (裝置計畫)。
do方面，重點是落實，執行。對於執行力，我的理解有執行力度和執行能力兩層含義。執行力度的解決方案是「認真」和「心態」；執行能力這個課題比較大，有機會再一起交流。
action方面，認識到不足後，我們去改進、改善、提高。
如此，日復一日、年復一年，積小成績為大成績，成為大牛。
三、 嚴格落實專案管理制度
我們在開發過程中所遇到的困難，最典型的是產生了比公司規定多得多的bug，有的模組花了比計畫長得多的時間，這些問題我認為最根本的原因是「欠債」導致的結果，沒有認真按照公司規定的專案管理制度進行q&a、內部規格與設計的review、code review等工作。
在專案初期的q&a階段，我們基本沒有提出什麼疑問，而q&a的好處是實實在在的，它有承前啟後的作用，加深我們對外部規格的理解（需求澄清）、指導我們對內部規格與設計。對於乙個最終有10萬多行**的專案，我們開發人員總共提了不到50個疑問，這是乙個不正常的現象。
外部規格編寫方面，我們有很多邊界沒有定義，比如超大檔案的處理、對已經人為破壞了檔案的處理、亂碼的處理、最小最大值規定等，而這些也是bug的重災區。這是我的問題，我需要反思與改進。
至於內部規格與設計的review、code review，由於專案進度的壓力，一直浮於形式。而我們回過頭通過最終的實際效果來看，沒有踏實做這兩個事情，我們表面上快了，實質上是慢了，因為衍生了一系列深層次bug。
所以，在2.0階段，我們要從心底認同公司的一套專案管理制度，好好落實而不是為了應付檢查而去交差了事。
某大型公司內部專案組管理方案 具有相當參考價值
專案組管理方案 一 本方案的適用物件 本方案適用於寶鋼國際進行除日常工作之外的新專案開發的需要，特別是成立專項小組，設定明確專案目標並有規定時間界限的專案，包括管理資源整合專案 如流程再造 技術改造專案 新技術開發專案如it等。二 專案組成員構成及工作職責確定 專案組一旦成立，需要立即明確小組成員 ...
關於在專案組中實施效能技術賦能的思考
賦能，顧名思義是指賦予某項能力或能量，對於本次服務端效能測試技術賦能來說，旨在增強研發人員對於效能的意識及主觀能動性，提高 質量，提高研發效能。在日常工作中我們發現了如下問題 1 效能成為盲點 有些同事並不清楚效能測試的工作內容是什麼，以及效能測試意義 2 遺漏效能問題 有些同事不清楚怎樣的系統表現...
在專案組也有段時間了，你對系統架構師了解過嗎？
系統架構師是乙個最終確認和評估系統需求，給出開發規範，搭建系統實現的核心構架，並澄清技術細節 掃清主要難點的技術人員。主要著眼於系統的 技術實現 因此他 她應該是特定的開發平台 語言 工具的大師，對常見應用場景能給出最恰當的解決方案，同時要對所屬的開發團隊有足夠的了解，能夠評估自己的團隊實現特定的功...