软件研发团队管理制度

2024-06-17

软件研发团队管理制度（共8篇）

1.软件研发团队管理制度篇一

研发团队建设与管理暨研发人员的考核与激励

2011年4月14--15日（上海）2011年4月27--28日（深圳）

======================== ◆主_办_单_位： _创_世_纪_企_业_培_训_网_（）

◆参_课_对_象：总经理、人力资源部经理/绩效考核专员、研发总监、研发经理、研发项目经理、技术管理部/研发管理部/项目管理部、研发骨干等

◆标_准_费_用：2600元/人（含培训、指定培训教材、午餐、茶点费等）

======================== ●培-训-报-名-中-心: 深圳报名电话：０７５５--８１２６２９７８

８１２６７２７８上海报名电话：０２１--２５９７６８３１联系人：万先生陈先生王小姐

======================== ◇课程背景curriculum background

======================== 研发系统的团队建设与绩效管理是企业高层领导、研发经理、人力资源经理最为头疼的问题之一，经常遇到以下问题：

1、研发体系是否应该有严格的考核制度，这样会不会挫伤研发人员的积极性？

2、研发的KPI 指标体系如何进行分解，KPI 指标如何进行量化和过程跟踪？

3、研发人员的素质如何识别，以便在选拔及招聘时所用？

4、绩效目标制定和考核结果反馈的过程中如何与员工进行沟通？

5、如何处理好考核的结果与过程并重的特点？

6、如何平衡研发结果的滞后和研发人员的及时激励之间的关系？

7、研发内部如何针对不同的职位进行分类的考核（部门主管、项目经理、员工„„）？

8、为什么建立了研发项目管理流程，但是团队运作仍然效率很低？

9、项目经理为什么经常抱怨权利不够？

10、研发团队游戏规则如何创建？

11、绩效面谈及沟通如何做？

本课程结合多家企业的实际，强调从业务的角度来进行研发的人力资源管理，通过理论及实践来指导研发及人力资源部门的主管对于研发人力资源管理有一个明确的、理论与实践结合的、可操作的方法，从而提高研发的管理效率，提高投入产出比。

======================== ◇培训收益training income ========================

1、分享多家企业研发管理咨询的专业经验，通过现场的互动帮助学员理清适合的研发人力资源管理方案

2、掌握研发的价值链，研发价值创造、价值评价和价值分配的各环节的重点

3、掌握研发人员的胜任力素质模型及技术任职资格的创建方法

4、掌握研发中高层管理者述职管理的制度、方法和操作技巧

5、掌握如何从整个企业的价值链来分解企业的KPI 指标，从源头理清研发的价值链

6、掌握研发团队和个人的绩效目标制定的方法（PBC）

7、掌握研发团队和个人的绩效辅导的方法和行之有效的操作技巧

8、掌握研发绩效管理结果的应用和研发体系的奖金分配方法，结合企业的自身情况设计激励措施

9、分享讲师20 多个咨询项目的绩效管理的案例资料（模板、表格、样例„„），使得学员参训后回到自己的公司能够很好实践

======================== ◇讲师资历lecturer synopsis ★主讲专家：张永杰先生

张永杰研发管理资深顾问（原深圳某大型世界知名高科技企业研发管理部经理）◆教育背景及曾任职务：

==>教育背景：西安交通大学工学学士、管理学硕士，1999年硕士毕业后先后任职于深圳某大型世界知名高科技企业和某生物医疗设备公司。==>曾任职务：项目经理、项目管理部副经理、产品经理等

◆工作经验：

实战派研发管理专家，长期受邀于广东省企业联合协会、深圳高新技术产业协会等行业协会，主讲研发管理类的课程。

多年高科技企业产品研发和研发管理、产品管理工作经历，先后担任过项目经理、项目管理部副经理及产品经理等职位，在长期的研发管理实践中积累了丰富的技术和管理经验。在国内某知名通信企业工作期间，先后从事产品开发、项目管理和市场营销策划等工作，并作为推行组成员与国际研发管理顶尖咨询顾问在研发及售后服务系统推动公司级研发管理变革。

在某生物医疗设备公司工作期间，担任研发管理部副经理，任职期间有针对性地将研发管理的业界最佳实践同公司现状相结合，全面建立并优化研发管理体系。同时兼任内部讲师，具有丰富的研发管理实战经验。

后从事研发管理咨询，先后作为项目核心成员和项目经理成功完成了近20个研发管理咨询项目体系的建设和落地（含市场需求与产品规划、产品开发流程体系、研发项目管理体系、研发人力资源等模块），在产品开发流程设计、研发项目管理和体系推行方面具有丰富的咨询经验。

张老师累计完成公开课程近300场，内训近百场，并成功完成了近20个研发管理咨询项目，累计培训过的企业有3000多家，培训并辅导过的学员已经超过万人，客户满意度均达到92%以上,实实在在为企业解决了产品研发、产品与产品上市管理难题,从而极大提升企业的产品管理、产品研发管理工作价值。

======================== ◇课程大纲curriculum introduction

========================

一、研发团队及绩效管理概述 1.研发人员具有哪些特点？ a)逻辑思维能力强 b)独立贡献者居多 c)技术导向性明显 d)流动意向明显

e)……

2.研发的团队有哪些？PAC、PMT、PDT等 3.高绩效研发团队的特征

a)明确的目标（目标从哪里来？企业目标和个人目标如何统一）b)相互信任（信任的基础是什么？如何建立）c)关心、帮助每个人（从哪些方面着手才是最有效的）d)沟通良好（如何才能有效的沟通）e)分工与授权（在具体工作中如何操作）f)合理的激励（没有足够的条件怎么办）

g)合理、完善的制度（制度目前不合理怎么办）

h)融洽的团队气氛（用什么方法培养良好的工作气氛）4.确定研发团队游戏规则的方法： a)亚斯兰现象 b)破窗理论 c)蛇蛙原理 d)火炉法则

e)案例研讨：研发人员允许犯什么样的错误，不允许犯什么样的错误 5.创建团队文化 a)工程商人

b)避免盲目创新 c)……

6.案例研讨

二、找合适的人：研发胜任力素质模型及技术任职资格 1.研发人员胜任力素质模型的创建 a)研发人员的常规素质要求 b)18种素质的定义

c)研发胜任力素质模型的创建方法 * 调查问卷法

* B·E·I访谈法：某咨询项目的BEI创建过程演示

d)如何基于研发胜任力素质模型创建结构化面试试题库？ * 演示：研发人员的结构化面试试题库 e)如何培养研发人员的胜任力素质？ * 业绩评估 * 关键事件 * 案例的总结 * 知识库的建设 * 研发文化的建设

* ……

2.研发人员的晋升通道及技术任职资格 a)研发人员晋升通道图 * 管理系列 * 技术系列

* 技术管理系列，如QA b)任职资格和开发流程的关系

c)如何基于开发流程创建技术任职资格体系？

d)咨询项目演示：某公司的技术任职资格体系创建过程

三、研发中高层领导：述职管理 1.2.3.a)如何理解研发绩效管理要从源头来抓

业界优秀公司管理研发中高层绩效管理的思路研发中高层领导述职管理的误区述职会成为故事会

b)每个述职者述职均非常优秀，但是公司业绩不行 c)没有述职评议的标准

4.研发高层领导述职管理的原则 5.研发高层述职管理的模型 6.研发高层述职管理的内容 a)述职报告的构成及关键内容

b)咨询项目演示：研发中高层的关键绩效指标（KPI）7.研发高层述职管理的操作 a)操作的流程

b)述职评议的过程

8.研发中高层领导的任职资格管理 a)任职资格标准

b)任职资格中如何关注行为规范 c)任职资格如何进行评议

9.实例讲解：

a)某案例公司的研发中高层领导的任职资格标准分析

四、研发中层和团队：基于价值链的研发KPI 指标设计 1.业界公司KPI 指标制定过程中的误区

2.如何从端到端的流程的角度来设计研发的KPI 指标 3.研发体系KPI 指标制定的原则 4.研发体系KPI 制定的方法

a)平衡计分卡的方法 b)鱼骨图的方法

5.设定研发KPI 需要考虑哪些因素（I、T、Q、C、S）

6.研发体系的KPI 指标库

a)产品线的KPI 指标的制定（产品线总监、产品经理、项目经理„„）b)资源线的KPI 指标的制定（软件、硬件、测试、工艺、QA„„）c)职能管理部门的KPI 指标的制定（HR、项目管理、配置管理„„）7.研发体系KPI 的应用 8.研发绩效的量化管理

a)研发绩效量化管理中存在的问题 b)研发绩效量化管理的原则

c)量化不了结果的KPI 指标怎么办？

d)研发绩效量化管理如何操作（考核绩效、考核改进）9.实例讲解：

a)某案例公司的研发体系KPI 指标库（指标与部门的对应、标准定义、示例„„）b)某案例公司KPI 指标量化管理的经验数据――》过程能力基线PCB

五、研发基层员工：研发绩效的目标管理

1.研发绩效目标迷茫的原因分析 2.研发绩效目标的分层体系 a)研发高层的绩效目标

b)研发体系、各职能部门、产品开发团队、研发人员的绩效目标 3.研发绩效目标的来源 a)职位说明书

b)项目团队的终极目标 c)资源部门 d)个人发展和成长

4.研发绩效目标制定的方法――个人绩效承诺PBC a)赢的承诺（WINNING）b)执行承诺（EXECUTION）c)团队承诺（TEAMWORK）

5.采用个人绩效承诺PBC 方式的优点分析 6.如何根据业务特点制定个人绩效承诺PBC 7.案例研讨：王老五的个人绩效承诺 8.绩效承诺目标的跟踪与修改（PIP）9.实例讲解：

a)某案例公司的个人绩效承诺PBC模板分析 b)某案例公司的个人改进计划PIP模板分析

六、研发团队中不同类型的人如何管理 1.研发人员工作太忙怎么辅导？ 2.研发管理人员太忙怎么辅导？

3.案例研讨：针对不同类型的员工如何进行管理 a)指挥倾向型 b)关系倾向型 c)思考倾向型 d)听命行事型

4.实例讲解：

a)某案例公司的研发绩效辅导的要求和具体操作模板

七、研发绩效面谈：评价与反馈管理

1.案例研讨：主管和下属在绩效面谈中能否达成共识？ a)造成绩效考核结果无法达成共识的原因是什么？ b)思考：这种情况在自己的公司是否普遍存在？

