最近一段时间，我一直在反复思考一个问题：我们的软件研发管理体系应该是怎样的？在不断思考的过程中，逐步有一些粗浅的认识，在此将这些认识记录成文字，并期待能够与更多的伙伴碰撞，进一步完善这种认识，并逐步上升到理论高度，从而有利于指导具体实践。
 
1. 对软件研发管理体系的一些概念认知
 1.1. 研发管理是什么
 关于研发管理，百度百科中这样定义：研发管理就是在研发体系结构设计和各种管理理论基础之上，借助信息平台对研发过程中进行的团队建设、流程设计、绩效管理、风险管理、成本管理、项目管理和知识管理等的一系列协调活动。
 
也就是说，研发管理首要一点就是要根据公司业务的发展确定相应的研发体系结构，之后按照这种研发体系结构组件一支高水平的研发团队，设计高效合理的研发流程，借助合适的研发信息平台支持研发团队高效工作，以绩效管理调动研发团队的积极性，以风险管理控制研发风险，以成本管理使研发在成本预算范围内完成研发工作，以项目管理确保研发项目的顺利进行，而知识管理使得研发团队的智慧联网和知识沉淀。
 
纵观各类软件企业，由于自身所处环境不同，因此其软件研发管理模式也不尽相同，这其中有基于CMMI能力成熟度模型指导下构建的研发管理体系，也有基于IPD集成产品研发框架指导下构建的研发管理体系，当然也有一些目前不少小企业、互联网企业推崇的敏捷研发管理体系。不同的研发管理体系其实都会有相应的交叉部分，最终追求的目标都是能否适合企业的发展，给企业带来市场和财务上的成功。
 
1.2. 基于CMMI的研发管理
 CMMI能力成熟度模型相信大家都不陌生，从一级到五级，覆盖了22个过程域，一般能达到CMMI3级别的基本上可以理解为各类流程、过程规则等已经达到一个较好的水平。当然，这里主要是指企业能够确实按照CMMI模型去实践，这种实践其实更适合于以瀑布式开发为主导的项目开发及产品研发模式。然则，实际上，大部分企业尤其是国内企业并不会严格按照这个模型去做，因为如果每一个过程域都不打折扣地执行地话，需要非常标准化的流程和强大的资源支撑，在这个讲究快速响应变化的时代其实是很难做到的，通常这个时候都会进行相应的裁剪，甚至会结合敏捷迭代等方面的模式，从而逐步形成自己公司的研发管理体系。
 
1.3. 基于敏捷模式的研发管理
 在这个快鱼吃慢鱼的互联网时代，对用户和环境越来越要求要快速响应。敏捷研发是当前不少互联网企业、中小企业推行的研发管理体系，主要理念就是敏捷迭代、小步快跑，快速改进、拥抱变化，用户参与等等。目前这方面也有不少公司除了有相应的敏捷研发体系之外，还有相应的成熟工具做支撑。例如，腾讯的TAPD敏捷研发平台就是其中的代表。通过对用户故事的层级拆分，实现对需求的有效管控和分解，从而确保持续迭代上线。
 
敏捷研发管理在当前我们以业务为导向、项目为主的情况下，要全面实施尚有较大困难，当然并非是完全不能做，主要是当前所处的环境、所面向的业务、项目开发模式、人员结构等可能较难满足敏捷模式推行的需要。
 
1.4. 基于IPD的研发管理
 之前有简单了解过IPD产品研发管理体系，我认为其中的核心就是“四四四”模型，四四四代表了四大团队、四个流程、四个支撑体系。
 
四大团队建设包括建立集成产品管理团队（IPMT）、建立产品市场团队（PMT）、建立产品开发团队（PDT）、建立技术开发团队（TDT）。
 
四大流程建设包括建立产品战略流程、建立需求管理流程、建立产品开发流程、建立技术开发及平台开发流程。
 
四个支撑体系建设包括建立项目管理体系、建立质量管理体系、建立绩效管理体系、建立成本管理体系。
 
个人感觉，基于IPD的产品研发管理从整体上来看是一个相对重量级的体系，要落地执行往往需要从整个公司层面去整体考虑和推动。
 
IPD的理念和敏捷开发理念在本质上是基本一致的，比如以市场需求（用户价值）为核心，将产品开发看成一项投资（商业价值），通过CBB—公共基础模块和跨部门的团队准确、快速、低成本、高质量地推出产品（各评审点的多团队参与和决策、通过各种技术改进提升产品开发效率和降低浪费、持续交付）。
 
从理论上来讲，IPD研发管理体系是一个较全面的体系，在当前我们的现状下也可能容易出现水土不服的情形，当然其中有一些好的做法是值得借鉴的。
 
2. 什么样的软件研发管理体系适合我们的发展
 从项目及产品的研发角度来看，发展到一定阶段的传统IT企业在研发管理上多数都是基于瀑布型的传统研发模式，由于项目的特点及人员的组织结构等因素，项目开发及产品研发的周期往往较长，较难适应市场快速变化的需要，也较难做到对客户的需求进行快速响应。而大部分的互联网公司及一些大厂，推行了敏捷研发模式，或者是在标准化项目管理和敏捷迭代两者融合上进行了相应的实践。
 
那么，针对当前我们所面临的一系列问题，究竟什么样的软件研发管理体系在未来一定时期内适合我们的发展？我们需要重构我们的软件研发管理体系吗？我们有必要重构我们的软件研发管理体系吗？带着这些问题，我想主要思考几个方面的问题。
 
2.1. 能否快速适应未来业务的发展变化
 技术是为业务发展而服务的，因此在考虑软件研发管理体系构建时，第一个要考虑的问题就是我们的软件研发管理体系能否快速适应公司未来业务的发展变化。特别是在传统IT业务与互联网新兴业务加速融合的大环境下，信息化能力是越来越多客户的第一选择，因此在业务的快速发展方面需要更加强有力的技术支撑，而这个支撑的背后就是需要我们能够有一套能够快速响应变化、敏捷高效的研发体系，特别是能够有一定的前瞻性并支撑到老业务的快速转型和新业务的拓展。
 
2.2. 在业务出现较大波动时能否弹性伸缩
 另外一个问题就是，业务在发展过程中，受大环境等诸多因素的影响，定然很难一直都是呈现直线上升的发展趋势，这当中必然会有波峰波谷，只不过这个波峰波谷是大是小的问题。而我们面临的问题则是，当出现较大的波峰波谷的时候，我们的研发管理体系应该如何适应？特别是在软件业务处于相对低谷时，既能够继续保持对技术研发的持续投入，又能够在应用开发等方面有一定的可伸缩性，从而正确地处理好软件生产效益问题。这里面可能会涉及到中高层次软件人才的相对稳定和低层次软件人才的灵活流动等问题。特别是在我们业务多样化的背景下，不同业务单元的发展会有不同的发展路径，对软件研发能力的诉求也有所不同，那么这里面首先涉及到的一点就是如何有效平衡基础研发能力和行业研发能力。
 
对于基础研发能力，个人认为应该是一个软件公司最内在的核心技术能力，往往很多时候基础研发工作很难像做行业应用开发那样立竿见影，但这项工作干得不好往往又容易成为行业研发能力的掣肘，这也是我们当前在人工智能、区块链等新技术潮流背景下总感觉难以发力的原因之一。
 
对于行业研发能力，个人认为应该要从两个方面去考虑，一个是产品化的能力，其二才是应用开发能力。应用开发能力很好理解，就是目前我们这么多年以来一直在做的各种类型的项目开发，而这里面大部分的项目开发其实都是偏应用层面的开发。而产品化的能力则是最近一两年以来我们重新关注的一个内容，不过这条路上我们尚开始起步，还有很长的路要走，也还有不少坑要踩。个人认为，产品化的能力能否真正发展起来，其中很重要的一点就是要考虑如何与基础研发能力做充分融合。产品化不等同于应用开发，应用开发更多是定制化的开发，是客户导向的软件开发，通常面向的是一个或少数几个的客户；而产品化则是要综合行业、市场、客户群体、新技术等多方面因素的研发，是市场导向的软件开发，面向的是一个或多个的客户群体，甚至面向的是一个市场或跨界市场。
 
2.3. 新技术研发及成果转化能否跟上业务变化
 最近几年，新技术层出不穷，在软件架构的发展方面也非常迅猛，历经了单体架构、垂直架构、SOA架构、微服务架构的演化。从我们公司目前的技术研发实际来看，我们有少量的项目/系统采用了SOA架构，然则大部分的项目/系统仍然采用的是单体架构和垂直架构。单从这一点来看，我们在技术领域的持续跟进及成果转化方面已然有落后趋势，这方面需要我们奋起直追才行。当然，出现如今这种局面固然由众多因素催生而成。比如，已有开发框架前端兼容性的问题最近一两年以来常常被诟病，诚然有它内在的好处，然则最近一两年以来，用户对系统的用户体验要求更高了，不再是单纯地满足于功能实现层面，而是开始追求良好的人机交互和界面展现。因此，这方面势必对新技术的要求更加迫切。最近几年，当不少团队都在往前后端分离走的时候，我们至今的绝大部分软件项目开发仍然停留在前后端分离之前，对不少用户界面展现要求高的软件项目而言，难以快速有效响应变化，同时对一些相对比较成熟的软件产品而言也难以做到接口自动化。
 
因此，能否在新技术的研发上抓住正确的方向并加快研发成果转化，为业务的快速变化提供强有力的技术支撑，是一个摆在我们面前急需解决的课题。从当今新技术的发展趋势来看，研发架构方面，我们虽说不能完全抛弃传统的单体/垂直架构，但我们必须要往微服务架构方向迈进，除了与最新技术接轨之外，更重要的是如何进行业务解耦，沉淀行业积累，并反向推动人员组织层次的变革，提升软件生产效率，提高软件质量。
 
除此之外，对于人工智能、区块链等新领域，也是需要综合业务应用场景打造适合我们自身发展的技术+业务融合之路。
 
2.4. 在标准化和敏捷迭代之间如何平衡
 标准化的软件研发道路固然有不少好处，有严谨的流程、规范的体系、固定的套路，当然更多的则是瀑布开发模式，虽然最近几年也陆续有迭代开发的模式，但更多的是被动式响应，而且这种迭代开发模式基本上是大阶段的划分，在每一个大阶段里面依旧是一个典型的瀑布开发模式，即历经需求分析、交互原型设计、UI设计、Web前端开发、程序开发、系统测试、部署实施等步骤，横跨周期往往较长，一旦发生需求变更，变动的代价过高。
 
敏捷开发强调以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行使用的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。
 
那么，问题来了，既然标准化项目管理模式下存在太多流水线作业及效率低下等问题，那么我们能够直接转向敏捷迭代模式呢？世界上万事万物都是对立统一的，个人认为不论是标准化项目管理模式还是敏捷迭代项目管理模式都有其擅长的一面。一方面，在现有的以项目为主导的软件开发体系中，标准化模式是我们一直以来的主要做法，也积累了不少经验做法；另一方面，采用敏捷迭代模式对于产品复杂不断有新需求加入等场景是比较适合的。所以这里面更多的是考虑如何更好地平衡标准化项目管理和敏捷迭代两者之间的关系。基本的思路就是结合标准化项目管理和敏捷迭代的优缺点进行适度裁剪，既能提高软件质量和软件开发效率，也能够保留一定的规范性和软件过程文档。例如，针对项目管理，通常是五个过程组：启动、规划、执行、监控、收尾，那么我们其实可以结合实际将规划提前，将监控贯穿于执行过程，这样就势必要求在启动时也要做好项目计划相关工作，在执行过程中抓住关注点并定期监控其执行情况，在收尾阶段做好项目回顾总结。
 
不论采用何种模式，我们的根本目标就是达到更低的成本实现更快速、更可靠的交付。近年来比较火热的是DevOps。DevOps（Development和Operations的组合词）是一组过程、方法与系统的统称，用于促进开发（应用程序/软件工程）、技术运营和质量保障（QA）部门之间的沟通、协作与整合。它是一种重视“软件开发人员（Dev）”和“IT运维技术人员（Ops）”之间沟通合作的文化、运动或惯例。透过自动化“软件交付”和“架构变更”的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。
 
因此，我们的软件研发管理体系中是否应该引入DevOps，进而改善公司组织文化、提高员工的参与感、提高交付效率，我想这也是需要重点关注和考虑的。
 
2.5. 组织过程资产能否持续积累并盘活
 组织过程资产指一个学习型组织在项目操作过程中所积累的无形资产。组织过程资产的累积程度是衡量一个项目组织管理体系成熟度的重要指标，项目组织在实践中形成自己独特的过程资产，构成组织的核心竞争力。
 
组织过程资产主要包括但不限于以下内容：项目组织在项目管理过程中指定的各种规章制度、指导方针、规范标准、操作程序、工作流程、行为准则和工具方法等。项目组织在项目操作过程中所获得的经验和教训，其中既包括已经形成文字的档案，也包括留在团队成员脑子中没有形成文字的思想。项目组织在项目管理过程中形成的所有文档，包括知识资料库、文档模板、标准化的表格、风险清单等。 项目组织在以往的项目操作过程中留下的历史信息。
 
