机房管理、软件研发

第一篇：机房管理、软件研发

机房管理、软件研发工作总结

一年来，本人认真做好本职的工作，不断学习新的技术，扩展了自己的知识面，并通过项目实践，提高了自身的动手操作能力。下面我将从思想、工作和学习三大方面总结一下2011年本人所取得的成绩、经验，以及存在的不足。

在思想上，本人始终坚持以一个党员的标准来严格要求自己，加强理论学习，不断提高自身的理论水平和政治觉悟，始终以“爱岗敬业，为人师表，严谨笃学，与时俱进”来督促自己的言行，以“以德为行，以学为上”的教育思想作为自己的行为准则，努力把“全心全意为人民服务”的宗旨体现在平常的工作中。

在工作上，本人时刻牢记自己是一名光荣的共产党员，能够爱岗敬业，不怕辛苦，以高度热情和责任感做好本职工作。作为一名实验室管理员，本人认真做好“微机七室”的机房管理工作，同时协助其他实验室管理员进行机房电脑的维护和升级工作。而作为我校数字化校园建设的一员，本人不断提高自己的理论水平，以实践项目来巩固自己的理论知识，努力为完善我校数字化建设而努力。在此期间，我参与了以下实践项目：

① 完善和维护“教工信息平台”，增加“学校实验室项目进度管理系统”

② 完善和维护“网络教学平台”、“助学系统”和“公文系统”；

③ 开发和维护“研究生处网站”、“学院关工委网站”；

④ 参与开发“学校资源平台”、“省中职教学资源平台”、“省中职信息化大赛网站”； ⑤ 为配合学校参与省质量工程检查，开发了“省质量工程项目申报展示平台”网站，并创建“会计学”、“旅游管理与服务教育”、“工商管理”等校级特色名牌专业网站； ⑥ 管理“中职云平台”上的虚拟主机，并在平台上部署各类应用及为各中职院校开设虚拟机。同时为了方便管理各虚拟机信息，开发了“中职信息云在线体验平台”；

⑦ 维护学校网站服务器，解决学校和各院系网站、各信息系统运行不正常的各类问题。在学习上，由于本人的主要工作是软件研发，因此在这一年中，我不断学习各种编程技术，如Struts，Spring，Hibernate等框架，并对之前搭建的开发框架进行了重构，以提高开发的效率。同时，不断学习其它新兴的技术，并将该技术运用到工作中，以提高工作效率。以上是我这一年的工作总结，虽然在思想、工作和学习上都取得了很大的进步，但也存在一些不足，如政治理论水平的欠缺；工作经验不足；网络水平不高，这些不足都是在新的一年中需要弥补回来的，我也相信，经过我的努力，一定会有所突破，有所成功的。

2012年即将来临，我为自己制定了以下的工作计划：

① 继续完善和维护现有的系统；

② 学习Android开发技术，尝试开发网络教学平台和中职教学资源平台客户端软件； ③ 学习AIX小型机和Oracle数据库，尝试将网络教学平台移植到Oracle数据库，并

部署到小型机上；

④ 在巩固现有的技术上学习一些新的技术，提高自身的专业水平。

第二篇：软件研发岗位职责

根据网上的一些资料以及公司实际的情况而制定：

1、负责部门人员的引进及本部门人员的绩效考评管理工作；

2、制订部门内部的改造计划，组织审定部门各项技术标准，编制、完善软件开发流程，并组织部门人员进行研究讨论；

3、抓好本部门项目组总结分析报告工作，定期进行项目分析、总结经验、找出存在的问题，提出改进工作的意见和建议，为公司领导决策提供专题分析报告或综合分析资料。

4、组织本部门人员的培训、技术指导以及技术难点突破工作；

5、配合市场部门开展工作，向市场部门提供必要的技术支持；

6、在需求调研中，配合项目组长进行需求调研工作，并对需求调研报告进行审核评定；

7、同项目组长组织设计开发工作，控制开发进度；