2.研发绩效评价到底谁说了算（资源线、产品线、HR„„）？ 3.绩效评价的原则（程序公正、过程与结果并重）

4.绩效评价的结果是否公开（不公开、公开、部分公开„„）5.绩效评价方法

a)人与人比还是人与标准比

b)考核比例的控制（要不要比例、如何控制比例、如何避免轮流坐庄）c)如何进行跨部门人员的绩效评价 d)新员工如何评价（经常是垫背的„„）

6.绩效沟通反馈要注意的问题 a)绩效管理诊断箱

b)绩效反馈的方法（如何针对不同的人采用不同的反馈方式、场合、地点„„）7.如何面对员工质疑或投诉 a)可不可以民告官

b)如何处理打小报告、越级报告

8.绩效反馈的“一个中心、两个基本点和四项基本原则” 9.如何与研发系统的几类“特殊人员”进行反馈沟通 a)明星员工 b)问题员工 c)如何激活休克鱼？

10.研讨：如何看待研发人员的流动和末位淘汰？

11.实例讲解：某案例公司的研发绩效反馈的操作表格和模板

八、评价结果的应用及奖金分配 1.如何对研发人员进行激励？ 2.激励员工的多种方式 a)攻关奖

b)5年/10年奉献奖 c)伯乐奖 d)专利奖 e)金牌

f)……

3.如何根据绩效及任职资格调整薪酬（加薪、降薪）4.研发奖金的构成 a)个人奖/团队奖 b)项目奖 c)绩效奖 d)季度奖

e)年终奖

5.研发季度、年度奖金的分配思路（蓄水池）

6.实例讲解：某案例公司研发体系奖金计算的公式及分配思路

========================

●培-训-报-名-中-心: 深圳报名电话：０７５５--８１２６２９７８

８１２６７２７８上海报名电话：０２１--２５９７６８３１联系人：万先生陈先生王小姐

========================

研发团队建设与管理暨研发人员的考核与激励

----报名回执表

----

如需发E-mail可发至baomingpx@126.com(請务必填写貴公司全称和参会學员真实姓名,谢谢！)

上海与广州总部传真:０２０--３９９５７３２１深圳传真:０７５５--８１２６２９７８

參會企業名稱：______________________________________參加人數：____________人

聯系人：__________________ 聯繫電話：_______________聯繫傳真：__________________

移動電話：___________________ 電子郵箱：________________費用總計：____________元

參會人一：________________ 所任職務：_______________ 移動電話：___________________

參會人二：_________________ 所任職務：______________ 移動電話：___________________

參會人三：_________________ 所任職務：______________ 移動電話：___________________

參會人四：_________________ 所任職務：______________ 移動電話：___________________

參會人五：_________________ 所任職務：______________ 移動電話：___________________

參會人六：_________________ 所任職務：______________ 移動電話：___________________

付款方式：（請選擇打“√”）□

1、電匯 □

2、轉帳

□

3、支票

□

4、現金

请您选-择参-会-地-点：（请选择打“√”）2010年口上海

口深圳

备注: 1.请您把报名回执认真填好后回传我司，为确保您报名无误,请您再次电话确认!2.本课程可根据企业需要组织内训。

2.软件研发团队管理制度篇二

关键词：软件研发,知识产权,管理机制

0 引言

随着我国经济、科技的飞速发展, 各行业的现代化程度不断提高。伴随着云计算、物联网等信息技术应用浪潮的兴起, 计算机软件的应用也越来越广泛, 软件产业已经成为当今信息产业的核心。计算机软件技术含量高、经济价值大, 通常能给软件权利人带来丰厚的利润, 由于其极易复制, 并且侵权行为惩罚力度不大, 使得软件侵权现象十分严重。因此, 各国高度重视软件的法律保护, 不断加强软件知识产权体系建设, 打击侵权行为, 以促进本国软件产业的健康发展。企业也应积极采取措施, 有效地保护、管理和运用知识产权, 加强软件研发过程中的成果管理, 强化并保持自身软件的竞争力。

1 软件知识产权内涵解析

1.1 知识产权理论概述

科学技术不断发展, 产业变革持续进步, 人们逐步认识到对于知识产品的拥有与使用能够带来丰厚的经济收益。然而, 技术的转移与公开势必会使原先的发明创造者丧失竞争优势, 这就需要建立一种机制, 以确保既能维持新技术发明人的技术优势, 又能满足社会对该技术的需要, 防止技术垄断。因此, 知识产权制度中的专利制度应运而生。18世纪60年代在英国开始的产业革命, 是专利制度产生的催化剂;随后, 在西方国家又产生了著作权制度和商标权制度。迄今为止, 经过数百年的洗礼, 知识产权制度已经成为国际上通行的保护智力成果和工商业信誉的法律制度。

1.2 软件产品特性约束

1978年, 世界知识产权组织 (WIPO) 发表了《保护计算机软件示范条款》, 该条款对计算机软件的定义是:计算机软件包括程序、程序说明和程序使用指导3项内容。软件的开发与使用过程使其具有特殊的产品性质。首先, 软件具有高成果性。软件产品是开发人员花费大量时间与精力而形成的产品, 蕴含了软件人员的设计思想与逻辑算法, 是一种脑力劳动的智慧成果;其次, 软件具有高价值性。软件产品通过团队分工协作并采用高新技术工具而获得, 故而开发成本较高;同时, 软件产品不仅能够提高工作效率, 而且能够提升经济效益, 在促进科技进步、社会发展等方面具有不可磨灭的作用;再次, 软件具有易复制性。软件运行结果并不展示该软件的技术特征, 具体的软件设计思路、程序编译方法等技术要素均体现在程序运行过程中, 加上很多技术方法属于开放共享资源, 这在一定程度上造成软件侵权过程简单而隐蔽。

1.3 软件知识产权保护的必要性

20世纪60年代初, 软件产业开始逐步发展, 直至今日, 已经成为信息产业的核心。软件研发一般需要企业投入大量的人力、物力、资金等, 但是软件盗版比起研发投入的开发与管理成本, 花费不仅低, 过程也较为简单。正因如此, 一些软件盗版的不法分子便投机取巧, 直接盗取他人的设计思路与软件程序, 改头换面之后变成自己的软件, 以谋取高额利润。盗版者不劳而获的行为损害了软件所有人的合法权益, 也危害了整个软件产品的出版市场, 不仅不利于软件研发的创新, 也不利于整个软件产业的发展。软件本身作为高价值且易侵犯的作品, 迫切需要一种法律制度来保护其智力成果与经济价值不受侵犯, 而知识产权作为一种制度保护手段, 可以充分保护软件人员的技术创新, 促进软件企业的产品开发。软件通过知识产权予以保护, 从开放性的角度来看, 软件企业将通过合法渠道公开自己的软件产品, 社会财富将持续累积;从竞争性的角度来看, 市场上将会诞生更多有价值的软件, 社会财富将加速累积。

2 软件研发企业知识产权管理问题剖析

知识产权是软件企业的保护手段与重要资产, 纵观软件产业知识产权管理现状, 其知识产权保护程度仍然与软件产业的发展要求不同步, 造成软件知识产权始终是软件企业发展的制约因素。

2.1 盗版制约企业发展

软件盗版主要包括以下4种情况:1 复制发行软件。未经软件著作权人同意, 直接复制或者发行其所拥有的软件;2抄袭仿制软件。稍加修改著作权人的软件, 本质上未明显变化, 即作为自产软件发行;3 捆绑嵌入软件。自产软件与著作权人的软件一同发行, 程序运行无法分离, 且未经过著作权人同意;4终端用户商业性使用软件。软件终端用户自行安装著作权人软件, 但是未经著作权人许可并且用于经营活动。

2.2 商业秘密流失形成企业困境

软件商业秘密流失包括以下3个方面:1关键人员流动。软件企业的关键技术人员或管理人员一般拥有企业的技术资料、市场信息、客户资源、管理策略等, 一旦这些人员更换企业, 将造成此类商业秘密信息的流失, 直接影响企业竞争与发展;2企业合作失信。软件企业与其它公司合作开发时, 提供了一些技术或商业秘密资料, 但是其它公司未履行相关保密约定, 便将这些信息公开或者使用;3他方非法盗用。其它公司在商业竞争中, 采取了盗窃、贿赂、要挟等非法手段, 盗取并且使用企业所拥有的技术及商业秘密资料。

2.3 合同漏洞导致企业纠纷

合同已经成为解决企业间纠纷的关键依据, 合同条款的规范准确将直接影响判断合同当事人是否承担法律责任。软件企业已经越来越认识到知识产权管理的重要性, 但是企业在合同签订与执行上仍然存在诸多问题, 造成各种知识产权合同纠纷不断出现。软件企业在合同签订时依然存在合同评审流于形式的现象, 导致软件开发合同中的保密条款、验收过程、验收准则、风险规避、权利归属、权利使用、收益分配等内容约定不清晰, 无法操作, 进而在合同执行过程中, 出现合同理解不一致、无法履行合同等情况。

2.4 新变化给企业带来新问题

网络与软件在信息技术领域互为促进, 共同发展, 信息安全问题也随之而来。通过网络, 利用病毒、木马等非法手段, 不法分子盗取账户信息、用户资料的现象时有发生, 网络安全在一定程度上已经成为软件和互联网产业发展的阻力。同样需要关注的是, 软件资源也出现了不合理、不均衡的发展。比如某些软件企业在其它公司的同类产品进入市场时设置种种障碍, 或者在市场竞争中采取联合老企业打压新对手等。这种企业的不正当竞争行为越演越烈, 造成了市场竞争的不良发展, 产生了恶劣的市场效应。

3 软件研发企业知识产权管理机制优化策略

3.1 规范研发体系知识产权管理制度

国外众多实践证明, 知识产权制度是企业管理体系的重要组成部分, 也是企业技术创新的不竭之源, 直接关系到企业的生存与发展。企业应根据自身特点, 综合考虑业务覆盖范围, 分析自身存在的知识产权管理问题, 明确与业务流程相匹配的知识产权管理要求, 形成知识产权管理的奖励与惩罚机制, 从源头避免知识产权风险的发生, 做到预防、执行、评价的闭环管理机制, 最终建立一套行之有效的知识产权体系。软件研发尤为如此, 需要基于软件生命周期过程制定一套符合实际的知识产权管理制度。根据GB/T 8566-2007《信息技术软件生存周期过程》, 软件生命周期包括获取过程、供应过程、开发过程、运作过程、维护过程等基本过程。软件研发与维护过程不同, 所采取的知识产权管理方法也不尽相同。企业应将知识产权理论与软件开发实践相结合, 根据软件生命周期各过程进行知识产权管理, 做到软件各阶段成果均有相应的制度保护。在制度体系建立的基础上, 各个层级贯彻执行, 能够严格管理知识产权的相关资料, 以保证企业在市场竞争与技术发展中立于不败之地, 以此构成的全方位保护体系, 不仅保护了企业的利益, 也促进了社会的进步。