经过多年的软件开发，我们做了大大小小形形色色的软件项目和产品，也逐渐积累了一些行业化的软件项目，但总的来看，能够形成规模化效应的软件产品尚较为匮乏，更多的是以定制化开发为主的软件系统，当然也积累了不少项目经验。在这过程中，也积累了不少标准、规范、流程、模板等各类软件过程资源。然而，从目前掌握的情况来看，这些资源是分散的，不够体系化的，还谈不上真正意义上的资产，至少在价值的发挥上还不充分。况且，软件行业这几年的人才流动率明显加快，人员更替的速度以及未能体系化的过程资产积累，加剧了组织过程资产的盘活难度。
 
那么，构建一个相对健全的、动态的、能够适应未来业务发展的组织过程资产库就显得尤为重要。这既是软件研发管理体系的一个重要组成部分，也是公司层面应该给予充分重视的。在组织过程资产库构建的过程中，其中很重要的一点就是如何让研发知识与经验成为公司的宝贵财产，这里就要充分考虑研发知识管理。知识管理把“隐形知识显性化”，是一项涉及知识库、过程资产、环境和交流等元素的整合过程，所管理的知识将作为一个团组织中过程资产的重要组成部分。对于软件研发而言，我们需要考虑怎么把业务人员和技术人员脑中的蓝图转化为显性知识。
 
3. 构建我们的软件研发管理体系应包含哪些内容
 软件研发管理体系的建设离不开几个关键要素：人员、技术、过程、资源，并在此基础上配以相应的管理手段。进一步来看，要构建适合我们自身发展的软件研发管理体系，需要着重考虑几个能力体系的建设，即：人员组织能力、技术研发能力、过程管理能力和资源建设能力。
 
前面也有针对“什么样的软件研发管理体系适合我们的发展”进行了一些相对粗浅的探讨，那么在考虑如何构建适合我们发展的软件研发管理体系之前，我想这里首先要明确一下我们期待构建的软件研发管理体系。我们公司的业务涉及众多行业客户，一直以来主要以定制化项目开发为主，同时也涉及运维服务，而在产品研发等方面则处于起步阶段，且在一段时期内项目、产品、服务将会长期并存，因此，个人认为适合我们的软件研发管理体系应该至少经历三个阶段，包括初期的标准化软件研发管理体系、中期的标准化与敏捷相结合的软件研发管理体系和后期的敏捷化软件研发管理体系。
 
基于上述这样的考虑，正常来讲我们当前应该在标准化的软件研发管理体系中要做进一步强化，而考虑到市场的快速变化、技术的日益进步，个人认为我们当前就需要开始考虑标准化的与敏捷相结合的软件研发管理体系。为什么还需要考虑标准化的软件研发管理体系呢？主要是传统的定制化的软件项目开发依旧占据主体，且目前在这方面仍然有非常大的改进提升空间，然而标准化的模式常常是过于强调标准、规范、流程，开发模式过于线性化，因此需要引入敏捷开发模式。所以，我们又需要考虑敏捷的软件研发管理体系，这主要是为了更好地适应市场变化、更快速地响应客户需求，更好地提升软件开发生产效率。
 
3.1. 人员组织能力
 关于人员组织能力，个人认为有两个关注点：一是团队的发展，二是个体的发展。这两者是相辅相成、互相融合促进的。综合来看，人员组织能力的建设主要包括设立与公司战略、业务、技术发展相适应的组织架构，并配以构建相对完整可行的岗位体系和对应的人员考核体系，同时在团队建设等方面持续改进与提升。
 
关于组织架构，当前的组织架构虽然解决了一些曾经的主要矛盾，但依然存在不少问题，突出的一点就是核心薄弱，即核心技术能力不强，仍旧需要投入大量的人力到各行业的应用开发中，当然这与我们一直以来承接定制化的软件项目开发不无关系。这是当前乃至未来一定时期需要解决的。
 
同时，最近几年来的组织架构主要是以职能型组织架构为主，产品线为主导的研发模式尚不成熟，针对项目及产品的团队构建主要是以项目经理来驱动，在项目团队的组成方面固然与互联网的项目团队截然不同。在团队建设方面，需要进一步打通团队之间的壁垒，强化团队的整体协同作战能力。
 
在岗位体系方面，特别是对人员的绩效评价方面，需要在已有的岗位体系基础上进一步考虑如何更好地执行落地，确保个人绩效目标与团队绩效目标的一致性和顺利达成。
 
3.2. 技术研发能力
 结合我们的实际，我认为在技术研发能力方面要考虑四个方面：一是技术预研，二是技术开发，三是产品开发，四是定制开发。
 
关于技术预研，通俗来讲就是：预研=预先+研究。这种预先研究通常来源于几个方面，例如来自外部竞争对手的迫使、来自客户或市场的需求、来自公司高层的决策等。为什么要做技术预研呢？这是扫清前行障碍的过程，这为后续展开总体设计、详细设计指明了方向，也是持续积累公司技术能力、保持与新技术同步而不至于脱离轨道的方式之一。
 
关于技术开发，其实这里主要指与基础平台、公共组件、关键技术等方面的技术研发。另外一个方面来理解，技术开发是技术预研的延续，是在技术预研成果经论证的基础上开展的一系列能促进公司发展、业务发展、技术发展而开展的技术研发工作。
 
软件产品是指向用户提供的计算机软件、信息系统、套装软件或在提供计算机信息系统集成、应用服务等技术服务时提供的软件，是通用的产品应用于某一行业领域而不是像软件项目一样为某一需求或者单位定制开发。
 
软件项目主要为特定企业开发或者部署实施一套专用的系统，在进入项目开发之前需要与用户进行具体的交流和讨论，了解用户心中对于软件预期的样子，后经过招投标，签订合同，实施交付。
 
关于产品开发，这方面我们尚处于起步阶段，尚缺乏一套完整可行的产品研发流程及最佳实践，需要摸着石头过河，也需要长期坚持不懈地努力。
 
关于定制开发，当前主要是基于客户需求的软件项目定制开发，后续还会包括基于产品衍生出来的定制化开发。前面的这种方式是我们当前最熟悉的模式，主要面临的困境是两个：一是如何实现快速交付，二是如何实现成本可控，从而提升软件项目的利润。
 
做项目侧重于在最短的时间内，按照客户的需求开发出操作敏捷，用户体验良好的软件。而做产品则侧重于市场驱动，时间相对充足，但要开发出有竞争力，有自身特色，且受客户欢迎的产品，要求功能响应速度快，操作简单，界面美观。
 
技术预研+技术开发是强化内核的内在需要，定制开发是现阶段的生存根本，产品开发则是为未来发展铺路。
 
3.3. 过程管理能力
 过程管理能力主要包括项目管理、开发管理、质量管理和配置管理等几个方面，需要一套完整合理的流程贯穿整个过程。
 
在项目管理方面，我们需要梳理当前项目管理体系的标准、规范、流程及相关实践，建立以过程为核心、以度量为基础、以人为本的可裁剪、受认可、能执行的信息集成项目管理体系，进一步规范公司的项目管理，提升项目群管理能力。结合项目管理的五大过程组（启动、计划、执行、监控、收尾），并结合敏捷迭代的思想，形成标准化项目管理与敏捷迭代相结合的具有实际指导意义的方法体系，同时将这套方法体系以指南性文件、规范性文件等形式传导到相关人员，确保可落地执行。此外，为加强过程管控、资源共享、工作协同，组建PMO团队，实现对项目群及重大项目的统一管控与决策支持。
 
在开发管理方面，一是要落实统一的软件开发规范，包括架构规范、设计规范、UI规范、编码规范、测试规范等。强化设计及开发关键环节的评审，包括对需求、概要设计、详细设计、UI设计等的设计方面的评审，对测试用例等方面的评审，对代码的评审检查（例如利用SonarQube进行代码的自动检查等）及发布评审等。同时通过试点+逐步铺开的方式着力推进CI/CD的落地。
 
在质量管理方面，进一步强化项目质量审计，逐步改进软件过程生产效能。而在配置方面，则加强对配置项的识别、配置空间的管理、变更控制等，规范软件开发过程，确保构建正确的系统。正确应用软件配置管理是开发高质量软件所不可缺少的。软件配置管理的过程是软件开发过程中质量管理的精髓。
 
综合来讲，在过程管理方面就是要形成一套适用的软件研发管理流程，并配以相应的节点管控，让不同开发角色之间即各司其职又相互融合促进，从而促进软件开发自组织能力的逐步提升，充分调动软件开发人员的主动性和积极性。
 
3.4. 资源建设能力
 简单来讲，资源建设是软件研发管理体系中的支撑体系。资源建设主要包括了一系列的制度规范、工具、模板、过程资料及交付物（例如项目文档、源代码等），以及相应的经验、知识沉淀等。一是要适时梳理相应的制度、规程、标准、规范、文档模板等，形成标准化资源库；二是要对不同行业历年来的项目资料及源代码分门别类做好规划和归档管理，形成静态库（归档库）和活跃库，同时做好数据安全管理；三是要对软件研发人员及工作中的一些隐性知识转化为显性知识，并逐步构建软件研发的知识图谱，促进知识经验的持续积累与转化，并通过链条式、网状式等方式实现知识分享与传播，形成经验知识库。

一、什么是OKR体系？
 
OKR体系的全称是Objectives & Key Results，即目标与关键成果。所谓OKR，O = Objective 可以理解为企业目标，KR ＝Key Results 可以理解为关键结果。浓缩在一起就是“为确保达成企业目标的关键结果分解与实施”。
 
 
OKR是企业进行目标管理的一个简单有效的系统，能够将目标管理自上而下贯穿到基层。对一个项目来说，设定目标是非常重要的，因为这决定了如何去做，以及能做到何种程度。
 
OKR 首先是沟通工具：团队中的每个人都要写 OKR，所有这些OKR都会放在一个文档里。任何员工都可以看到每个人在这个季度最重要的目标是什么，团队这个季度的目标是什么。 
OKR是努力的方向和目标：OKR代表你到底要去哪里，而不是你要去的地方具体在哪里。 
OKR必须可量化（时间&数量）。比如健身时设定锻炼目标，如果只是定义成「我们要努力提高身体素质」，肯定不是一个好的 OKR，因为无法衡量，好的OKR是「今年的跑步时间较去年增加一倍」。 
目标必须一致：制定者和执行者目标一致、团队和个人的目标一致。首先，制定公司的OKR；其次，每个团队定自己的 OKR；第三，每个工程师或设计师写各自的OKR。这三步各自独立完成，然后对照协调这三者的OKR。OKR跟个人绩效没有关系，因为OKR 系统的结果和每个人并不直接挂钩。 
目标要是有野心的，有一些挑战的，有些让你不舒服的。一般来说，“最佳”的 OKR 分数在0.6-0.7之间，如果某人只拿到1分，那么他 OKR 订的目标显然是野心不够的。但是低分数的人也不应该受到指责，而是应通过看他工作上的数据，帮助他改进下一季度的 OKR 目标。 
通过月度会议Review ，时时跟进OKR： 在月度会议上需要确定如何去达到目标，是一个帮助达到目标的过程。 
通过季度会议Review ，及时调整OKR：互联网的变化非常快，每季度有一个OKR 的 review，调整的原则是目标（Objectives）不变，只允许调整关键成果（Key Results）。 
 
为了更好的理解如何制定OKR体系，我们看个例子：
 
 
 
目标（Objectives）：为OKRs组织测评系统建立一个可实施的模型
 
 
关键成果（Key Results）：
 
 
按时完成介绍OKR的presentation 
完成一个三个月的OKRs的案例 
让管理部门同意并制定一个3个月的测试机制 
 
 
二、OKR与KPI的区别
 
OKR表示Objectives and Key Results，即目标和关键成果，是一套定义和跟踪目标及其完成情况的管理工具和方法。KPI表示Key Performance Indicators，即关键绩效指标，是一种可量化的、被事先认可的、用来反映组织目标实现程度的重要指标体系，也是企业绩效管理过程中一个实用而且有效的工具，更是绩效管理实现过程中的一个重要内容。KPI的本质是一种管理工具，它主要是从结果上来考察绩效，不关注过程，一切用指标来说话。
 
OKR 主要的目的是为了更有效率的完成目标任务，并且依据项目进展来考核的一种方法。它的主要流程是这样的一个循环。
 
明确项目目标。 
对关键性结果进行可量化的定义，并且明确达成目标的/未完成目标的措施。 
共同努力达成目标。 
根据项目进展进行评估。 
 
而对于国内来说，更熟悉的其实是 KPI (Key Performance Indicator)，而 KPI 的流程则是这样的。
 
进行人事组织。 
确定影响结果的关键性因素，并且确立 KPI 。 
对关键绩效指标进行检测，并且进行实时监督。 
对有错误行为的人进行监督，更甚者开除。 
 