8、负责组织软件项目的测试工作，对软件产品的质量负责；

9、对项目组文档进行质量、数量和时间控制，并组织召开评审会；

10、对部门下面人员的日报、周报检查，了解每一个开发人员的工作情况以及工作状态；

11、规范部门内部管理，提高员工整体技术水平，把握技术发展方向，使得技术发展方向与主流技术合拍；

12、热情接待客户，并妥善处理客户的抱怨、投诉以及突发性事件；

13、视下属为兄弟姐妹，在工作生活中给予最多的关爱。

第三篇：转正申请(软件研发)

尊敬的领导：

我于2010 年5月18日成为公司的试用员工，到今天3个月试用期已满，根据公司的规章制度，现申请转为公司正式员工。

初来公司，曾经很担心不知该怎么与人共处，该如何做好工作；但是公司宽松融洽的工作氛围、团结向上的企业文化，让我很快融入到了工作当中。

在此之前从未接触到有关高速公路的软件开发，还担心会拖延项目时间，给大家增加麻烦。经过这一段时间，发现在组长及同事的带领之下，能快速跟上公司的节奏。

本部门的工作中，我一直严格要求自己，认真及时做好组长布置的每一项任务，同时主动为组长分忧；专业和非专业上不懂的问题虚心向同事学习请教，不断提高充实自己，希望能尽早独当一面，为公司做出更大的贡献。当然，刚入公司，难免出现一些小差小错需领导指正；但前事之鉴，后事之师，这些经历也让我不断成熟，在处理各种问题时考虑得更全面，杜绝类似失误的发生。在此，我要特地感谢部门的领导和同事对我的入职指引和帮助，感谢他们对我工作中出现的失误的提醒和指正。

经过这三个月，我现在已经能够独立处理项目中出现的问题，整理项目内容的详细设计文档，进行项目BUG的修改，与数据中心的业务人员讨论业务，采集需求变化中产生的新的业务。当然我还有很多不足，处理问题的经验方面有待提高，团队协作能力也需要进一步增强，需要不断继续学习以提高自己业务能力。

这半年来我学到了很多，感悟了很多；看到公司的迅速发展，我深深地感到骄傲和自豪，也更加迫切的希望以一名正式员工的身份进入开发团队，实现自己的奋斗目标，体现自己的人生价值，和公司一起成长。在此我提出转正申请，恳请领导给我继续锻炼自己、实现理想的机会。我会用谦虚的态度和饱满的热情做好我的本职工作，为公司创造价值，同公司一起展望美好的未来！

2010年8月25日申请人：xxx

第四篇：研发经费管理办法(软件)

研发资金管理办法

1.目的

为切实加强公司研发投入的财务管理，确保项目资金的合理使用，充分发挥财务核算、监督管理的职能作用，确保项目研发专项资金的安全、有效，提高资金效率和研发效率，根据公司财务制度，结合公司项目管理的特点，制定本制度。2.实施范围及执行

2.1 本制度规定了公司技术研发部(中心)开展项目研发的资金使用管理要求。2.2 本制度规定了专项研发经费的使用范围。2.3 本制度自总经理签发批准之日起正式施行。3.原则

3.1 专款专用、逐级审批、逐项使用的原则； 3.2 勤俭办事、精细筹算、力求节约的原则；

3.3 保证经费申请、使用畅通，为产品研发提供可靠的资金保障为原则。4.相关部门职责

建立和健全科研经费管理责任制和监管机制，明确相关职能部门和项目负责人的职责和权限，加强对研发经费的监督和检查。

4.1 公司主管副总经理：负责研发项目经费预算的审核、划拨和有关支出的审批，负责科研经费使用的监督和检查工作。

4.2 研发中心：项目负责人负责编制研发项目经费的预算和决算，严格按照项目任务书或合同书规定的开支范围和标准使用项目经费，自觉控制经费的各项支出，对研发经费使用的真实性、有效性承担责任。