3.2 强化研发部门知识产权管理职能

企业知识产权专业化程度的高低直接影响知识产权制度的执行效果。首先, 企业应安排高层直接管理知识产权等法律事务工作, 重大事宜进行集体决策, 避免出现管理失误的情况;其次, 企业应配备专职人员负责企业的知识产权管理工作, 积极参与软件全生命周期的各个过程, 包括项目预研、立项、研发与维护等重要阶段, 全方位为软件项目提供知识产权法律的咨询与指导;再者, 企业还应聘请知识产权领域的权威专家或者专业律师, 对于企业面临的知识产权管理问题, 获取专业咨询服务, 对于实际发生的知识产权纠纷, 也可获取专业的调研、取证、诉讼服务。例如, 一些企业认为在没有最终软件产品的时候配备专职知识产权管理人员为时尚早, 且管理成本太大;一些企业在知识产权专业分工、岗位设置上仍然存在短视现象, 造成一些知识产权问题没有经过专业指导并真正解决。诸如此类, 知识产权管理问题将最终形成 “蝴蝶效应”, 造成问题波及范围、影响程度越来越大。企业应强化部门的知识产权职能, 积极采取有效措施, 共同避免发生重大损失。

3.3 加强研发环境知识产权管理功能

规范安全的软件研发环境能够在一定程度上保护软件的阶段性成果, 对于保护软件知识产权具有重要作用。企业必须加强软件研发过程的软件配置管理工作, 建立健全管理机制, 针对需求、设计、编码、测试、实施、维护等阶段, 对需求规格说明书、概要设计、详细设计、源代码、测试文档、实时记录、维护文档等技术资料严格管理, 做到技术资料标识的唯一机制, 建立技术资料访问的人员权限机制, 形成技术资料修改的追溯机制, 按照企业的质量体系管理要求定期开展配置审计工作, 保证技术资料的完备性、一致性与可追溯性。规范的技术资料是企业的重要价值所在。例如, 在规避人员流动风险方面, 即使研发人员出现流动的情况, 后备人员也能够较快地根据齐备的技术资料, 理解软件研发的设计架构, 掌握软件研发的管理过程, 保证软件开发过程与最初设计方案一致。所以, 企业要不断规范软件研发环境, 确保技术资料的安全、完整, 保障软件知识产权的阶段成果。

3.4 提升研发人员知识产权管理能力

管理人员的能力素质直接影响企业知识产权管理制度的宣贯与执行效果。随着科技的不断进步, 企业合作研发的各种新型模式不断涌现, 这使得知识产权管理工作变得越来越复杂。在现代化全球研发网络不断发展的过程中, 知识产权管理工作也涉及到多国、多地区的各种复杂利益。在此背景下, 知识产权管理专责人员不仅要具有基本的法律知识, 更要掌握相关领域的专业技术知识, 并且能够积极稳妥地处理涉外知识产权事务。软件企业应该配备专职从事知识产权管理的人员, 这些人员不仅要熟练掌握我国法律知识, 也要对外国法律知识有所涉猎, 而且要了解软件行业的技术知识。企业应定期对专责人员进行知识产权教育培养, 组织知识产权工作人员参加专利局或其它机构组织的培训;另外, 还应针对实际工作中出现的问题, 邀请专利审查员、专利代理人到企业开展专题讲座。

参考文献

[1]陈敏.以知识产权为镜探视软件行业的发展[N].中国知识产权报, 2012-08-01.

3.自主研发软件科学管理设备篇三

重报印务设备报修平台的设计思路

由于报纸的特殊性，报纸印刷时间多在深夜且集中在凌晨1～5点，因此，要求每台设备保持正常运转并满负荷工作，而如果设备在生产中出现故障，操作人员要先填写纸质故障报修单或电话报修，维修人员再到现场处置，这样势必严重影响整个生产安排及出版时效。以往这种设备管理方式的不足之处在于：①夜班生产管理者对各种设备的整体运行状况掌握得不够全面，不便统一调度全盘生产；②夜晚进行设备维修，只能做应急处理，彻底的维修工作必须在白天完成，这样容易造成夜班操作人员对维修后的设备状况了解不够，不利于后续跟踪；③设备管理者对每台设备的动态状况了解不全面；④维修人员接到报修信息可能有延迟，不能保证及时到场处理等。

因此，为了快速上报设备故障，及时反馈维修情况，分析故障原因，达到智能化设备管理的目的，我们在生产车间各机台电脑已联网的前提下，拟定出在Visual Studio环境下，用Asp.net+C#语言和SQL数据库编程设计报纸印刷设备报修系统的方案，命名为 “重报印务设备报修平台”。系统基于Web下浏览及操作，将生产车间、机电维修车间、管理部门的电脑进行联网，可多用户共享操作。

重报印务设备报修平台界面简介

在设备报修平台的最初设计中，我们以设备故障报修单和维修记录单的形式进行设计。随着设计的深入，我们就想能否增加对各种设备的维修情况和零件更换的查询和统计功能呢？由于系统设计时已经建立了数据库，只要增加查询和统计功能就能达到这种效果，因此，我们又增加了以时间、部门、机台、报修人员等为关键词的查询功能。目前，重报印务设备报修平台以 “报修信息表”为主界面，包含“用户登录”、“车间报修单”、“维修记录”、“零件更换统计”、“报修信息查询”和“设备维修统计”6个子界面。

1.系统主界面（报修信息表）

系统主界面（报修信息表）以表格形式显示设备报修情况，每行记录代表一条设备报修信息，以序号、报修时间、报修部门、报修机台、报修人员、机电、故障描述、主管确认、维修情况、机台确认、操作11个栏目显示设备故障报修情况，如图1所示。

当操作人员填报完设备故障后，系统主界面上会显示一条相应的报修信息，该信息经车间主管审核确认后，设备故障的报修过程即完成，机修或电工会根据提示信息立即到场处置。

2.车间报修单界面

在浏览器中输入服务器IP，访问重报印务设备报修平台，车间操作人员等用户登录车间报修单界面（如图2所示），填写报修情况，提交后，系统主界面（报修信息表）上将增加一条数据记录。

3.维修记录界面

当机修或电工处理故障后，进入维修记录界面进行填报。为保证维修质量，该界面内增加了对维修效果的验证，需要机台和主管确认，如图3所示。

4.报修信息查询界面

为方便对报修信息的查询，重报印务设备维修平台还设有以时间、机台、故障类型等为关键词的查询功能，如图4所示。

5.维修统计界面

图5为维修统计界面，从中可以查到某段时间内的设备维修情况，从而为更好地管理设备提供了有力的依据。

重报印务设备报修平台使用案例

我公司从2013年10月开始安装试用 “重报印务设备报修平台”，经过近半年的不断完善，设备的管理者、操作人员和维修人员都已经能够熟练运用该系统，更快、更好地排除设备故障，为保证生产时效提供了技术保障。下面是该系统的4个应用实例。

1.快速处置故障

2013年11月23日，胶印车间的高宝COLORA宽幅印刷机（德国产）在印刷《重庆晨报》1～16版时，第5版图片出现黑版上脏的问题，报修后经分析，认为是喷水电磁阀接触不良造成缺水，从而导致上脏，对症下药，我们很快排除了故障，并在重报印务设备维修平台中进行了记录。2014年1月23日，该故障再次出现，通过系统查询，我们很快掌握了喷水组件的相关情况及以往维修情况，大大缩短了故障分析时间，快速处置了故障。

2.故障类型查询

2013年12月，通过系统统计故障报修情况，发现胶印车间的SSC系列机器报修的故障中，龙骨传送Z型三角皮带断裂次数达8次，占当月报修故障总数的34.78%（该机台当月故障报修次数总计23次），查找维修人员的维修记录发现，其中有3处的皮带断裂在次日重复出现，虽然维修人员及时进行了处理，但由于维修时的操作空间限制，皮带热合黏接后的效果不一致，从而导致同一故障反复发生。针对该情况，技术人员自行设计了一套专用夹具，统一了该种皮带热合黏接时的操作规范，并对所有维修人员进行了培训。从次月开始，同一故障报修次数明显减少，每月只有1～2次，属于正常范围。

nlc202309031653

通过采取上述统计、查找记录、分析原因、采取针对性措施的处理办法，有效避免了类似故障的重复发生，提高了设备的有效运转时间。

3.零件更换统计

2014年3月，通过系统查询印前车间的零件更换记录，发现2号CTP设备当月共更换了2个新的摩擦胶轮，而该零件的正常使用时间应在6个月以上。通过查看维修记录，发现故障描述现象为“PS版定位不准，清洁摩擦胶轮后无效，CTP设备自动退版”，故障原因未查明。设备管理员通过组织技术人员跟踪、查找、分析，确定根本原因是定位轮的电阻增大，导致其导电性能下降，无法稳定地检测到定位信号，从而引发以上故障。经过相关处理后，故障彻底排除，避免了零件的非正常损耗，降低了维修成本。

4.统计数据分析

设备有效运转率是衡量设备维护保养工作的重要指标。设备管理部门每月都要对各车间各机台的设备故障报修、维修进行统计。传统的统计方法需要花一两天的时间，还要逐一对纸质报修单分类和统计。而通过该系统，就可以自动、随时统计各种数据，减少了人工统计量且数据更加准确，达到了真正管理好设备的目的。

重报印务设备报修平台的优点和不足

1.优点

由于该系统是公司自主研发的，所以更适合公司的设备管理，使用至今，得到了设备管理部门及机台操作人员、维修人员的充分肯定。

（1）加强了生产车间设备故障报修人员与维修人员之间的沟通，维修人员能够在第一时间到现场处理和排除故障，报修人员也可以准确了解故障的维修进度和维修结果，同时有效避免故障漏报、漏修。

（2）有利于生产调度员实时掌握所有生产设备的动态运行状况，从而根据每台设备的具体情况，及时做好生产安排，保证生产时效。

