怎样管理软件开发团队

要点三人力资源计划

角色和职责的分配 ：

测试的角色（谁）和职责（做什么）必须落实到合适测试的相关人员。角色和职责可能会随着时间而改变，大多数角色和职责将分配给积极参与测试工作的有关人员，如测试经理、测试管理小组的其他成员以及为测试做出贡献的个人。要找出完成测试所需要的角色和职责时，必须考虑到以下几点∶

（1）角色∶某人负责测试某部分工作的标识，如测试经理、测试成员、测试设计人员。角色的明确性如职权、职责和边界对于测试成功至关重要。

（2）职权∶使用测试资源、做出决策和批准的权利，如实施方法的选择、质量接受水平以及如何对测试进行中的偏差做出反应。当团队成员的权利和职责匹配时，他们能做得最好。

（3）职责∶为了完成测试，要求测试团队成员执行的工作。

（4）能力∶完成测试活动所需要的技能。如果测试团队成员不具备完成测试活动所必须的能力，那么绩效将受影响。当发现岗位职责与能力之间存在某种程度的不匹配时就必须采取提前的应对措施如培训、招聘人员或变更测试范围。

测试的组织结构图 ：

可使用多种形式描述测试的角色和职责，最常用的有三种∶层次结构图、责任分配矩阵和文本格式。除此之外，在一些分计划（如风险、质量和沟通计划）中也可以列出某些测试的工作分配。无论采用任何形式，都要确保每一个工作包只有一个明确的责任人，而且每一个测试团队成员都非常清楚自己的角色和职责。

责任分配矩阵

反映团队成员个人与其承担的工作之间联系的方法有多种，而责任分配矩（PAM）是最直观的方法。在大型测试中，RAM 可以分成多个层级。如高层级的RAM可以界定团队中的哪个小组负责工作分解结构图中的哪一部分工作;而底层级的RAM被用来在小组内为具体活动分配角色、职责和授权层次。矩阵格式，又称表格，可以使每个成员看到与自己相关的所有活动以及某个活动相关的所有成员。责任分配矩阵有时在矩阵中以字母引用。

如表1-1中所示的 RAM 可以被称为 RACI（Responsible 负责 Accountable参与 Consult征求意见 Inform通知）（表1-2），左边一列代表的是各项活动，右边各列的第一行代表的是人员（也可以是小组或部门）

③文本格式，见图3-2。团队成员职责需要详细描述时，可以用文字形式表示。通常提供如下信息∶职责、权利、能力和资格。这些文档有各种称谓如职位描述表、角色、职责、权利表等等。这些描述和表格在测试的整个执行过程中会根据

验教训进行更新，以便为将来的测试提供更好的参考。

人员配备管理计划 ：

人员配备管理计划是测试管理计划的一个分计划，描述的是何时以及怎样满足人力源需求。根据测试的需要，它可以是正式的或者非正式的，既可以是非常详细的。也可以是比较概略的。为了指导正在进行的团队成员招聘和团队建设活动，人员配备管理计划随着测试的持续进行而经常更新。人员配备管理计划中的信息随着测试应用领域和规模的不同而不同，它应该包括以下基本内容∶

（1）组建测试团队。在计划招聘所需的测试成员时，测试管理团队必须回答很多问题。如所需的人员来自组织内部还是外部是否有足够多的人员拥有所需的能力或者是仍需培训测试成员需要在固定地点工作或是远程分散办公测试所需不同层次的专业技能成本如何人力资源部门能够提供给测试管理团队什么样的支持

（2）时间表。人员配备管理计划说明了测试团队成员（个人或者集体）的时间安排，以及相关的招募活动何时开始。

（3）人力资源释放安排。事先确定测试团队成员遣散的时间和方法，对测试和组员都是有好处的。当已经完成任务的人员在适当的时候离开测试时，我们就不用再继续为其付人工费，从而降低测试的成本。提前将这些人员平稳地转移到新测试上也可以提高士气