4.3 财务部：负责研发经费的财务管理和会计核算，指导项目负责人编制项目经费预算，审核项目经费决算，监督和指导项目负责人按照项目经费管理规定使用研发经费。5.项目研发经费范筹：

项目研发经费是指项目研究与开发过程中所发生的直接费用和间接费用。一般包括人员费、仪器设备费、能源材料费、试验外协费、差旅费、会议费和其他相关费用。

5.1 设备费：是指在项目研发过程中购置或试制专用仪器设备，对现有仪器设备进行升级改造，以及租赁外单位仪器设备而发生的费用。

5.2 材料费：是指在项目研发过程中消耗的各种原材料、辅助材料以及低值易耗品的采购及运输、装卸、整理等费用。

5.3 检测试验费：是指在项目研发过程中支付给外单位的检测、试验、测试等费用。5.4 燃料动力费：是指在项目研发过程中相关大型仪器设备、专用科学装置等运行发生的可以单独计量的水、电、气、燃料消耗费用等。

5.5 差旅费：是指在项目研发过程中开展科学实验（试验）、科学考察、业务调研、学术交流等所发生的外埠差旅费、市内交通费用等。差旅费的开支标准应当按照国家有关规定执行。

5.6 会议费：是指在项目研发过程中为组织开展学术研讨、咨询、检查、项目验收或鉴定等活动而发生的会议费用。举办会议前，须向主管副总提出会议申请并编制会议用款计划，财务部按主管副总审批的限额报销会议费。

5.7 合作、协作研究与交流费：是指在项目研究开发过程中与国际、国内科研机构合作、协作研究支付给合作、协作单位的费用，项目研究人员出国及外国专家来公司工作的费用。

5.8 出版/文献/信息传播/知识产权事务费：是指在项目研究开发过程中，需要支付的出版费、资料费、专用软件购买费、文献检索费、专业通信网络费、专利申请及其他知识产权事务等费用。

5.9 劳务费：是指在项目研究开发过程中支付给项目组成员、没有工资性收入的相关人员和项目组临时聘用人员等的劳务性费用。明确规定在编人员不得列支人员费的项目，按规定执行。

5.10 专家咨询费：是指在项目研究开发过程中支付给临时聘请的咨询专家的费用。5.11 业务招待费：是指在项目研究开发过程中发生的一定标准的业务招待费用。5.12 车辆使用费：是指项目研究过程中使用自备车辆所发生的费用。汽油费、过路费、停车费可在科研经费中支出。

5.13 其它费用：指与项目研究直接有关的其他支出。6.研发项目经费的审批管理

6.1 研发项目经费一经公司批准，必须专款专用，任何部门不得任意截留、挪用或挤占他用。

6.2 产品研发经费经公司批准后，由公司财务部门按单项预算拨给项目承担部门，由项目组按项目研发计划支配使用，不得挪作它用。财务部门单列帐户，进行核算监督。

6.3 计划内的支出，由项目负责人审签，可根据研发工作进展和器材供应情况调整用款计划。但调整过的用款，须经所在部门领导审批。如改变用途，须报请总经理审批。

6.4 项目承担部门申请现金开支，按公司财务制度审批程序，并按项目计划和实施阶段分期申请，由各项目负责人和技术副总逐级审批。

6.5 使用研发经费的项目承担部门，须在研发中心领导和财务、技术主管领导的监督管理下，循序投入，合理开支。财务部门按设置的独立账户进行核算，年终按规定报送决算，并于项目结束后按批复的决算核销经费。7.研发阶段工作报告

获得项目拨款后，须定期向公司提交研发工作报告。

7.1 研发进度正常的，按《经费开支计划》中相应的用款额拨款；

7.2 研发进度不正常或经费使用不当时，财务部将减少或暂停拨款，以至撤消经费投入；

7.3 不按时提交研发工作进展情况报告的，财务有权暂不拨款。8.研发项目经费的结算管理