（3）维修人员之间可以利用系统互相借鉴学习，积累维修经验或吸取教训，提高维修技能，减少维修时的故障诊断时间，通过采取有针对性的预防措施，尽量避免相同故障的重复出现。

（4）替代了以前使用的纸质报修单，减少了人工统计量和可能产生的差错。通过系统的查询和统计功能，设备管理员可以准确掌握每台设备发生故障的时间、种类和频率，从而进行相关的数据分析，达到改进设备管理的目的。

（5）增强了员工使用信息化技术进行设备管理的意识，为我公司在新的印刷基地全面推广智能化管理系统打下了基础。

2.不足

目前，该系统的不足是在零件的管理和更换方面，还未与库房的数据接轨。然而报纸印刷企业长期在夜班生产，若无备用零件更换，会造成印刷设备停机，影响出版时效。因此，未来，我们将在原有系统的基础上，增加零件的编码入库、更换领用以及机台跟踪，从而准确掌握零件质量和实际使用效果，实现全方位的设备智能化管理。

4.软件研发团队管理制度篇四

近日InfoQ有幸独家专访了微软Visual Studio Business Applications团队的总经理潘正磊，与她探讨了微软研发团队管理的相关问题：技术人员的职业发展、如何培养接班人、如何管理不同规模的研发团队等等，

个人简介

潘正磊女士是位于美国雷德蒙市的Visual Studio Business Applications团队的总经理。这个团队通过提供多种工具，使全球开发人员能便捷地在微软平台上搭建商业应用程序。她同时领导开发工具部门的中国研发团队，进行Visual Studio、Visual Studio Team System等产品和技术的全球研发工作。92年，她以软件开发员的身份加盟微软，参与Access、Visual InterDev等产品的开发。1998年至2006年间，她先后担任Visual Basic.NET开发经理、Visual Studio产品线开发总监、Visual Studio Team Architect产品总经理和Visual Basic产品总经理，为专业开发人员提供在.NET平台上最高效的开发工具，使数百万Visual Basic 6.0用户迁移到.NET平台。

先给我们介绍一下你自己和你自己现在所做的事情吧?

我是在1992年大学一毕业就参加了微软，一开始是做开发程序员，就是Developer，最开始开发的项目是Microsoft Access，现在也是微软卖的很好的一款产品。在Access开发了几年之后，我转做另外一个产品叫Visual Interdev，那是我们微软第一款针对网络Web做的开发工具;那之后我在Visual Basic团队做Developer Manager，就是开发经理的职位，当时我们整个从VB6到VB.NET 转型，所以跟.NET做平台开发，是一个非常艰苦的项目。之后还在Visual Studio里做了一系列的职务，包括开发总监，包括我们Visual Studio Team Architect的产品总经理，包括Visual Basic的产品总经理。现在是Visual Studio Applications的产品总经理，像我们刚才所说的，主要我们这个团队做的是针对企业的开发工具。

你是从一个基层的开发人员一直走到现在，那我想，在你整个过程中应该是有很多的感触，特别是从一个开发人员然后到一个管理职位，在整个过程中有没有什么比较难忘的事情?

因为已经工作十几年了，所以说，确实有很多故事了，我觉得比较难忘的几个故事，还是跟我们最高层打交道的时候比较有趣。我们在做Visual Interdev的时候，那是我们第一款针对Web的产品，当时微软对Web的定义、对Internet的战略不是非常清晰。记得我们跟Bill Gates在做产品Review时候，他一开始对我们这个产品是有些意见的。他说，你这个产品做出来以后，对Windows有什么好处或者是坏处。这是一个挺尖锐的问题，让我们所有人回去都要好好想一想。

还有最近我们在做另外一款产品Review的时候，也是跟我们Steve Ballmer，我们的CEO，跑上来我就要给他做一个演示Demo，我们的CEO就说现在所有演示都不要做，他叫我们最资深的副总裁，“你就到黑板上面去，把你们这个产品要做出来的三个目标先给我写上去，写完以后我们再做演示，看你这演示有没有达到你这三个目标”，这个跟Steve Ballmer做Review常常会碰到这种情况。

他会直接帮你梳理你的产品目标?

他会用你很意料不到的方法来问你，因为一般我们去做这种总裁Review都是有准备好一套PowerPoint，有一套我们自己的思路，他就会从你的思路之外问一些问题，保证你确实能够解释出来你为什么要做这个东西，然后你的思路是什么，你的战略是什么，这是一些蛮有挑战性的东西。

在你的个人从开发人员到一个团队管理的过程中，在做团队管理的时候有没有遇到一些困难、一些比较难忘的事情?

做团队管理的时候，因为团队管理最主要的是几大块：第一，你要造就一个非常强的团队。这中间有很多(差异)，你这团队是你自己接手的，还是这个团队是你自己一个一个雇佣进来，这个完全是不同的。还有和你的Partner(合作)团队，因为微软很多项目需要好多几个团队来一起合做才能做好，那跟你Partner的这个运行过程中也有很多的这种Interaction(互动)，有的时候如果大家的战略目标不一样，就会造成很多各种各样的问题，那所以这都是有很多故事的。我现在一下想不出来一个特别好的、最有挑战的。因为从组建团队中，这么多年走过来，基本上什么场景都碰到过了，所以我还真一下想不出来一个最好的故事，或者是说最有挑战性的故事。

其实我也了解到在你整个的发展过程中，到最后成为全球微软有两千多个总经理，你是为数不多的华人，那么从整个阶段来看，你是如何去总结自己的这段历史?

我觉得微软现在华人的总经理比较少，但是我觉得从长远来说肯定会越来越多，这实际上是我们在九几年有大量的大学毕业生开始出国，然后开始在美国，或者这种(国外的)地方开始就业有关。我相对来说出国比较早一些，所以我进微软也很早。那像九几年之后，95、96，包括90年代末期，有大批的中国员工进入微软，所以我相信这以后的华人工程师或者华人总经理，各方面只会越来越多。那另一方面，在微软或者是在很多大企业里，自己的一步一步都是要慢慢走过来，然后都是要脚踏实地，最主要的是要想到说你对这个团队有什么贡献，你对你的客户有什么贡献，如果能够比较的专注于某方面工作的话，那我觉得在成长中是很有好处的。

进入微软的华人很多，工程师也很多，但我想也淘汰了很多，最终可能会有一个人冒上来，而且这个人就是你，我想问一个比较直接的问题，你觉得为什么会是你走到今天这个位置?

我觉得每个人的长处是不太一样的，我觉得我自己的长处，第一是技术方面还不错，因为一开始在做工程师，如果你技术上面做不好，是不可能往上走的。另一方面，我觉得我对资源整合这一方面是比较强的，我的一个强项是我很快就能看出我下面的员工他们最适合什么，他们不太适合什么，那把他们放在最适合于他们的工作岗位上。这样第一能够是最大的调动他们的积极性，第二整个团队可以成一个非常高效的团队。

而且我在管理人员方面，很多跟我做了很多年的员工，愿意跟我做很多年，所以这也是作为一个领导者应该比较重要的素质。

我觉得是这些是可以学的，但有些可能有的人就会比较容易一些，比较自然一些，有的人可能就是要学的更多一些。

但是我想在你的团队里面应该也有一些能力非常强的，比如说他的存在会让你有所威胁，那么在这种情况之下，你是如何和他们相处的?

你看，我这个考虑思路跟你完全不一样，我不会觉得我团队里面有谁对我是有所威胁的，我的出发点就是我希望能够培养一批人才，如果有一天我能够不用去上班了，而且我的团队还可以执行得非常好，这才是我的目标，所以我是希望有人能够来代替我。

因为微软里面包括很多公司是这样的，有挑战性的工作是非常多的，如果我这个工作做完了，如果我下面培养出一批人才，能够取代于我的话，那还有更加具有挑战性的工作在等着我去做，所以这个思路不是说有这个人会对我造成危险性，而是我如果有一天能够找到一个，或者请到一个比我更强的员工，这是一个非常高兴的事情，非常令人振奋的事情。

实际上在我的职业生涯中也确实有过这样的经历，我那时候在做Visual Basic开发经理的时候怀孕了，我知道会休蛮长的产假，而且一度还动过可能不回来上班的想法，做全职妈妈的这种心思，所以我那时候就把我下面的一个开发主管，一个开发主管一直培养他，而且当时就是培养他到最后，我去休假之前，说那这个团队就交给你了。等我五个月休完产假回来之后一看，那个团队虽然是我打造的，交给他之后他还是管理的非常好。我说太好了，那你就来做开发经理。那个时候我就去做了我们Division另外一个工作，整个部门的开发总监。

就像我说的，这世界需要能人的事情非常的多，所以你是一个能干的人你不要有这种危险感，因为需要你的地方是非常多的。

所以我想，一个人的自信对于他的整个的成长是非常有帮助的?

实际上我觉得如果在微软来说，如果你没有自信，那你可能很难从一个开发工程师往上走非常的远。因为在微软我们招的都是，真的是世界上英文词叫“cream of the crop”，都是最最顶尖的大学生，或者是外面有经验的人。在这样一种环境中，你怎么样能够跟大家交流，怎么样可以说服大家同意你的观点，怎么样听取别人的反馈，自信心实际上是一个非常基本的素质。如果你没有这个素质，就是作为一般的开发工程师也不会走的太远的。

另外我比较好奇的一点，比如说在你整个的几个阶段里面：有基本的开发人员，然后到一个比如说项目经理、一个产品的带头人，然后再成为一个产品的总监，最后成为总经理，那么这几个段它有什么特别的不同吗，除了你管理的人越来越多?

那是有非常大的不同的。作为一个开发工程师来说，你最主要的是要把你的代码写得越快越多越好。因为你对产品的贡献是鉴于你代码的数量，你写代码数量直接就反映成你对这个产品功能多少的体现，你的代码行写得多，那这个功能才增加得多，你写的代码行是最难的那部分，那才说明你对这个产品最主要的核心部分有贡献，这是作为开发工程师。

作为一个开发主管来说，就是我们叫Development Lead，第一方面，作为管理者，你对这个团队的价值，不仅仅是说你自己写了多少行代码，这相对来说是比较少的，最主要是你这个团队对整个产品的贡献是什么，那还是基于你这个开发的功能有多少，然后你这个功能是不是做得好，你架构是不是做得好，但是你的核心价值是把你这些资源都组合起来，然后能够帮助你团队的员工扫平障碍，让他们非常顺利地开发。