通过两者的对比我们能够看到，OKR 主要强调的是对于项目的推进，而 KPI 主要强调的是对人事的高效组织，前者要求的是如何更有效率的完成一个有野心的项目，而后者则强调的是如何保质保量的完成预定目标。OKR相对于KPI而言，不是一个考核工具，而是一个更具有指导性的工具，说白了，是一个PLAN-DO-REVIEW的cycle。他存在的主要目的不是考核某个团队或者员工，而是时刻提醒每一个人当前的任务是什么。每个人都有自己的OKR，每个团队有团队的OKR，无论级别高低，团队大小，都需要制订和服从OKR。这个OKR在每个季度结束之后要做一个评分。评分高低并不直接决定一个员工的晋升和待遇，而更多的是提醒员工，这个季度工作完成的怎么样，未完成的工作为什么没有完成，下一阶段的工作重心是什么。
 
KPI 理论上是必须严格按照 SMART 标准制订的，是否达到甚至达到比例多少（小于 100% 还是大于 100%）都是要能测量的。但这就导致一个问题，有些事情值得去做，但在做出来一部分之前无法测量因此无法制订目标，这时候就陷入了先有鸡还是先有蛋的问题了。KPI 还有一个更严重的问题，那就是为了完成可测量的目标，有可能实际执行手段与该目标要达到的愿景正好相反。举个例子来说，我们希望用户更喜欢使用我们的产品，因为喜欢无法测量，所以把 PV 写进了 KPI 里面。但在实际执行过程中，我们可以把用户原本在一个页面上就能完成的事情分到几个页面上来完成，结果 PV 达到了 KPI 指定的目标，但用户其实更讨厌我们的产品了。大家如此应付 KPI 是因为 KPI 跟绩效考核挂钩。如果 KPI 达不到那就会影响奖金，所以就算违背公司利益，违背用户利益，也要把自己的 KPI 完成了，把部门的 KPI 完成了。
 
KPI存在的缺陷：
 
没有人对最终结果负责，每个人只对自己的过程负责。 
人的主观能动性被压抑。 
结果高度依赖机器和管理者的指令。 
 
OKR 解决了 KPI 的这些缺陷。首先它和绩效考核分离，把绩效考核交给 peer review（相当于中国公司的 360 度评价）来做。然后它强调 Key Result 必须服从 Objective，所以如果你在 Objective 上写了要让用户喜欢我们的产品，但你实际执行 Key Result 的手段违反了这一点的话，谁都能看得出来。既然 Key Result 只是用来服务于 Objective 的，那就没必要像 KPI 那样一早制订好然后强制执行了。你可以在做的过程中随意更改 Key Result，只要它们还是服务于原本的 Objective 就行。
 
OKR 最重要的作用就是帮助你「stay focus」，「stay focus」又能帮助你「make impact」。总的来说，绩效考核的核心都是 impact（Google的impact文化。衡量的是员工为Google做出了多大的impact，而不是员工是不是很努力地干了很多活，也不是员工是不是听老板的话完成了老板布置的任务。），而测量的手段都是 peer review。其实在没有 OKR 的情况下，这套绩效考核机制还是完全能操作的，但参与者就可以因为缺乏引导而没办法实现他们能实现的最大 impact。OKR 就是让你在每个季度开始之前想一想，有哪些事情从 impact 的角度来说是值得做的，有哪些事情是你想做的，然后取个交集，再列举若干有一定概率（通常建议是 2/3）能达成目标的手段。除了 make impact，OKR 还能用来引导你 stay focus 在别的事情上。
 
如果要说 OKR 和 KPI 的区别，区别就在于 KPI 只能让驴使劲走，而 OKR 用于保证驴头朝正确的方向。有些驴拼命想往前走，不希望落后于别人，这时候 OKR 用于帮助驴少走曲线。有些驴本来就不想走，这时候就需要 KPI 充当鞭子了。一家公司能不能用 OKR，首先要看有没有正确的驴。
 
 
OKR考核：“我要做的事”，KPI考核：“要我做的事”，理解不同，但二者都强调有目标,同时也需要有执行力。OKR的思路是先制定目标，然后明确目标的结果，再对结果进行量化，最后考核完成情况。KPI 的思路也是先确定组织目标，然后对组织目标进行分解直到个人目标，然后对个人目标进行量化。
 
 
OKR 和 KPI 两者谁都无法真正的替代对方，因此谁取代谁并不重要，找到适合的绩效评估方法，这才是重要的事情。比如说对于销售来讲，它更在意的是如何保持持续稳定的收入，因此就需要的是更硬性的标准来约束销售人员能够完成任务，所以其需要的是 KPI 而不是 OKR 。而对于营销团队来讲，他们最需要的是如何将影响最大化，而过于刻板的 KPI 就限制了营销团队的灵活性，因此其更适合的是 OKR ，而不是 KPI 。
 
三、如何实施OKR？
 
 
基本的要求：
 
最多5个O，每个O最多4个KRs。 
百分之六十的O最初来源于底层。下面的人的声音应该被听到，这样大家工作会更有动力。 
所有人都必须协同，不能出现任何命令形式。 
一页写完最好，两页是最大限值了。 
OKRs并不是绩效评估的工具。对个人来说，它起到很好的回顾作用。能快速明了地让自己看到我做了什么，成绩是怎么样。 
分数0.6-0.7是不错的表现，因此0.6-0.7将是你的目标。如果分数低于0.4，你就该思考，那个项目究竟是不是应该继续进行下去。要注意，0.4以下并不意味着失败，而是明确什么东西不重要及发现问题的方式。分数永远不是最重要的，除了是作为一个直接的引导作用。OKR不是绩效考核的武器！每个季度末对关键结果进行考核，完成60-70%就算好，如果100%完成，说明你的目标设定过于简单。 
只有在KRs仍然很重要的情况下，才持续为它而努力。 
有个联合会组织来保证每个人都向同样的目标行进。（事实上OKRs实施过程中，你能够获得大家的认可和帮助，这是很有趣的事情） 
 
基本的流程：
 
1、设定目标。（从战略开始确定年度目标，季度目标）
 
目标务必是具体的、可衡量的，例如不能说笼统地说“我想让我的网站更好”，而是要提出诸如“让网站速度加快30%”或者“融入度提升15%”之类的具体目标；不能说“使gmail达到成功”而是“在9月上线gmail并在11月有100万用户”。
 
目标要是有野心的，有一些挑战的，有些让你不舒服的。一般来说，1为总分的评分，达到0.6-0.7是较好的了，这样你才会不断为你的目标而奋斗，而不会出现期限不到就完成目标的情况。员工通常每季度会制定4到6个目标，目标太多也会令人焦头烂额。
 
目标必须达成共识，目标必须是在管理者与员工直接充分沟通后的共识。没有达成共识的目标不能算作目标，目标的设定以达成共识为终点。
 
实施的关键流程：从上至下，目标的设立顺序应该是公司到部门到组到个人。个人自己想做什么，和管理者想他做什么一般来说是不会完全相同的。那他可以通过先查阅上层的目标，在自己想做的事情范围内找到能对公司目标有利的部分，将他拿出来和自己的管理者进行讨论，做权衡取舍。某种情况下，很有可能这个自己想做的东西，会变成公司今后改变的发展方向。
 
2、明确每个目标的KRs（从季度目标到“关键结果”的分解）
 
所谓的KR就是为了完成这个目标我们必须做什么？ KR是必须具备以下特点的行动：
 
必须是能直接实现目标的； 
必须具有进取心、敢创新的可以不是常规的； 
必须是以产出或者结果为基础的、可衡量的，设定评分标准； 
不能太多，一般每个目标的KR不超过4个； 
必须是和时间相联系的。 
 
目标既要有年度KRs，也有季度KRs：年度KRs统领全年，但并非固定不变，而是可以及时调整，调整要经过批准；季度KRs则是一旦确定就不能改变的。在这里要切记可以调整的是KRs，而不是目标。目标不能调整，措施和方法（KRs）可以不断完善。同样KRs的设定也必须是管理者与员工直接充分沟通后的共识。
 
3、推进执行（从关键结果到“行动计划“）
 
当有了关键结果（期望的结果）后，就要围绕这个具体的目标来分解任务了。所以，每项关键结果就会派生出一系列的任务，交给不同的同事负责。关键结果负责人就成了名符其实的项目经理，来组织协调大伙。因此，关键结果的项目经理应当是团队非常重要的成员，他们能够调度和影响企业资源，如果他还不具备这个能力，就把这个权力给他。至少，项目经理和企业决策者之间应当保持绝对通畅的沟通。
 
3、定期回顾。
 
每个季度做回顾。到了季度末，员工需要给自己的KRs的完成情况和完成质量打分——这个打分过程只需花费几分钟时间，分数的范围在0到1分之间，而最理想的得分是在0.6到0.7之间。如果达到1分，说明目标定得太低；如果低于0.4分，则说明可能存在问题。
 
每个员工在每个季度初需要确定自己本季度的 OKR，在一个季度结束后需要根据自己这个季度的工作完成情况给 OKR 打分。每半年公司会进行一次 Performance Review，主要是 review 员工过去半年的绩效，并根据 Performance Review 的结果变更 Job Ladder（业务职级）和薪酬。值得一提的是，所有的个人Performance Review 的成就内容及级别都是全公司共享公开的。这个对于很多公司来说是不可想象的，因为一方面可以做到更为公平和透明，另一方面也给每位同事提供了更好学习和成长自己的样本，激励大家在产品研发中更高质量的挑战和要求自己。
 
执行的关键：
 
每个季度和年度都有OKRs，并保持这样一个节奏的。每个季度都打分。年度的OKRs不是一下就敲定了的。比如你在12月设了下季度和年度的OKRs，往后集中精力在实施季度OKRs上，毕竟这是眼前的目标。而过了一段时间，你可以验证年度OKRs是不是正确的，并不断修订它。年度的OKRs是指导性的，并不是约束。 
可量化的。O和KR的不同：O要是有挑战性的，如果是板上钉钉的事情就是不够的；KRs能很好的支持O的完成，是要明显可量化的，便于评分的 
个人、组、公司层面上均有，个人、组、公司OKRs的不同：个人OKRs是你个人展现你将会做什么；组的OKRs不是个人打包，是组优先做的事情；公司OKRs是高层对整个公司的展望 
 
最后总结下OKR的好处有哪些？
 
规范思维，核心目标突出； 
沟通更精准，让每个人都很清楚什么对他们是最重要的； 
建立测量过程的指标，时刻了解我们距离目标还有多远； 
使组织的努力更聚焦。 
 
四、内在动机与OKR？
 
心理学家Deci 等，将不由外部力量驱使，根植于人内心的自然需求，称为内在动机。
Deci指出，人的这几种自然需求包括：
 
自主需求（Autonomy）：希望对自己所做的事有选择自由，而非被迫。
 
胜任感（Competence）：希望自己能掌控环境，胜任工作。
 
趣味性（Interesting）：事情本身要充满乐趣（Joy），好玩（fun）。
 
这几种自然需求构成了内在动机的核心要素，驱动着人不停地探索未知世界，展现出无穷的创造性。
 
内在动机到底有什么用？
 
为了更好地理解内在动机，我们先来看看外在动机的作用。
 
外在动机是指以获取诸如金钱、奖品、食物等物质类激励作为行动目标的动机。比如，每天搬1000块砖，如果是为了获得100元酬劳，那么这100元钱就是外在动机。
 
当目标非常明确时，外在动机可以很好地发挥作用，它能非常精准地激发员工为之而努力。所谓重赏之下，必有勇夫，就是这个道理。
 
但是，外在动机在针对创造性工作时，就显得特别的无能为力。
 


科学研究表明：
 
1、内在动机有利于激发个体的创造性内在动机驱动的人，其创造性强于外在动机驱动的人。事实上，外在激励会削弱人们的内在动机。
 
2、内在动机能很好地激发个体更深层地理解事物的本质心理学家做过一个实验，让两组学生学习多篇文章，然后让他们进行复述，同时告诉其中一组学生，他们每复述一篇文章会得到1美元。实验结果表明，有金钱激励组学生记忆的内容要多于没有金钱激励组，但他们对文章理解的深度远不如没有金钱激励组学生。这充分说明：外在激励可以增强机械记忆，却减弱了他们对事物本质的追求。3、内在动机能让人更有恒心和毅力基于内在动机工作的员工，在一项工作上坚持的时间会更长；与之相反，基于外在激励工作的员工，当外在激励存在时，他们工作很努力，但一旦外在激励撤销，员工的工作兴趣会立马减退。4、内在动机能激发个体的挑战意识研究表明，当工作是员工自主选择时，员工的承诺意识更强，也更愿意选择有挑战性的任务去挑战自我。心理学家为此也做过一个实验，让两组学生去选择不同难度的任务去完成，并给其中一组学生一定额度的金钱激励。实验结果表明，金钱激励组学生更倾向于选择容易的任务去完成，而没有金钱激励组学生则更倾向于选择超出他们当前能力的任务去挑战自我。5、内在动机能增强个体的幸福感Schulz 通过一个研究发现，处于内在动机状态下的人，患疾病的概率更低，死亡率也更低。
 