8.1 研发项目经费的使用、管理，以方便科研，有利于发挥研发人员的积极性为前提。研发项目因故中止或撤销，项目负责人必须向研发中心领导和主管技术副总提出《研发项目中止报告》，并及时清理帐目，将余款和已购器材处理收入，悉数交回公司财务部。经公司财务部审查后核销。

8.2 研发项目计划实施结束后，项目承担部门应配合财务抓紧清理收支帐目，在一个月内编制完成《研发项目经费决算表》，连同其它总结材料，一式两份报公司财务部，经审查签署意见后，批复所在部门核销。已拨经费结余，退回财务后用。

8.3 研发中心对项目经费的使用情况，应接受公司财务部的定期审计或专项审计。编报《研发项目经费决算表》，应经财务部签署审计意见。

8.4 项目负责人应按项目计划书规定的时间及时结题，原则上应在研发项目结束或

通过验收后六个月内办理结帐手续。对无正当理由逾期不办理结帐手续的，财务部有权暂时冻结项目经费的使用，待结帐后才能继续使用。9.监督与违纪处理

8.1.研发中心应加强经费使用的管理和监督。总经办应进行抽查，项目负责人和所在部门应积极配合，如实反映情况。

8.2.研发项目组成员应严格遵守财务制度和本办法规定，如有弄虚作假、截留挪用或挤占经费等违纪行为，财务部有权抵制和越级反映，并视情节轻重，采取通报批评、撤销资格、赔偿损失、罚款等处理，严重者追究法律责任。

总经理批准： 发布实施日期：

第五篇：几个软件研发管理的问题

几个软件研发团队管理的小问题

最近在与一位总经理交流的时候，他谈到他们公司的软件研发管理，说：“我们公司最大的问题是项目不能按时完成，总要一拖再拖。”他问我有什么办法能改变这个境况。从这样一个问题开始，在随后的交谈中，又引出他一连串在软件研发管理中的遇到的问题，包括：

.现有代码质量不高，新来的开发人员接手时宁愿重写，也不愿意看别人留下的“烂”代码，怎么办？

.重构会造成回退，怎样避免？

.有些开发人员水平相对不高，如何保证他们的代码质量？

.软件研发到底需不需要文档？

.要求提交代码前做Code Review，而开发人员不做，或敷衍了事，怎么办？.当有开发人员在开发过程中遇到难题，工作无法继续，因而拖延进度，怎么解决？.如何提高开发人员的主观能动性？

其实，每个软件研发团队的管理者都面临着或曾经面临过这些问题，也都有着自己的管理“套路”来应对这些问题。我把我的“套路”再此絮叨絮叨。

1.项目不能按时完成，总要一拖再拖，怎么改变？

找解决办法前，当然要先知道问题为什么会出现。这位总经理说：“总会不断地有需求要改变和新需求提出来，使原来的开发计划不得不延长。”原来如此。知道根源，当然解决办法也就有了，那就是“敏捷”。敏捷开发因其迭代（Iterative）和增量（Incremental）的思想与实践，正好适合“需求经常变化和增加”的项目和产品。在我讲述了敏捷的一些概念，特别是Scrum的框架后，总经理也表示了对“敏捷”的认同。

其实仔细想想，这里面还有一个非常普遍的问题。对于产品的交付时间或项目的完成时间，往往由高级管理层根据市场情况决策和确定。在很多软件企业中，这些决策者在决策时往往忽略了一个重要的参数，那就是团队的生产率（Velocity）。生产率需要量化，而不是“拍脑门子”感觉出来的。敏捷开发中有关于如何估算生产率的方法。所以使用敏捷，在估算产品交付时间或项目完成时间时，是相对较准确的。Scrum创始人之一的Jeff Sutherland说，他在一个风险投资团队做敏捷教练时，团队中的资深合伙人会向所有的待投资企业问同一个问题：“你们是否清楚团队的生产率？”而这些企业都很难做出明确的答复。软件企业要想给产品定一个较实际的交付日期，就首先要弄清楚自己的软件生产率。