像我最开始做管理的时候，我只管理了三个员工，有一个员工如果做得慢一点，那我最多周末去加一加班，他没有做完帮他补做完就完成了，我觉得相当简单的一件事情。等我那个团队长到10个人的时候，你就发现，第一，不可能我周末再来加班，也不可能把10个人里面有两三个人可能要做的慢一点，如果按同样的比例来说，我不可能把这两三个人要做的东西都做完了。那这个时候你要做，就是我们从这个Skill来说，如果要整个团队都能够非常顺利高效，你就要想“我怎么样让这十个人互相之间能够(协调好)”，就是很多程序是有顺序的问题，把顺序问题安排好，有些东西可能要需要一些决定，尽早的把决定做好，下面的架构可以做好，跟其他团队的关系要搞好，因为他们可能有些东西要拿来，他们先做完之后我们才能做，所以有很多东西Dependency Management，这些东西全部都要管理好，就像造房子，管理一个项目一样。这样管理好你这十个人才能都是马不停蹄、非常高效地把这个东西做好。

等你做开发经理的时候，开发经理因为不是一个第一线的管理者，而是第二线的管理者，这个时候最最有挑战性可能是，你很多东西要通过你第一线的开发主管传达到下面去，如果你开发主管对你说的话不认可，那你的观念、决定不一定真正能够传达到最下面的开发人员。而且你下面的开发主管可能每个人都还要管一摊不同的东西，你怎么样让他们之间能够互相配合、互相合作，从一个大局上面来看你整个这个开发团队缺什么，有的时候他们开发主管在那里面做，他不一定会知道说，我实际上比较缺一个真正能帮我把这个架构搞在一起的人，或者一个特别懂客户的人，那要把这个全部都想清楚，真正打造一个非常强的团队，这又是另外一套的艺术，我觉得。

在微软如果你不懂这产品(技术)，你是没有办法做一个合格管理者的，你不仅要做人员的管理者，你还要做这个产品的定义，而且还要跟你的团队交流，什么地方是应该做的，什么地方是不应该做的。

是多重角色了?

对，因为从开发经理来说，我在美国喜欢说三个P，你要管理产品(Product)，你要管理人员(People)，你还要管理流程(Process)，这三样东西都要抓起来，你才能作为一个合格的开发经理，然后让整个团队都能高效地运行。

他和现在的总经理有很大的区别吗?

非常大的区别，因为从开发经理来说，他还只是主要是管开发团队的。开发团队总的来说只是占了可能是1/3。总经理跟产品经理是两个不同的概念，产品经理是说你管一个产品，那总经理你是管多种产品，像我刚才所说的，实际上我现在这个组里面有三种不同的产品。

那这三种不同产品很多时候会有不同的进度表，发布时间会不一样。怎么样把里面相同的东西能够整合出来，让大家最有效地利用，而且还要针对每一个产品有他特别的开发。怎么样管理这一套产品线，而且跟我们的市场部，跟我们的营销部，跟我们的DPE(开发工具及平台事业部)，那些合作都是在这个层面上面是完全不同的。而且在这上面你就更要想说，这几个产品，就像我们叫Portfolio(投资组合)，就好像如果你要是投资，你可能有些放风险基金，有些放银行存款，有些是放外汇，你还要再从比较高的角度上，看你每一个产品到底里面放多少的资源进去，为什么这个产品放这么多资源，而且要看你成功的定义是什么。

而做一个产品的开发经理，这么多资源实际上已经分配给你的，你在这个资源的基础上面把它做到最大最好，所以这还是不同的概念。

更加强调统筹的作用，那我们回到技术层面来讲，在你的身上可以看到一个，我认为他是微软一个研发团队的技术变迁史，或者一个缩影。那么我想问的问题是，在你的理解当中，从你进入微软研发团队一直到现在，在整个的产品的开发过程中，主要经历了哪几个比较重大的阶段?

我觉得这个问题非常好，因为你让我回想了一下。确实有几个非常大的不同(阶段)。

在我进微软的时候还是微软比较新，很多产品还是刚刚第一代，像我那时候做Microsoft Access，现在已经无穷代了。那时候刚刚是第一版，当时发布时非常振奋人心的，

如果打一个比喻，就比较像我们80年代刚刚开放的时候，那时候商品比较少，用计算机的人数少，相对来说需求也少。所以那个时候从微软来说，只要发布产品就会有很多的用户来使用。因为我们有很多很基本的需求，而市场上却都没有。那我们发布的产品只要大面上不错的话，就可以非常容易地满足用户的需求。从Word第一版开始发行的时候，前面几版你可以想有很多很多基本的功能是，现在觉得都是肯定是应该有的，但是当时都是很新的东西。

但是产品在做了时间久了之后，等你发布第五版、第六版、第七版、第八版的时候，这时有很多基本的用户需求已经满足了，在那个前提上怎么样把你的产品更上一层楼，这实际上就变成一个相对来说比较困难的问题。很多时候，像我们的Office团队最大竞争者不是别人，是前面一个版本的Office。所以在一开始我觉得我们在微软里边定义产品的时候，比方说90年代初，跟客户沟通之后我们就是用一个Waterfall(瀑布式开发模式)这种Model，因为我们觉得我们知道这个产品应该做什么，我们就把它做完了，然后放在外面市场上，相对来说一定是卖得不错的，卖得很好的，所以这是我们比较成功的一个模式。

自己可以主导?

当然我们还是要跟客户有反馈，一开始要跟客户研究，但是我觉得相对来说做得少，而且相对来说比较容易满足客户的需求。因为那时候大家的基本需求有很多都没有满足。等到我觉得差不多就是99年、2000年，就是差不多那个阶段，我们那时候很多产品已经开发了好几代了，等到那个时候我们就有一个危机，因为我记得是差不多是2000年的时候，那时候客户对我们的满意度相对来说比较低，而且我们跟合作伙伴的关系相对来说比较僵一点，在美国还有很多的诉讼案，那个时候我觉得实际上是微软处于一个比较低潮的阶段。但是从那之后，我们确实就开始转型了，我觉得一个最基本的理念，我自己有这个感受，一开始就觉得说我们可以定义这个产品，定义了以后就做，做完以后卖，这是我们最开始的运营模式。

大概是2000年之后，我们就发现对用户反馈的需求变得非常多，而且一个版本一开始跟用户反馈一次是远远不够的。从开发模式来说，开始时我知道什么是对的，我知道用户需要什么，我只要开发什么，这是我们本来的模式。在那之后，我们的模式时我不太确定用户确实需要的是什么，我们可能要先做一些prototype，试验品出来，让用户去体验一下，体验完了以后再给我们反馈，这是不是他们确实要的，我们在这个反馈基础上再更改。所以你可以看出来整个流程，一开始的想法跟后来想法是不太一样的，而且我们在2000年以后，在后面的开发中，对用户的反馈的需求比以前是大大增加了，而且我们fundamental mindset(最基本的理念)，从一开始我绝对知道什么样是一个对的产品，到我不太确定，那我需要跟用户多次反馈，才能知道真正什么是对的产品，那这两个其实是非常不一样的开发模式。我们之后开始用这种开发模式之后，因为微软作为一个很大的团队，确实也碰到很多的挑战，因为很多时候你要想改一点东西实际上是非常难的。

涉及到方方面面。

方方面面，我就喜欢说，像你要是自己想在家里后院造一个小房子，你怎么改都没有关系。但是你要想造金茂大厦，造到一半想改一点什么东西，那你可以想到有很多的东西要配合。你如果要改一点东西，那对你的电梯、电路、楼层、重量，都有很多的考虑因素在里面。

那作为一个大的开发团队，你怎么样能够同时满足客户的需求，又能够在你的架构基础上能够做这种改动。因为最后你的产品还是要满足客户需求，才能够有卖点。你怎么样做这么一个调整，这也是我们在前七、八年中慢慢转型的过程。那相反过来，你如果看，拿我们Visual Studio作为一个例子，从08年，我们前面几个例子看到我们开始大量的出我们叫CTP(Community Technology Preview，社区技术预览版)，而且跟我们的客户、开发人员的交流变得非常的透明，很多时候我们很早就把我们想做什么，愿意做什么，有的时候把我们写的Spec，就是产品定义放在网上，给我们的MVP(微软最有价值专家)先让他们反馈，我们现在做很多这样的工作，在这之前都是没有的。

对于你们内部的开发团队来讲，产品的设计方面是有很大的挑战，也是一种很大的转型。那么你们在自己做开发的过程中是不是也有一些分为几个阶段来呢?

对!如果是按以前的开发模式，那你可以想到我们更多的是这种，我们现在决定要做这些feature(功能)，这些功能需要这样这样，那就是一条线做下来，最后把它发布就可以了。

就像瀑布模型一样的?

对。如果你要是想象做的功能可能需要在做的过程中调整的话，你中间的每一个开发阶段，就要设计一个跟用户反馈的过程，然后真正把那反馈拿回来，然后在下面一个过程中做调整。同时你还不能把你的那个发布日期改动的太多，所以你就可以看到这个难度实际上是增加了很多。

在每一个改变的环节上，根据刚才我们的交流，他应该是客户来进行推动的。那还有一个问题是，在什么时候你们认为这是一个改变的时机，认为这个开发模式应该改变了，这个产品设计的模式应该改变了，你们做决定的时候，有没有某一个观点来刺激着你们去做这种改变呢?

没有，因为微软很多事情不是Top-Down，不是从上面这么Drive(推动)下来的。第一，从管理层来说，我们比较注重抓的是用户的满意度，看他的满意度如何，就能体现我们跟他一开始交流的够不够。另一方面，比方说我们这个产品真正是有多少用户反馈，而且是把这些反馈做到了产品里面去，这也是我们可以衡量的、量化的。而且很多时候微软有一个团队开始做一个比较好的模式，那其他团队会说，这个模式不错，他也开始借鉴。所以我们这个转型也是慢慢转型，不是说一下子，整个全部团队开始转型，不是这么一个过程。

可能是某一个团队他先采用了某一种方法，然后其他团队开始慢慢的效仿，应该从底下往上推?然后从小到大这么一种方式?

说的非常对，因为我们不是Top-Down。从上面管理来说，你要抓的是最后的那个结果，你想看到的结果是什么，那么你鼓励下面团队去实验不同的方法能够达到这个结果，有的试验可能比较成功，有的试验可能不是很成功，那么你再把成功的这种方法，然后再在其他团队里面推广，一般多半都是使用这种模式比较多。

微软的高层他不会认为就是，OK了，所有的开发团队应该采用这么一种统一的开发方法来去做，他没有这么一种强制的要求吗?

