㈠ 如何管理生产管理文件
首先需要明确是管理哪些类型的文件？文件的格式？用途？管理目的？
文件管理通常有以下几个方面：
①统一管理文件存储，实施存储空间的分配与回收。
②确定文件信息的存放位置及存放形式。
③实现文件从名字空间到外存地址空间的映射，即实现文件的按名存取。
④有效实现对文件的各种控制操作(如建立、撤销、打开、关闭文件等)和存取操作(如读、写、修改、复制、转储等)
⑤实现文件的高速存取
简单的说：保密存放，可高效检索，能借阅，可收回，文件版本号管理，可以借助信息化的管理系统来管理。
㈡ 如何使文件各资料做到最新版本，版次
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 。