2.现有代码质量不高，新来的开发人员接手时宁愿重写，也不愿意看别人留下的“烂”代码，怎么办？

这可能是很多软件开发工程师都有过的体验，在接手别人的代码时，看不懂、无法加新功能，读代码读的头疼。这说明什么？排除接手人个人水平的因素，这说明旧代码可读

性、可扩展性比较差。怎么办？这时，也许重构是一种两全其美的办法。接手人重构代码，既能改善旧代码的可读性和可扩展性，又不至于因重写代码带来的时间上的风险。从接手人心理的角度看，重构还有一个好的副作用，就是代码重构之后，接手人觉得那些原来的“烂”代码被修改成为自己引以自豪的新成就。《Scrum敏捷软件开发》的作者Mike Cohn写到过：“我的女儿们画了一幅特别令人赞叹的杰作后，她们会将它从学校带回家，并想把它展示在一个明显的位置，也就是冰箱上面。有一天，在工作中，我用C++代码实现了某个特别有用的策略模式的程序。因为我认定冰箱门适合展示我们引以为豪的任何东西，所以我就将它放上去了。如果我们一直对自己工作的质量特别自豪，可以骄傲地将它和孩子的艺术品一样展示在冰箱上，那不是很好吗？”所以这个积极的促进作用，将使得接手人感觉修改的代码是自己的了，而且期望能够找到更多的可以重构的东西。

3.重构会造成回退，怎样避免？

重构确实很容易造成回退（Regression）。这时，重构会起到与其初衷相反的作用。所以我们应该尽可能多地增加单元测试。有些老产品，旧代码，可能没有或者没有那么多的单元测试。但我们至少要在重构前，增加对要重构部分代码的单元测试。基于重构目的的单元测试，应该遵循以下的原则（见《重构》第4章：构筑测试体系）：

-编写未臻完善的测试并实际运行，好过对完美测试的无尽等待。测试应该是一种风险驱动行为，所以不要去测试那些仅仅读写一个值域的访问函数，应为它们太简单了，不大可能出错。

-考虑可能出错的边界条件，把测试火力集中在哪儿。扮演“程序公敌”，纵容你心智中比较促狭的那一部分，积极思考如何破坏代码。

-当事情被公认应该会出错时，别忘了检查是否有异常如期被抛出。

-不要因为“测试无法捕捉所有Bug”，就不撰写测试代码，因为测试的确可以捕捉到大多数Bug。

-“花合理时间抓出大多数Bug”要好过“穷尽一生抓出所有Bug”。因为当测试数量达到一定程度之后，测试效益就会呈现递减态势，而非持续递增。

说到《重构》这本书，其实在每个重构方法中都有“作法（Mechanics）”一段，在重构的实践中按照上面所述的步骤进行是比较稳妥的，同时也能避免很多不经意间制造的回退出现。

4.要求提交代码前做Code Review，而开发人员不做，或敷衍了事，怎么办？ 如果每个开发人员都是积极主动的，Code Review的作用能落到实处。但如果不是呢？团队管理者需要一些手段促使其有效地进行Code Review。首先，我们采用的Code Review有2种形式，一是Over-the-shoulder，也就是2个人座在一起，一个人讲，另一个人审查。二是用工具Code Collaborator来进行。无论哪种形式，在提交代码时，必须注明关于审查的信息，比如：审查者（Reviewer）的名字或审查号（Review ID，Code Collaborator自动生成），每天由一名专职人员来检查Checklist中的每一条，看是否有人漏写这些信息，如果发现会提醒提交的人补上。另外，某段提交的代码出问题，提交者和审查者都要一起来解决出现的问题，以最大限度避免审查过程敷衍了事。

博主Inovy在某个评论说的很形象：“木（没）有赏罚的制度，就是带到厕所的报纸，看完就可以用来擦屁股了。”没有奖惩制度作保证，当然上面的要求没有什么效力。所以，当有人经常不审查就提交，或审查时不负责任，它的绩效评定就会因此低一点，而绩效的评分是跟每年工资涨落挂钩的。说白了，可能某个人会因为多次被查出没有做Code Review就提交代码，而到年底加薪时比别人少涨500块钱。