绝对没有，因为微软的产品线非常的长，有各种各样的产品。开发方式实际上就是我们说的Process(流程)，很多时候根据你这个产品不一样，各方面会不一样的。那我对Process理解是这样，就说Process是应该帮助你的开发更有效、更快，很多时候我们觉得Process非常烦琐，时间上会让你慢下来，实际上这个不是它的(目的)，它就是没有达到要求。用另外一个比喻，其实像我们来的路上都是有很多红绿灯，有的地方是有那种转盘。像美国还有一种就是叫Four-Way Stop(四向停车)，就是你到那边停下来看看左边、右边有没有车，没有车就可以通过。那他实际上都是不同的管理交通方式，管理这个车流量的一种方法，根据不同的地点，你要选择最适合地点的一种方法，有的地方如果车流量不是很大，用这个Four-Way Stop就可以了，有的地方可能有六、七个不同的出口，那用转盘是最合理的。有的地方，在美国比方说有的地方你停了电，本来有红绿灯的地方，你停了电就变成了Four-Way Stop，那时这个地方一定是堵车堵得不得了，因为红绿灯可以帮助流量的增加。

开发的管理方法也是非常类似的，根据不同的项目你要选择对你来说比较合适的方法。如果是一个比较小的项目，你用一个heavy weight(重量级)的方法那就是不合适的。这是为什么微软不会从上面说你一定要用什么样的方法，他考核得是你最后那刻做出来的结果，你的结果是怎么样，能不能在你所承诺的时间里面把东西做出来，你做出来东西用户是不是认可，你做出来的东西后面是不是有很多质量问题，还是说很好用。你在做下面一个版本的时候，就可以反映出你前面做的架构好不好。如果你前面做架构延伸性非常差，你第二个版本相对来说就会多花时间，因为要把前面重新(改造)。

遇到很多兼容性的问题?

对，所以这种才是比较硬性的考核标准，那下面用什么样的方式，你自己应该去选一个对你团队来说最合适的方式。

那我们再具体一点，就是你作为一个开发团队的负责人，肯定在整个的团队管理生涯当中，采用了很多新的技术，很多的新的开发方法，那你是有一种什么样的观点来评估这个技术、这个方法是不是应该用在自己的团队里面?

一般还是看结果。我本人是比较愿意去试验新的方法，我会让一个feature crew (功能小组)去试验这个方法。然后给他一段时间，他来给我反馈，这个不管是方法还是新的工具，他有什么优点，他有什么缺点，因为很多时候你想是想不出来，你还一定要去试，试了之后才知道它到底是好用还是不好用，它什么地方好，什么地方不好，就跟车一样，你得要去试开一下。然后在这之后，根据他的好处跟坏处，你还再可以跟现有的方法再看，再评估一下，你是把它全盘拿过来呢，还是把它改动之后再引用，或者有没有什么办法把它好的地方能够结合到现有的方法之中，不好的地方把它抛开不用。

你每换一个开发工具，或者是每换一个开发流程，尤其是团队大了，相对来说实际上是一个比较难的事情。因为你对整个开发、测试，还有工程师，你都要进行一个训练的过程。所以一般来说，我并不鼓励有什么是最热门的，我们都来试一下，因为这个是不太可能达到效果的。很多时候如果一个新的办法在推行之中，大家对这个方法不熟悉，很多时候员工也会有抵触情绪。因为我本来这个用的很好，我也知道怎么用，它里面好的、坏的我都知道了。那现在你如果是一个新的东西，我对它第一不知道，第二没有感觉，然后第三现在我就是不知道怎么跟大家合作，那一开始可能会有生产效率的这种降低。所以从这种方面来说你都要考虑进去，尤其是团队大的话，有的时候是在现有方法之上，说哪些是一定要改动的，哪些是不能改动的，那很重要一方面就是把这个理念，你为什么要改，你不是教你这个团队方法，你要把你想最关键解决的这个问题，为什么你要做这个改动，你现有方法你觉得最最不好的问题是什么，你要把这个问题跟团队讲清楚。那团队在理解了这个东西而且他也认可的情况下，比方说我们以前的开发方法是假设我们知道用户需要什么的，我们现在开发方法是假设我们并不完全知道用户需要什么的。这是一个非常基本的理念不同，你把这个要跟团队讲清楚，那他真正能够明白体会了这个问题之后，那再接下来他会和你一起改进他的工作方法。

工作方法不是我来改进的，是我的团队来改进的。因为他在日常工作(开发、测试)中发现了问题，发现什么是更好的解决方案，他要有这种主观能动性，他要明白我想解决的问题是什么，他才能够主动帮我来想更好的解决方法。那想出解决方法之后，我们大家再分享，一般都是这样。

很多可能都是从底下往上冒出来的?

绝大多数。因为我每天不在那里做开发，我不可能知道什么是最好的解决方案，确实要每天在做的人才会在他做的过程中发现说，我们这个地方好像浪费了很多时间，我们有没有什么好的方法把它给解决一下。他如果是这个涉及比较广，他会跟我们有一个汇报的过程，因为他可能会问我要资源，或者要其他的东西，那在这个时候我会给一些比较方向性的东西：这个问题我早就知道了，但是我现在决定不解决，因为可能有其他的方方面面的原因，所以我不解决;或者说这个想法非常好，我给你资源，你去给我做一个试验原型出来，然后我们再来看一下，这是非常常见的。

那我想作为一个比较成功的技术研发团队的管理者，给我们其他团队的负责人，如果提三点建议有没有什么好的建议?

我觉得对中国团队来说，有些是不是适合国情我就不知道了，但是我先说一下三点建议：

第一，就是真正的要有这种自信心，要去培养你的接班人。而且是不仅是你要培养你的接班人，每一个重要的职位下面都要有一个接班人，而且这个需要和你重要职位的人一起在培养，因为这是打造一个长久的成功的团队非常重要的一点。因为你没有这种传帮带的话，那你这个团队也许是现在可以把这个产品做出来，如果你们有重要人员离职之后，你还能不能是一个成功的团队，这是一个非常重要一点。

第二点，你怎么样能够调动员工最大的积极性，而且我觉得有的时候中国的员工不够主动，你让他做他会做得非常好，但是你不跟他说的事情，他也许就不做。这个我看得比较多，不管在美国和中国的华人员工里面都是比较常见的一个问题。作为一个管理者，你怎么样能够让他能够非常主动把问题告诉你，而且把解决方案也告诉你，这个是从微软文化上面来说是非常重要的一件事情。

第三个方面，从微软来说是人脑加电脑，从我们做IT来说是人脑加电脑，那实际上最主要的还是人脑，那你是不是真的培养员工，真正是让员工在你团队里的重要性充分的发挥了出来，只有在这个时候员工才认可你的管理的方式，才能认可他是这个团队的一员，才能想到怎么样在这个团队里面发挥最大的重要的作用，那这也是我觉得开发管理者应该多思考的问题，和多做的事情。

还有没有其他想和我们读者做分享的呢?

我觉得我们中国IT员工，从IQ上面来说非常的高。而且尤其从钻研角度来说，也是非常(努力)，真的是。我们在微软自己就觉得我们在中国招的大学生素质，比我们在美国招的大学生素质要高，真的是从那个IQ上面来说。

但是，我觉得有一些可能文化上面的东西，可能会限制这些员工的发展。我看到比较多的是，有的时候员工他们碰到一个问题，我觉得可能是考试考太多了，他们看到一个问题，他们不太会去跟旁边的人，一起跟周围的团队里面的人，或者跟美国团队人一起交流，一起想最好的解决方案，能够把大家不同的观点整合起来。很多的时候看到他们自己在非常辛苦地在干。那苦干之后真的是做出来成果就说，你有没有考虑到一二三四五六，那你有没有跟这个人这个人去谈过，好像这方面做得相对来说比较差一点。因为我觉得我们考试的模式就说你不能问别人，你都要自己解决。

我们在工作中都是，你不可能一个人把方方面面都考虑全，这是不可能的。所以你一定要跟你团队里面的人搞好关系，一定要把团队里面帮你一起想这个问题，还有什么其他的观点，而且能够非常坦然的把这个观点结合到你的解决方案中去，那我觉得这方面相对来说就是相对弱一点。而且就是这种主动性比较差，如果你没有跟他说要做什么事情，你交代的我都做好了就完了。那这两方面我觉得中国员工需要想一想怎么样加强的地方。

感谢您接受我们的采访。

谢谢!

5.如何激发研发人员提升团队战斗力篇五

孙子云：上下同欲者胜。激发员工是管理者面临的一个永恒课题，但在团队能力建设的实践中，不少管理者对员工的工作积极性感到困惑。本文中，笔者分享了在困难的情况下通过激发员工来提升战斗力的心得和体会，值得探讨与借鉴。提升团队能力，是研发团队永恒的课题。提升团队能力的基础，是关注下属的成长，其中重要的一点是对下属的激励。根据自己前一阶段的工作实践，在这方面有一些体会和教训。

去年10月份，我作为XXX产品硬件经理兼资源部门主管，正式接管了一个五十多人的硬件开发团队。当时团队的状况是：人员分散、异地开发、新员工比例高，入职不到一年的员工比例超过70％。一般在一个项目组内部，除了项目经理外，几乎都是新员工，但与之对应的任务却很具有挑战性。由于XXX产品的特殊性，所开发和维护的单板复杂度高，要求员工技能过硬。同时，由于XXX产品刚刚转产销售，网上问题也比较多，维护工作量也很繁重。开发工作需要老员工带队，维护工作也需要有经验、有能力的员工攻关，因此，为数不多的老员工工作压力大、加班多，士气有所下降；而新员工由于辅导力度不够，成长速度缓慢。

对于我来说，焦点问题是，在困难的情况下，如何提升团队的战斗能力，使之与我们当前的工作相适应？根据我们团队的特点，我认为重点是需要让老员工发挥更大的作用。越是在老员工稀少的情况下，越是要重视对老员工的激励，只有把老员工充分调动起来，才能形成团队的骨干力量，新员工也才能有一个良好的成长环境。

一、关注老员工，让老员工焕发出新的工作热情

对于团队中的老员工，他们的技术水平相对是比较高的，但是由于长期作战，工作热情逐步减退。同时，工作对他们来说也比较得心应手了，挑战性慢慢在消失，但这些人是团队的技术骨干，对团队绩效起到重要作用，如何激发他们的工作激情是摆在团队面前的最重要的问题。