（4）培训需求。如果计划分配到测试中的人员不具备必须的技能，就要制订出一个培训计划。这个计划可以包含如何协助团队成员获得对测试有益的证书，从而促进测试的执行。培训计划是测试计划的一个分计划。

（5）表彰彭和奖励。明确的奖励标准和完善的奖惩系统将有助于推广和加强期望的行为。要想有效，表彰和奖励必须基于个人负责的活动和绩效。如某人可以为达到成本目标而受到奖励，但同时他应该对费用的支出决策有一定程度的控制权。在编制人力资源计划时，表彰及奖励计划是他的一部分。表彰和奖励的实施是团队建设过程的一部分，最后要确保兑现奖赏。

（6）遵守的规定。人员配备管理计划包括一些策略，以确保遵从相关的政府法律如劳动法、规章、制度、劳动合同或其他的与人力资源相关的法律法规和政策。

（7）安全性。针对安全隐患，为确保测试团队成员而制定的政策和规定，应该纳入人员管理计划和风险清单内

团队建设的最大病症：精神离职

项目管理说到底，核心是对人的管理。在张兴接手研发团队后，遇到的第一个难题就是团队成员常常是出人不出力。现在回忆起这些情况，张兴还感到后怕。这种情况的出现往往意味着在团队建设中隐藏着危险信号，并蒙蔽了团队经理的眼睛。如果不引起重视，团队建设将会前功尽弃。

让张兴非常苦恼的出人不出力，就是团队成员的精神离职，而这在团队中是普遍存在的。精神离职的特征表现为：工作不在状态，对工作不够认真，团队内部不愿意协作，行动较为迟缓，个人能力在工作中发挥不到30％，基本上是在无所事事的状态下结束一天的工作。

精神离职产生的原因大多是个人目标与团队愿景不一致产生的，也有工作压力、情绪等方面原因。正所谓百姓百心，在一个团队里大家由于心态、观念、能力的不一致使到很多研发工作进展缓慢。项目经理也往往不知道研发人员究竟是不会做还是不愿做，还是由于资源缺乏而不能做，从而很难让员工凝成一股绳高效地完成研发目标。针对精神离职者有效方法是：多沟通，用团队精神与团队愿景来提升工作状态，用激励手段提升工作热情。具体做法可以是安排假期，让精神离职者冷静思考，调整状态，然后根据实际情况考虑团队中是否会重新接纳。

高效软件开发团队的特征

高效的软件开发团队是建立在合理的开发流程及团队成员密切的合作的基础之上的，成员共同的迎接挑战、有效的计划、协调和管理各自的工作以至完成明确的目标，高效的开发团队具有如下特征：

1、 具有明确且有挑战性的共同目标 一个具有明确的而且有挑战性目标的团队比目标不明确或不具有很大的挑战性目标的团队效率高得多，通常技术人员往往会因为完成了某个明确的任务，而且这个任务的完成具有挑战性的意义而感到自豪，反过来团队成员为了获取这种自豪的感觉而更加积极的工作从而带来团队开发的高效率，如作为系统设计人员很清楚的知道在什么时候要做到什么，什么时候开始做，什么时候必须完成，为了完成工作必须面临哪些挑战，怎么解决这些困难等为设计出一个高质量的软件项目提供了重要保证，而模模糊糊的去设计一个系统或模模糊糊的就去编写代码是非常危险的，而且会为此付出高昂代价，因此高效的软件开发团队具有挑战性的共同目标。

2、 团队具有很强的凝聚力 在一个高效的软件开发团队中，成员们凝聚为一个整体共同进行工作，他们是相互支持、互相交流、互相尊重的，而不是相互推卸责任、保守、相互指责的，在一些散乱的开发团队中往往存在这样的问题，一些程序员是比较保守的，明明知道另外的模块中需要用到一段与自己已经编写完成但有些难度的程序代码，他也不愿拿出来给其它程序员共享，不愿与系统设计人员交流，这样给项目的进度造成了些不可度量的因素。

