## 序言 之前做研發的時候非常鄙視管理，覺得管理的那些人就知道搞政治，後來做了開發主管，以及到部門經理之後，管的人多了發現管理真是門大學問，真的應該每個人都要學習一些基本管理知識，特別是剛入社會的打工人。 具體的管理理論就不在這篇文章裡多說了，這篇文章的目的是針對最近的新組建的團隊做了一些最最基本的管理規範，由於我本人又核心負責產品的管理工作，所以習慣性把管理規範也當做產品來做，當前版本就叫v0.0.1吧，之所以起了個這麼小的版本號，是因為這個管理規範只有最基礎的框架，在後續的管理過程中會持續迭代，補充裡面的細節。 ## 1.會議管理 ### 月度會議 - 會議時間：最後一週，一般30~31號 - 會議內容：上個月工作情況總結，下個月計劃確認 - 會議材料：下個月規劃內容清單 - 會議產出：下個月詳細計劃 ### 每週例會 - 時間：星期一上午 9點半 - 會議內容：上週的產出總結，本週計劃 - 會議材料：本週計劃，上週產出物 - 會議產出：到日和人的任務分解 ## 2.產品管理 ### 產品需求流程管理  ### 產品版本管理 #### 版本的目標 每個版本需要有明確的目標，這個目標不是來自產品經理的單方面猜想，而是需要結合市場部門的需求制定當前產品的版本所滿足的市場目標，在版本管理時候不僅目標要明確，範圍也要明確，只有確定了需求的目標和範圍產品和研發人員才知道大概版本是什麼計劃時間點發布。 #### 產品版本規範 ##### 版本號管理 標準的版本號必須（MUST）採用 X.Y.Z 的格式，其中 X、Y 和 Z 為非負的整數，且禁止（MUST NOT）在數字前方補零。X 是主版本號、Y 是次版本號、而 Z 為修訂號。每個元素必須（MUST）以數值來遞增。例如：1.9.1 -> 1.10.0 -> 1.11.0 版本格式：主版本號.次版本號.修訂號，版本號遞增規則如下： 主版本號：大的版本升級，已經不相容當前版本了（包括樣式、底層功能等）， 次版本號：當你做了向下相容的功能性新增，例如新增了一個模組， 修訂號：當你做了向下相容的問題修正，一些小的問題改善，bug修正。 先行版本號及版本編譯元資料可以加到“主版本號.次版本號.修訂號”的後面，作為延伸。 ## 2.技術管理 ### 技術選型 小公司小團隊一個合格的CTO需要做好技術選型其實並不難，很多難不是難在技術上面，而是難在臉面上，技術選型一定不是追求技術的時尚程度，也不是技術的效能，而是目前公司人力資源是否擅長的，招聘人力成本上，因為很多小公司很難活到技術架構需要微服務，分散式這樣的普適性面試都會問的問題要求。 案例：一開始的技術選型，我們就是最普通的java，springboot框架+一個mysql，前端vue & element ui， redis？微服務？高可用？這些都沒有，因為系統在很長一段時間內每天的訪問量不超過1000人，技術的前期就是如何最小的成本把業務跑起來，後面再持續迭代優化，需要什麼再加什麼。 ## 參考引用 - 產品版本管理：https://semver.org/lang/zh-CN/ ### 關於作者 作為曾經的程式設計師，現在的產品經理，有時候狠起來自己給自己提需求的，曾經作為程式設計師我是快樂的，現在作為產品經理我也是快樂的，偶爾擼擼程式碼陶冶情操，不忘初心，通過技術和產品不去改變世界，只是表達點什麼，微信公眾號 `產品經理與狗`，主要寫一些產品、技術、管理等文章，歡迎關注。 ![](https://img2020.cnblogs.com/blog/94489/202012/94489-20201228002057682-18405141