老员工的激励，尤其是对沉淀下来的老员工的激励，是一个比较困难的任务。谈到激励手段，一般都会想到加薪，但是根据经验，这对老员工并不一定是最好的激励方法。

换位思考，我需要什么？如何才能激发我的工作热情和意愿？我认为是被尊重和自我实现。

团队中有一个老员工A，对CPU板比较熟悉，技能较高，但工作主动性一般，我一直在考虑如何激发他的工作热情。恰好，我们产品有一块CPU扣板出了问题，故障品数量大增，派人去生产线定位问题，也找不到故障原因，严重影响了产品的合同发货。我意识到这可能是一个好机会，于是决定派A去处理这个问题。我找A谈到这个任务后，他本能地借故推脱，说自己手头的工作忙，走不开。我首先认可他承担的工作任务确实比较多，是产品线目前的客观现实，所有人都很忙，作为技术专家可能就更忙一些；然后我强调了这件事情影响很大，希望他能出手力挽狂澜，危难中显英雄本色；同时，也提醒他平时多参加体育锻炼，保重身体。他听了以后，很愉快地接受了任务。果然，只用了不到一周的时间，他就彻底解决了问题。随后，他还做了一件超出我期望的事情，主动写了一套胶片，把这个问题的由来、分析过程和解决方法都详细记录，形成了一个很好的案例。我把这个案例发给项目组所有

成员，要求大家学习，并且给他申请了个人荣誉奖，在部门公告牌上宣传了他的攻关事迹，树立了他CPU专家的形象。

这件事情以后，A的工作主动性显著提高，热心辅导新员工、积极参加评审活动，很好地发挥了技术骨干的作用。即便后来他调到其他部门，对我的求助申请也是积极响应。

二、欣赏个体差异，让合适的人做合适的事

我们似乎存在这样一个思维定式：对于技术能力强的老员工，将来的发展方向一定是要走上管理岗位，有个一官半职，否则就没有发展空间。甚至对于一些立志一辈子做技术工作的员工，这种观念也会对他们的信念形成压力，最终难以留在研发一线。普遍的情况是，研发的老员工如果没有机会升迁到管理岗位，往往会离开研发部门，转其他部门工作。当然，也不是说这种流动不好，但是，当研发所有的老员工都在这样流动的时候，就永远是新人做开发，技术和经验无法得到有效的继承和积累，难以培养真正的、资深的技术专家。

我们团队有一个老员工B，1997年入职，一直工作在研发一线，负责单板开发，善于解决疑难技术问题，是资深硬件专家。他本人对技术很专注，不愿意做管理工作。

但是，随着团队中新员工的不断增加，以及新版本的不断启动，他被任命为一个项目的硬件经理。起初，所有人都认为以他的技术能力，完全可以胜任这个岗位。但事实证明，他不适应、也不喜欢这个新的岗位，对团队的计划、监控、新员工的培养、沟通等各个方面没有感觉，还是对所有技术问题都事必躬亲。干了一段时间，虽然自己筋疲力尽，但团队绩效评价不好。

后来，为了扭转这种局面，我们在团队中提拔了一个技术能力略低，资历较浅，但有管理潜质的员工接替工作。新官上任以后，大胆管理，而B也解脱了烦恼，积极配合工作，主动承担了疑难问题的技术攻关任务，项目组绩效逐渐有了起色。

三、建立共同目标

对老员工有效的激励手段，对新入职的员工不一定是适用的。新员工需要的是建立共同目标、委派有挑战性的工作、提供学习和提高的机会。另外，调薪也是很有效的激励手段。

今年入职的新员工，有工作热情，但技能不足，为了让他们能够融入团队，认可华为文化，首先要树立共同的目标和愿景。因此，新员工到部门报到的第一件事，就是集中谈话，帮助其树立工作自豪感和责任感。我们负责的产品属于高端数据通信设备，因此，根据我们产品的情况，通过例会、学习会和公告牌等形式，向新员工宣传我们产品取得的业绩以及未来的发展前景，使大家意识到我们正在从事着一个有意义的事业，我们打出的每一个市话，都是我们的产品承载的。大家每次提及，都充满了骄傲和自豪。鉴于我们产品的特殊性，这种激励效果是很有效的，新员工回家以后，或者和同学朋友交流的时候，往往会提到这些事情，由此而充满了成就感。

四、调整队形，集中练兵

新员工是团队的未来和希望，需要细心加以培养，但数量庞大的新员工，从某种意义上来讲，对团队的冲击也是明显的。培养不好，一方面可能导致高的离职率，影响团队士气；另一方面，技能不熟练的新员工一旦走上开发岗位，可能会对产品的质量造成隐患。

根据团队的实际情况，我调整了团队的结构，把绝大部分新员工集中在维护项目组，由两个老员工带领，负责转产单板的维护，这样做，可以一举多得。第一、新开发的单板质量有保证，不会出现老员工在排雷，新员工继续埋雷的情况；第二、可以对新员工进行集中式的培训，减少了老员工的辅导时间和人力投入，节约了资源；第三、从培养过程的科学性看，有利于培养员工的实际动手能力，避免了理论与实践分离的问题，能加速其成长。

这个政策在实行中，发挥了很好的效果，因此，我将其作为一项制度固定了下来：凡是到团队的新员工，首先分配到维护项目组工作半年，以后视情况再分流到各个开发项目组中。这样，开发项目组收到的员工都具备一定的实际工作经验。更重要的是，他们在维修单板的过程中遇到的一些设计问题有切身体会，在开发过程中基本不会旧错重犯，这不仅提高了团队的效能，也提高了新员工的成就感和归属感。

总结

团队建设和员工的激励，是研发团队主管的主要责任。激励员工的手段是多种多样的，要具体情况具体分析，没有普适的措施，但都遵循相似的原则：要有同理心，站在对方的立场上考虑问题。

开放心态、注意倾听、不要自以为是，以平等、关注、尊重的态度与下属沟通。老员工是团队的宝贵财富，是团队的骨干和支柱，以合适的方式激发他们的工作热情，会达到意想不到的效果。

加薪确实是激励手段，但不是万能的。

对待新员工，重点是培养，提供成长的机会。新员工自己感到能力的提升往往是最好的激励手段。

6.东方海外软件研发中心笔试篇六

1. J2EE的认识，面向对象和UML的认识(吹水题)

2. 给出一段程序，写出运行结果(可惜是java题，看不太懂)

3. 给出一段程序，写出程序的作用及输出，并判断程序是否有错或是否可改进(具体题目内容忘了)

4. 编程题：判断N个整数(其值都是在1-N间)是否有重复，

这道题我还是用基本的循环做，估计它是要考虑时间复杂度的。

5. 单身类(singleton)的实现;SQL语句(学生-课程-成绩问题);给定程序判断程序在运行时产生多个个对象。

7.软件研发团队管理制度篇七

项目驱动型公司是通过做一个个项目来发展的。但是随着公司规模的扩大, 要想使企业在未来市场竞争中处于不败之地, 仅仅通过完成一个个零散的项目是很难实现的。研发具有自主知识产权的、能够持续发展的软件产品, 将会进一步增强企业的核心竞争力。项目驱动型公司要想做好产品研发, 尚有诸多需要解决的问题:

(1) 缺乏一套系统的产品研发指导方案;

(2) 认为产品研发只是研发部门的事情;

(3) 缺乏公司级进行产品规划、产品开发决策的组织;

(4) 职能化特征明显的组织结构, 跨部门团队协作困难;

(5) 组织机构单独核算, 自谋发展、各自为政, 产品重复建设、利用率低;

(6) 缺乏对产品研发管理各个环节进行整合的结构化流程;

(7) 缺乏对产品研发人员的培养方案、考评机制;

(8) 缺乏统一的产品研发管理的IT支撑平台;

(9) 技术研发与产品研发没有分离;

(10) 偏向技术产品研发, 与业务分离;

(11) 缺乏平台, 跨项目共享差, 交付成本高。

2 主流新产品研发管理模式

2.1 以项目管理的职能式开发

这是企业通常采用的产品开发模式, 往往是在不窥全貌的情况下做出新产品的开发决策。

本模式关注的是各个部门的纵向管理, 缺乏对盈利模式, 产品概念, 研、产、供、销一条龙的横向关系管理。容易发生总经理“救火”的现象。

2.2 产品及周期优化法

产品及周期优化法 (Product And Cycle-time Excellence, PACE) 是当前企业流行的集成产品开发 (Integrated Product Development, IPD) 方法的理论基础。PACE认为产品开发要关注七个核心要素, 它们提供了必要的基本管理构架来管理产品开发项目, 并将这些项目在企业内部整合成一个整体。

单项目管理的四要素:阶段评审决策、跨职能的核心小组、结构化的开发流程、各种开发工具和技术。

跨项目管理的三要素:产品策略、技术管理、管道管理。

2.3 集成产品开发 (IPD)

IPD是一套产品开发的模式、理念与方法。IPD的整体框架如图1所示。

IPD的框架可以概括为集成组合管理团队和产品开发团队两个跨部门团队、两大流程 (市场管理流程和IPD流程) 和一系列的要素。

IPD的七要素:

(1) 异步开发与共用基础模块

将产品开发工作分解为不同层次的任务, 通过减弱各开发层次间的依赖关系, 重用已有的公共基础模块实现技术开发与产品开发的分离。

(2) 跨部门团队

指由开发、生产、采购、财务、制造、客户服务等不同部门人员组成的贯穿整个产品开发过程的团队。

(3) 结构化流程

指相互关联的流程活动有一个框架结构, 结构化流程的特征之一是在流程的不同阶段有对应的决策评审点。

(4) 项目管理和管道管理

项目管理指在产品概念产生到产品投放市场的过程中建立规范的管理方式;管道管理指同时对多个项目的资源进行有效的平衡。

(5) 客户需求分析 ($APPEALS)

用于了解客户需求, 确定产品市场定位的工具, 它从八个方面衡量客户对产品的关注。通过$APPEALS的分析, 可以确定产品的哪一方面对客户是最重要的。

(6) 投资组合分析

指对在市场上处于不同竞争位置的产品, 根据市场需求作出产品开发的投资决策。

(7) 管理的衡量指标

从商业的角度对产品开发过程中不同层次人员或组织的工作绩效进行衡量的一系列指标, 更多体现在商业层次, 例如:市场占有率、人均利润等。

2.4 门径管理系统