3、 具有融洽的交流环境 在一个开发团队中，每个人行使自己的职责，如需求分析人员制定需求规格说明、系统设计人员做系统概要设计和详细设计、项目经理配置项目开发环境并且制定项目计划等，但每个人的工作不可能做到完美的，如系统概要设计的文档可能有个别地方词不达意，做详细设计的时候就可能会造成误解，项目经理制定计划时可能忽略了某种风险的存在而造成执行者过于紧张的压力等等情况都需要大家通过交流、反馈的手段然后协商解决的，因此高效的软件开发团队是具有融洽的交流环境的，而不是那种简单的命令执行式的。

4、 具有共同的工作规范和框架 高效软件开发团队具有规范性及共同框架的工作，对于项目管理具有规范的项目开发计划，对于分析设计具有规范和统一框架的文档及审评标准，对于代码具有程序规范条例，对于测试有规范且可推理的测试计划及测试报告等等。并且所有成员都明白自己的职责，知道必须完成什么计划？由谁来完成？什么时候开始？什么时候结束？按什么顺序？等，总之一个高效的开发团队无论是工作内容还是工作流程都具有不同程度的规范性和标准风格的框架。

5、 采用合理的开发过程 软件的开发不同于一般商品的研发和生产，开发过程中会面临着各种难以预测的风险，比如需求的变化、人员的异动、技术的瓶颈、同行的竞争等，高效的软件开发团队往往是采用了合理的开发过程去控制开发过程中的风险、提高软件的质量、降低开发费用，这样的团队会根据自身的必要程度决定要执行哪些工作？如配置管理、资源管理、版本控制、代码控制等，团队还合理的分划并定义开发过程的里程碑，决定每项活动内容的底线和审评标准，决定各项活动的先后关系或迭代的关系等。总之高效的软件开发团队的开发过程的原则是高效率、高质量、低成本。

当然，你会不服气，说自己已经研究过这些资料，并且转化成了自己的知识，而知识是无价的。 可是残酷的现实告诉你，知识既不会带来“颜如玉”，也不会带来“黄金屋”。自认为饱学之士的你，为何反而不被重用？不被运用的知识是死知识，你可能成为别人的“百科全书”/“智力提款机”，但偏偏你自己不知道该做些什么。 而且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 小结本文从自身的经历出发，说明了个人知识管理的必要性。探讨知识和文档资料的区别与联系，以及如何对知识进行条理化。 最后引出了知识地图这一工具，描述了其作用以及如何使用知识地图。希望能够对读者构建自己的知识体系架构带来帮助。

近几年，大数据、云计算等高科技技术在中国的快速发展，为了健康长远的发展和提升市场竞争力，越来越多的企业需要开发属于自己的软件产品。

有些企业会选择自己招人组建it部门做软件开发，但要面临招聘难和成本控制问题，在人力成本逐年提升的环境下，组建一个完整的IT团队需要巨大的资金投入，项目结束后的人力闲置更是浪费成本。有的企业会求助于专业第三方it外包服务商来，或选择it项目外包，或选择it人力外包。

而由于it项目外包的不透明性和大量的沟通的不到位，一些不愉快的事情时有发生，不少大中型的企业会更倾向于使用it人力外包，像华为、腾讯、阿里巴巴等这些大企业就是通过it人力外包来引进软件人才的。

企业使用it人力外包可以根据项目团队的实际用人需求，灵活安排人力进行补充，并可以从简单的代码编写及测试工作中释放出自己人的时间，投入在关键的项目任务上。那么it人力外包流程是怎样的，分为那几步呢：

1、用人企业提出用人需求：如人数，岗位职责，任职条件等。

2、双方签订框架协议：用人企业与it人力外包公司签订服务框架协议。