综合起来，内在动机让人们跟随兴趣、自主选择、并积极地去挑战自我，因而从长远来看，他们更富有创造性，更有毅力，能取得更大的成就，身心也更健康。
 


内在动机和OKR之间是什么关系？
 
Google的OKR能很好地激发员工的创新意识，正是因为Google的OKR体现了内在动机的核心理念，如果用一张图来描述OKR和内在动机的关系，就是下图这样：
 
 
1、OKR强调自下而上制定，让员工有基于自己兴趣和特长选择工作的自由，这正好体现了内在动机里的“自主”要素；
 
2、OKR的目标不用于考核，是为了避免“外在激励”对内在动机的影响；
 
3、OKR强调目标要有野心，是为了让员工在挑战自我的过程中感受到“胜任感”；
 
4、OKR强调目标要全员公开，也是为了激发员工在社会比较中的“胜任感”。
 


哪些因素影响内在动机发挥作用？
 
1外在激励会削弱内在动机
 
Edward Deci 在《Intrinsic motivation and self-determination》一书中用大量研究事实证明了这一点。在其中一项研究中，他把“索玛立方”难题交给两个单独的小组完成，并在附近摆放了一些杂志：
 
 
 
 
第1组为参与组员提供现金奖励。第2组无现金奖励，只是告诉组员，他想观察他们如何解决这一难题。
 
一段时间以后，Deci博士告诉每个小组，测试已经结束，他将在10分钟内回来做调查。事实上，他在各组不知情的情况下继续进行观察，结果：
 
有现金奖励的参与者更有可能放下拼图，开始阅读杂志。而没有奖励的参与者则更有可能继续尝试解决难题。
 
这项研究表明：外在激励会削弱人们的内在感知，把一件本来很有趣的事变成了一件为了获得外在激励而不得不做的事，因而，当外在激励撤销时，事情本身对他们也就毫无吸引力了。
 
《Succeed》一书作者Heidi Grant Hallorson也曾举过一个这样一个例子：
 
她的一位侄子原本非常喜欢读书，常常是一读就好几个小时。后来，学校为了提升学生的阅读量，强制要求所有学生每天在学校必须阅读至少30分钟。自那以后，作者发现，她的侄子每次在阅读时都会频繁的看表，以确信是否达到“30分钟”目标。
 
这就是一个外在激励削弱了内在动机的典型案例。
 


2控制会削弱内在动机
 
如果你将完成A作为获得B的先决条件，那么A就变成了一种控制手段。比如，你只有发表一篇文章，才会给你一笔稿费。“发表文章”这个动作本身就处于一种“控制”条件下。
 
内在动机的核心是“自主”，即让个体感知到“选择自由”。控制会让个体失去“选择”感，“被迫”去做一件事。
 
心理学家做过一个实验，让学生分别绘制两组图画：
 
第1组（实验组）如果他们完成了第1组中的2幅图画，他们就有资格绘制第2组中的图画。第2组（控制组）简单的将两组图画按顺序分发给学生。
 
几星期后，心理学家发现，第1组（实验组）学生中，还愿意花时间绘制第1组图画的人明显少于第2组（控制组）。
 
这个实验说明，控制本身会削弱个体的内在动机。
 
心理学家还发现，如果人们一直处于被“剥夺自主”状态，久而久之，他们恢复自主的动机也会慢慢减弱，然后逐渐处于一种麻木的”无动机“状态。所以，对那些长期处于管制状态下的人们，即使给他们自主，也很难在短时间内重新点燃他们的内在激情。
 


3正向反馈促进内在动机
 
正向反馈是指诸如表扬、肯定、认可一类的反馈，它有别于像批评、指责这类负向反馈。
 
前文已经说过，内在动机的另一核心要素是胜任感。正向反馈有利于增强个体胜任感，从而促进内在动机。
 
 

OKR很好地体现了内在动机四大核心理念：自主、胜任感、对工作发自内心的热爱、外在动机会削弱内在动机，因此它能很好地培育员工的创新意识，这正是OKR能成功的关键所在。因此，如果你的团队看重的是创新，而非执行，那么，你应当努力地培育员工的内在动机，不要”花钱做傻事“。

 
以上内容整理自网络。其他相关阅读资料：http://en.wikipedia.org/wiki/OKR

现代管理学之父彼得·德鲁克说：“21世纪的组织，最有价值的资产是组织内部的知识工作者和他们的生产力。”团队知识管理的重要性正在被越来越多的企业和组织重视，戴尔、惠普、毕马威等众多知名公司早已搭建一套完善的团队知识管理体系。然而国内大部分公司在这方面还处于早期探索阶段。
互联网团队属于重协作类型。对重协作型的团队而言，知识管理更是极为重要。然而很多团队在搭建团队知识管理体系过程中遇到了很多问题。那么，究竟如何才能搭建起一套有价值的团队知识管理体系呢？
一、了解团队知识管理体系
1.知识管理是什么？
知识管理目前仍没有一个标准的定义，众多定义中比较全面的一个是：
在组织中建构一个量化与质化的知识系统，让组织中的资讯与知识，透过获得、创造、分享、整合、记录、存取、更新、创新等过程，不断的回馈到知识系统内，形成永不间断的累积个人与组织的知识成为组织智慧的循环，在企业组织中成为管理与应用的智慧资本，有助于企业做出正确的决策，以应对市场的变化。
从定义中可以看出，团队知识管理体系有一个十分有趣的特点——团队知识管理体系是一个“生产者即消费者”的平台。由团队成员来生产内容，而这些内容也由团队成员来使用、分享，整个流程形成一个完整的内容生态环境。这个内容生态质量完全由团队自己来控制，价值的高低也取决于团队本身。即想要从中获得高价值的内容，就需要有人向其中输入高质量的内容。本质上跟知乎有些相像。所以想要创造一个健康的生态，就必须达成生产与消费的平衡。
2.为什么要搭建团队知识管理体系？
企业会把现金放在保险柜里，会对所有资产进行严密的管理，包括记录各个资产的账目、位置和数量等等。知识作为最有价值的资产，自然也需要妥善管理，以便它保证能够在最需要的时间将最需要的知识传送给最需要的人，这样可以帮助人们共享信息, 并进而将其通过不同的方式付诸实践, 终极目标是协助企业实现价值最大化。
二、如何搭建团队知识管理体系
第1步：普及
创建团队知识库是一个很简单的动作，只要在某个平台上创建一个团队，我们甚至就可以说创建完成了。然而搭建不同，搭建是一个持续一段时间的行为。搭建包括前期的准备、规划，后期的管理、完善等等，直至形成一个完整的可持续的体系。
如何让团队知识管理体系长久地运营下去才是难题，而能否解决这个难题的关键，正是团队是否认可这种方式。只有大家认可了，才会主动来做这件事情。前期需要对团队进行知识管理意识的普及，如跟大家分享其他企业利用这样的管理方式的例子，如让大家先尝试个人知识管理等。目次在于让大家认识到知识管理的有效性，继而愿意来尝试这种方法。
第2步：规划
规划是非常关键的一步，切勿提出要搭建团队知识管理体系后，只是简单地要求成员来上传自己的文档，后续就不再予以关注。这样不仅无法调动多数成员积极性，比较积极的一部分成员也只能按照自己的想法东拼西凑，最后搭建出一个非常混乱的体系。不仅耗费了积极成员的精力，还无法让他们得到任何成就感。
如果要建立一个团队知识管理体系，一定要指定专人负责规划，职责到人才能够把事情做到位。至于如何制定具体的规则，可以结合难点，进行一场头脑风暴。不仅能够充分发挥团体的智慧，还能够了解每一个人的想法。
在整个规划中，搭建知识架构这件事非常重要。后期在要求成员扩充内容时，可能成员本人并不知道该写什么，就会以架构作为参考来选题。所以架构本身就带有指导的性质，切不可敷衍。
规划中的两个难点：
难点1：怎样把隐性知识显性化？
这里涉及到了关于知识的两个名词。隐性知识指的是未被表述的知识，如技能、秘诀等；显性知识则是以书面文字、图表和数学公式加以表述的知识，更加直观。一般来讲，隐性知识比显性知识更完善、更能创造价值，隐性知识的挖掘和利用能力，将成为个人和组织成功的关键。显性知识则必须能很快地再转换为隐性知识，否则它的真实价值就不复存在。因为显性知识转换为企业员工隐性知识的过程，一般都是知识应用的过程或知识成为生产力的过程。
怎样把隐性知识显性化，通俗地来说就是怎样把优秀人才的工作经验转化大家看得懂的文字或流程等。一个可考虑的方式，是在每一个项目或较复杂工作做成果总结的时候，规定项目负责人对整个过程进行一次复盘。即除了提交成果以外，还要对整个项目从头到尾进行一次梳理，归纳出优点和不足。这样其他成员也能够间接从中吸取到经验教训。
难点2：如何快速找到对自己有用的信息？
完善的分类模式+脑图+准确标题=快速查找
团队知识库会随时间而扩大，当目录层级非常多的时候，如何找到所需的信息成了一大难题。如果不在归纳梳理上花功夫，知识库里的内容就容易成为一个“杂书间”，完全没有条理，来找“书”的人也根本无法找到对自己有用的“书”。实际上，解决这个问题所要的事也很像一个图书管理员的日常。
首先要建立一个合理的分类架构，这件事情要由对团队工作所有相关领域都极熟悉的元老级人物来做。因为他们知道什么是合理构架，知道团队需要什么样的内容，知道什么样的内容具有复用性，会从更严谨的角度出发来搭建架构。新人不够熟悉业务领域，所以无法搭建起一个实用合理的知识架构。
然后要在已经创建了分类架构的基础上，制作一张全局预览图。比较建议的方式是做一张可以实时更新的云端协作思维导图，随着知识库内容的增加而更新。团队成员想查找信息的时候，只要打开脑图就能够找到大概的位置。因为文件夹目录只能看到当下的一层，而要精准地找到某个文件，则需要看到完整的结构。
除此之外，在最初制定管理规则的时候，对文档标题进行比较严格的规定，要求标题中包括比较详细的关键字，也有助于查找。
第3步：管理与完善
规划中制定的规则在实施中还会发现各种不完善的地方，需要在后期的实施中持续优化。甚至可以做A/B 测试来观察不同的规则所带来的效果。规则方面，非常重要的一点是适度，不能让成员感到要求过分。这种用规则来进行约束的方法，可以称之为“硬管理”手段。
与“硬管理”相对的还有“软管理”，指的是为达成目的所使用的非强制手段。在“软管理”中，管理者的作用十分关键。一方面能够起到表率作用：管理者自己分享一些经验、行业观察等，带起分享知识的风气。另一方面，管理者可以鼓励有潜力的成员，让员工感到被认可，从而主动分享自己的知识。还可以表扬对知识库贡献比较大的成员，增加他们的成就感，同时也让其他的成员愿意花心思来做这件事。
实际上，最重要的是创造一个乐于分享的和谐氛围，让大家自发性地来分享知识，而不是因为被push才不得不写。
此外，还要明白每个团队都有自己的特点，产品团队、研发团队、运营团队等等，在很多方面都有自己的特性。当前企业文化、员工素质、运营模式也是需要考虑的方面。应以专人管理辅以员工自发，并随其发展而逐步调整两者比例。
管理难点：怎样让团队成员持续分享自己的知识？
经济奖励+精神奖励=持续分享
分享知识这件事本身就是有门槛的一件事，要求持续分享则是更高的目标。对于成员而言，团队知识管理体系常见的驱动力有两种：经济价值和个人价值。
要求成员主动而持续地分享，最有效的还属经济驱动。常见形式是有直接的奖金鼓励，以及间接的积分或悬赏等鼓励方式。个人价值方面，则可以提供成员更多成就感，以及更优的工作机会。这两者激励机制都是反馈周期越短，效果越明显。
Tips：先试错，再实行
实际上搭建一个完整的团队知识分享体系是一个比较复杂的过程，需要投入许多成本和精力，所以可以先小范围进行尝试，采用产品中MVP（最小化可行产品）的理念来进行试错，等到状态比较理想的时候再在团队全体成员中实行。
挑选团队知识管理平台
想要搭建起一个完整的团队知识管理体系，必然要借助团队知识管理平台，用以管理存放团队知识文档。好的平台能让搭建团队知识体系这件事变得更简单，从而达到事半功倍的效果。
1.对团队知识管理平台的要求
一个好的团队知识平台至少要做到以下几个方面：
（1）稳定，知识安全不丢失。
文档的安全是首要考虑因素，所以平台最好由大厂提供。
（2）存储空间大，且内容不泄密。
团队知识、资料包括许多机密，平台一定要谨慎选择，非常小的第三方平台可能没有那么有保障。
（3）个人文档和团队文档加以区分。
方便成员使用，因为成员也有自己的知识库，需要加以区分。
（4）多级目录，多种成员权限，多种文档权限。
多种目录是为了分类与层级管理。多种权限则是leader的管理需要。
（5）利于查看使用，分享便捷。
使用方便和分享快速很重要。就使用而言，需要符合多终端的特点，这样才能满足不同的应用场景。分享则包括成员间的分享，以及向外部人员的分享，轻量操作为佳。
（6）最好还提供多人共同编辑，而且编辑完能够直接保存到平台。
多人编辑能够让工作流程更简单，不需要传输下载。直接保存到平台也是非常重要的功能。
很多工具都把“编辑”与“保存”分离开了，编辑依托于别的工具，到保存的时候在纳入管理保存工具之下。流程的衔接性不友好，要在多个系统中切换。复杂的操作流程会提高分享门槛。
（7）带一些沟通功能，如评论等。
能够对文档进行评论可免去需要来回切换至IM工具的繁琐过程。评论最好是划词评论，能够更清晰地了解评论针对的是哪部分内容。

        
驱动
21
世纪新型商务企业发展的原动力是什么？有人答曰：项目管理。的确，项目管理作为一门新兴的学科，发展之快已超过了我们的想象。美国
Fortune
杂志甚至预言，项目经理将是
21
世纪的首选职业。让我们共同走近项目管理。
 
