㈠ 如何管理生產管理文件
首先需要明確是管理哪些類型的文件？文件的格式？用途？管理目的？
文件管理通常有以下幾個方面：
①統一管理文件存儲，實施存儲空間的分配與回收。
②確定文件信息的存放位置及存放形式。
③實現文件從名字空間到外存地址空間的映射，即實現文件的按名存取。
④有效實現對文件的各種控制操作(如建立、撤銷、打開、關閉文件等)和存取操作(如讀、寫、修改、復制、轉儲等)
⑤實現文件的高速存取
簡單的說：保密存放，可高效檢索，能借閱，可收回，文件版本號管理，可以藉助信息化的管理系統來管理。
㈡ 如何使文件各資料做到最新版本，版次
1、實驗室有各類文件，首先對實驗室的文件進行編號，保證每份文件都有唯一的編號。
2、文件的分發
2.1、資料員應負責建立所有文件、資料的明細和受控文件目錄。
2.2、資料員應建立文件發放清單，對下發文件進行編號登記，領用人應在「文件發放回收登記表」上簽收，使下發的文件始終處於受控狀態。
3、文件的替換和更改
3.1、技術負責人應組織有關人員定期跟蹤標准或規程/規范的最新出版信息。
3.2、資料員負責文件資料有效性的確認。需要替換或更改的技術文件應由使用人提出申請, 經技術管理層批准後, 由資料員登記編號下發使用。
3.3、文件的更改申請應說明更改的理由，必要時應提出書面依據及背景材料。更改的審批應由原審批人負責。文件修訂與更改相應記錄應保存。
4、文件的作廢與銷毀
4.1、應停止使用的技術文件，由使用人提出申請，經技術負責人批准後，中止使用。
4.2、所有失效或作廢文件由資料員及時從發放或使用場所撤出，加蓋「作廢文件」印章，防止使用作廢文件；尤其在合訂本中的有關標准，有效文件應予以標明。
4.3、因為某種原因需要保留的任何已作廢文件，都應進行適當的標識；
4.4、對要銷毀的作廢文件，由相關部門填寫「文件銷毀申請單」，編制人核准後報實驗室主任或其授權人批准銷毀。
4.5、資料員應對需淘汰的文件及時清理, 集中管理。需要銷毀的文件應由資料員列出銷毀清單，書面報告實驗室領導，批准後在質量負責人監督下銷毀。
5、文件的保管、借閱及歸檔
5.1、文件均應保存適當的期限。保存期限根據文件的重要程度而定。
5.2、借閱、復印文件應填寫「借閱申請單」，由實驗室主任審批後向資料員借閱、復印；資料員填寫文件借閱登記表。
5.3、所有原始觀察記錄、計算和導出數據、原始記錄、檢測和/或校準證書副本、能力驗證報告等都屬保密文件，其借閱、復印應執行《保護客戶的機密信息和所有權管理程序》並填寫「文件借閱登記表」。需要保密的文件應由資料員設專櫃保管。
5.4、文件的歸檔應安全貯存，防潮、防火、防蟲、防遺失，編號登記保管；
5.5、超過保存期的檔案資料，由資料員列出銷毀清單，書面報告實驗室領導，批准後在質量負責人監督下銷毀。
㈢ 如何做產品版本迭代管理
1. 為什麼要制定迭代計劃
有以下幾個優勢：
減少錯誤成本
提高進度專把控
限定屬范圍
管理客戶期望
維持系統穩定
2. 如何制定迭代計劃
確定工作范圍
預估工作時間
制定迭代計劃
1. 開發進度管理
提高可控性
降低延期風險
確保開發對需求的正確理解
及時排查進度障礙
選擇更優的實現方式
引起團隊重視
保障項目資源
多請下午茶
2. 控制任務變更
減少需求調整
控制新增任務
3. 發版管理
用戶通告
規范更新文檔
制定發版標准
資源保障
每一次迭代就是一次小的項目管理，推動項目的前進需要依賴產品經理豐富的溝通技巧以及極強的執行能力。
㈣ PM如何做好需求管理和版本規劃
不管是個人還是公司，在每一年或者季度都會有目標、方向上的規劃。其實產品也是一樣，也是需要目標作為方向的指導。
不管是做一個項目，還是做個產品，明確知悉「目標」，並且以「目標」為最終導向來分解各個階段目標，朝著方向努力，正如黑夜中向著光明的那一盞燈，即使道路曲折但只要有方向，就不會迷失。
產品的目標，分為［長遠目標］和［短期目標］：
產品的長遠目標，是與產品定位和戰略掛鉤的，產品最終給用戶呈現的是一個什麼東西，能給用戶解決什麼問題。
短期目標，則可以理解為長遠目標的拆分，可按時間拆分季度目標、月目標，或者再細顆粒度拆分為版本目標，在考慮短期目標時需要確保方向是在長期目標范圍之內的。
這點相信很多的pm在工作過程中也是知道的，所以不展開細講，寫在這里，只是強調「目標」的重要作用，不管在分析一個需求還是在做規劃的時候，都需要有桿「目標」秤，時不時去思考，訊問自己：這符合目前的目標嗎？對完成目標有意義作用嗎？
pm的工作不但是對產品需求進行挖掘分析、產品設計，而且更多的時間需要花在版本/需求管理上，所以，想重點來講講關於版本管理和需求管理的一些工作經驗分享。
什麼時候需要開始版本的管理？如何進行管理？版本前和版本後具體需要做些什麼？想必是具體的疑惑點，結合自己的工作經驗和總結，個人總結了產品版本規劃的流程規范，具體可以看下圖：
為確保版本開發資源的銜接性，版本開發需要進入並行狀態才不會產生資源的閑置。當一個版本開發完畢後，就要立馬開展下一個版本的開發，因此，在上一個版本的開發完畢前就要完成新版本的需求設計任務。
一般來說，在完成一個版本的需求分析（包括原型製作、需求評審、需求文檔編寫）並成功遞交給開發後，就要開始新版本的規劃任務了。
1、版本目標的確定：在這個版本需要處理哪些模塊的功能或者重點支撐哪個用戶
2、版本規劃書：具體要做什麼功能，涉及到哪些端，一般一個版本是大功能＋小功能＋眾多bug
3、版本規劃會議（部門內部會議，確定版本，確定資源分配）：眾人拾柴火焰高，個人的力量與想法畢竟有限，而且技術、運營在版本上也會有自身的計劃和想法，因此需要一起來評審規劃的版本計劃，讓各方了解計劃要做些什麼，也提前准備和進行時間評估。
版本中管理，在我理解，其實就是一個需求管理的過程。
許多同學會問：那麼每個版本到底要做些什麼需求呢？來源在哪？我個人覺得，管理好需求，就是規劃版本的來源了。
需求可以分為未挖掘的需求、待規劃的需求、規劃開發中的需求，來源包括外部用戶反饋、同事反饋、內部領導、運營團隊、項目團隊以及競品中分析的需求，自己的產品研究得出的想法等等。
那麼根據需求類型也可將需求管理總結為三點：1、用戶反饋的記錄管理 ；2、需求池的管理 3、當前開發任務的跟蹤
針對以上3個方面的，我總結了3個層面的列表管理清單（需求池的建立及管理工具，有很多，excel、X-mind、trello 、oBridge、禪道，最適合也最直觀的個人還是會使用excel）：
用戶反饋列表，收集各種吐槽、優化建議、新創意idea（用戶的任何一個反饋，都不能放過。從中挖掘，或許會有新的想法和創意）
使用說明：
只要是有產品的反饋，不管大小，都需要記錄下來，最原始最直接的反饋，往往是很多pm會不重視。
及時針對反饋進行等級標注，致命問題需要及時排入版本或者緊急修復，也可鍛煉pm的敏銳性。
需求特性列表，需求記錄及日常管理的清單列表，我會統稱為需求池子（這三個清單中最為重要的）
使用說明：
這個清單有兩個用途：
(1)對目前開發中的需求進行進度跟蹤，包括需求分析的進度和開發的進度，哪些需求還在UI設計階段，哪個端已開發完畢等等，在一個列表中能看得很清楚。具體要看公司對pm的定位，有些公司會將pm的職責定位為項目管理者。
(2)是作為需求池子，對待規劃的需求進行管理、分派解決版本，即為確定哪個需求在哪個版本中處理
這個清單，是需要團隊中的每個人進行及時更新、維護的，因此規范非常重要。
一般來說，錄入需求池是由pm來負責，包括優先順序、來源、類型等內容的確定（黃色區域）。在做每個版本的規劃前，需要把即將要在下一個版本作的功能需求更新到該清單中（一般是在開完版本規劃部門會議，並且得到大家認可無誤後更新）。
開發團隊、設計團隊則對目前該需求的狀態進行更新維護（紅色區域）。更新時間一般是在每周五部門例會前進行更新，例會時會根據狀態進行工作核對。並且在周一分配工作任務時，也可結合清單來進行分配。
自己在每天的體驗產品方面遇到的bug及優化點（這個列表，是鍛煉自己要保持對產品使用頻率）
使用說明：
這個清單其實是給自己記錄來用的。作為合格的pm是需要每天來用自己設計的產品，從用戶的角度去體驗產品，從中發現需要改善的地方。因此就給自己制定了這個清單。
另外也想聊聊，關於pm的日常工作。傳言產品經理需要掌握的技能很多，能畫得了原型，分析得了市場，談得了需求，也能協調得了產品生命周期各環節的工作。我也想分享下，自己作為產品經理的日常：
1、每日產品體驗 （Bug List)
每天需要處理關於產品的很多雜亂事項，但每天我也會至少留半小時的時候，對自己的產品以及競品反復體驗，並且記下體驗過程中得出來的需求點。這一點能保持作為pm的產品觸覺，也能讓自己回歸為用戶去體驗、思考產品。
2、用戶反饋收集與反復查看（Feadback List）
每天定期查看產品的用戶反饋後台，自建渠道包括用戶群，社交媒體是否有用戶投訴反饋，清楚問題之後記下需求點，若是屬於bug或者急需解決的需求，立刻反映給開發解決，若是屬於不緊急的需求，則列入版本迭代規劃中。
3、數據分析（可行性低，b端產品）
4、每日站會，了解目前階段情況，統籌與識別風險
每天會組織團隊開10分鍾左右的站立式會議，主題很明確，每人發言將昨天自己工作的內容和今天計劃要做的事情，具體涉及到需要協調、溝通的，會議後再具體進行，在不耽誤大家的工作時間情況下，是了解目前進度的很好的方式。
㈤ 軟體系統怎麼做版本管理
軟體開發好之後，代碼不是一成不變的，需要不斷調整，比如新增功能，優化功能，修復bug。
那麼如何去區分不同時期階段的代碼呢？就有了所謂的版本管理概念，比如剛發布的軟體系統定義為1.0版本，推出新功能之後就是1.1版本。
我們通過命名版本號的方式來區分不同版本的代碼，例如1.1版本新增了1個功能，優化了2個功能，修復了3個bug。
來看一個實際的例子，我們開源的likeadmin是怎麼做版本管理的。
likeadmin的所有代碼變更都公開在gitee代碼託管平台，大家可以看到我們的程序員每次提交的代碼更新日誌。
每當研發完成一個版本的所有規劃功能，我們會在gitee發布新版本。發布新版本之後，程序員就可以繼續進行新的功能研發了。
接下來雖然不斷會有新的代碼提交，但是直接點擊對應版本的下載鏈接，就能下載該版本的代碼了，不會弄混，這有點 歷史 鏡像的感覺。
另外，為了進一步方便大家下載likeadmin不同版本的代碼，並且了解版本之間的區別，我們專門在官網做了一個更新 歷史 的頁面。
這個頁面，點擊進去就是一個時間軸，記錄了不同版本的發布日期，版本變化。
這就是likeadmin的版本管理方式了。
歡迎點贊加關注，帶你一起深入了解程序員視界。
㈥ SVN如何管理項目的版本號，如1.0.1.xx，修改到1.1.1.xx
一般是這么操作的：
首先在項目版本庫的根目錄下建立trunk、branches、tags三個文件內夾，容日常開發都在trunk文件夾下進。其中tags文件夾主要用於進行版本標記，對此文件夾通常只有該項目的配置管理員有寫的許可權，其他人只讀。
當開發到某個大版本（如1.0.1）完成的時候，就用分支/標記功能，在tags文件夾下拉個分支出來，這個分支就標記為release_1_0_1，當下一個版本（如1.1.1）完成的時候，就再往tags文件夾下拉個分支出來，標記為release_1_1_1 。