IT人员如何管理知识

IT 技术团队的绩效考核是比较头痛的事情。从技术员工的角度来讲，我和大家一样是很反感绩效考核的，主要原因是技术绩效到底怎样去量化是个难点。但是从管理的角度讲，技术团队必须要有绩效管理机制。

绩效管理是各级管理者和员工为了达到组织目标共同参与的绩效计划制定、绩效辅导沟通、绩效考核评价、绩效结果应用、绩效目标提升的持续循环过程。绩效管理的目的是持续提升个人、部门和组织的绩效。

绩效管理的核心是完成组织目标，以目标为导向，以激励为主要手段，以惩罚为次要手段(但必须要有)。KPI 相关的内容，都是必要或不必要的浮云。

通过绩效管理，你可以激发技术人员的潜能，可以给技术团队一个发力的方向，让大家为了完成团队的目标而努力。

对于个人来说，可以提高个人工作效率，提升个人经验和知识水平，最终提升个人的收入和影响力。 对于团队来说，可以提高团队的效率、协作性以及团队的自我成长性。 对于企业来说，可以提高企业效率，降低运营成本，提升客户体验，增加客户黏性和用户规模，推动公司发展技术业务，直接带来收入。

技术团队绩效管理的四大难题

难题1：领导觉得员工做得不好，员工自己感觉特别良好。

原因：直接领导和直接下属之间对绩效目标的理解没有达成一致，或者领导也不清楚绩效目标是什么。

难题2：每个员工的绩效都不错，但团队的绩效却没有提升，甚至是下降了。

原因：团队没有目标，或者说员工绩效目标与公司、团队绩效目标不一致。

难题3：绩效管理流于形式，实施一段时间执行不下去了。

原因：绩效管理环节遗漏、绩效结果应用不合理，或者领导并没有真正想管绩效。

难题4：技术体系的绩效不好量化。

原因：一方面要看领导心里是否有杆秤;另一方面因为技术体系属于非销售部门，工作结果不太好评估，不同岗位的要求也不一样。

绩效目标要结合公司的目标，然后进行任务分解。 要明白关键目标和结果是什么，影响考核结果的因素有哪些，要让所有人都清楚。 最重要的是帮助大家达成目标，而不是只关注最后的考核结果。 技术指标、效果指标(如产生的销售增量、转化率)、贡献评估一样不能少。

领导与下属要沟通确认好绩效目标和绩效计划。 绩效辅导必不可少，绩效管理不是为了给员工扣分，是为了让员工更好地达成绩效。 要与利益、晋升等挂钩，公司与员工平衡共赢。 发现问题及时纠错。 绩效考核标准尽可能量化，要根据不同岗位、不同职级定义绩效目标和绩效合同。

具体案例：

创业团队，成员7人，3个后端JAVA，1个前端JS，1个产品经理、1个UI，1个测试。产品已经上线，现处于优化阶段。

考核周期，1个季度。

考核分数前2名，奖励绩效工资。

IT管理的重点在于业务策略与 IT 部门提供的服务之间的一致性。IT 管理可建立必要的管理机制来确保可预测的 IT 服务交付，从而确保业务流程和 IT 流程之间的联系。IT 管理传统上属于CIO、CEO和一些 IT 和业务线（line of business，LOB）执行人员的专属领域。

SOA管理是 IT 管理的扩展。它与 IT 管理的区别在于，SOA 管理的重点具体放在通过服务和面向服务的计算交付的有效 IT 实现上。

面向服务的计算机的目标是把业务流程作为 IT 服务交付。与 IT 管理不同，SOA 管理要求与业务线更紧密的耦合。面向服务要求采用层次化的手段来实现管理。SOA 管理必须在企业级实现，且必须与传统的 IT 管理模型一致。但与传统 IT 管理不同，SOA 管理要求使用同时具有分层性和跨组织特点的模型/域模型。因此，LOB、重要程序以及相关各方都要求使用自己的管理模型。这对加速实现那些对特定社区具有极大价值的服务的实现很有必要。类似地，技术 IT领域内的 SOA 管理具有独特的重点，以便有效地开发、部署和管理服务。