“金字塔工程”到“北极星导弹计划”
 
论起项目管理的起源，其实很早。古代诸如金字塔、长城等著名的伟大工程项目的成功，都得助于当时对工程项目进行的严密和科学的管理。20世纪60年代初，在著名数学家华罗庚教授的倡导下，将项目管理的概念引入了我国，并在当时的国民经济各个部门进行试点应用，将这种方法命名为“统筹法”。之后，中国科学院管理科学与科技政策研究所，还牵头成立了“中国统筹法、优选法与经济数学研究会”。改革开放后，项目管理在水利、建筑、化工等领域开始被大量地应用起来。2000年底，联想在“天麒”、“天麟”两款计算机产品的开发过程中，结合业务对项目管理的需求，配合项目管理相关理论、方法编制软件方案，使该项目在8个月的时间内便全部完成，并达到了国际上PC生产技术的最高水平。
 
现代项目管理的概念起源于美国。上个世纪五十年代后期，美国的Booz-Allen 
 
Lockheed公司首次在北极星导弹计划中运用了PERT技术。同一时期，美国的Dupont and 
 
RamintonnRand公司创造了CPM方法，用于研究和开发、生产控制和计划编排，结果大大缩短了完成预定任务的时间，之后它们分别被称为“计划评审技术”和“关键路径法”。现代项目管理科学便是从这两项技术的基础涎杆俜⒄蛊鹄吹模 诤狭撕罄捶⒄蛊鹄吹腤BS工作分解技术、蒙特卡罗（Monte Carlo）模拟技术和EV挣值分析技术，形成了一门关于项目资金、时间、人力等资源控制的管理科学。著名的阿波罗登月计划、曼哈顿计划等都是采用项目管理的理论和方法而取得成功的经典案例。
 
9大知识体系与5个具体阶段
 
早期的项目管理主要关注的是成本、进度(时间)，后来又扩展到质量。最近十几年间，项目管理逐渐发展成为一个涵盖9大知识体系、5个具体阶段的单独的学科分支。9大知识体系包括：
 
·集成管理在项目分析中，项目管理人员必须把各种能力综合起来并加以协调利用。
 
·范围管理定义项目的边界，着眼于“大画面”的事物。例如项目的生命周期、工作分工结构的开发、管理流程变动的实施等。
 
·时间管理要求培养规划技巧。有经验的项目管理人员应该知道，当项目出现偏离规划时，如何让它重回规划。
 
·成本管理要求项目管理人员培养经营技巧，处理诸如成本估计、计划预算、成本控制、资本预算以及基本财务结算等事务。
 
·人力资源管理着重于人员的管理能力，包括冲突的处理、对职员工作动力的促进、高效率的组织结构规划、团队工作和团队形成以及人际关系技巧。
 
·风险管理需要管理人员在信息不完备的情况下作决定。风险管理模式通常由三个步骤组成：风险确定、风险影响分析以及风险应对计划。
 
·质量管理要求项目管理人员熟悉基本的质量管理技术。例如：制作和说明质量控制图、实施80：20规则、尽力达到零缺陷等。
 
·采购管理项目管理人员应掌握较强的合同管理技巧。例如，应能理解定价合同相对于“成本附加”合同所隐含的风险。应了解签约中关键的法律原则。
 
·沟通管理要求项目管理人员能与他们的经理、客户、厂商及属下进行有效的交流。
 
5个阶段是：项目启动、项目计划、项目执行、项目控制和项目收尾。
 
除此之外，作为一个称职的项目管理专业人员，还必须具有相应的通用管理知识和经验、相关的业务知识背景以及精深的风险管理经验。也就是说，项目经理应当是一个具有相当丰富的知识并具有合理知识结构的高级复合型人才。
 
现在，项目管理在全球范围内被政府、大型公司、企业以及小型非赢利组织广泛地采用。与此同时，具备项目管理经验和项目领导才能的管理者，在职场上变得炙手可热。因为全球化的竞争要求新项目和新业务的发展都要在预算范围内按时完成。
 
向项目管理要高效
 
项目是一项为了达到一个特殊目的而进行的临时性活动。每一个项目有明确的开始和结束时间，项目能够由组织的各个层次创建；涉及的人数可以是一个人，也可以是上千人；可以只涉及一个单独的部门，也可以是跨部门的合作。项目管理可以应用于任何项目，而不受它的大小、预算或期限的限制，例如：
 
·开发一个新产品或服务；
 
·设计一个新车型；
 
·运作一次政治竞选；
 
·建一座大桥；
 
·发射火星探测器；
 
·建立一个电子商务站点。
 
 
那么，什么是项目管理呢?按照PMBOK2000的定义，项目管理是运用相关的知识、工具和技术管理的活动，目的是满足客户对特定项目的要求。项目经理负责管理整个项目，他的工作主要是：
 
·在项目范围、时间、成本、风险和质量之间做出最佳平衡；
 
·满足不同项目干系人的不同需要和期望；
 
·实现既定的需求目标。
 
        理想情况下，所有的企业都能够从项目管理中获益，特别是在管理资本投入和间接活动的花费上。在当今快速多变、全球化的市场环境下，所有类型的企业都需要看到它们投资在固定资产设施、房地产建设以及一些设备的升级上面的回报和收益，或者要对一些内部功能的管理和跟踪，如IT项目、市场项目等。无论什么行业，项目管理都可以使企业通过更好的信息共享来提高生产率和降低成本，在有限的资源条件下更快地以更低的成本交付产品和服务，从而增加营收。
 
项目管理可以帮助企业通过把日常工作标准化、减少可能被遗忘或被忽略的任务，来达到客户的期望值；
 
项目管理也能使可利用的资源以最有效的方式得到最佳的利用；项目管理还能使高级管理者洞察到组织内正在发生的和将要发生的事件。 
 
项目管理原则的应用能够帮助高级管理层做到：
 
·建立成功的衡量指标；
 
·以客户为中心并与客户保持一致；
 
·量化体现价值的成本；
 
·优化组织资源的使用；
 
·贯彻质量原则和标准；
 
·实施战略计划；
 
·缩短新产品的研制周期并快速进入市场。
 
  相关小知识
 
IPMA：国际项目管理协会，是一个在瑞士注册的非赢利性组织，是项目管理国际化的主要促进者。IPMA创建于1965年，最早是一个在国际项目领域的项目经理之间交流各自经验的论坛。1967年，IPMA在维也纳主持召开了第一届国际会议，项目管理从那时起即作为一门学科而不断发展。
 
IPMA的成员主要是各个国家的项目管理协会，到目前为止共有29个成员组织。这些国家的组织用他们自己的语言服务于本国项目管理的专业要求，IPMA则以广泛接受的英语作为工作语言提供有关需求的国际层次的服务。为了达到这一目的，IPMA提供了大量的产品和服务，包括研究与发展、培训和教育、标准化和证书制以及有关广泛的出版物支撑的会议、学习班和研讨会等。
 
PMI： Project Management 
 
Institute（美国项目管理学术组织），成立于1969年，是一个有近5万名会员的国际性学会。它致力于向全球推行项目管理，是项目管理专业最大的由研究人员、学者、顾问和经理组成的全球性专业组织，在教育、会议、标准、出版和认证等方面发起技术计划和活动，以提高项目管理专业的水准。PMI正在成为一个全球性的项目管理知识与智囊中心。
  
前言
CMM（Capability Marurity Model，软件能力成熟度模型）是于1984年美国国会与美国主要的公司和研究中心合作创立的一个由联邦资助的非盈利组织——软件工程研究所（Software Engineering Institute,SEI）的一个早期研究成果。该模型提供了软件工程成果和管理方法的框架，自90年代提出以来，已在北美、欧洲和日本成功地应用。现在该模型已成为事实上的软件过程改进的工业标准。下面我们来一起学习有关CMM的一些基础知识。  
一、 CMM基本概念  
过程（Process）：为实现既定目标的一系列操作步骤[IEEE-STD-610].  
     软件过程（Software Process）：指人们用于开发和维护软件及其相关产品的一系列活动、方法、时间和革新。其中相关产品是指项目计划、设计文档、编码、测试和用户手册。当一个企业逐步走向成熟，软件过程的定义也会日趋完善，其企业内部的过程实施将更具有一致性。  
     软件过程能力（Software Process Capability）：描述了在遵循一个软件过程后能够得到的预期结果的界限范围。该指标是对能力的一种衡量，用它可以预测一个组织（企业）在承接下一个软件项目时，所能期望得到的最可能的结果。 
 
软件过程性能（Software Process Performance）：表示遵循一个软件过程后所得到的实际结果。
    软件过程成熟度（Software Process Maturity）：是指一个具体的软件过程被明确地定义、管理、评价、控制和产生实效的程度。所谓成熟度包含着能力的一种增长潜力，同时也表明了组织（企业）实施软件过程的实际水平。随着组织软件过程成熟度能力的不断提高，组织内部通过对过程的规范化和对成员的技术培训，软件过程也将会被他的使用者关注和不断修改完善。从而使软件的质量、生产率和生产周期的到改善。 
 
CMM是软件过程能力成熟度模型（Capacity Maturity Model）的简称，是卡内基－梅隆大学软件工程研究院为了满足美国联邦政府评估软件供应商能力的要求，于1986年开始研究的模型，并于1991年正式推出了CMM 1.0 版。CMM自问世以来备受关注，在一些发达国家和地区得到了广泛应用，成为衡量软件公司软件开发管理水平的重要参考因素和软件过程改进事实上的工业标准。 
 
CMMI（Capability Maturity Model Integration）即能力成熟度模型集成，这也是美国国防部的一个设想，他们想把现在所有的以及将被发展出来的各种能力成熟度模型，集成到一个框架中去。这个框架有两个功能，第一，软件获取方法的改革；第二，建立一种从集成产品与过程发展的角度出发、包含健全的系统开发原则的过程改进。 
 
关键过程（区）域（Key Process Area）是指一系列相互关联的操作活动，这些活动反映了一个软件组织改进软件过程时所必须满足的条件。也就是说，关键过程域标识了达到某个成熟程度级别时所必须满足的条件。在CMM中一共有18个关键过程域，分布在第二至五级中。  
     关键实践（Key Practices）：是指关键过程域中的一些主要实践活动。每个关键过程域最终由关键实践所组成，通过实现这些关键实践达到关键过程域的目标。
 
软件过程评估（Software Process Assessment）是用来判断一个组织当前所涉及的软件过程的能力状态，判断下一个组织所面向得更高层次上的与软件过程相关的课题，以及利用组织的鼎力支持来对该组织的软件过程进行有效的改进。  
     软件能力评价是（Software Capability Appraisal）用来判断有意承担某个软件项目的软件组织的软件过程能力，或是判断已进行的软件过程所处的状态是否正确或是否正常。  
 
软件工程组（Software Engineering Group）：负责一个项目的软件开发和维护活动的团体。活动包括需求分析、设计、编码和测试等。  
     软件相关组（Software Related Groups）：代表一种软件工程科目的团体，它支持但不直接负责软件开发或维护工作，如软件质量保证组、软件配置管理组合软件工程过程组等等。在CMM的关键实践中，软件相关组通常应该根据关键过程域和组织的上下文来理解。 
 
软件工程过程组（Software Engineering Process Group）：是由专家组成的组，他们推进组织采用的软件过程的定义、维护和改进工作。在关键实践中，这个组织通常指“负责组织软件过程活动的组”。  
     系统工程组（System Engineering Group）：是负责下列工作的个人的团体：分析系统需求；将系统需求分配给硬件、软件和其他成分；规定硬件、软件和其他成分的界面；监控这些成分的设计和开发以保证它们符合其规格说明。 
 
系统测试组（System Test Group）：是一些负责策划和完成独立的软件系统测试的团体，测试的目的是为了确定软件产品是否满足对它的需求。
 
     软件质量保证组（Software Quality Assurance Group）：是一些计划和实施项目的质量保证的团体，其工作目的是保证软件过程的步骤和标准是否得到遵守。 
 