门径管理系统 (Stage-Gate System, SGS) 将新产品发展切分为各个不同的五个阶段。每个阶段包含一套平行活动, 由来自公司中不同部门的人员同时进行。在大部分企业的阶段关卡流程中, 阶段提供一套对企业有利的活动建议, 即可做为标准的实务操作。每个阶段在设计上都将搜集必要信息, 以使方案得以进展至下一个关卡或决策点。每个阶段都是跨部门, 没有任何阶段为单一部门所专属。

在每个阶段之前, 都设有关卡或过关 (Go) /淘汰 (Kill) 决策点。关卡是新产品发展之质量控管的检核点, 是过关/淘汰或优先级的决策点, 可以决定接下来在流程中采取的方向。

2.5 产品价值管理

产品价值管理模式 (Products value management, PVM) 的主要核心内容:

(1) PVM十分重视盈利模式和价值链分析, 强调产品规划和产品管理。

(2) PVM认为需要有效的产品开发流程入口管理和决策评审, 把产品开发流程和市场管理流程有机地融合在一起。

(3) PVM突出产品需求分析、产品概念和营销组合的协调。

(4) PVM强调项目管理对于产品研发的核心作用, 主张产品管理实行产品经理制。

(5) PVM关注技术开发平台建设、核心技术开发和成本价值工程, 认为系统化的思维方式是改善研发绩效的正确途径而非KPI+BSC。

(6) PVM认为企业就是经营核心竞争力, 倡导R&D策略联盟。

3 过程能力成熟度模型集成

过程能力成熟度模型集成 (CMMI) 的核心思想:

(1) 过程质量决定交付质量

CMMI将开发活动划分为22个过程域, 每一个过程域是关注研发项目中某个方面, 并且在CMMI标准中也有定义和相应的工具方法。强调组织只要严格按照规范化的过程去开发, 便可以保证最终交付的质量。

(2) 组织能力需要持续改进

CMMI将组织的研发能力划分为5个等级, 每个等级有详细的标准, 建议组织根据自身能力、实际商业需要、组织资源多少灵活决定组织优化改进的目标。

CMMI的核心目的是用于衡量和改善组织过程能力, 强调过程规范性, 最终达到保证开发交付质量的目的。

4 敏捷开发

2001年, 敏捷联盟起草了一个旨在鼓励更好的软件开发方法的宣言, 称为敏捷联盟宣言。该宣言是敏捷软件开发方法的核心。

敏捷宣言:

●个体与交互重于过程和工具;

●可用的软件重于完备的文档;

●客户协作重于合同谈判;

●响应变化重于遵循计划。

敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。Scrum和XP (Exercise Priority:极限编程) 就是敏捷开发的具体方式, Scrum偏重于过程, XP则偏重于实践。

5 项目主导的软件产品研发管理模式

对于项目驱动型公司产品研发管理模式的制定, 应该在现有项目管理体系基础上进行扩展, 引进业界成熟的适用的产品管理框架体系。

公司在项目管理中一直研究并实践着CMMI体系, 目前组织能力成熟度已经达到一定的高度;从上边几种产品研发管理模式的分析, 可以看出IPD在国内企业已被广泛深入应用;为了能够快速响应市场的需求变化, 以及技术产品研发的不确定性, 必须把敏捷开发模式考虑进来, Scrum是最好的选择。

项目主导的软件产品研发管理模式将是IPD+CMMI+Scrum三者的融合、一体化的方案, 在不同方面利用三者各自的特点, 分别对产品研发方向、质量和速度给予充分保障。

(1) IPD强调市场驱动、投资回报, 将市场、财务、竞争、技术有效融合为一体, 所以利用IPD来确保产品研发方向的正确性以及产品全生命周期的管理;

(2) CMMI强调项目的规范性、精细化管理, 所以利用CMMI将IPD的策略落实为具体的计划、流程、制度、模板、控制方法;

(3) Scrum强调快速迭代, 所以利用Scrum将CMMI制定的整体项目目标, 切分为短期能实现的具体目标, 满足市场快速变化、快速交付的要求。

出于对所需时间、成本、公司现状、IPD各要素的实施难度的考虑, 项目主导的软件产品研发管理模式没有必要从开始就把IPD的七个要素全部纳入进来, 首先实施需要紧迫解决的跨部门团队、结构化流程、异步开发与基础模块这三个要素, 具体细节中融入CMMI和Scrum的有关理念, 以后再逐步补充完善这一模式比较好。

5.1 组建跨部门团队

项目驱动型的公司, 产品研发的需求来源之一是各个项目, 成品后的服务对象也是各个项目, 所以从组织结构上把产品研发部门、项目承接部门、其他职能部门严格分离开来是不利于产品研发和推广应用的, 必须集成起来, 消除产品研发只是研发部门的观念, 消除跨部门协作的壁垒, 消除信息孤岛, 成立跨部门的团队, 既让产品有研发依据也让产品有用武之地, 从组织上为产品成功提供保障。

在IPD中有两类跨部门团队, 一个是集成产品管理团队 (IPMT) , 属于高层管理决策层;另一个是产品开发团队 (PDT) , 属于项目执行层。

建议IPMT由公司高层领导, 由产品研发部门、项目部门、销售部门、财务部门、质量管理部门等部门的相关领导组成。IPMT的主要职责是: (1) 产品需求管理; (1) 产品战略规划制定; (3) 产品业务决策评审; (4) 产品技术评审; (5) 产品在项目中的推广应用; (6) 保证产品满足项目要求; (7) 产品的生命周期管理。

建议PDT由产品研发部门、项目部门、质量管理部门相关成员组成。PDT的主要职责是:产品需求的实现;产品的测试、发布;产品在项目中应用的支持。

5.2 制定结构化流程

结构化流程是基础, 尤其是在跨部门团队下, 更需要形成统一的打法, 同时流程作为载体可以有效固化经验教训。IPD流程中的1个主流程和6个阶段流程均属于项目级的流程, 10个子流程属于功能过程管理级的流程。主流程和阶段流程需要这些子流程的支撑, 由跨部门团队进行计划和管理。10个子流程与CMMI的项目管理、流程管理、工程管理、支撑管理四大管理能够很好地融合。

整体产品开发过程按照IPD运作, 从产品立项开始到量产发布结束, 涵盖概念、计划、开发、验证、发布、生命周期6个阶段, 4个业务决策评审点, 7个产品级技术评审点;过程中相对独立的设计、实现、验证环节时, 严格按照CMMI的规范要求进行;验证之后, 把各个子系统开始整合时, 按照IPD的流程规范来执行。在实现比较小的模块部分, 采用Scrum方法完成。

5.3 采用异步开发与共用基础模块

异步开发与公共基础模块是公司应该指持续引进和坚持推广的理念。通过异步开发, 使技术开发与产品开发相分离, 技术先行, 从而有效降低产品开发的风险, 缩短产品推广的时间。从各个项目上, 通过不断地分析、抽取、构建共用基础模块, 搭建起公司的技术货架和产品货架。基于这些共享的技术货架和产品货架开发的产品或实施的项目, 无疑质量、速度和成本上会得到更好的控制和保障。

6 结语

本文在项目驱动型IT公司的现有项目管理成熟度基础上, 融合了被国内很多企业应用的IPD模式。考虑到IPD在一个企业中实践的难易度以及对企业实现各要素的紧迫性, 选择了IPD七要素中的跨部门团队、结构化流程、异步开发与共用基础模块作为优先应用的要素。同时考虑到产品研发本身的特点, 在某些环节上采用Scrum方式更可取。所以探索出的这套IPD+CMMI+Scrum三者融合的模式, 能够很好地满足项目主导的软件产品研发管理的需求。

参考文献

[1]周辉.产品研发管理[M].北京:电子工业出版社, 2014.

8.软件研发团队管理制度篇八

关键词：“金工硬剪纸”；特色产品；研发团队

1 背景分析

自2010年开始，珠宝专业在课程设置上增设了金工制作类课程，经过几年的课程内容改革和师生的共同努力，研发了一系列金工硬剪纸作品，并于2016年8月，成功申报了国家实用新型专利。随着专利的成功申报，“金工硬剪纸”系列作品参与对内对外礼品制作达120余件，并参加了北京国际珠宝展学校展团的展览，深受好评。面对大众对金工产品的需求日益旺盛的良好态势，单纯地依靠师生课上制作不足以满足各方的个性化需求，急切需要设置专门的部门和人员来进行“金工硬剪纸”特色产品研发。

2 金工硬剪紙产品介绍

2.1 金工硬剪纸定义

金工硬剪纸，创意灵感源于中国传统文化——剪纸。该系列产品主要采用金工首饰制作工艺：利用吊机打孔之后，用锯弓进行直线和曲线锯切，参考给定的图案完成作品。“金工硬剪纸”产品，可用于个人观赏或作好友间馈赠礼品，属于艺术品范畴。

2.2 专利

“金工硬剪纸”已经作为一种实用新型专利受到国家专利法保护。专利名称为：包括金工硬剪纸制品的框式装饰物，专利号：ZL201620082178.X，专利权人：北京市商业学校，专利发明人：武改朝、田禾、杨轶等等。

2.3 产品内容

现已开发出6个系列的“金工硬剪纸”产品：无框书签类、普通背板类、人物剪影类、书法设计类、设计背板类、分部组合类等。分类的参照标准为：有框无框、背板设计等。当然，分类标准也可以参考：人物、花鸟、LOGO、传统文化等。具体内容包括：十二生肖、花鸟剪影、人物剪影、中国传统文化（龙凤呈祥、凤穿牡丹等）、北京文化（天坛、长城、鸟巢等）等（见图1、图2）。

2.4 目标

十六字方针：产品导向、专利保护、磨砺意志、精炼技能。

3 研发团队设置建议

借助祥龙雅信公司平台，实行专人负责，成立专门的特色产品研发运营团队。团队设研发主任1名，副主任2名，分管两个工作组：研发组和运营组。工作组成员可以由师生共同组成。

3.1 研发组人员构成及主要职责

（1）人员构成。组长1名（老师负责），组员若干（可以含学生若干）。

（2）主要职责。包括产品设计、产品制作、售后服务等环节工作。

3.2 运营组人员构成及主要职责

（1）人员构成。组长2名（老师负责），组员若干（可以含学生若干）。

（2）主要职责。主要负责市场调研、客户开发、宣传（包括公众号、纸媒等）、销售（包括网销、微店销售、实体店销售和各类促销活动等）、客户维护、售后市场分析等。

4 研发团队考核及运营利润分配办法建议

4.1 教师