研发团队管理制度

相关推荐

研发团队管理制度

为什么研发团队的管理很重要?

研发团队管理制度

新产品开发日益成为企业成功经营的核心。持续推出新产品将使企业立于不败之地，而卓有成效的新产品开发取决于优秀的新产品开发团队。人们的共同结论是"有什么样的开发团队就有什么样的新产品"这可以说是一条定律。大至一个企业的新产品开发活动质量，小到一个具体的新产品开发项目的质量，接触和评估其团队都是最直观、最有效的方法。对新产品开发团队的评价来源于相互作用的三个方面：团队中的个人、团队机制和团队文化。对于企业的高层管理者来说，他们当中的很多人并不是产品专家，他们对于新产品开发的管理更多地体现为对新产品开发团队的管理。

研发团队有哪些形式?

新产品开发团队的组织形式是由新产品开发项目的性质决定的。开发团队的组织原则是：开发项目越复杂，对企业的意义越重大，开发团队就越独立，就越需要减少企业日常工作的影响。对于消费品企业，开发团队一般有以下三种类新产品开发团队类型新产品项目性质团队类型团队特点管理要素新平台产品开发独立的专职团队独立于企业日常运营保持独立性财务目标完善现有产品线跨部门临时团队开发工作与其他日常工作并行部门协调机制产品技术改进技术改进团队范围最小，方式灵活把握项目运行的时机

"跨部门临时团队"的组织形式是在消费品的新产品开发中最常见的、基本的组织形式，于管理的组织形式。说它"基本"，是因为在其它两种团队类型的早期，经常以"跨部门临时团队"的形式出现;说它"难于管理"，是因为部门之间存在着观念和信息的"壁垒"，这些壁垒很难打破，而打破这些"壁垒"，恰恰是新产品开发管理的关键。正是基于以上原因，"跨部门临时团队"是我们论述的重点。在很多高技术企业，技术开发团队多采用独立的专职团队形式。开发人员被"关"在一个舒适的、"与世隔绝"的空间里，在特定的时间内展开"科研攻关".

研发团队如何形成好的机制?

建设开发团队的工作机制，其目的在于沟通信息、明确责任、协调进度。工作机制可以分为两种：正式机制和非正式机制。正式机制多体现为团队会议，非正式机制则是不同部门的开发人员之间的随机交流。在很多消费品生产企业，新产品开发项目的主要责任者是市场部门和研发部门，因为他们是新产品的设计师、知识源和"专家".开发团队的工作机制首先是这两个部门的协调机制，然后才是由这两个部门主导的团队工作机制(见表2)。

表2 新产品开发团队的工作机制参与部门主要内容关键备注研发-市场部门联席会议市场部、研发部门定期交流所有项目情况，确定开发方向，产生新项目。长期坚持。有些企业叫做"新产品开发委员会"，范围也有所扩大。

项目运行会议项目组所有成员在某个项目里程碑完成后评估项目运行情况，做出下一步的安排。完成情况的可靠性。

项目回顾会议项目组所有成员项目完成或终止后对项目整体运行的总结。真正明确失败原因。避免犯同样的错误，形成指示和经验积累。

总结报告制度市场部或研发部项目经理负责项目每一阶段结束后汇总项目运行情况，并发给每位项目组成员。保证决策信息的真实性。

对于那些非正式的团队机制是不好用制度规定下来的，非正式的团队机制在很大程度上受到团队文化的制约。

如何建立研发团队文化?

新产品开发团队文化是企业整体文化的组成部分，因此新产品开发团队文化具有企业文化共有特性，又有它的独特性和自身要求

观察新产品开发团队文化最有效的方法是"听"，听听他们在交流中说些什么，是否符合新产品开发活动的内在要求。如果没有好的团队文化，新产品开发过程中就会出现一些莫名其妙、看似荒唐但却是不可挽回的严重失误。很多企业的研发经理为这些失误感到苦恼，但他们往往在失误本身上找原因，却没有看到隐藏在失误背后的不健康的团队文化。新产品开发团队文化与新产品开发所需要的专业知识和技能无关，但是它却深刻地影响着新产品开发工作的质量，甚至可以说是团队文化塑造了新产品。在很多美国公司，高级的研发领导人甚至没有技术背景，但他们依然可以卓有成效地领导产品研发，其中一个重要原因就是他们有能力塑造一个优秀的研发团队文化。塑造团队文化的最好方法是企业高层管理者的率先垂范和团结一致，而不是期待基层开发人员的自觉。一家公司的高层采购经理认为，产品开发所需新原科的采购在他的工作中并不重要，重要的是现有原材料的采购维护;一家公司的生产总监认为，新的生产工艺会破坏现有的生产秩序，所以需要抵制;一家公司的技术总监认为，他的责任只是产品开发成功，至于主动组织新产品知识培训则不是他份内之事;一家公司的总经理问道，为什么开发人员总是不切实际，异想天开?这些企业的高层经理抱有这样的观点，新产品开发团队文化也就可想而知了。所以，建设良好的新产品开发团队文化，需要高层管理者从自身做起。

总经理如何管理研发团队?

除了把握企业战略和产品方向外，总经理对新产品开发活动的管理在很大程度上体现为对新产品开发团队的整体管理。总经理很难深入新产品开发的技术细节，但在中国企业中(尤其是民营企业)，总经理对新产品开发工作影响巨大。对这个问题的探讨，具有极为重要的现实意义。建议总经理对新产品开发团队的管理应注意：

(1)容忍创新的"健康失败".鼓励创新首先意味着有创新的意愿，其次意味着容忍"健康的失败".所谓"健康的失败"是指那些付出了真诚努力的失败。产品创新的历程从来不是一帆风顺的，某一点的改变可能会引起连锁反应，"牵一发而动全身".改变固然会有失败的可能，但不改变就不会有成功的新产品。在一个"动辄得咎"的环境里，不能想象产品创新的成功。总经理对产品创新的影响首先在于培育一个创新受到鼓励的环境。

(2)培养"专家意识"，减少对开发细节的干涉。产品创新的专家首先是那些敢于对产品创新负责任的人，其次才是拥有丰富产品创新经验的人。在企业里经常发生没有人敢于对产品开发负责的现象，决策"议而不决"，然后由总经理判断而"定于一尊".企业家不是神，不能洞悉一切风险，这种决策方式从一开始就孕育很大的风险。总经理需要明确责任，鼓励负责任的勇气，才可能在企业内部培养出"专家".

(3)打破技术部门的壁垒，重视专业的横向交流。技术部门在中国企业中一向是"管理的黑箱"，只看到投入产出，看不到里面发生了什么。但技术过程对产品方方面面的影响极大。总经理应该鼓励技术部门走出"黑箱"，与市场、采购、财务乃至销售部门建立交流的机制，使技术部门看到他们的工作对企业其他部门产生了怎样的影响，而技术部门也会看到产品创新的广阔机遇。

(4)给开发人员开阔视野的见习机会。创新经常来自于换一个角度来看问题，来自于找到正确的基准。一年到头埋头于实验室的开发人员创新精神一定是不活跃的。给开发人员参观、学习、研讨的机会，回过头来审视自己的产品，就会产生新的认识，产品创意就蕴含在这些新的认识当中了。

几个软件研发团队管理的小问题2015-10-29 10:54 | #2楼

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将会提出申请，一旦批准，他的头衔随之提高，薪水也会有相对较大提高。从而使每个开发人员觉得“有奔头”，自然他们的主观能动性也就提高了。

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

【研发团队管理制度】相关文章：

研发管理制度04-17

团队管理制度03-10