IT 管理最佳实践和流程已在 CoBIT (Control Objectives for Information and Related Technologies) 等相关工作中进行了说明。CoBIT 是由金融分析师发起的，并由他们参与了部分开发工作。IT 管理方面存在大量知识和最佳实践，而对 SOA 管理则不是如此。SOA 管理是一门发展中的科学，需要各个行业的专家、计算机科学家和供应商广泛地参与。事实上，IBM 等供应商当前开发工具来帮助部署 SOA 管理。业务和 IT 专家需要紧密合作，以便成功部署 SOA。通过面向服务提供业务价值，会有效地更改组织与 IT 部门的交互方式。希望采用 SOA 策略的组织需要业务流程专家、老练的 IT 架构师和强有力的 SOA 管理程序。有效的管理会成为促进 IT 行业的 SOA 推广的有效方法。

当然，你会不服气，说自己已经研究过这些资料，并且转化成了自己的知识，而知识是无价的。 可是残酷的现实告诉你，知识既不会带来“颜如玉”，也不会带来“黄金屋”。自认为饱学之士的你，为何反而不被重用？不被运用的知识是死知识，你可能成为别人的“百科全书”/“智力提款机”，但偏偏你自己不知道该做些什么。 而且IT领域知识的更新换代很快，一不小心，花费大量精力掌握的知识就成了“废品”，其价值不如一枚“茶叶蛋”， 这让身为IT“专业人士”的你，情何以堪？如果经历过风雨的你仍然执着于技术，本文将与你探讨IT技术人员进化之路，探讨如何更有效的管理知识，如何让知识变成能力，运用知识解决问题。Table of Contents1 缘起2 资料，知识，智慧，思想，精神3 知识的条理31 业务领域32 行业划分33 类别34 掌握程度4 知识地图41 知识地图的作用42 如何表述知识地图5 小结1 缘起加入某证券公司已经2年了，最近发现自己的知识体系有有些混乱。其实这是好事，说明知识的领域变宽了， 带来的问题是需要抽出时间进行专门的梳理，这是一项比较繁重的体力劳动，尤其对于奔4的人来说。在十余年的IT生涯中，这样的事情发生过几次，其中比较重大的有以下几次：第一次是解散自己的创业团队，加入某软件服务商（ASP）并担任项目经理。 之前的创业团队规模较小管理简单，个人关注的领域主要在开发技术；到了新公司拓展了项目管理、需求分析、政府行业知识（主要是区域政府一站式审批，新农村合作医疗）、协同办公解决方案 等知识领域， 也涉及到一些软件开发平台、CMS、以及BI产品。第二次是到一家外企的解决方案部门，主要工作内容是Consulting，即分析问题并提出解决方案。期间积累了企业管理（尤其是IT管理）、电信行业、民航行业、电视媒体行业的业务知识，知识管理（KM）解决方案，以及BPM、ESB、Portal等平台软件，了解了SUN和IBM的服务器，同时客串了一些Flash/Flex和M$ WPF的研究及培训工作。第三次也就是现在，加入证券公司。从乙方变成了甲方，工作内容又有了比较大的变化。首先是扩充证券行业的业务知识，接下来的工作重点放在企业架构（EA）、IT运维（主要是应用系统管理、配置管理、问题管理）、甲方的项目管理等。为了做好这些工作，又额外关注了IT规划、企业IT治理、IT组织架构等领域；在技术方面包括ESB实施和webservice规划、服务器虚拟化、HP服务器及一些网络和存储设备、Linux、Oracle、网络规划设计（学习）、数据仓库和数据挖掘（了解）、消息中间件、集中交易系统架构、规则引擎、CEP、性能测试、应用开发平台等等。出于兴趣和爱好还在学习python和emacs。相信你已经明白我为什么会写这篇文章了——这些急速扩充的知识迫切需要条理化，否则短期内知识领域的急剧扩充必然导致大脑崩溃。学习的过程可能是在某个领域的不断深入，也可能是对更多领域的扩展。在知识爆炸和渴求复合型人才的今天，后者应该更加重要。知识领域的扩展，必然会带来某种“混乱”，即新的领域知识打破了你原来的知识框架，对知识的主观定位及知识之间的关联变得模糊不清。所以过一段时间（2-3年）就需要对你掌握的知识进行重新梳理，这是一个痛苦的“破而后立”的过程，但完成它，你就会看到一片新天地展现在你面前。这也就是写出本文的原因。2 资料，知识，智慧，思想，精神在着手梳理之前，还是要搞清楚一些基本概念。前面所谓的”知识“其实并不确切，那么，到底什么是知识，以及知识与其他的概念有什么关系呢？正如每个孩子都珍藏过小石头，每个IT人士都收集资料。我手头也有多年积累的大量文档。但这些文档仅仅是资料，时效性很低（尽管我在技术上不是很追求时髦），可能1-2年的时间就变成了硬盘上的垃圾，需要经常清理。要让这些资料发挥作用，就必需及时进行归纳、整理、沉淀，将其中有价值的内容纳入自己已有的知识体系。只有这样，资料才能转化为知识，并在需要的时候发挥作用。世上从来不缺少这种人，才高八斗学富五车却四体不勤五谷不分，此谓“懒”；满腹经纶却不通世故，谓之“呆”。 “懒”者，懒得去解决问题。毕竟学习知识是一种输入，解决问题是一种输出，后者的难度更大，需要的思考更多，于是乎懒得去做。 ”呆“者，知识的奴隶，空有满腹学识却根本不知如何运用，知识成了死知识，而人成了书呆子。 究其根本，就是知识没有转化为“生产力”。如果能够运用知识解决问题，这就叫做智慧。知识之间有很多共通之处，有些人能够发现知识之间的规律，并运用这些规律产生出新的知识为别人所用，这叫做”有思想“。思想需要领悟，只靠学习是没有用的。要做到所有这一切，需要研究并务实，合作且独立，并经常自省；需要内心的强大，这叫做精神。精神才是一切行动的源动力。简言之：信息的管理产生知识知识的运用产生智慧知识的积累产生思想一切的根本在于精神3 知识的条理知识的条理可以有很多，但够用就好。过多的线索反而会让知识丛林变得扑朔迷离，难以形成全貌。对于IT人员来说，可能以下几方面的线索就够用了。31 业务领域如果你在从事企业级应用相关的工作，对于业务领域（Business Domain）的划分是非常重要的，这可以使你明确当前的主题能够解决企业哪方面的问题。业务领域的知识解决“是什么”的问题。根据不同的业务分析和表示方法论，有不同的描述方式，但大体来说总要包含以下几个部分：领域模型业务服务业务流程业务角色对于一些比较成熟的领域，会有相应的参考模型，如供应链的scor模型，研发领域的pace或ipd，项目管理的pmbok，软件工程的cmmi等。 这些模型都会包含上述的基本内容，而且适用范围比较广泛。对于业务领域的划分，可以参考企业管理中的层次及方面两个维度，如下表： 企业管理销售与市场生产财务人力资源IT决策层 管理层 *** 作层 随着对某个领域的不断深入，该领域会越来越细分，比如对于IT管理这个方面，可能会划分为：IT管理 决策层 企业架构 IT策略IT组织及治理策略IT规划管理层 IT资产管理IT绩效IT项目管理安全管理采购管理 *** 作层 应用管理IT基础设施管理32 行业划分有些知识可能是某个或某类行业专属的，并不适用于所有行业，所以还需要划分一个”行业“的维度。这个维度与业务领域进行正交。 行业划分不一定精确，完全可以按照你自己的知识结构进行划分。可以在一定程度上使用树。比如我自己的行业划分如下：IT服务 硬件维护和支持软件维护和支持咨询服务 管理咨询 IT咨询开发和集成 定制开发 应用集成应用部署IT外包服务 应用外包 平台外包基础设施外包金融行业 证券银行保险基金媒体行业 电视台网站电子商务 B2BB2CC2C支付服务电信行业政府行业 区域政府国家部委制造业零售业33 类别很多东西都可以成为知识，但知识确实有很多种。不同种类的知识，其适用范围也各不相同。 比如“产品生命周期管理”是制造业产品管理领域的知识，但是其对应的“生命周期理论”又是一种理论类的知识。 再比如敏捷开发、面向对象都属于方法论的范畴，而emacs是一种开发工具。对于IT人员，下面的类别都是比较常用的：理论方法论解决方案 技术解决方案业务解决方案行业解决方案技术应用开发技术网络技术工具模板 都涉及到标准规范，指导书，培训教材，模板，检查单这些核心内容，这相当独立来看是完整的一套体系。其中需要专门说明的是解决方案类。解决方案是对知识的一种运用，但针对运用的结果和经验进行总结，就会形成新的知识。 解决方案根据运用的范围不同，可以分为技术解决方案、业务解决方案和行业解决方案。显然，他们会分别知识类别中的技术、业务领域中的层次和方面、行业划分相交叉。34 掌握程度对于学习来说，认识到自己对于某项知识的掌握程度非常重要，可以使学习的目的性更强。一般我们喜欢用知道，了解，熟悉和精通来表示掌握的程度。知道 知道有这么一类知识，知道其定位及能够解决的问题，但是对细节不清楚。了解 掌握此类知识大体包含哪些部分的内容（即细分），在需要时可以通过参考资料进行使用。熟悉 掌握60%以上的要点，并具备实际解决问题的经验。精通 掌握80%以上的要点，具备多次运用的经验，能够指导别人如何学习或运用。4 知识地图前面介绍了对于IT人员比较实用的对知识进行条理化的一些维度，包括领域（层次+方面）、行业、类别、掌握程度等。 综合运用这些条理，对知识进行定位和标识，梳理知识之间的关系与关联，就能够使知识以有序的面貌呈现处理，极大提高知识的利用率。 这就是知识地图, Knowledge Map，简称K-Map41 知识地图的作用导航 对知识的导航是知识地图最根本的功能，通过知识地图能够通过多种方式和线索找到需要的知识。关联 知识之间存在各种关系，如上述每个维度内的层级关系，维度之间的正交关系和关联关系等等。知识之间的关联形成一个网状结构。盘点 构建了知识地图，也就有了关于知识的清册（Category)。可以随时盘点自己已经掌握了哪些知识，掌握到何种程度，以及还有哪些知识需要扩充。42 如何表述知识地图到这里，你可能已经迫不及待要建立自己的知识地图了。表述知识地图主要有两种方法：一种是显式表达，可以用文字，或图形化的工具（如xmind,visio等）专门进行描述。另一种是隐式表达，没有专门的知识地图说明，但是将知识地图运用在各种工具中，比如文件和目录结构，gmail，evernote，emacs org-mode, 以及blog中。5 小结本文从自身的经历出发，说明了个人知识管理的必要性。探讨知识和文档资料的区别与联系，以及如何对知识进行条理化。 最后引出了知识地图这一工具，描述了其作用以及如何使用知识地图。希望能够对读者构建自己的知识体系架构带来帮助。

