最近兄弟部門部門做了比較大的調整。需要重新去定義產品，並做好產品的版本規劃。從質量管理部okr來分析，支援產品部門做好產品規劃也是個優先任務。
（實際是以前沒有明確，達成約定的版本規劃和版本號定義…）
乙個好的產品規劃，除了對自己的產品有充分清晰地思考之外，還要兼顧外界的技術趨勢、業界的動態、公司資源的考量。一定不能盲目地去加各種各樣的需求，或者毫無目的地去做版本迭代。每個版本的需求一定都是基於產品目前的現狀，市場的情況，最後基於產品發展的目的而去做的。
這是我總結的產品規劃流程圖：
因為對具體的產品業務不清楚，所以在職能擅長的範疇內，我會在產品版本命名規則，環境分層兩方面給與產品部門具體的支援和建議。
軟體版本號的命名規範與原則
為了在軟體產品生命週期中更好的溝通和標記，很多公司對版本命名都有自己的一套規範，例如：
我們應該對軟體的版本號命名的規範和原則有一定的了解。
alpha版：也叫α版，此版本主要是以實現軟體功能為主，通常只在軟體開發者內部交流，一般而言，該版本軟體的bug較多，需要繼續修改。
beta版：此版本相對於α版已經有了很大的改進，消除了嚴重的錯誤，但還是存在著一些缺陷，需要經過多次測試來進一步消除，此版本主要的修改對像是軟體的ui。
rc版：此版本已經相當成熟了，基本上不存在導致錯誤的bug，與即將發行的正式版相差無幾，測試人員基本通過的版本。
release版：此版本意味著"最終版本"、"上線版本"，，在前面版本的一系列測試版之後，終歸會有乙個正式版本，是最終交付使用者使用的乙個版本。該版本有時也稱為標準版。一般情況下，release不會以單詞形式出現在軟體封面上，取而代之的是符號(r)。
2、版本號的命名規範與原則
軟體版本號有四部分組成：《主版本號.>《子版本號》.《階段版本號》.《日期版本號加希臘字母版本號》。希臘字母版本號共有5種：base、alpha、beta、rc、release。 例如：1.0.0.180313_base
通常，完全的版本號定義，分三項： 《主版本號.>《子版本號》.《階段版本號》, 1.1.0
3、版本號修改規則
主版本號(1.x.x)：當功能模組有較大的變動，比如增加多個模組或者整體架構發生變化。此版本號由專案決定是否修改。
子版本號(x.1.x)：當功能有一定的增加或變化，比如增加了對許可權控制、增加自定義檢視等功能。此版本號由專案決定是否修改。
階段版本號(x.x.1)：一般是 bug 修復或是一些小的變動，要經常發布更新版，時間間隔不限，修復乙個嚴重的bug即可發布乙個修訂版。此版本號由專案經理決定是否修改。
日期版本號(x.x.x.180313)：用於記錄修改專案的當前日期，每天對專案的修改都需要更改日期版本號。此版本號由開發人員決定是否修改。
希臘字母版本號(x.x.x.x_beta):：此版本號用於標註當前版本的軟體處於哪個開發階段，當軟體進入到另乙個階段時需要修改此版本號。此版本號由專案經理決定是否修改。
4、版本號的階段標識
按照軟體的研發過程，可以再將版本號進行相應的標註管理，但管理會變得過於複雜，視具體情況而定！
以android為例， android中有 versioncode 和 versionname，他們分別所代表的意思如下：
verisoncode:內部版本號，必須是整型。用來區分版本的新舊，版本號越大，代表距當前越近的發布版本。給開發者內部使用的。
versionname:向使用者展示的版本號，必須是字串，這個版本號就是我們可以用來遵循規範的位置，可以作為版本比較的，判斷是否需要提示更新、是否需要強制更新的依據。
使用scm進行**管理
公司使用的scm系統是svn， 以下結合svn介紹怎樣進行**版本管理。
subversion有乙個很標準的目錄結構，是這樣的。比如專案是proj，svn位址為svn://proj/，那麼標準的svn布局是
svn://proj/
|+-trunk
+-branches
+-tags
svn有兩種普遍的管理模式：
以trunk做開發：
所有的開發都是基於trunk進行開發
時間區間(1)
時間區間(2)
(2)的結束時間是turnk1.0.1開發的結束時間。結束時發布1.0.1產品。此時做以下事情：
以分支做開發：
時間區間(1)
時間區間(2)
(2)的結束時間是branch1.0.1開發的結束時間。結束時發布1.0.1產品。此時做以下事情：
一些注意事項：
如果修復bug，可以在trunk或者branch上做，但是一定要使用subversion的合併功能，而不是在trunk和branch上分別改兩遍。如果改兩遍，造成的結果是在要將branch合併到trunk上出現衝突。
如果有些核心資料結構的變動，將它放在小版本公升級後的第乙個迭代進行。避免對使用者造成公升級困難，或者使用者需要重新裝載所有資料。
合併**的時候需要非常小心，保證branch上的**和合併以後trunk的**一樣非常關鍵。如果不一樣會造成這種情況：第乙個從branch上發布的產品沒有問題；後來為了修復乙個bug，從trunk上發布乙個新版本後，出現了第乙個發布沒有出現的問題。
環境版本如何扭轉
專案因具體情況可能會出現多個測試環境進行維護的情況，這裡以三套環境，n日為週期為例，該類情況可參考以下流程進行版本發布！
角色：開發，測試，開發負責人、版本負責人
環境：開發環境、測試環境、準生產環境
時間線事務t日
9點版本負責人建立版本
9-16點，開發人員開發功能，修改bug（bug解決關聯禪道版本）
16-18點，開發負責人確認版本資訊（開發功能，測試注意事項，svn模組最後version），提交版本負責人
版本負責統計專案各產品版本資訊（開發功能，測試注意事項，svn模組最後version），驅動測試
t+n日
t+1日9點，測試人員更新測試環境
t+1日至t+n日15點，測試-測試版本（依據ｂｕｇ，功能，測試注意事項進行測試），提交ｂｕｇ（ｂｕｇ關聯禪道版本）
t+n日15..30-17點，確認測試環境版本資訊，提供專案經理（郵件描述版本更新內容及測試結果）
專案經理確認版本測試結果，驅動準生產環境進行更新
t+n日17點-18點。冒煙準生產
t+n+1日
測試準生產
開發版本：
測試版本：
產品研發過程管理的方法和工具
使用redmine進行研發管理，redmine不僅可以用來做軟體研發過程管理，而且可以用來管理非軟體研發的專案。它給整個團隊乙個總覽圖，同時記錄所有的細節。
產品經理之產品規劃
產品規劃 1.什麼是規劃 規劃是對未來的規劃,下個星期要做的事情不是規劃 規劃事要可以落地的行動方案,願景和理想不是規劃 新產品的規劃契機，主要是分析和說明方向和去式的可行性，通過盡量全面的論證來避免戰略上的錯誤 成長期的產品規劃，主要是突出產品迭代和演進過程中的產品路線，以把握諸多需求和功能的主次...
產品經理規劃
第一曲 方案曲 1.1 首先，找到方向 1.2 以巨人的視角俯視網際網路全域性 分二個方面 乙個是商業模式創意 乙個是技術創意，各有各的優缺點。商業模式缺點是門檻低，競爭極其激烈。優點是成長速度快，容易形成規模。舉例 拼多多。二年時間市場到了千億。技術創新相反 門檻高，週期也長，做成後壁壘非常高。舉...
敏捷開發產品管理系列之二 產品版本規劃
本文是敏捷開發產品管理系列的第二篇。序言及設立迭代目標，產品版本規劃，產品使用者群規劃，新產品研發，預估會議，product servant，product owner團隊，產品線管理 本文是一篇舊文，原名為 迭代期內無變更 與敏捷開發產品版本規劃 因符合本系列內容，做相應修改後重新編排發出。支援派...