软件配置管理组（Software Configuration Management Group）：是一些负责策划、协调和实施软件项目的正式配置活动的团体。
 
     培训组（Training Group）：是一些负责协调和安排组织培训活动的团体。通常这个组织负责准备和讲授大多数培训课程并协调其他培训方式的使用。 
CMM 的分级
任何一个软件的开发、维护和软件组织的发展离不开软件过程，而软件过程经历了不成熟到成熟、不完善到完善的发展过程。它不是一朝一夕就能成功的，需要持续不断的对软件过程进行改进，才能取得最终的成效。CMM就是根据这一指导思想设计出来的。该模型为了正确和有序地引导软件过程活动的开展，建立一个能够有效地描述和表示的软件过程的改进框架，使其能够对各阶段软件过程的任务和管理起指导作用。该模型以产品质量的概念和软件工程的经验教训为基础，指导企业如何控制开发、维护软件的生产过程和如何制定一套与之相适应的软件过程及管理体系。 
（一）、分级标准
CMM模型描述和分析了软件过程能力的发展程度，确立了一个软件过程成熟程度的分级标准。一方面软件组织利用它可以评估自己当前的过程成熟度，并以此提出严格的软件质量标准和过程改进的方法和策略，通过不断的努力去达到更高的成熟程度。另一方面，该标准也可以作为用户对软件组织的一种评价标准，使之在选择软件开发商时不再是盲目的和无把握的。 
 
CMM的分级结构可以描述为：
     ①、初始级：软件过程的特点是无秩序的，有时甚至是混乱的。软件过程定义几乎处于无章法和步骤可循的状态，软件产品所取得的成功往往依赖于极个别人的努力和机遇。
     ②、可重复级：已建立了基本的项目管理过程，可用于对成本、进度和功能特性进行跟踪。对类似的应用项目，有章可循并能重复以往所取得的成功。
     ③、已定义级：用于管理的和工程的软件过程均已文档化、标准化，并形成了整个软件组织的标准软件过程。全部项目均采用与实际情况相吻合的、适当修改后的标准软件过程来进行操作。
 
④、已管理级：软件过程和产品质量有详细的度量标准。软件过程和产品质量得到了定量的认识和控制。
     ⑤、优化级：通过对来自过程、新概念和新技术等方面的各种有用信息的定量分析，能够不断地、持续地对促进过程进行改进。
除第一级外，每一级都设定了一组目标，如果达到了这组目标，则表明达到了这个成熟级别，自然可以向下一级别迈进。CMM体系不主张跨级别的进化。因为从第二级开始，每一个低级别的实现均是高级别实现的基础。 
（二）CMM的主要内容 
CMM为软件企业的过程能力提供了一个阶梯式的进化框架，它采用分层的方式来解释其组成部分，如图示。在第二至第五个成熟等级中，每个等级包含一个内部结构的概念。      每一级向上一级迈进的过程中都有其特定的改进计划，具体情况如下。
 
 
 
初始级的改进方向是：建立项目过程管理，是使规范化管理，保障项目的承诺；艳进行需求管理方面的工作，建立用户域软件项目之间的沟通，使项目真正反映用户的需求；建立各种软件项目几乎，如软件开发计划、软件质量保证计划、软件配置管理计划、软件测试计划、风险管理计划及过程改进计划等；积极开展软件质量保证活动（SQA）。
     可重复级的改进方向是：不再按项目制定软件过程，而是总结各种项目的成功经验，使之规则化，把具体经验归纳为权利组织的标准软件过程，把改进软件组织的整体软件过程能力的软件过程活动，作为软件开发组织的责任；确定全组织的标准软件过程，把软件工程及管理活动集成到一个稳固确定的软件过程中，从而可以跨项目改进软件过程效果，也可以作为软件过程剪裁的基础；建立软件工程过程小组（SPEG）长期承担评估域调整软件过程的任务，以适应未来软件项目的要求；积累数据，建立组织的软件过程库及软件过程相关的文档；加强培训。 
 
已定义级的改进方向是：着手软件过程的定量分析，已达到定量地控制软件项目过程的效果；通过软件的质量管理达到软件质量的目标。
     已管理级的改进方向是：防范缺陷，不仅在发现了问题能及时改进，而且应采取特定行动防止将来出现这类缺陷；主动进行技术改革管理、标识、选择和评价新技术，是有效的新技术能在开发组织中实施；进行过程变更管理，定义过程改进的目的，经常不断地进行过程改进。
     优化级的改进目标方向是：保持持续不断的软件过程改进。 
（三）CMM的内部结构
CMM为软件过程能力的提高提供了一条改进的途径。CMM由5个成熟度等级组成，每个成熟度等级有着各自的功能。除第一级外，CMM的每一级按完全相同的内部结构构成的。成熟度等级为顶层，不同的成熟度等级反映了软件组织的软件过程能力和该组织可能实现预期结果的程度。 在CMM中，每个成熟度等级（第一级除外）规定了不同的关键过程域，一个软件组织如果希望达到某一个成熟度级别，就必须完全满足关键过程域所规定的要求，即满足关键过程域的目标。
（四）软件过程评估和软件能力评价
软件过程评估所针对的是软件组织自身内部软件过程的改进问题，目的在于发现缺陷，提出改进方向。评估组以CMM模型为指引调查、鉴别软件过程中的问题，翻过来将这些问题与CMM关键实践活动所提出的指导一起用于确定组织的软件过程改进策略。
     软件能力评价是对接受评价者在一定条件下、规定时间内能否完成特定项目的能力考核，即承担风险的系数大小。评价包括承包者是否有能力按计划开发软件产品，是否能按预算完成等。通过利用CMM模型确定评价结果后，就可以利用这些结果确定选择某一承包商的风险。也可以用来判断承包者的工作进程，推动他们解决软件过程。
 
CMM为评估和评价提供了一个参考框架，指出了在评估和评价中通常采用的步骤。      具体来说，评估过程是：选择一个工作组；完成问卷调查和取样工作；结果分析；现场访问；与CMM模型对照分析；依据关键过程域的基本情况列出评估提纲。以上步骤在软件过程评估和软件能力评价题勾勒很有参考价值的方法，但在具体操作时以下这些特点也值得考虑： 
 
     ①、在现场访问和考察中，充分运用成熟度问卷和结果分析为依据。
     ②、以CMM模型作为现场调查的路线图。
     ③、利用CMM中的关键过程域定义软件过程中的优点和缺陷，从中发现差异。
     ④、对关键过程域目标是否是满足的实际情况出发，分析满意程度，写出书面报告。 
     尽管软件过程评估和软件能力评价有很多相似之处，但由于其目的和结果的不同，它们之间的差异也是必然存在的，如： 
 
①、软件过程评估和软件能力评价在出发点和目标上的不同，使得会谈目的、调查范围、收集的信息和输出的表示方式上有着本质的不同。尤其在一些细节规范方面，评估和评价的方法有很大差异。      ②、软件过程评估和软件能力评价的结果和结果所起的作用不同。因为两者的侧重点不一样，即使是对同一个应用项目，运用相同的方法，也不会得出相同的结果。      ③、被评估和评价单位的态度对评估和评价活动的影响。评估在某种意义上被评估单位的态度较积极，而评价在某种意义上被评价单位的态度可能比较慎重。软件过程评估是在一个开放的、互相协作的环境中进行的，而软件能力评价往往是在有较大的阻力的环境中进行的。 
 
（五）CMM的组织保证
 
    当人们面对CMM实施时，首先想到的就是人员的构成和各种小组的划分。它是实施CMM的组织保证，是一切活动的基础。CMM在制定软件过程实施中本着尽量不和具体的组织机构和组织形式相联系的原则，为的是提供一个独立于具体企业而又有广泛指导意义的模型框架。但在实施各种软件关键实践中，不可避免地要涉及到角色和组织结构。所以为了使CMM能够适用各种级别和各种规模的企业，SEI提出了一个相对抽象的组织结构，它与组织、项目、人员（角色）相关联，具有自己特定的术语，而且可能不同于其他组织所用的名词。例如基本概念中提到的主要的软件工作组的概念。 
 
三、 正确的态度看待CMM
 
    SEI的CMM并不是软件开发的方法学，也不是产品模板，更不是过程法律。CMM是过程改进的途径，是一套指南，帮助你通过持续的重复、测量和提炼，稳步创造与净化开发环境。CMM的假定是：如果你实施一个不断重复、测量和提炼的大纲，作为环境改进的副产物，质量便会自然的提高。不要把CMM设想为一套规则，而应将它理解为一个学科，做事的一般方法。在这套指南下运作，你会发现这里有着广阔的空间，让你剪裁和塑造自己的大纲，以适应组织的特定要求。
 
CMM不采用“用这种方法做这类事”的风格，它也不对由问题的IT组织提供快速的纠正方案。CMM是一个指南针，指导你如何逃离暴风雪。CMM是一个大纲，要求你对整个IT组织的有关部分，从高层领导到软件生产的第一次线工作者，都做出坚定的、长期的实施承诺。成熟的过程不可能在它之间实现。
     在如何解释CMM建议时，它允许极大的灵活性。CMM意识到，IT组织之间存在着很大的差别。他们的客户不同，使用的工具不同，人员智力和专业背景不同，从事的项目属于不同的类型，规模大小不同，要求也各不相同。因而，他们应当以自己的方式走向成熟。在一处活用的东西，在另一处未必适用。这一点非常重要，中国部分软件公司的前车之鉴也从某种程度上给了我们建议和经验教训，那就是，要灵活应用CMM，不要幻想一夜就有成效。 
从 CMM 到 CMMI 的映射
CMM 到 CMMI 的映射是一个复杂的体系，它涉及到 KPA 重构， KP 的再组织。图 1 只是从总体上描述了 CMM 到 CMMI 的映射关系。
 
映射分析
CMMI 虽然是建立在 CMM 基础之上，两者大部分相似，但还是有很大差异。从总体上讲， CMMI 更加清晰的说明各过程域和类属实践（ generic practice ）如何应用实施，并指出如何将工作产品纳入相应等级的配置和数据管理基线，风险管理策略，验证策略等。 CMMI 包含更多工程活动，如需求开发，产品集成，验证等过程域；过程内容的定义更加清晰，较少强调文档化规程。
如图，在 CMMI2 级中增加了测量和分析 KPA （ Measurement and analysis ），将各测量分析实践（ KP ）归结为一个正式的关键过程域，而在 CMM 中测量分析实践是散落在各等级中的。因此在 CMMI 中更加强调了量化管理，管理的透明度和软件开发的透明度得到了升级。
 
CMMI3 级中增加了需求开发（ Requirements Development ）、技术解决方案（ Technical Solution ）、产品集成（ Product Integration ）、验证（ Verification ）、确认（ Validation ）、风险管理（ Risk Management ）、决策分析和决定（ Decision Analysis and Resolution ） KPAs 。 CMM 中的软件产品工程 KPA 被需求开发，技术解决方案，产品集成，验证，确认 KPAs 所取代；同行评审 KPA 被融入到验证 KPA 中； CMM 中集成软件管理 KPA 所阐述的风险管理在 CMMI3 中形成了一个独立风险管理 KPA 。同时集成软件管理和组间协调 KPAs 合并成集成项目管理 KPA 。合成团队、决定分析和解决方案、组织的一体化环境 KPAs 是全新的，其过程内容在 CMM 中没有提及。
CMMI4 中没有新的过程域，只是对原来的定量过程管理，软件质量管理 KPAs 重新构建为定量项目管理和组织过程性能 KPAs 。
CMMI5 中的技术变更管理和过程变更管理 KPAs 合并为组织革新与技术推广 KPA ，缺陷防范 KPA 重新构建为原因分析和解决方案 KPA 。
CMM 到 CMMI 的升级 
升级前的准备工作 
(1) 回顾 CMMI 模型和其他的 CMMI 信息，确定如何使 CMMI 最好的满足组织需要（ 2 ）拟订升级策略。（ 3 ） 在升级过程中确保以前用于 CMM 改进的投资得到维持和运用（ 4 ）将升级事项通告客户（ 5 ）将对现有过程域和新增过程域的改进费用编入预算，并提供有关改进需要的培训。（ 6 ）确定组织升级计划的风险表并管理这些风险，关键要识别 CMM 和 CMMI 之间的差异以及这些差异如何得到支持。
 
升级的方法：
一旦做好了升级前的准备工作，弄清了升级可带来的利益和成本，可执行下列活动进行升级，这些活动是迭代的。
（ 1 ） 选择适合组织最好的 CMMI 模型。 CMMI 覆盖各种知识体，包括项目管理，软件工程，系统工程，集成产品，过程开发供应商来源。按组织的商业目标选择模型。
（ 2 ）选择最适合组织的表示法。 CMMI 有阶段式表示法和连续式表示法，由于 CMM 采用的是阶段式的表示法，许多组织都采取 CMMI 阶段式表示法，若组织对连续式表示法较熟悉，也可以采取连续式表示法。
（ 3 ）将选择的 CMMI 模型与 CMM 对比，确定需要变更的范畴。具体的对比见上文。 变更的主要活动是对 CMMI 中重组的 KPA 及 CMMI 中新增的 KPA 进行更新。
 