5.软件研发到底需不需要文档？

软件研发需要文档的起原可能有2种，一是比较原始的，需要文档是为了当开发人员离职后，企业需要接手的人能根据文档了解他所接手的代码或模块的设计。二是较高层次的，企业遵从ISO9001质量管理体系或CMMI。

对于第一种，根源可能来自于两个方面：

-原开发人员设计编码水平不高，其代码可读性较差。

-设计思想和代码只有一个人了解，此人一旦离职，无人知道其细节。

在编码前写一些简单的设计文档，有助于理清思路，尤其是辅以一些UML图，在交流时也是有好处的。但同时，我们也应该提高开发人员的编码水平增加其代码的可读性，比如增强其变量命名的可读性、用一些被大家所了解的设计模式来替代按自己某些独特思路编写的代码、增加和改进注释等等，以减少不必要的文档。另外推行代码的集体所有权（Collective Ownership），避免某些代码只被一个人了解，这样可以减少以此为目的而编写的文档。

对于第二种，情况有些复杂。接触过敏捷开发的人都知道《敏捷宣言》中的“可以工作的软件胜于面面俱到的文档”。接触过CMMI开发或者ISO9001质量管理体系的人知道它们对文档的要求是多么的高。它们看起来水火不相容。但是，它们的宗旨是一致的，即：构建高质量的产品。

对于敏捷，使用手写用户故事来记录需求和优先级的方法，以及在白板上写画的非正式设计，是不能通过ISO9001的审核的，但当把它们复印、拍照、增加序号、保存后，可以通过审核。每次都是成功的Daily Build和Auto Test报告无法证明它们是否真正被执行并真正成功，所以不能通过ISO9001的审核。但添加一个断言失败（类似assert(false)的断言）的测试后，则可以通过审核。

CMMI与敏捷也是互补的，前者告诉组织在总体条款上做什么，但是没有说如何去做，后者是一套最佳实践。SCRUM之类的敏捷方法也被引入过那些已通过CMMI5级评估的组织。很多企业忘记了最终目标是改进他们构建软件及递交产品的方式，相反，它们关注于填写按照CMMI文档描述的假想的缺陷，却不关心这些变化是否能改进过程或产品。

所以敏捷开发在过程中只编写够用的文档，和以“信息的沟通、符合性的证据以及知识共享”作为主要目标的质量体系文档要求并不矛盾。在实践中，我们可以按以下方法做，在实现SCRUM的同时，符合审核和评估的要求：

-制作格式良好的、被细化的、被保存的和能跟踪的Backlog。复印和照片同样有效。-将监管需要的文档工作也放入Backlog。除了可以确保它们不被忘记，还能使监管要求的成本是可见的。

-使用检查列表，以向审核员或评估员证明活动已执行。团队对“完成”的定义(Definition of “Done”)可以很容易转变为一份检查列表。

-使用敏捷项目管理工具。它其实就是开发程序和记录的电子呈现方式。

总而言之，软件研发需要文档（但文档的形式可以是多种多样的，用Word写的文字式的文件是文档，用Visio画的UML图也是文档，保存在Quality Center中的测试用例也是文档），同时我们只需写够用的文档。

6.当有开发人员在开发过程中遇到难题，工作无法继续，因而拖延进度，怎么解决？ 这也是个常遇到的问题。如果管理者对于某个工程师的具体问题进行指导，就会陷入过度微观管理的境地。我们需要找到宏观解决办法。一，我们基于Scrum的“团队有共同的目标”这一规则，利用前面提到的集体所有权，当出现这些问题时，用团队中所有可以使用的力量来帮助其摆脱困境，而不是任其他人袖手旁观。当然这里会牵扯到绩效评定的问题，比如：提供帮助的人会觉得，他的帮助无助于自己绩效评定的提高，为什么要提供帮助。这需要人力资源部门在使用Scrum开发的团队的绩效评估中，尽量消除那些倾向个人的因素，还要包含团队协作的因素，广泛听取个方面的意见，更频繁地评估绩效等等。

