软件版本管理规范
软件版本管理
目录
1.引言 (1)
1.1.目的 (1)
1.2.范围 (1)
1.3.术语定义 (1)
1.4.参考资料 (2)
1.5.版本控制记录 (2)
1.6.版本更新记录 (2)
2.版本管理 (4)
2.1.版本标示方法 (4)
2.1.1.正式版本 (4)
2.2.目录结构 (5)
2.3.文档的存放 (6)
2.3.1.开发文档的存放 (6)
2.3.2.源代码的存放 (6)
2.3.3.SQL的语句存放 (7)
2.3.4.发行文档的存放 (7)
2.4.配置管理流程 (7)
2.5.权限控制的管理 (8)
3.更新管理 (9)
3.1.源程序的修改 (9)
3.2.版本升级 (10)
3.2.1.版本升级原则 (10)
3.2.2.新版本发布 (11)
3.3.文档的变更 (11)
4.备份管理 (12)
1.引言
版本控制就是对软件开发过程中所创建的配置对象不同版本进行管理，保证任何时间都可以取到正确的版本以及版本的组合。
版本控制的主要功能是记录开发过程中的每一次修改，让开发的工作可以随时检查过往历史记录和获得正确版本，是系统的成长记录。
1.1. 目的
本文档的编制是为了规范产品部、研发部、测试部对软件产品版本的管理。
1.2. 范围
本文档为产品部、研发部、测试部的管理员提供有关版本管理规范的相关内容，包括：
●版本标识方法
●软件系统数据的存放
●文档的修改控制
●文档的备份制度
1.3. 术语定义
SCM
软件配置管理（Software Configuration Management）缩写
SVM
软件版本管理（Software Version Management）缩写
SVN
一个开源的版本控制系统Subversion.
文档
一种数据媒体和其上所记录的数据。
配置管理
标识和确定系统中配置项的过程，在系统整个生存周期内控制这些项的投放和更动，记录并报告配置的状态和更动要求，验证配置项的完整性和正确性。软件配置
软件的具体形态在某时刻的瞬时影像。
配置项
软件配置管理的对象称为配置项，如：系统规格说明书，项目开发计划，用户手册，源码。
基线
软件生存周期中各开发阶段末尾的标记，它的作用是把各阶段工作的划分更加明确化，使本来连续的工作在这些点上断开，使之便于检验和肯定阶段成果。
1.4. 参考资料
《软件版本管理规范》浪潮集团山东通用软件有限公司
《泰豪软件开发软件版本管理制度》
《tortoise SVN的使用手册》
1.5. 版本控制记录
版序状态部门拟稿审核批准发布日期
1.0
1.6. 版本更新记录
*A - 增加M - 修改D - 删除版本/修订版修改页码修改记录修改人日期
1.0 初始版本
2.版本管理
2.1. 版本标示方法
为了使工作规范化、统一化，研发本部各部门实行的版本标识管理方法。2.1.1.正式版本
软件版本号由四部分组成，X.Y.Z.DATA_希腊字母，
X：主版本号，用来表示提供给客户的产品功能的主要增强。在一个极端的例子中，主版本号的上升用来说明产品现在已经拥有了一个全新的功能类。从市场和许可权的角度来看，主版本号的升级相当于购买一个完全独立的产品。从开发者角度来看，一个主版本号的迭代差不多总是反映了一个新的独立分支或是其主干还可以延续主版本的生命期。
Y：特征版本号，用来表示产品新增了一些特征，或者是在原来文档中描述的特征上作了重要的修改。用来确定特征版本号什么时候需要修改的一个衡量标准就是产品功能说明书。产品的特征版本升级是在主版本之间保持产品竞争力的一种重要机制。
Z：缺陷修复版本号，用来表示在该版本上所做的缺陷维护行为的等级。版修复版本是稳定市场和最小化客户技术支持费用负担的一种重要机制。
Alpha版: 此版本表示该软件在此阶段主要是以实现软件功能为主，通常只在软件开发者内部交流，一般而言，该版本软件的Bug较多，需要继续修改。
Beta版: 该版本相对于α版已有了很大的改进，消除了严重的错误，但还是存在着一些缺陷，需要经过多次测试来进一步消除，此版本主要的修改对像是软件的UI。
RC版: 该版本已经相当成熟了，基本上不存在导致错误的BUG，与即将发行的正式版相差无几。
Release版: 该版本意味“最终版本”，在前面版本的一系列测试版之后，终归会有一个正式版本，是最终交付用户使用的一个版本。该版本有时也称为标准版。一般情况下，Release不会以单词形式出现在软件封面上，取而代之的是符号(R)。例如：1.1.1.051021_beta.第一个1为主版本号，第二个1为子版本号，第三个1
为阶段版本号，第四部分为日期版本号加希腊字母版本号，希腊字母版本号共有5种，分别为：base、alpha、beta、RC、release。
2.2. 目录结构
由于各部门的实际情况不同，目录结构很难统一，但为了能更好地管理各部门部文档，建议可将被管理的配置项分为三大类：文档类、源码类及安装盘类，这样存放比较清晰，有利于版本管理。具体目录如下表格所示：
根目录一级目录二级目录三级目录
项目名称+版本号源代码（SRC）
集成代码代码的合并
第一个模块代码
第二个模块代码
数据库SQL
公共开发包代码
文档(DOC)
立项文档立项计划书立项申请书
项目计划项目开发计划
需求文档需求规格说明书
设计文档设计概要说明书数据库设计说明书
界面布局原型界面动态页面
参考资料项目一些参考资料
验收文档验收资料
测试文档测试计划测试报告测试用例
试用信息
测试部署部署材料
发布（RELEASE）
SETUP
RELEASE
发布文档
2.3. 文档的存放 2.3.1. 开发文档的存放
文档归档流程：
文档编写员编写文档
评审人员
文档评审
配置管理员修改文档
格式规范化检查
评审版本
确认版本
不通过
通过
2.3.2. 源代码的存放
测试人员
配置管理人员
从SVN 提取代码编译
制作安装程勋
打印测试本
入库安装程序源代码测试报告评审报告更新版本
系统测试
开发人员
源代码入库
从SVN 上提取代码
修改源代码
通过
不通过
2.3.3. SQL 的语句存放
各子系统SQL 文件放入…..\.......\SQL 下，对于不同的数据库，分别建立不同的子目录，如WAT 、SYB 、MSS 、ORC 、DB2等。公共SQL 文件直接放入…\SQL 下即可，不同数据库的特殊SQL 分别放入对应的子目录下。
2.3.4. 发行文档的存放
发行文档是指产品交付用户使用所必须的文件。包括：产品可执行文件，用户使用说明书，联机帮助（HLP ）；资源文件（BMP ，ICO 等），环境配置文件等。
2.4. 配置管理流程
提交测试任务
完成开发任务
提交发布请求处理BUG
测试执行测试计划
测试用例
提交测试报告
更新测试环境
回归测试
新版本发布入库提交测试部发布文档更新
额定版本信息制作安装程序
研发人员项目管理人员测试人员
配置管理人员
流程说明：
1.开发人员完成所负责代码模块的编写任务后，提交到项目经理处；
2.项目经理向测试部提交测试任务；
3.配置管理员准备测试所需环境；
4.测试员开始测试并提供实时测试BUG ；
5.开发人员处理测试人员提供的BUG ，并提交测试员进行回归测试，直至BUG 关闭；
6.测试完成后，测试人员提供测试报告；
7.根据项目情况决定是否发布新版本；
8.配置管理员与各成员确定好新版本的各项信息；
9.配置管理员发布新版本。
2.5. 权限控制的管理
为保障文档的安全性，一致性，以及防止意外修改，必须对不同的文档设置不同的访问权限。
文档权限类别：只读权限，读写权限。
文档类别：DOC，SRD，RELEASE。
用户类别：开发人员、测试人员、分析设计人员、部门经理、配置管理员、安装盘制作人员、问题及需求管理人员、用户文档编写人员等。
为了控制不同的使用权限，根据要求在服务器上分别建立不同的用户，针对不同的配置项所在目录分配不同的权限。
为了便于各部门的管理，应以表格的形式列出人员与管理对象的访问关系（用户权限清单）。
3. 更新管理
3.1. 源程序的修改
变更申请人
评审人员
开发人员
测试人员
配置管理人员
提交变更
取消变更
变更实施代码测试
更新版本归档入库
变更影响分析
审核
测试报告评审
当开发小组在开发同一产品时，应能保障：各成员间的修改不会互相覆盖；程序员的修改能及时反映到产品的最新版本中。
建议首先在相应子系统的下一级建一目录，如checkout ，存放正在修改的文档及修改登记表。当某个程序员要修改某一文档时，遵循以下程序：
1) 接收维护任务；
2) 查看需要修改的文件（如PBL 及SQL 等）是否正在被其它人员修改（检查checkout 目录下是否存在要修改的文件或后缀已改为该程序员姓名简写）；
3) 如果有人在修改该文件，等待或与相应的开发员联系，重复2。否则继续；
4) 将该文件复制到checkout 目录下，在修改登记表中登记；或将该文件的后缀改为本人姓名简写；
5) 将该文件拷贝到自己的私有目录； 6) 根据要求修改源文件；
7) 根据要求测试，并进行相关项的回归测试；
8) 交测试人员测试，如未通过，重复6，如通过则继续；
9) 在checkout 目录中删除该文件，并在修改登记表中标注修改完成； 10) 将修改完毕的文件通过电子邮件或其它手段送交版本管理员，版本管理员将文件复制到相应的路径；如遇特殊情况（版本管理员出差），程序员可将修
改完毕的文件复制到相应的路径下，或将后缀改回正式。
11)回复下达者，报告维护任务完成。
3.2. 版本升级
3.2.1.版本升级原则
版本升级应严格纳入版本管理的控制之下。应当谨慎地控制版本的升级，保障高版本的向下兼容性，或提供严格定义的升级方法。
主版本号(1)：当功能模块有较大的变动，比如增加多个模块或者整体架构发生变化。此版本号由项目决定是否修改。
子版本号(1)：当功能有一定的增加或变化，比如增加了对权限控制、增加自定义视图等功能。此版本号由项目决定是否修改。
阶段版本号(1)：一般是Bug 修复或是一些小的变动，要经常发布修订版，时间间隔不限，修复一个严重的bug即可发布一个修订版。此版本号由项目经理决定是否修改。
日期版本号(140606):用于记录修改项目的当前日期，每天对项目的修改都需要更改日期版本号。此版本号由开发人员决定是否修改。
希腊字母版本号(beta):此版本号用于标注当前版本的软件处于哪个开发阶段，当软件进入到另一个阶段时需要修改此版本号。此版本号由项目决定是否修改。
每次版本升级，要填写版本升级记录表，
记录表样例如下：
主版本号子系统
名称
子系统
版本
发布
日期
变更功能描述
发布
人
批准
人
备注
主版本号：记录当前发布的版本
发布日期：该版本批准发布的日期
修改文件：版本修改记录，版本修改日志
3.2.2. 新版本发布
新版本的发布包括主版本号和次版本号的升级，一般不包括内部版本号的升级。流程如下：
1) 接收新版本发布任务，接收本次发布的版本代号。
2) 在指定目录中，根据本次发布的版本号建立相应的子目录，将current 下的所
有内容拷贝至新建目录下。
3) 可在新建目录下建立readme.txt ，并加入相应的内容。
3.3. 文档的变更
文档变更流程：
变更申请人
提交变更评审人员文档评审
文档编写人员
取消变更
变更实施
打评审版本确认版本不通过
配置管理员
变更影响分
析及审批更新版本
不通过
通过
通过
4.备份管理
为了保证文档的最大可恢复性，要随时及定期地进行备份工作。
1)随时备份：
①开发人员每天都要将自已当日修改的源文件在本地机器上进行备份。
②开发负责人每天要将所有源文件在本地机备份。
③建议备份采用循环备份。
2)定期备份
①备份形式为硬盘备份和光盘备份。硬盘备份时，要备份在独立的硬盘上；光盘备份时，要将光盘存放在可靠的地方。
②备份周期视各部门的具体情况而定。如果处于开发阶段，每周应对所有的源程序项进行备份，一般为每周周五；如果处于其它阶段，根据具体情况而定，但周期不能超过两周。
③备份要由版本管理员负责，备份原则应是保证文档的最大可恢复性。
UL产品的品质管理规范-第2版
UL产品的品质管理规范编制：
审核： 批准： 创建日期：2010.5.18 更新日期：2010.11.10 UL产品的品质管理规范 1、目的 1.1严格管控UL产品是否符合FUS细则要求和物料的追溯要求。 1.2保证不符合FUS细则要求和物料追溯要求的物料和产品不投入使用和交付。 1.3减少VN项（不符合报告）的开具 2、适用范围 本规范适用于通过UL认证的产品的跟踪服务检查和新品的验证检查。
3、引用文件 Follow-Up Service Procedure、E228719文件、E332532多重列名文件，Traceability Requirement，Printing UL Mark 4、职责 4.1研发部针对UL产品的新品研发要符合该类产品的UL标准要求； 4.2采购部负责采购的物料符合UL中FUS细则要求和追溯要求； 4.3生产制造部负责加工工序符合FUS细则要求和追溯要求； 4.4品质管理部负责物料追溯材料的采集、物料的入库检验、加工工序的监控和成品检验，FUS细则的保存和更新，接待当地的UL检查员的检查工作。 5 UL跟踪检验程序 5.1 UL当地检查员会以事先不告知的方式到工厂检验，并依照UL的FUS细则做检查； 5.2 工厂生产UL的产品类别属于TYPE R,检验频率在一般情况下是一年四次，及每个季度一次； 5.3 工厂代表必须在UL检查员被告知后的10分钟内出面，带其进入工厂进行检查，若指定的工厂代表不在，则要由其代理人陪同检查员完成检查工作，工厂不得拒绝UL检查员进入生产区域或原材料库/成品库等与生产有关的地方； 5.4文件要求 5.4.1 工厂代表必须妥善保存UL的FUS细则，并适时地更新； 5.4.2针对UL要求的检验、测量和测试的设备，其内校和外校报告必须符合UL仪器校验规范（UL IMTE Requirements） 5.4.3UL要求的检验、测量和测试的设备的校验计划、校验和点检记录要随时可查。 5.5生产线的检查 ●UL检查员检查确认相关加工过程是否符合要求。例如：焊锡、时间、温度等是否符合细则中关键 部件的黄卡信息中的要求。 ●UL检查员随意抽取生产线上的半成品或未入库的成品，查看产品部件、标签是否符合要求。 5.6原材料库和成品库的检查 ●原材料库的检查 UL检查员根据细则要求抽查产品中使用的物料，查看该物料的包装和追溯材料是否符合要求； ●成品库的检查
公司软件管理规范
XXXXXX有限公司 文件制订（修订、作废）申请单NO.: 表格编码：
1. 目的 为规范公司软件、程序的管理，确保开发、使用、变更等过程得以受控，根据本公司实际情况，特制定本规范。 2. 适用范围 本规范适用于公司所有自主开发、外购、客供软件、程序的管理。（如无特别说明,本规范内“软件”包含软件、程序） 3. 软件分类: 3.1产品源程序: 由研发部软件开发工程师编写，实现产品功能的烧录文件。 3.2 ATE测试软件及测试程序： 是指由信息技术部负责编写的配套ATE硬件使用的产品测试软件平台,及在此平台下针对不同型号产品编写的测试程序。 3.3 设备应用程序: 是指工程部在设备操作系统下针对不同产品型号编写的对应程序（ATE除外）。如：打码程序、贴片程序、SPI检测程序、AOI检测程序、分板程序、回流焊程序、X-Ray 测试程序等。 3.4管理应用软件: 是指企业使用的电子化管理工具或系统平台。如:ERP系统、品质管理系统、SPC系统、生产报表系统、电子看板系统、绩效管理系统、项目管理系统等 3.5办公软件：Windows、office、Coremail、PDM、AutoCAD、杀毒软件等。 4、职责定义: 原则上公司各部门均可依据自身需求提出软件申请，由技术部门进行开发，交由使用部门进行管理，异常无法解决时,可向技术部门寻求技术支援。具体定义如下： 4.1 需求提出部门:依据公司或者部门的实际情况,提出软件需求申请。软件需求多由软
件使用部门提出，但也可以由其它部门提出。 4.2使用/管理部门:对提出的申请进行评估,确定需求后向开发部门发起正式申请;在软件验收合格后负责日常的管理、维护等；当异常时且无法解决时，及时向开发部门反馈,并要求协助处理。 4.3开发部门:对于使用/管理部门提出的申请进行评估,确定执行方案,并最终完成软件开发；开发部门也负责后期的技术支援。 4.4监控部门:负责对软件验收完成后的使用过程进行监控，确保不出现使用错误,维规操作,使用非法软件及机密软件外流等。 4.4软件管理职责对照见下表： 分类开发部门使用/管理部门监控部门 产品源程序研发部工程部品质部 ATE测试软件及测试程序信息技术部工程部品质部 设备应用程序工程部工程部品质部 管理应用软件信息技术部使用部门信息技术部 办公软件信息技术部使用部门信息技术部 5.软件管理规范： 5.1软件申请、开发、使用管理流程图：（如下图）
项目立项管理制度
经营类项目立项管理制度 1．目的 为规范集团投资决策的基本程序，以化解风险，减少损失，提高效益，特制定本制度。 2．适用范围 本制度适用于集团总部和各分子公司。 3．定义 经营类项目指以盈利为目的，周期长、投资较大，一般采取有限责任公司等独立法人形式长期运营的项目。 4．职责 4.1集团投资发展中心负责各类项目信息汇总、完成《项目建议书》，并提交董事长办公会研究。 4.2集团事业部或董事长指定责任人负责组织《项目可行性报告》编制，并提交董事长办公会讨论。 4.3董事长办公会负责《项目建议书》、《项目可行性研究报告》、项目立项的审批。 5．文件内容 5.1项目立项流程 项目立项由三步工作完成：提交《项目建议书》；；审议《项目可行性研究报告》；决策立项。 5.2项目建议书 各类项目信息由投资发展中心汇总、完成《项目建议书》，并提交董事长办公会研究。 5.3项目可行性 《项目可行性研究报告》由集团事业部或董事长指定责任人负责组织编制，并提交董事长办公会审议决策。
5.4外聘 如在项目论证过程中需要外聘专家或机构，另行规定。 5.5项目立项 项目经董事长办公会审批立项后，应确定项目经理。投资发展中心登记立项，并下发《项目任务书》；人力资源中心据此调配项目组人员；财务管理中心凭此注入开办资金。 5.6本制度与《投资项目红黄绿灯管理制度》、《股权激励制度》等制度配套执行。 6．相关文件 《投资项目红黄绿灯管理制度》、《股权激励制度》 7．附件 附件一《项目任务书》、附件二《项目可行性研究报告》 8．附则 8.1本制度由董事长办公会制订和执行，投资发展中心负责解释和实施。 8.2本制度自颁布之日起生效。
腾讯干部管理
腾讯管理干部管理规范 1 目的 为规范公司管理干部晋升/任命及未胜任基层管理干部管理等流程，明确具体要求并指导相关工作，建立干部能上能下的管理机制，以适应公司持续发展及强化内部管理的需要，特制订本管理规范。 2 范围 本管理规范适用于以下三个方面： 2.1各级中层及基层管理干部的晋升/任命，均须符合本规范标准与流程；高层管理干部的晋升由公司人力资源管理委员会和总办根据公司业务战略以及相应的干部晋升标准进行逐一讨论、集体决议。 2.2 各级基层管理干部中未胜任人员的管理，均须符合本规范标准与流程；中高层管理干部中未胜任人员的管理方式由公司人力资源管理委员会根据各人实际情况进行逐一讨论、集体决议。 2.3 管理职级需要符合《腾讯组织架构与管理职级管理规范》所规定的相关标准。 3 定义 3.1 高层管理干部：是指通过公司红头发文，正式任命的管理职级在公司副总裁以上（含公司副总裁）级别的管理干部，包括公司副总裁、高级副总裁、高级执行副总裁等。 3.2 中层管理干部：是指通过公司红头发文，正式任命的管理职级为助理总经理、副总经理、总经理的管理干部。 3.3 基层管理干部（以下简称“基干”）：是指通过联合发文，正式任
命的管理职级为副组长、组长、副总监、总监、高级总监的管理干部。 3.4 晋升：是指在腾讯管理干部职级体系中从低一级的管理职级提升到新的更高的管理职级，同时赋予与新职务一致的责、权、利的过程。中层管理干部晋升指“基层管理干部->助理总经理->副总经理->总经理”的晋升；基层管理干部晋升是指在“员工->（副组长）->组长->(副总监)->总监->（高级总监）”的晋升，其中副组长、副总监与高级总监视工作及管理需要为可选职级。 3.5 任命：是指对拟任的管理干部通过红头发文或联合发文正式公告、并授予相应责、权、利的过程。 3.6 降职：是指在腾讯干部管理职级体系中,从较高的管理职级下降到较低的管理职级，同时匹配与新职级一致的责、权、利的过程。基层管理干部降职是指从“高级总监->总监->副总监 ->组长->副组长”的管理职级下降,具体可视工作及管理需要,降职至较低一个管理职级或更低的管理职级。 3.7 免职：是指免去所有管理职务，从管理干部转为员工，同时匹配与新岗位一致的责、权、利的过程。 4 干部晋升/任命任职资格 4.1 干部晋升/任命原则 各级管理干部晋升/任命应该遵循以下基本原则： 4.1.1 组织发展需要原则：管理干部的岗位设置遵循以组织或业务发展为目的的必要原则。 4.1.2公正公平原则：在晋升/任命时严格遵照本规范对管理者的资历、
产品版本管理规范
基于Tortoise SVN的软件产品版本管理规范[草稿]
目录 1. 引言 (1) 1.1. 目的 (1) 1.2. 范围 (1) 1.3. 术语定义 (1) 1.4. 参考资料 (2) 1.5. 版本控制记录 (2) 1.6. 版本更新记录 (2) 1.版本管理 (4) 2.1. 版本标示方法 (4) 2.1.1. 正式版本 (4) 2.2. 目录结构 (5) 2.3. 文档的存放 (6) 2.3.1. 开发文档的存放 (6) 2.3.2. 源代码的存放 (6) 2.3.3. SQL的语句存放 (7) 2.3.4. 发行文档的存放 (7) 2.4. 配置管理流程 (7) 2.5. 权限控制的管理 (8) 2.更新管理 (9) 3.1. 源程序的修改 (9) 3.2. 版本升级 (10) 3.2.1. 版本升级原则 (10) 3.2.2. 新版本发布 (11) 3.3. 文档的变更 (11) 3.备份管理 (12) 4.版本工具Tortoise SVN的使用 (13)
1.引言 版本控制就是对软件开发过程中所创建的配置对象不同版本进行管理，保证任何时间都可以取到正确的版本以及版本的组合。 版本控制的主要功能是记录开发过程中的每一次修改，让开发的工作可以随时检查过往历史记录和获得正确版本，是系统的成长记录。 1.1.目的 本文档的编制是为了规范产品部、研发部、测试部对软件产品版本的管理。 1.2.范围 本文档为产品部、研发部、测试部的管理员提供有关版本管理规范的相关 内容，包括： ●●●●版本标识方法 软件系统数据的存放文档的修改控制 文档的备份制度 1.3.术语定义 SCM 软件配置管理（Software Configuration Management）缩写SVM 软件版本管理（Software Version Management）缩写 SVN 一个开源的版本控制系统Subversion. 文档
业务项目管理办法(试行)
支付业务项目管理办法（试行） 第一章总则 第一条目的 为规范公司业务项目管理，明确业务项目管理的工作要求、项目管理各方职责以及工作流程，合理配置资源，确保公司各业务项目的全面评估、有效管控，提高业务项目管理的工作效率和水平，特制订本办法。 第二条基本要求 业务项目（以下简称项目）管理工作的基本要求是：鼓励创新、服务市场、科学管理、规范流程。 1.在执行公司有关保密规定的原则下，由公司业务规划管理委员会及业务与运营管理部对项目立项评审、项目实施、阶段性成果、项目上线评审以及项目工作效果评估等进行公开发布。 2.项目主办部门应按照项目规划进度，定期报告项目推进实施和执行情况，并具体说明项目分阶段的进展程度。 3.项目推进过程中应严格按照项目方案和项目工作流程操作。对于已经生产上线的项目，业务与运营管理部组织对项目运作情况定期开展过程控制、监督评价及项目质量效果评估。 第三条适用范围 本办法适用于以下项目的管理： 1.公司面向市场所开发的新业务、新产品。主要指在业务品
种、产品功能、支付方式、业务管理、运营流程等一个或多个方面，与公司现有业务和产品具有显著差异，或对公司现有业务和产品进行重大改进、资源整合，并能给公司带来较好经济价值的业务和产品。 2.已上线的综合支付项目的优化，涉及较大程度的系统、业务改造支持。 3.公司明确要求进行立项和上线评审的其他项目。 4.已上线，需进行跟踪评价和监督管理的项目。 总公司各部门及各分支机构应遵照本办法（含附件）的要求，开展项目立项、上线评审及项目跟踪评价等相关项目管理工作。本办法内容将根据公司业务的实际发展情况，及时进行更新和调整。 第二章参与主体及各方职责 第四条参与主体 在项目管理工作中，参与主体应主要由项目主办部门、项目管理部门和项目专业评审部门组成。 项目主办部门，是提报项目立项申请的部门，承担项目建设的主要工作责任，并完成项目立项申请、项目上线申请等所需的项目基础资料的准备工作。 项目管理部门，是负责组织项目论证、立项评审、上线评审，协调推进项目实施和项目过程管控，开展项目效果评估管理的部
腾讯管理干部管理规范
腾讯控股集团管理标准 GＬ/HＲ０10—2012V４.0-L1腾讯管理干部管理规范 2012－6-１５发布 2０12-6—１５实施 腾讯控股集团
前言 本标准公司于２0０６年3月16日以腾集字［2００6]05号文件发布实施，主要是对基层管理干部的晋升原则、晋升标准、后备管理干部的申报流程、基层管理干部任命流程、免职流程等作出明确规定,以有效识别后备管理干部、强化基层管理干部梯队建设、提升基层团队执行力，适应公司发展及强化内部管理的需要。 本标准２006年6月1日进行了第一次修订,主要是因为公司新文件体系对管理制度提出了新的要求,与2０06年3月１6日发布的版本相比,内容不变,主要是对格式、编号进行更改。 本标准2010年11月4日进行了第二次修订,主要修改内容包括:调整了该标准的适用范围为包括公司中层、基层在内的各层级管理干部的晋升/任命；明确了各级管理干部的任职资格要求;对各级管理干部晋升/任命流程进行细化,以确保公正、公平。 此次修订为第三次修订，主要修改内容包括：明确在公司内部建立起管理干部能上能下的管理机制,以及对于未胜任基层管理干部的管理举措；并根据组织架构变革后新的架构名称，调整相关描述。 本标准由人力资源部负责起草、解释。 本次（修订)起草人:ｉrisfzｈaｎｇ(张芳芳）； 主要审核人:ｘｉｄaｎ（奚丹）；laurawu(吴彦）；hｏsｅa（张辉）； 批准人:ｐonyma（马化腾)；martｉｎlau（刘炽平）；charleｓ(陈一丹）； 本标准首次发布日期：2０06年3月１６日 本标准第一次修订发布日期：20０6年6月１日 本标准第二次修订发布日期:2０10年11月4日 本标准第三次修订发布日期:２０12年６月1５日 本标准发送部门:公司各部门
产品管理规范
产品管理规范 公司内部编号：（GOOD-TMMT-MMUT-UUPTY-UUYY-DTTI-
产品管理规范 公司管理体系文件编号： 产品管理规范版号： 页码：共21页 编制：日期： 审核：日期： 批准：日期： 1 目的 实现以市场为导向的产品规划，有计划有组织地进行研究与产品开发活动。 有效地调动营销部门以及生产部门的创造性思维，把市场与消费者的认识转换在新产品中，确保产品开发和企业产品战略的一致性，快速、合理应对市场需求，规避产品投资风险，并为企业获得最大限度的利润。 2 范围 本制度适用于本公司产品开发、上线、管理全过程，对产品管理的流程做出规定，是公司管理产品规划工作的依据，各相关营销、生产部门必须遵照执行。 3 职责 产品管理是企业在产品生命周期中对产品规划、开发、生产、运营和支持等环节进行管理的业务活动，包括需求管理、市场管理以及开发管理 4 内容 具体如下： 产品战略规划
产品战略包含：1 产品路线 2 产品策略 3 产品计划 产品研发 产品研发包含：1 需求阶段 2 设计阶段 3 开发阶段 4 测试阶段 5 发布阶段（上线） 产品生命周期 产品生命周期包含：周期管理（1 导入期 2 成长期 3 成熟期 4 衰退期）组织、主要人员及职责 1组织结构 2重要角色 重要角色负责人：产品负责人、研发负责人、产品管理负责人、运营负 责人。 重要角色包括：产品经理（需求提出人）、需求管理员、技术人员、运 营人员。 3其中对重要角色职责及相关要求定义如下： 产品管理会 产品管理会由产品中心、运营中心、产品研发中心总监以及参与在产品生命周期过程中的产品规划经理、用户研究人员、产品负责人、开发负责人、运营负责人等共同组成。 主要职责： （1）制定运营计划，确定运营目标； （2）优化产品，制定运营策略； （3）监控产品质量，把控经营结果；
软件版本管理规定
上海精佑通信技术有限公司企业标准 （管理标准） Q/HT 0001–2005 软件版本管理规定 V1.04 2005-04-11 发布 2005-04-11实施
上海精佑通信技术有限公司 目录 1范围 (4) 2术语和定义 (4) 2.1软件 (4) 2.2产品软件 (4) 2.3生产支持软件 (4) 3软件版本命名规则 (5) 3.1软件版本命名组成 (5) 3.2手机软件版本命名 (5) 3.3模块软件版本命名 (5) 3.4手机PC侧软件版本命名 (6) 3.5模块PC侧软件版本命名 (7) 3.6手机生产支持软件版本命名 (7) 3.7模块生产支持软件版本命名 (8) 3.8公用于所有手机和模块的软件版本命名 (9) 3.9无线上网卡相关软件版本命名 (9) 3.10无线上网卡驱动软件版本命名 (10) 3.11正式版本号的升级规则 (10) 3.12版本的电子文件命名规则 (11) 4软件版本发布流程 (11) 5禁止条例 (14) 6管理条例 (14) 7附录 (14)
上海精佑通信技术有限公司 文档版本变更记录： 版本号拟制日期拟制人版本描述存档编号 V1.00 2005-4-11 郝军初始版本 V1.01 2005-4-27 郝军1．版本号前增加“V”,用以明显标识版 本号 2．版本号和时间之间以下划线分隔 3．增加生产支持软件种类 4．增加无线上网卡生产支持软件、管理 器软件和驱动软件命名 5．增加版本发布流程的文字说明 V1.02 2005-7-1 郝军增加手机和模块生产支持软件的类型：射 频补丁软件（RFP） V1.03 2005-7-15 郝军更改版本号升级规则，更改资料外发申请 表 V1.04 2005-7-26 郝军增加机卡合一版本的命名规则 注：1）拟制、审核、会签、批准不走电子流程时，必须用钢笔或签字笔填写，不得用铅笔、圆珠笔填写。
项目立项管理办法
项目立项管理办法 项目信息报备管理工作是市场部管理的一项重要基础性工作。为了加强公司工程项目的管理力度，规范项目立项管理，特制定本办法。 一、当前项目信息报备管理的基本情况 现今区域向市场部所报备的项目信息数量较多，无重点；市场部对区域所报备的信息核实困难，是否准予立项只凭区域单方陈述来考量。批准立项的信息基本上都已经由市场部实施启动流程，但大部分项目都是有头无尾。 二、项目立项管理的范畴 “项目立项管理”是指公司新开发的项目立项。老项目的改建项目和增量项目不对其进行规定。项目立项流程中的项目信息报备是确认销售机会的过程，业务员要对项目报备的数据负责，他们所报备的资料，真实性以及对甲方的掌控是业务员的绩效考核指标之一。目前是由业务人员提交表格形式的报备需求（《项目信息表》），然后由区域总经理签署准予立项意见，由所选择的设计院所长对项目进行判断、分类和立项意见，准予立项的项目发至市场部，由市场部部长确认后批准正式录入项目报备系统，给其项目编号。 三、项目立项的流程 1、业务经理填写《项目信息表》，由区域总经理填写准予立项意见后提交公司设计院三所所长审核，各所所长审核并签署立项意见。2．需要召开项目立项评审会德特殊项目，由设计院各所负责人召集
项目评审小组召开评审会议。 3．市场部汇总评审小组的评审意见，经2/3以上评审成员同意可以正式立项，总经理和董事长拥有否决权。 4、一般项目由设计院将准予立项的项目及相关的所有资料（包含《项目信息表》）一并转给市场部部长。 5．市场部负责进行对项目需求的确认，并根据甲方需求给设计院各所下达项目启动通知。 6．市场部负责对项目的实施过程进行跟踪，并将所有项目完成的最终方案进行存档和记录。
产品经理手册管理知识和规范即产品经理工作流程工具
产品经理手册管理知识和规范即产品经理工作流程 工具 The document was prepared on January 2, 2021
4.5.1 产品扩张：长度、宽度、深度，由产品经理主抓，不断地开发新产品，形成系列产 品，不断地改进产品，与老产品一起形成统一周密的产品布局格式； 4.5.2 市场扩张：全新市场、拓展市场、老市场，由市场经理主抓，不断地开拓新市场， 扩大现有的市场份额，维持老市场的市场份额； 企业扩张2条线的图示： 4.6产品经理的职责： 4.6.1 对产品的市场成功和财务成功负责； 4.6.2 实施产品的结构化开发，保证产品符合市场需求，使产品在质量成本进度功能服务 以及品牌等方面具有相当的市场竟争能力 4.6.3 对产品全流程负责，包括产品需求、开发、推广、生命周期各过程； 4.6.4 对产品包负责，不仅仅是开发的产品，而且包括了质量、文档、成本、营销网络、 运营支撑、定价、知识产权等； 4.6.5 协调与资源部门的接口关系，保证信息交流和信息共享； 4.6.6 进行信息收集和数据分析，为产品策略制定和决策服务； 4.7产品经理的必备素质和能力（按百分比计算）： 4.7.1 优秀的项目管理能力，是一个精明而讲究实际的管理者，占产品经理能力的35%； 4.7.2 扎实的业务管理能力，有全流程的丰富的工作经验，占产品经理能力的20%； 4.7.3 一定的技术和研发能力，有创造性思维，占产品经理能力的15%；
4.7.4 娴熟的沟通协调能力，具有灵活性，同时有组织性和纪律性，占产品经理能力的15%； 4.7.5 具有优秀的魅力和人格指数，使项目组成员快乐而有生气，占产品经理能力的 15%； 4.8产品经理坚守的七项原则： 4.8.1 关注竟争，学会将竟争对手变成合作伙伴 4.8.2 关注手中的资源和筹码 4.8.3 先思考后行动，以销为主到营销并重最终到先营后销 4.8.4 关注团队运作，学会跨部门协调，以非原则问题妥协换取别人对原则问题的支持 4.8.5 不要与规则和约束对抗，主动承担责任，做比自己职责大一丝的事情，但不抢功 4.8.6 关注业务，不在乎组织架构 4.8.7 学会对最终结果负责任，不要纠緾细枝末节 4.9产品经理如何获取有效的支持： 4.9.1 善于调动各种资源做事情，而不是自已亲自去作； 4.9.2 首先，要有意识地关注周边部门，关心和支持他们的工作和活动； 4.9.3 其次，采用例会、周报、日常联系等形式，定期和周边部门进行交流，了解对方的 状况，获取他们的认同； 4.9.4 再次，要学会在矛盾中解决矛盾，善于处理和化解各种纠纷，搞好部门间的团结； 4.10产品经理的任职资格标准： 4.9.1 产品经理应该具备专业的技术等级素质，是直接参与技术研发的人员； 4.9.2 产品经理应该具备丰富的产品全流程管理经验，在任务管理、团队建设、流程执 行、资源调配和利用有丰富的经验，在职位素养和工作态度上是都是优秀的； 4.11产品经理的培养途径和晋升通道：
软件版本管理规范标准[详]
软件版本管理规 第一章目的 本规详细规定软件项目版本管理的对象、存储目录、分支、权限、维护等容，使软件项目版本管理流程化并规化，确保在系统开发和实施过程中项目的完整性和一致性。 1.第二章适用围 所有系统开发及实施项目的软件项目都应进行版本管理。项目中所有正式文档和代码都应纳入配置库（可使用工具建立配置库，本文所述使用的是SVN）进行版本管理。 2.第三章职责 配置库管理员：负责配置库的日常维护和管理；监督开发及测试部门及时提交版本管理对象（即配置项）。 此岗位可由开发或测试人员兼任。 3.第四章容 4.1. 版本管理对象 包括但不限于： 项目总体计划 可行性研究报告 开发计划 需求说明书 需求设计原型 设计说明书 系统开发变更申请单 系统管理手册 用户操作手册 培训计划 培训记录 源程序 支持系统运行的配置文件 存储过程脚本 测试计划 测试用例 测试脚本 测试报告 上线计划
上线申请 版本维护日志 4.2. 配置库的目录结构 每个项目在配置库中应拥有唯一的项目名称。配置库目录结构与项目部的目录结构建议按下列格式创建。 配置库目录结构规划： ┠tags(发布) ┃├v1.0.0_T1_2016909 ┃├v1.0.0.33899_T1_20161009 ┃├v1.0.0_R1_20161109 ┃├v1.1.0_T1_20170109 ┃└v1.1.0_R1_20170209 ┠trunk(主版本) ┃└projectA ┃├src ┃├MY_MOOC ┃├doc ┃├tool ┃├。。。 ┖branches(分支) ├SY_ABC ├TJ_ABC ├WH_MOOC 其中，项目部的目录结构： |–projectA |–src （保存该项目的源程序） |–doc （保存项目相关文档） |–000.项目管理（保存项目过程管理相关文档） |–010.项目计划（保存项目计划相关文档） |–020.项目需求（保存项目需求相关文档） |–030.系统设计（保存项目设计相关文档） |–030.系统测试（保存项目代码测试相关文档） |–040.系统实施（保存项目部署实施相关文档） |–050.系统运维（保存项目运维文档，包括培训、用户手册等） |–060.技术资料（保存项目技术文档，包括第三方技术资料等）
[应用]建设工程项目立项管理办法
[应用]建设工程项目立项管理办法建设工程项目立项管理办法 1范围 本办法规定了建设工程项目管理流程、工程项目申报管理、工程项目年度计划和零计划管理、工程项目审批管理、工程项目内容管理、工程项目时效性管理、工程项目追加管理、工程项目风险管理的基本要求。 本办法适用于公司所属各单位。 2术语 2.1建设工程项目:是指由八钢公司投资的构成固定资产项目或对固定资产功能进行恢复、改造的项目～固定资产项目主要包括:基建、技改、安全、环保、能源、更新改造、零购、零固。非固定资产投资项目主要包括:大中修、检修、抢修、绿化、环境治理。 2.2立项:是指八钢公司为了发展和维持正常的生产经营活动～进行必要的投资～并对投资项目进行可行性和必要性论证～确定投资控制目标并上报宝钢集团或八钢公司得到批准的过程。 3管理职责 3.1设备工程部负责 3.1.1对拟立工程项目可行性和必要性的调研和审查管理～包括咨询设计及咨询设计成果的审查管理。 3.1.2拟立工程项目中有关投资金额的审核管理。 3.2项目单位负责 3.2.1拟立工程项目,包括本单位内部项目,的审查确认和申报管理。 3.2.2配合主管部门对拟立工程项目的调研并提供有关资料的管理。 4管理程序 4.1建设工程项目立项管理流程图见附件一。 4.2工程项目申报管理
4.2.1对八钢公司发展有影响的、建设规模大、涉及面广的拟立建设工程项目～如:基建、技改、技措、环保、能源等固定资产投资项目～各单位可通过八钢办公信息网“OA”或SGMIS系统向设备工程部和八钢公司领导申报。 4.2.2申报单位应详细说明立项理由～尽可能对拟立项目的可行性进行 论述～如拟立项目通过SGMIS系统申报的～须将以上内容挂入文档。 4.2.3对于影响面不大、建设规模小的拟立建设工程项目～如:小型基建、大中修、检修、零购、零固、绿化、环境治理等～各单位应通过SGMIS或WZMIS系统向设备工程部申报。 4.2.4申报单位应以文档形式说明立项理由、实施方案及工程量概预算清单明细～属更新改造、安措、技措等固定资产投资项目～应做投入产出效益分析～以便调查立项。如拟立项目较复杂～需要进行专业设计的～申报单位可通过SGMIS委托设计院做设计方案～详细的设计要求等内容需挂入委托书文档。 4.2.5大中修和检修项目申报费用原则上不含设备和备品配件及主要材料的采购费用。 4.2.6必要时～对于涉及生产、生活和公共设施的突发性抢修项目～各单位应通过电话直接向设备工程部申报～设备工程部同意后协调组织实施～项目单位在一周内～通过SGMIS补办立项手续。 4.3工程项目年度计划和零批计划管理 4.3.1申报单位应根据本单位的发展要求和生产工艺及设备的运行状况～在当年9月前向设备工程部申报次年计划实施的各类工程项目～设备工程部组织审批后～以年度计划的形式下发执行。 4.3.2除年度计划之外～申报单位也可根据当年的实际情况和需求～向设备工程部申报项目～该类临时申报的项目称为零批计划项目。 项目的咨询设计和调研
腾讯公司绩效管理制度
腾讯集团公司绩效管理制度 参考版本
腾讯集团公司绩效管理制度 一、总则 第一条目的 1、本制度是广东腾讯集团有限公司依据自身实际情况订立的管理制度之一。 2、通过确定公司和职位的关键绩效因素，以责任结果为导向，建立员工绩效管理体系，使公司实际经营管理行为与战略目标统一，员工绩效与组织绩效统一，通过员工绩效的持续提高带来公司绩效的不断改进，增强公司的核心竞争力。 3、在绩效与公司战略、目标和价值观之间建立清晰的联系，公平合理地评价员工绩效，为浮动薪酬发放、年度综合评定、薪酬分配、晋升与调配等积累数据，为人事管理与开发提供准确的员工绩效信息。 4、建立规范的绩效沟通与反馈机制，向员工反馈绩效评价和对比信息，为员工改进绩效提供指导和帮助，同时激励员工不断学习，自我管理，创造职业生涯的辉煌 第二条适用范围 本制度适用于广东腾讯集团有限公司。 各子公司、项目公司可参照本制度，自行制（修）订其绩效制度。子公司、项目公司自行制（修）订的绩效制度，报集团人事部、人事总监审核，总裁审批后，遵照执行。 第三条制度内容概要 本制度通过对季度及月度主要工作指标的分解和细化，并尽可能量化各项考核指标，使集团的绩效管理规范、高效。 二、设计指导原则 第四条绩效管理体系的构成 1、绩效管理体系包括关键绩效指标体系KPIs、公司绩效管理、员工绩效管理、年度综合评估等。
2、绩效的有效性侧重于绩效管理各环节流程制度的建设以及各级管理者绩效管理能力的提升。 3、绩效管理必须建立制度化、规范化的双向沟通机制。各部门负责人作为人事管理第一责任人，有帮助下属提升能力与完成管理任务的责任。 4、在绩效管理中，突出绩效考核对公司绩效改进的关键作用。绩效考核以KPI为基础，以业绩衡量标准/工作结果对员工行为结果进行考核；绩效考核以目标为导向，依靠绩效目标的牵引和拉动促使员工实现绩效目标；绩效考核强调主管和员工的共同参与，强调沟通和绩效辅导。 第五条绩效管理体系的原则 1、“三公”原则，即：“公正、公开、公平”，绩效管理各环节目标公正，过程公开，评价公平。 2、团队倾向性原则：团队的领导者与员工是不可分割的利益共同体，团队中所有人员都对部门的KPI和涉及的业务流程负责。领导者要通过绩效辅导帮助下属提高绩效，各个任职者有责任帮助流程相关周边人员提高绩效。 3、客观性原则：主管在评价下属时以绩效为主，以日常管理中的观察、记录为基础，各部门要逐步规范对员工日常工作计划与总结的管理，以此作为考核的主要依据。 4、绩效考核责任结果导向原则：突出业绩，以在正确的期间达成正确绩效结果为依据，同时兼顾能力或者关键行为以及个人态度对工作和团队的价值贡献。 5、动态与发展原则：绩效管理保持动态性和灵活性，绩效标准、实施标准将随着公司和管理对象的成长以及战略的变化而变化。 三、绩效管理执行综述 第六条考核对象 集团总部的考核对象为所有员工，总裁的考核方法由董事会根据经营目标与计划完成情况另行确定； 第七条考核周期 集团总部的考核周期分为三类，即： 1、月度考核：适用于集团总部所有员工，一般于次月10日前完成。
产品运营管理办法(草案)
XX公司 产品运营管理办法（草案） 第一章总则 第一条为了规范本公司项目产品的运营管理，保证投入资金的安全和有效增值，实现投资决策的科学化和经营管理的规范化、制度化，使本公司在竞争激烈的市场经济条件下，稳健发展，赢取良好的社会效益和经济效益，特制定本制度。 第二条本公司及下属各子公司在进行各项目产品的投资运营管理时，均须遵守本制度。 第三条本公司及下属各子公司的重大投资项目由发起单位（公司投资管理部或子公司）按照《XXX投资管理办法（试行）》（以下简称《公司投资管理办法（试行）》）进行实施。 第四条本公司项目投资管理的职能部门为公司投资管理部（以下简称投资部）。 第二章项目与产品的选择及投资分析 第五条各拟投资项目产品的选择应以本公司的战略方针和长远规划为依据，综合考虑业务产业的主导方向及产业间的结构平衡，以实现投资组合的最优化。
第六条各拟投资项目产品的选择均应经过充分调查研究，并提供准确、详细资料及分析，以确保资料内容的可靠性、真实性和有效性。项目材料包括：1、前期策划方案；2、市场调研报告；3、产品定位分析；4、商业计划书；5、产品投资预算。分析内容包括：１、市场状况分析；２、投资回报率；３、投资风险（政治风险、汇率风险、市场风险、经营风险、购买力风险）；４、投资流动性；５、投资占用时间；６、投资管理难度；７、税收优惠条件；８、对实际资产和经营控制的能力；９、投资的预期成本；10、拟投资项目产品的筹资能力；11、投资的外部环境及社会法律约束。 凡合作拟投资项目产品在人事、资金、技术、管理、生产、销售、原料等方面无控制权的，原则上不予考虑。由公司进行的必要股权投资可不在此例。 第七条各拟投资项目产品依所掌握的有关资料并进行初步实地考察和调查研究后，由拟投资项目产品的提出单位（下属子公司或公司投资部）提出项目建议，并编制项目建议书、商业计划书、可行性报告及实施方案报送公司主管领导审核。主管领导对投资单位报送的报告经调研后认为可行的，应尽快给予审批,按《公司投资管理办法（试行）》及集团相关的规定程序提交有关会议审定。对暂时不考虑的项目，最迟五天内给予明确答复，并将有关资料编入储备项目存档。 第三章项目的审批与立项 第八条拟投资项目产品的审批权限严格按照集团有关
项目软件版本号管理规范
项目软件版本号管理规范
历史修改记录 一. 目的
1.1软件版本按照一定的规则保存所有版本，避免发生版本丢失或混淆等现象， 并且可以快速准确的查找到任何版本。 1.2软件版本规范有利于公司各部门之间的对接工作，有利于公司内部资料统一 管理。 1.3本文档是为规范研发部软件版本管理而制定的。 二. 范围 2.1本文档为研发部软件开发版本提供有关版本管理规范的相关内容，包括：2.2版本标识方法及管理 2.3版本升级 2.4文档及源码的备份制度 2.5所有研发部软件工程师成员都必须遵照项目软件管理规范操作，公司内部使 用按照文档及源码存放备份制度。 三. 版本管理 3.1版本号规则 3.1.1每个归档版本都有两个版本号：内部版本号和外部版本号。版本号使用 VP规则，V(Version)是指外部版本号（研发测试版本），P(Patch)是指补丁版本号（可选）。 3.1.2版本号命名：V/B+主版本号+次版本号+修订版本号+日期版本号
3.2版本号修改规则 3.2.1主版本号：当功能模块有较大的变动，比如增加模块或是整体架构发生 变化。此版本号由项目决定是否修改。 3.2.2次版本号：相对于主版本号而言，次版本号的升级对应的只是局部的变 动，但该局部的变动造成程序和以前版本不能兼容，或者对该程序以前的协作关系产生了破坏，或者是功能上有大的改进或增强。此版本号由项目决定是否修改。 3.2.3修订版本号：一般是Bug 的修复或是一些小的变动或是一些功能的扩 充，要经常发布修订版，修复一个严重Bug 即可发布一个修订版。此版本号由项目经理决定是否修改。 3.2.4日期版本号：用于记录修改项目的当前日期，每天对项目的修改都需要 更改日期版本号。此版本号由开发人员决定是否修改。 如： V8.1.0.XXX (上一级版本号有变动时，下级要归零) 3.3版本号修改举例说明 如此时版本号为：V8.1.0.XXX ，此时为内部测试阶段 3.3.1 开发人员修复了测试人员提交的bug并经测试人员测试验证关闭bug 之后，发布到外网时，此时就进入了软件的下一个阶段，版本号可改为： V8.1.1.XXXX ，如当前日期跟上一个版本号的日期不一样，版本号可改为： V8.1.1.XXX。
研发项目立项管理制度(汇编)
研发项目立项管理制度 为使公司研究开发（以下简称研发）项目的管理工作规范化、程序化、充分调度研发人员的积极性，提高研发成果的产出率和成果转化率，特制定管理办法。 一、研发项目的立项： 原则上公司部设立基础研究项目。研发项目的重点放在符合市场需要。能很快转化成产品，或对现有生产工艺或技术、产品质量或产量的提高有重要意义的项目。主要包括根据公司发展资助开发的项目，与公司外相关科研院所合作开发或技术转让的项目，公司享有稀罕的重大技术改造项目。 1. 立项程序： 1.1研发项目由研发中心向公司提出，项目提出要有立项申请书。 1.2公司组织专业技术委员会的专家对项目建议的可行性进行评估、论证，必要时可聘请公司外专家参与项目的论证。 1.3项目经过初步论证、筛选后，重大研发项目主管部门组织进行市场调研，收集信息，并就项目的前瞻性、市场需求等做出可行性分析，写出可行性报告，可行性报告的内容包括： 1）总论； 2）技术可行性分析； 3）项目成熟程度；
4）市场需求情况； 5）投资估算及资金筹措； 6）经济效益和社会效益； 7）考核指标及进度计划； 8）总论。 2．立项批准： 经过可行性论证的项目，列入公司年度研发计划。提高董事会讨论，董事会根据公司的总体发展、效益的情况、技术储备需求等决定是否开展研发项目并对研发经费投入额度进行批准。 二、研发项目的管理： 1．项目管理部门： 研发中心是实施研发项目管理的职能部门，负责编制公司研发项目的年度计划及预算，监督、协调研发项目的进展，以及研发项目的考核验收、成果的申报等。为便于研发项目的管理，充分利用现有的厂房、设备、人员等科研资源，一些研发项目可由相关部门进行主管，或根据需要单独建立项目研究组。 2．研发项目实行项目负责人制
腾讯公司绩效管理制度
一、总则 第一条目的 1、本制度是广东腾讯集团有限公司依据自身实际情况订立的管理制度之一。 2、通过确定公司和职位的关键绩效因素，以责任结果为导向，建立员工绩效管理体系，使公司实际经营管理行为与战略目标统一，员工绩效与组织绩效统一，通过员工绩效的持续提高带来公司绩效的不断改进，增强公司的核心竞争力。 3、在绩效与公司战略、目标和价值观之间建立清晰的联系，公平合理地评价员工绩效，为浮动薪酬发放、年度综合评定、薪酬分配、晋升与调配等积累数据，为人事管理与开发提供准确的员工绩效信息。 4、建立规范的绩效沟通与反馈机制，向员工反馈绩效评价和对比信息，为员工改进绩效提供指导和帮助，同时激励员工不断学习，自我管理，创造职业生涯的辉煌 第二条适用范围 本制度适用于广东腾讯集团有限公司。 各子公司、项目公司可参照本制度，自行制（修）订其绩效制度。子公司、项目公司自行制（修）订的绩效制度，报集团人事部、人事总监审核，总裁审批后，遵照执行。 第三条制度内容概要 本制度通过对季度及月度主要工作指标的分解和细化，并尽可能量化各项考核指标，使集团的绩效管理规范、高效。 二、设计指导原则 第四条绩效管理体系的构成 1、绩效管理体系包括关键绩效指标体系KPIs、公司绩效管理、员工绩效管理、年度综合评估等。 2、绩效的有效性侧重于绩效管理各环节流程制度的建设以及各级管理者绩效管理能力的提升。
3、绩效管理必须建立制度化、规范化的双向沟通机制。各部门负责人作为人事管理第一责任人，有帮助下属提升能力与完成管理任务的责任。 4、在绩效管理中，突出绩效考核对公司绩效改进的关键作用。绩效考核以KPI为基础，以业绩衡量标准/工作结果对员工行为结果进行考核；绩效考核以目标为导向，依靠绩效目标的牵引和拉动促使员工实现绩效目标；绩效考核强调主管和员工的共同参与，强调沟通和绩效辅导。 第五条绩效管理体系的原则 1、“三公”原则，即：“公正、公开、公平”，绩效管理各环节目标公正，过程公开，评价公平。 2、团队倾向性原则：团队的领导者与员工是不可分割的利益共同体，团队中所有人员都对部门的KPI和涉及的业务流程负责。领导者要通过绩效辅导帮助下属提高绩效，各个任职者有责任帮助流程相关周边人员提高绩效。 3、客观性原则：主管在评价下属时以绩效为主，以日常管理中的观察、记录为基础，各部门要逐步规范对员工日常工作计划与总结的管理，以此作为考核的主要依据。 4、绩效考核责任结果导向原则：突出业绩，以在正确的期间达成正确绩效结果为依据，同时兼顾能力或者关键行为以及个人态度对工作和团队的价值贡献。 5、动态与发展原则：绩效管理保持动态性和灵活性，绩效标准、实施标准将随着公司和管理对象的成长以及战略的变化而变化。 三、绩效管理执行综述 第六条考核对象 集团总部的考核对象为所有员工，总裁的考核方法由董事会根据经营目标与计划完成情况另行确定； 第七条考核周期 集团总部的考核周期分为三类，即： 1、月度考核：适用于集团总部所有员工，一般于次月10日前完成。 2、季度考核：适用于集团总部所有员工，于每年1、4、7、10月的15日前完成上季考核工作。 3、年度考核：适用于集团总部所有员工，具体方案另行公布。
公司产品等级管理办法
有限公司管理制度 QGZD/CBZ 产品等级管理办法 （征求意见稿） 2013-02-1发布2013-02-15实施
前言 本制度规定了公司产品等级管理，规范产品等级评定。 本制度根据QGZD/CB 11.03-2006《产品等级管理办法》修改而成。本制度由质量部提出并起草。 本制度由总经理批准。 本制度从颁发之日起实施。 编制：日期： 审核：日期： 批准：日期：
产品等级管理办法 1、目的 为持续改进实物质量，提升全员质量意识，鼓励员工生产优质产品，特制定本办法。 2、管理范围 本办法适应于公司生产车间提供的铸件、模样的质量等级认定及管理。 3、管理职责 3.1 技术部负责制定质量等级标准。 3.2 生产车间按分等办法提出申请。 3.3 质量部组织评定，并根据评定的结果实施奖励或考核。 3.4 综合管理部负责监督评定的过程，并监督奖励、考核的到位情况。 4、管理内容 4.1 申报 4.1.1 各生产车间生产的产品，在车间内部工序全部完成报检时，进行自我评判，认为能够达到一等品、优等品（或一级模样、二级模样）的条件，向所在车间检验站申报，提请等级评定。 4.1.2 铸铁件单件重量1吨（铸钢件100Kg）以上，按单件申报，小于此重量零件按批次申报（每批5件）。 4.1.3 合格件、不合格品不需车间申报，质量部直接或评审后判定。其中不合格品由质量部分为A、B、C级，按《不合格品控制程序》处置。 4.2 评定
4.2.1 检验站受理车间等级评定申报后，站长对其进行初步评定。 4.2.2 检验站站长认可后，签署意见，由质量部组织技术部、生产供销部等部门进行评定，评定结果报质量副总批准。 4.2.3 质量部根据评定结果，每月初将上月优等品、一等品零件的奖励报表和不合格品的考核报表报综合管理部。 4.3 流程 4.4 评判标准 4.4.1 铸件的质量分级的评判参照QJ/CB03.47-2005《产品零件质量分级》。 4.4.2 模样的质量分级的评判参照QJ/CB03.08-2006《铸造用模样技术条件》。 4.4.3 不合格严重程度分级依据QJ/C02.B182-2010《产品质量缺陷严重度分级》。 5、处置 5.1 铸件 5.1.1被最终评定为优等品的零件，按结算价格的150%结算。 5.1.2被最终评定为一等品的零件，按结算价格的120%结算。 5.1.3 A类不合格品按结算价格的80%结算。；B类不合格品按结算价格的90%结算）。 5.2 模样 5.2.1被最终评定为一级的模样，按结算价格的120%结算。 5.2.2被最终评定为二级的模样，按结算价格的110%结算。 5.2.3 A类不合格品按结算价格的80%结算；B类不合格品按结算价格的90%结算。