（ 4 ） 确定升级会带来的影响。
（ 5 ）向 CMMI 升级因该报高级管理层的认可。
（ 6 ）变更组织目前的过程改进计划以支持 CMMI 升级。过程改进计划要反映出工作的优先级、组织所需增加的新部门。将该计划送交评审，得到关键储金保管者（ key stakeholders ）的许诺和认可，计划要说明升级可能带来的管理风险和进度风险，所需的培训，工具，和服务支持。传达这个计划并保持更新。
（ 7 ）确保对工程过程组，技术工作组及其他相关的员工进行 CMMI 的培训。
（ 8 ）获取 SCAMPI 评估支持。
（ 9 ） 修改每个项目已定义的过程使其与项目改进计划一致。
（ 10 ）给每个项目制定升级进度表 不同的项目升级进度表可能不同，如果有的升级工作已经完成则该工作可以抛弃。
（ 11 ）执行 SCAMPI 评估，看是否所有的目标过程域和目标得到支持。
处于 CMM 不同成熟等级的组织所做的具体工作 
（ 1 ） CMM1 级：
如果组织正使用 CMM 模型致力于过程改进而并处于 CMM1 级，那么组织应该继续用 CMM 模型。在改进的同时，组织将 CMM2 与 CMMI2 进行对比和差异确认，分析这些差异中哪些是对组织有价值的。当组织刚达到 CMM2 级时其主要工作时立即从 CMM2 向 CMMI2 升级。
（ 2 ） CMM2 级，
组织应该把其当前的过程改进向 CMMI2 级映射，填补两者之间的差距，从 CMM2 升级到 CMMI2 完成后，在下一步的工作中采用 CMMI 模型进行过程改进。主要有一下几方面
 
(1) 将 CMM 中分散的测量分析活动集中到 CMMI2 级测量分析 KPA 中，形成一个独立的过程域，提高开发的透明度。
(2) 重定位测量分析 KPA （ Measurement and Analysis ）的共同特征（ common feature ）
测量分析 KPA 重组见表 所示。
 

表示符说明： QPM Co 2 Ac1,3,4,5,6 表示定量过程管理（ Quantitative Process Management ）过程域执行的约定（ Commitment to perform ） 2 和执行活动（ Activities to perform ） 1,3,4,5,6 。
Co 表示执行的约定； Ab 表示执行的能力； Ac 表示执行的活动； SG 表示特殊目标（ Special Goal ）； GG 表示一般目标（ Generic Goal ）；其他可类推。
 
（ 3 ） CMMI3 级
①将 CMM 软件产品工程 KPA 分解为需求开发、技术解决方案、产品集成、认证、确认 KPAs ，并进行扩充。
②了解 CMMI3 级中新增的决定分析和解决方案、合成团队，组织一体化环境 KPAs ，并填补。
③迭代 CMM2 级的工作。
说明
卡内基梅隆大学软件工程研究所推出 CMM Version 2.0 draft C 后就停止了在 CMM 的改进。 CMM 被 CMMI 所取代是大势所趋。许多正在运用 CMM 模型进行软件过程改进的组织纷纷向 CMMI 升级。而 CMMI 模型迄今还没有成熟，卡内基梅隆大学软件工程研究所 推出了 CMMI-SE/SW 1.1 和 CMMI-SE/SW/IPPD ，在目前的产品集中没有关于软件采购方面的内容，估计以后还会推出这个科目。而且从 CMM 向 CMMI 升级也只是处于尝试阶段。组织升级的操作过程，运用 CMMI 模型所带来的效益等信息还很匮乏，这些信息也为未能及时反馈到卡内基梅隆大学软件工程研究所，这也给 CMMI 模型的改进及向 CMMI 的升级工作带来了一定的难度。 
 
关于CMM评估的一些背景资料 
CMM评估包括5个等级，共计18个关键过程域，52个目标，300多个关键实践。每一个CMM等级评估周期（从准备到完成）约需12-30个月。每一级别的评估由美国卡内基梅隆大学的软件工程研究所授权的主任评估师领导一个评审小组进行，其成员大部分来自企业内部。评估过程包括员工培训（企业的高层领导也要参加）、问卷填写和统计、文档审查、数据分析、与企业的高层领导讨论和撰写评估报告等。评估结束由主任评估师签字生效。国外CMM等级评估生效，只需要主任评估师的签字，既没有某主管单位的批准，也没有盖上公章的证书。显然，国外更看重主任评估师及公司的信誉。 
 
取得主任评估师的资格的条件： § 首先要有10年以上的软件开发经验； § 其次要在美国卡内基梅隆大学的软件工程研究所接受培训，培训费用每人约需数万美元，非美国人加倍； § 第三要经过两次以上CMM评估的全过程实习； § 第四要得到已有主任评估师资格的人推荐。主任评估师的资格并非终身制，如要继续保持，每年至少要参加两次CMM评估。 目前全世界一共只有313个主任评估师，大部分在美国，而我国大陆还没有一个主任评估师。由于我国在CMM评估中要聘请外籍主任评估师，所以费用较高。据估计，要通过一个级别的CMM评估，费用是通过ISO9001认证的十多倍。 
作业
1、请用图表的形式描述CMM的分级结构？
2、软件过程性能和软件过程能力的主要区别是什么？
3、关键实践的主要描述的是什么？
4、CMM和CMMI的主要区别有哪些？
5、假如你是SQA，你应该具有什么样的心态去看待CMM的评定？
 
 
 
软件工程的七条基本原理
 
       自从1968年提出“软件工程”这一术语以来，研究软件工程的专家学者们陆续提出了100多条关于软件工程的准则或信条。美国著名的软件工程专家 Boehm 综合这些专家的意见，并总结了TRW公司多年的开 
发软件的经验，于1983年提出了软件工程的七条基本原理。 

Boehm 认为，这七条原理是确保软件产品质量和开发效率的原理的最小集合。它们是相互独立的，是缺一不可的最小集合；同时，它们又是相当完备的。 

人们当然不能用数学方法严格证明它们是一个完备的集合，但是可以证明，在此之前已经提出的100多条软件工程准则都可以有这七条原理的任意组合蕴含或派生。 

下面简要介绍软件工程的七条原理： 

1 用分阶段的生命周期计划严格管理 

这一条是吸取前人的教训而提出来的。统计表明，50%以上的失败项目是由于计划不周而造成的。在软件开发与维护的漫长生命周期中，需要完成许多性质各异的工作。这条原理意味着，应该把软件生命周期分成若干阶段，并相应制定出切实可行的计划，然后严格按照计划对软件的开发和维护进行管理。 Boehm 认为，在整个软件生命周期中应指定并严格执行6类计划：项目概要计划、里程碑计划、项目控制计划、产品控制计划、验证计划、运行维护计划。 

2 坚持进行阶段评审 

统计结果显示： 大部分错误是在编码之前造成的，大约占63%; <2> 错误发现的越晚，改正它要付出的代价就越大，要差2到3个数量级。 因此，软件的质量保证工作不能等到编码结束之后再进行，应坚持进行严格的阶段评审，以便尽早发现错误。 

3 实行严格的产品控制 

开发人员最痛恨的事情之一就是改动需求。但是实践告诉我们，需求的改动往往是不可避免的。这就要求我们要采用科学的产品控制技术来顺应这种要求。也就是要采用变动控制，又叫基准配置管理。当需求变动时，其它各个阶段的文档或代码随之相应变动，以保证软件的一致性。 

4 采纳现代程序设计技术 

从六、七时年代的结构化软件开发技术，到最近的面向对象技术，从第一、第二代语言，到第四代语言，人们已经充分认识到：方法大似气力。采用先进的技术即可以提高软件开发的效率，又可以减少软件维护的成本。 

5 结果应能清楚地审查 

软件是一种看不见、摸不着的逻辑产品。软件开发小组的工作进展情况可见性差，难于评价和管理。为更好地进行管理，应根据软件开发的总目标及完成期限，尽量明确地规定开发小组的责任和产品标准，从而使所得到的标准能清楚地审查。 

6 开发小组的人员应少而精 

开发人员的素质和数量是影响软件质量和开发效率的重要因素，应该少而精。这一条基于两点原因：高素质开发人员的效率比低素质开发人员的效率要高几倍到几十倍，开发工作中犯的错误也要少的多； 当开发小组为N人时，可能的通讯信道为N(N-1)/2, 可见随着人数N的增大，通讯开销将急剧增大。 

7 承认不断改进软件工程实践的必要性 

遵从上述六条基本原理，就能够较好地实现软件的工程化生产。但是，它们只是对现有的经验的总结和归纳，并不能保证赶上技术不断前进发展的步伐。因此，Boehm提出应把承认不断改进软件工程实践的必要性作为软件工程的第七条原理。根据这条原理，不仅要积极采纳新的软件开发技术，还要注意不断总结经验，收集进度和消耗等数据，进行出错类型和问题报告统计。这些数据既可以用来评估新的软件技术的效果，也可以用来指明必须着重注意的问题和应该优先进行研究的工具和技术。
 
 
常用的功能测试方法
 
 
   
 
功能测试就是对产品的各功能进行验证，根据功能测试用例，逐项测试，检查产品是否达到用户要求的功能。常用的测试方法如下： 
 
　　1. 页面链接检查：每一个链接是否都有对应的页面，并且页面之间切换正确。 
 
　　2. 相关性检查：删除/增加一项会不会对其他项产生影响，如果产生影响，这些影响是否都正确。 
 
　　3. 检查按钮的功能是否正确：如update, cancel, delete, save等功能是否正确。 
 
　　4. 字符串长度检查: 输入超出需求所说明的字符串长度的内容, 看系统是否检查字符串长度,会不会出错. 
 
　　5. 字符类型检查: 在应该输入指定类型的内容的地方输入其他类型的内容(如在应该输入整型的地方输入其他字符类型),看系统是否检查字符类型,会否报错. 
 
　　6. 标点符号检查: 输入内容包括各种标点符号,特别是空格,各种引号,回车键.看系统处理是否正确. 
 
　　7. 中文字符处理: 在可以输入中文的系统输入中文,看会否出现乱码或出错. 
 
　　8. 检查带出信息的完整性: 在查看信息和update信息时,查看所填写的信息是不是全部带出.,带出信息和添加的是否一致 
 
　　9. 信息重复: 在一些需要命名,且名字应该唯一的信息输入重复的名字或ID,看系统有没有处理,会否报错,重名包括是否区分大小写,以及在输入内容的前后输入空格,系统是否作出正确处理.
 
　　10. 检查删除功能:在一些可以一次删除多个信息的地方,不选择任何信息,按”delete”,看系统如何处理,会否出错;然后选择一个和多个信息,进行删除,看是否正确处理. 
 
　　11. 检查添加和修改是否一致: 检查添加和修改信息的要求是否一致,例如添加要求必填的项,修改也应该必填;添加规定为整型的项,修改也必须为整型. 
 
　　12. 检查修改重名:修改时把不能重名的项改为已存在的内容,看会否处理,报错.同时,也要注意,会不会报和自己重名的错. 
 
　　13. 重复提交表单：一条已经成功提交的纪录，back后再提交，看看系统是否做了处理。 
 
　　14. 检查多次使用back键的情况: 在有back的地方,back,回到原来页面,再back,重复多次,看会否出错. 
 
　　15. search检查: 在有search功能的地方输入系统存在和不存在的内容,看search结果是否正确.如果可以输入多个search条件,可以同时添加合理和不合理的条件,看系统处理是否正确. 
 
　　16. 输入信息位置: 注意在光标停留的地方输入信息时,光标和所输入的信息会否跳到别的地方. 
 
　　17. 上传下载文件检查：上传下载文件的功能是否实现，上传文件是否能打开。对上传文件的格式有何规定，系统是否有解释信息，并检查系统是否能够做到。 
 
　　18. 必填项检查：应该填写的项没有填写时系统是否都做了处理，对必填项是否有提示信息，如在必填项前加* 
 
　　19. 快捷键检查：是否支持常用快捷键，如Ctrl+C Ctrl+V Backspace等，对一些不允许输入信息的字段，如选人，选日期对快捷方式是否也做了限制。 
 
　　20. 回车键检查: 在输入结束后直接按回车键,看系统处理如何,会否报错. 
 
 
 
 
 
 
   此文是对我个人测试思想的一个总结，由于经验不够，知识浅薄，如果有什么不合理的地方请一笑了之。 
一、面向对象的概念 
    所谓的面向对象是软件开发的一种重要的思维方式，是把软件开发过程中出现的事物,用一个个的对像来分析.一般一张数据表可以封装为一个对像。用个形象的比喻：我们现在要做一张桌子，首先我们考虑到的是我们要做的是什么？是桌子；桌子是用来干什么的呢？是用来吃饭、喝茶、看书、打麻将的；然后就要考虑桌子由哪些部分组成？由桌面和桌腿来组成；接着我们需要考虑我们采用什么材料呢？纸？不行...那可什么都干不成，OK，用木头；接着就可以开始把组成桌子的组件做为对象开始分析--桌面如何做是用刀砍的还是用刨子刨呢？桌腿又如何做... 