从普遍角度上说，一个有效的项目管理要从几方面入手。

1 项目范围

明确定义好项目管理范围，才能有效配置相应资源。

2 项目计划

根据项目要求，制定切实可行的项目计划。国内大部分项目经理都是根据上级指示做事，没有仔细做过项目评估，这就导致在项目执行过程中，经常出现不可控因素，影响了项目的执行结果。

3 项目资源

包括设备，材料，资金，人力资源等。关键是资金和人力资源，一个是保持适当的现金流，一个是保证有足够的人去做该做的事。

4 风险预估

包括对用户及对自身评估两部分。对用户主要涉及其信用度，财务状况，技术能力/经验等方面；对自身主要包括足够的项目管理人员，技术人员配置是否足够，经验是否丰富，有否做过同类项目，用户的付款条件对项目管理造成的风险是否可控？

以上是针对工程类项目，针对软件开发项目，在项目范围/风险中，还需要特别关注用户对项目的具体及特殊要求。

背景由于最近几年公司业务的不断发展和壮大，业务部门对IT技术和自动化系统的依赖越来越大，他们需要IT来支持处理大量业务数据和交易。然而，由于公司缺少一支有组织且结构化的一线IT支持服务团队，雇员们在面对时而发生的IT故障和问题时变得越来越沮丧：他们不知道向谁寻求帮助，在四处求救时浪费了大量的宝贵时间；另外，对于那些重复发生的问题和服务故障，没有一个现成的经验和知识帮他们直接解决问题，使得IT服务人员陷入一遍遍解决同类问题的僵局。当他们处理外汇买卖业务或其他相关业务时，客户的需求和业务的特性使时间和准确率对他们来说至关重要。他们迫切需要一种最快，最准确的方法来协助完成所有交易。然而，他们却搞不清一旦发生技术故障，他们应该打电话找谁来寻求帮助。甚至即使打了电话，问题也不能得到很好解决，影响业务的进行。这直接导致了这些业务部门的IT最终用户产生如此错觉：IT服务与我们业务部门不是同路人，他并不是一个值得信任的，拥有共同业务目标的好的合作伙伴。这种对IT技术支持团队的错误认识，直接影响了各营业网点及分公司向客户提供服务的能力，降低了客户的满意度。业务需求与业务部门的误解形成鲜明对比的是，IT部副总裁感到自己身上的压力越来越大：一方面，在面对各业务部门的不理解和抱怨时，他和他的团队要负责向全北美洲的所有企业客户以及几百个分支机构提供IT支持服务；另一方面，为了提供更符合业务需求的IT服务，他还要向整个IT团队灌输一种以业务为中心的文化：即IT是为了业务服务，更好的服务于各种业务的需求。该公司的CIO认为，他的最终目的是建成一个提供IT服务的“一站式店铺”——以一种单点联系的方式解决所有与IT相关的问题。这一服务方式有以下几个方面的好处：·由于只有一个联系点，发生服务故障时，业务人员可以直接与IT技术服务人员联系，避免了不知找谁来解决问题的情况发生，从而缩短了“遗失时间”。·通过配置管理中的配置管理数据库，处于单一联系点的IT服务人员可以掌握所有配置向信息，使其可以更有效果且更有效率的使用各种配置项资源。·服务台人员对所有IT用户提交的服务请求，故障和问题等进行记录，这些记录提供了一种发现IT基础设施问题的机制。·为IT管理提供一种可量化的评价机制来评估业务·位于服务台的服务人员可直接接触用户，解决用户的问题。他们的服务以及对用户的态度将直接决定了业务用户对IT的认识，有效的IT服务台将彻底促进IT与业务的沟通，改善业务对IT的认识·当面对同时发生的大量突发事件时，服务台提供了一种结构化的流程来安排工作优先级，影响度大且紧急的问题优先解决；同时，服务台选择最快的方式来恢复发生故障的IT服务。

以上就是关于互联网IT团队如何开展绩效管理全部的内容，包括:互联网IT团队如何开展绩效管理、如何保证it业务管理办法完全彻底的得到执行和实施、IT人员如何管理知识等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！