二，即使动用所有可以使用的力量，如果某个难题真的无法逾越，为了减少不能按时交付的风险，产品负责人应当站出来，并有所作为。要么重新评估Backlog的优先级，使无法继续的Backlog迟一点交付，先做一些相对较低优先级的Backlog，以保证整体交付时间不至于延长；要么减少部分功能，给出更多的时间去攻克难题。总之逾越技术上难关会使团队的生产率下降，产品负责人必须作出取舍。

7.有些开发人员水平相对不高，如何保证他们的代码质量？

当然首先让较有经验的人Review其要提交的代码，这几乎是所有管理者会做的事。除此之外，管理者有责任帮助这些人（也包括水平较高的人）提高水平，他们可以看一些书，上网看资料，读别人的代码等等，途经还是很多的。但问题是你如何去衡量其是否真正有所收获。我们的经验是，在每年大约3月份为每个工程师制定整个的目标，每个人的目标包括产品上的，技术上的，个人能力上的等4到5项。半年后和一年后，要做两次Performance Review，目标是否实现，也会跟绩效评定挂钩。我们在制定目标时，遵循SMART原则，即：

Specific（明确的）：目标应该按照明确的结果和成效表述。

Measurable（可衡量的）：目标的完成情况应该可以衡量和验证。

Aligned（结盟的）：目标应该与公司的商业策略保持一致。

Realistic（现实的）：目标虽然应具挑战性，但更应该能在给定的条件和环境下实现。Time-Bound（有时限的）：目标应该包括一个实现的具体时间。

比如：某个人制定了“初步掌握本地化技术”的目标，他要确定实现时间，要描述学习的途经和步骤，要通过将技术施加到公司现有的产品中，为公司产品的本地化/国际化/全球化作一些探索，并制作Presentation给团队演示他的成果，并准备回答其他人提出的问题。团队还为了配合其实现目标，组织Tech Talk的活动，供大家分享每个人的学习成果。通过这些手段，提高开发人员的自学兴趣，并逐步提高开发人员的技术水平。

8.如何提高开发人员的主观能动性？

提高开发人员的主观能动性，少不了激励机制。不能让开发人员感到，5年以后的他和现在比不会有什么进步。你要让他感到他所从事的是一个职业（Career），而不只是一份工作（Job）。否则，他们是不会主动投入到工作中的。我们的经验是提供一套职业发展的框架。框架制定了2类发展道路，管理类（Managerial Path）和技术类（Technical Path），6个职业级别（1-3级是Entry/Associate，Intermediate，Senior。4级管理类是Manager/Senior Manager，技术类是Principal/Senior Principal。5级管理类是Director/Senior Director，技术类是Fellow/Architect。6级是Executive Management）。每个级别都有13个方面的具体要求，包括：范围（Scope）、跨职能（Cross Functional）、层次（Level）、知识（Knowledge）、指导（Guidance）、问题解决（Problem Solving）、递交成果（Delivering Result）、责任感（Responsbility）、导师（Mentoring）、交流（Communication）、自学（Self-Learning），运作监督（Operational Oversight），客户响应（Customer Responsiveness）。每年有2次提高级别的机会，开发人员一旦具备了升级的条件，他的Supervisor将会提出申请，一旦批准，他的头衔随之提高，薪水也会有相对较大提高。从而使每个开发人员觉得“有奔头”，自然他们的主观能动性也就提高了。

上面的“套路”涉及了软件研发团队管理中的研发过程、技术实践、文档管理、激励机制等一些方面。但只是九牛一毛，研发团队管理涵盖的内容还有很多很多，还需要管理者在不断探索和实践的道路上学习和掌握。