一套完整的方法成形了就可以具体实现了，在做的过程中桌面要做多大，桌腿要做多长都要事先考虑到是不是要留出接口，这些就是我们给组成桌子的组件赋予的属性。OK，现在可以做出具体的实物了，做好实物组件（对象）以后就要将做好的桌面桌腿进行组装，由于我们事先考虑好了组件的属性，考虑到了必须预留接口，因此我们可以很轻易的组合成功，桌子做出来了。以上就是面向对象的思想的一个简要的比喻 

了解面向对象必须了解的几个名词：对象、方法、属性、继承、多态 

二、游戏测试 
    游戏测试是整个软件测试行业中比较特殊的一部份，他有着大多数软件测试的共性，也具备自身的特性，而相对于许多通用软件的测试来说，游戏测试所具备的特性是非常明显的。现在就简要的说说上面提到的共性和特性。 
共性： 
1、测试的目的就是为了尽可能的发现软件存在和潜在的问题。 
2、测试都是需要测试人员按照产品行为描述来实施。产品行为描述可以是书面的规格说明书、需求文档、产品文件、或是用户手册、源代码、或是工作的可执行程序。 
3、每一种测试都需要产品运行于真实的或是模拟环境之下。 
4、每一种测试都要求以系统方法展示产品功能， 以证明测试结果是否有效， 以及发现其中出错的原因， 从而让程序人员进行改进。 
    总之，软件测试就是对产品进行尽可能的全面检查，尽可能的发掘bug，提高软件质量，从而为企业创造利润。 
特性： 
    网络游戏世界从某种意义上说是另一个人类社会，只是人们在网络游戏世界中进行着在被允许的范围内的活动，包括了修炼、交流、合作、经商、欺诈、情感、冲突等等。而在游戏制作时这些进行这些行为的部分就是一个个完整的功能，我们在进行测试的时候，需要考虑的不仅仅是能否实现功能，要考虑更多的是人们在进行操作时会如何做，可能有多少种做法，这些做法应该有什么样的响应，哪些做法是被禁止的，在进行了被禁止的操作后应该有什么的响应。因此这里就是涉及到了游戏世界的测试方法： 
1、游戏情节的测试，主要指游戏世界中的任务系统的组成， 有人也称为游戏世界的事件驱动， 我喜欢称为游戏情感世界的测试。 
2、游戏世界的平衡测试，主要表现在经济平衡,能力平衡（ 包含技能， 属性等等）,保证游戏世界竞争公平。 
3、游戏文化的测试，比如整个游戏世界的风格， 是中国文化主导,还是日韩风格等等，大到游戏整体，小到N P C（ 游戏世界人物） 对话， 比如一个书生，他的对话就必需斯文， 不可以用江湖语言。 

以上陈述中关于游戏特性的部分概念是曾在金山公司的测试人陈卫俊提出来过的,在此引用 

三、如何用面向对象的思想进行测试 
    上面了解了面向对象的概念以及游戏测试和通用软件测试的区别以后我们可以进入正题了---如何用面向对象的思想进行游戏测试? 
    首先,和所有通用软件以及硬件产品一样,我们的游戏是一个产品,是一个存在的实体,因此,我们把这个"实体"当做一个大的对象开始分析,整个游戏由哪些部分构成,而构成整个游戏的大的部分又由哪些组件构成,认真分析完这些以后就可以着手进行测试了,注意,这里说"可以进行测试了"意思不是马上就能进入测试,听我慢慢道来. 
     "工欲善其事,必先利其器"---某位高人说的,我们做测试也是一样,分析完毕后,我们要做的还是分析 ^_^ 不过这里的分析和之前的分析有点点区别,这里我们需要分析的是具体功能的关键测试点和风险点,测试不能盲目,打蛇要打七寸.....在这里我们就是把某个具体的功能作为一个对象，我们要分析组成这个功能的是哪些因素，一共有哪些测试点，哪些测试点是关键点，哪些是高风险点，一一列举出来,这样我们就一目了然了，然后就是我们打算采用何种方式来进行测试，这里就是方法了.测试的方式可能有很多种(比如在不同的操作系统下进行测试等),因此我们也需要一一列举，此外我们需要分析的还有测试过程中我们需要用到的具体测试手法、具体的数值、特定的环境等等这些就是属性，当然这些我们也必须整理出来。 
    将以上提到的对象、方法、属性整理成文档就是我们测试时所必须的测试用例了。当然，还是老话，测试用例的优劣是以覆盖面来评判的，这里就需要经验了，简单说就是靠累积以及学习。 
     OK，测试用例我们完成了，剩下的就是实施测试了，实施测试时个人觉得一定要按照用例的描述去执行，如果在测试过程中觉得用例不完善可以先更新用例再进行测试，一定不要先测试再补用例！！ 
    接下来就是测试报告，报告中包含的应该有所有测试点的简述，包括了通过测试的部分和存在bug的部分。bug管理是很重要的一环，在这里不详述。 
    关于测试流程在这里就不做具体说明，在这里希望阐述的是一种测试的思想，个人觉得测试除了要有扎实的相关基础知识以便更深入的了解产品以外，更重要的是测试思想，具备了完善的测试思想才能有计划的完成每一步测试，从而提高测试的效率，保证测试产出的质量，也更好的保证产品的质量。面向对象是一种思想，用面向对象的思想来组织、计划、实施测试工作，能让我们在测试工作中有很强的目的性，他能清楚地告诉我们今天要做什么，明天要做什么，我们要做的是哪些，说回游戏测试，游戏开发是一个迭带的开发模式，因此测试工作往往会有很大的随机性，因此当我们接到一个新功能时，首先要明确我们要测得这个功能是做什么的，有什么用，这个功能怎么使用。OK，我们了解了这个功能是什么，能做什么就可以开始细化分析了：这个功能共由哪些子功能组成，这些子功能是否有自己的子功能点，一层层的分析下去，然后就是从最底层的功能点分析：这个功能什么情况下要发挥其功效，发挥其功效的因素有哪些，怎么样去发挥具体的功效，该功能有没有相应的容错机制，这些就是我们的详细测试点和测试手法。然后向上一层一层分析，一直到最顶层就是我们的功能完整的测试方针。这样我们就把面向对象的思想完全用到了测试中。当然，在分析的过程中我们必须考虑到，与游戏情节、游戏风格、游戏平衡、玩家的易用性是否冲突等等因素，适时地给策划提出正确的建议。 
     
    以上陈述的种种，无非是想将面向对象的思想用到测试中的好处列举出来，或许经验浅薄说的有些苍白，但是我坚信一点，测试是一种思想，是一种绝对不亚于开发思想的学问，要想做好测试就需要具备良好的测试思想，或者良好的测试思想不是一天两天能够形成的但是相信只要把测试当做一种职业，当作一种事业来做，把自己真正当成保证产品质量的最后一道关卡，成为一个BT（BestTester）就指日可待了！
 
 
软件测试用例的认识误区
  
     
 
      
软件测试用例是为了有效发现软件缺陷而编写的包含测试目的、测试步骤、期望测试结果的特定集合。正确认识和设计软件测试用例可以提高软件测试的有效性，便于测试质量的度量，增强测试过程的可管理性。 
 
      
在实际软件项目测试过程中，由于对软件测试用例的作用和设计方法的理解不同，测试人员（特别是刚从事软件测试的新人）对软件测试用例存在不少错误的认识，给实际软件测试带来了负面影响，本文对这些认识误区进行列举和剖析。 
 
      
误区之一：测试输入数据设计方法等同于测试用例设计方法 
 
      
现在一些测试书籍和文章中讲到软件测试用例的设计方法，经常有这样的表述：测试用例的设计方法包括：等价类、边界值、因果图、错误推测法、场景设计法等。这种表述是很片面的，这些方法只是软件功能测试用例设计中如何确定测试输入数据的方法，而不是测试用例设计的全部内容。
 
      
这种认识的不良影响可能会使不少人认为测试用例设计就是如何确定测试的输入数据，从而掩盖了测试用例设计内容的丰富性和技术的复杂性。如果测试用例设计人员把这种认识拿来要求自己，则害了自己；拿来教人，则害了别人；拿来指导测试，则害了测试团队。听起来似乎是“小题大做”，但是绝不是“危言耸听”。 
 
      
无疑，对于软件功能测试和性能测试，确定测试的输入数据很重要，它决定了测试的有效性和测试的效率。但是，测试用例中输入数据的确定方法只是测试用例设计方法的一个子集，除了确定测试输入数据之外，测试用例的设计还包括如何根据测试需求、设计规格说明等文档确定测试用例的设计策略、设计用例的表示方法和组织管理形式等问题。 
 
      
在设计测试用例时，需要综合考虑被测软件的功能、特性、组成元素、开发阶段（里程碑）、测试用例组织方法（是否采用测试用例的数据库管理）等内容。具体到设计每个测试用例而言，可以根据被测模块的最小目标，确定测试用例的测试目标；根据用户使用环境确定测试环境；根据被测软件的复杂程度和测试用例执行人员的技能确定测试用例的步骤；根据软件需求文档和设计规格说明确定期望的测试用例执行结果。 
 
      
误区之二：强调测试用例设计得越详细越好 
 
      
在确定测试用例设计目标时，一些项目管理人员强调测试用例“越详细越好”。具体表现在两个方面：尽可能设计足够多的设计用例，测试用例的数量阅读越好；测试用例尽可能包括测试执行的详细步骤，达到“任何一个人都可以根据测试用例执行测试”，追求测试用例越详细越好。 
 
      
这种做法和观点最大的危害就是耗费了很多的测试用例设计时间和资源，可能等到测试用例设计、评审完成后，留给实际执行测试的时间所剩无几了。因为当前软件公司的项目团队在规划测试阶段，分配给测试的时间和人力资源是有限的，而软件项目的成功要坚持“质量、时间、成本”的最佳平衡，没有足够多的测试执行时间，就无法发现更多的软件缺陷，测试质量更无从谈起了。 
 
      
编写测试用例的根本目的是有效地找出软件可能存在的缺陷，为了达到这个目的，需要分析被测试软件的特征，运用有效的测试用例设计方法，尽量使用较少的测试用例，同时满足合理的测试需求覆盖，从而达到“少花时间多办事”的效果。 
 
      
测试用例中的测试步骤需要详细到什么程度，主要取决于测试用例的“最终用户”（即执行这些测试用例的人员），以及测试用例执行人员的技能和产品熟悉程度。如果编写测试用例的人员也是测试用例执行人员，或者测试用例的执行人员深刻了解被测软件，测试用例就没有必要太详细。而如果是测试新人执行测试用例，或者软件测试外包给独立的第三方公司，那么测试用例的执行步骤最好足够详细。 
 
      
误区之三：追求测试用例设计“一步到位” 
 
      
现在软件公司都意识到了测试用例设计的重要性了，但是一些人认为设计测试用例是一次性投入，测试用例设计一次就“万事大吉”了，片面追求测试设计的“一步到位”。 
 
      
这种认识造成的危害性使设计出的测试用例缺乏实用性，或者误导测试用例执行人员，误报很多不是软件缺陷的“Bug”，这样的测试用例在测试执行过程中“形同虚设”，难免沦为“垃圾文档”的地步。 
 
      
“唯一不变的是变化”。任何软件项目的开发过程都处于不断变化过程中，用户可能对软件的功能提出新需求，设计规格说明相应地更新，软件代码不断细化。设计软件测试用例与软件开发设计并行进行，必须根据软件设计的变化，对软件测试用例进行内容的调整，数量的增减，增加一些针对软件新增功能的测试用例，删除一些不再适用的测试用例，修改那些模块代码更新了的测试用例。 
 
      
软件测试用例设计只是测试用例管理的一个过程，除此之外，还要对其进行评审、更新、维护，以便提高测试用例的“新鲜度”，保证“可用性”。因此，软件测试用例也要坚持“与时俱进”的原则。 
 
      
误区之四：让测试新人设计测试用例 
 
      
在与测试同行交流的过程中，不少刚参加测试工作的测试新人经常询问的一个问题是：“怎么才能设计好测试用例？”。因为他（她）们以前从来没有设计过测试用例，面对大型的被测试软件感到“老虎吃天，无从下口”。 
 
      
让测试新人设计测试用例是一种高风险的测试组织方式，它带来的不利后果是设计出的测试用例对软件功能和特性的测试覆盖性不高，编写效率低，审查和修改时间长，可重用性差。 
 
      
软件测试用例设计是软件测试的中高级技能，不是每个人（尤其是测试新人）都可以编写的，测试用例编写者不仅要掌握软件测试的技术和流程，而且要对被测软件的设计、功能规格说明、用户试用场景以及程序/模块的结构都有比较透彻的理解。 
 
      因此，实际测试过程中，通常安排经验丰富的测试人员进行测试用例设计，测试新人可以从执行测试用例开始，随着项目进度的不断进展，测试人员的测试技术和对被测软件的不断熟悉，可以积累测试用例的设计经验，编写测试用例。
     
 

 
 
 
使用面向对象的思想进行测试（游戏测试相关）