3、推荐候选人面试：it人力外包公司推荐候选人到用人企业面试。

4、新人签订劳动合同：面试通过的候选人如果是新员工，将与it人力外包公司签订劳动合同，如果是其他项目调过来的，面试通过后则不用签订合同。

5、提供驻场开发技术服务：面试通过的软件开发人员到客户指定现场提供开发服务，it人力外包公司定期开展外派员工关怀等工作。

6、按月支付服务费：用人企业按月支付服务费直至人才外派服务结束。

it人力外包除了可以帮助企业降低经济成本，在企业的资源配置、体系建立、业务布局、风险规避等各方面都将成为强有力的支持。目前it人才外包已成为很多企业用于提高自身核心竞争力、降低运营成本等的战略性手段。

在交流的过程当中，刻意的统一了语言，会使得我们尽管是一个远程团队，但是在交流的时候，能够很清楚的知道我们在对信息架构在哪一层进行反馈。这不但使得业务方可以反馈技术方，其实技术方也在引导业务方。语言的影响是双向的。

在技术领域里，我们也选择了隔离性更好的技术架构，使得MVP的代码不会变成我们演进道路上必须长期背负的负累。而之所以在一篇聊“语言”的文章里提技术架构，是因为我们认为真正的架构不是纸上的，也不是代码里的，而是每个团队成员心里的架构。实施一个架构必然也是要进行大量沟通，也需要统一语言。

而在交流业务的时候，我们刻意的划分了各种不同的子领域，又在每个领域当中统一了名词。统一名词还是比较简单的，最难的是划分领域，我们为此投入了大量的工作，也犯了一些错误，但这些付出是值得的，这之后，我们的沟通变得非常流畅。

IT行业的人员流动率接近25%，这意味着每年技术团队中至少有1/4的新人加入。即便想尽方法让的团队保持稳定，随着敏捷和精益创业的相关思想慢慢成为我们的工作常识，每个项目存在的时间都不会太长，这使得IT团队经常性的重组，有时是团队被打散，有时是同一个系统从一个团队交给了另一个团队。如果缺乏一种有效的反馈机制，那么无论是人员流动还是组织重组，所造成的切换成本都是一个很大的。尽管这个切换成本无法消除，但是尽量减少切换成本是我们每个专业人员应该追求的，尤其是团队中的技术领导者。

技术领导者重音在“领导”，而不在“技术”。尤其在今天，技术就是业务。优秀的技术领导者更不能把自己变成一个救火队员，只是被动的响应，尽管救火队员常常因为很容易被人看到而获得一些关注和赞扬，但在中国的文化里，我们都知道还有更高一层的境界，这个境界存在于很多典故中，比如上医治未病，善战者无赫赫之功。同理，软件开发领域的技术领导者们也应该努力使大多数问题发生的基础消灭于无形，这就需要我们走出舒适区，深入到软件开发的第一现场，进行现场管理。

技术上： 作为IT外包人员，首先要了解知道的要多，一个人能顶好几个人用！知识不能只局限于某一方面！

个人素质上：做外包，就是要有一种吃苦的精神，攀比心不能强，要有平常心！

IT外包人员必须严格遵守技术与流程规范、资产管理等规定。

在项目初期因企业在IT管理与规划不明确，IT外包人员应主动与客户进行主动沟通，积极配合客户的IT需求进行调整与改进计划。

IT外包人员应积极推动客户数据安全管理的认知与保障措施，保证对重要数据至少有最小化安全保障。

若在计划内无法完成进度，IT外包人员需提供分析报告，并在会议上汇报原因，提出解决办法。如需调整计划，需与项目管理人员协调，对重大调整需汇报主管。

以上就是关于IT产品经理高级教程-团队管理能力3全部的内容，包括:IT产品经理高级教程-团队管理能力3、如何管理it团队建设、怎样管理软件开发团队等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！