本章试图阐述对于互联网产品研发团队而言，如何基于前面几个章节所述的组织架构、工作模式、产品特点，建设团队及成员的评估和激励的思路。

软件工程的研发是一个创造性的技术类工作，而对互联网这类的持续周期长、阶段性弱的产品来说，对软件工程的质量和创新力的要求是比较高的，结合前文中对组织结构和工作模式的设计，以什么来度量产品研发团队的工作效能，应该有着与其它行业（劳动密集型、销售型、项目型等等）不同的方式。

在前面的章节中，一直围绕着核心目标：“建设敏捷、自驱的研发生态，打造持续快速的价值交付能力”而设计的组织结构和工作模式，关注的是需求这个“用户价值和业务价值的载体”，在整个组织中的快速流转。那么，在设计度量指标的时候，就应该更多的去关注价值在端到端流转过程中的“流动效率”，而较少关注支撑价值实现的“资源效率”。

流动效率：需求从提出到交付的时长、上下游团队等待时间的占比、缺陷创建和修复时间分布等。

资源效率：资源的忙闲程度、使用率、执行速度、错误率等。

很多组织对研发团队实施的考核，都会以“资源效率”为重点，来设计考核的指标（KPI），在我经历和了解过的公司中，还没有取得良好效果的案例，甚至会带来组织僵化，因为软件工程研发的过程中，会有几个比较突出的特点，会与以“资源效率”作为考核的指标产生冲突：

  1. 软件工程的研发需要在促进团队间、人员间协作、互助的环境下，可以产生较好的效果（开发的效率和质量），软件工程的研发是一个团队共同为一个目标努力的过程，期间需要较多的跨角色、跨团队的协作互助。

    这里提到的质量并不单指交付给用户的功能质量，而更多的是软件工程的质量，也就是Ward Cunningham所提出的“技术债”，随着技术债的增长，会使整个组织陷入裹足不前的艰难境地。技术债越多，效率越低，成本越高。

  2. 研发的过程中，经常需要去改动别人产出的成果。新的需求要建立在历史成果（现有代码）上进行，或对发现的可以优化的代码，随时进行重构，以优化工程的可维护性、可扩展性（也是为了减少“技术债”）。

    只要改代码，就有可能产生缺陷，而代码对于程序员来说，代码就是操作技术世界的手。

  3. 团队每个成员的创造力叠加，会为工程研发及产品、业务注入活力，但创新就会试错，就会带来问题，而“程序员”又是一群渴望以技术驱动创新的人。

  4. 很多观点和实践都说明了基于知识积累的基础上，更好的激发创新、产生创新的环境是：在放松的环境、放松的心情时；放空自我后；

以“资源效率”作为考核，通常会设计两个主要的指标：工作量和缺陷率。对工作量和缺陷的管控，看似一切都可控了，其实会对上述特点带来负面效果，以工作量作为指标，会减少协作互助，增加内耗；以缺陷作为指标，反而会增加工程的技术债，写出的代码更偏向于“可运行的代码”，而不是“可交付的代码”，带来工程可维护性、可扩展性问题。团队逐渐向，大家只关心手中的任务，对出现的问题相互推诿的方向发展。

对于工作量的评估，如前面章节对“迭代计划的评估过程”中所描述的，当工作量评估完了，那对评估结果的准确性、合理性的判断，又会成为难题，外行（非技术人员）判断不了，你说高了，程序员会告诉你听不懂的原因，内行判断又需要了解这个需求开发的结果、系统设计的结果、执行人员的能力，这些判断的依据，每个人的标准还没法做到一样，都是主观性的。

上有政策下有对策，现在对于KPI也好，OKR也罢，员工都有了各种办法可以“适应”考核，让员工把心思用到如何“适应”考核上面真的好吗？

当然，社会面的一些影响也促使了团队采用以“资源效率”作为考核的方式，中国的软件行业，很长一段时间都是在复制别人的产品、复制别人的经验，打价格战，大量同质化带来的竞争，企业对经济效益的重视程度大于价值和持久化，过多的投机，这些都需要依靠控制“资源效率”来降低成本。随着市场的变化，对建设技术壁垒，促进技术创新的大环境也在改变，对“资源效率”的重视程度也会逐步降低，而更多的关注创新和价值流动的效率。

基于”流动效率“如何设计度量研发效能的指标，阿里的研发团队会关注下面几个方面：

  • 持续发布能力

    • 发布频率：团队对外响应的速度不会大于其交付频率，发布频率约束团队对外响应和价值的流动速度
    • 发布前置时间：体现了团队发布的基本能力，如果时间开销很大，就不适合加大发版频率

  • 需求响应周期

    • 交付周期时间：反映了整个团队，对客户需求和业务机会的响应速度
    • 开发周期时间：反映了技术团队的响应速度

    区分交付和开发周期，是为了解耦并明确问题，以做出针对性的改进，交付周期时最终的目标和检验标准

  • 交付吞吐率

    • 单位时间交付用户需求数量：单位时间内，交付需求的数量，关注整个团队的需求交付吞吐率的前后对比，反应交付效率的趋势和问题，间接体现资源效率

  • 交付过程质量

    • 缺陷发现和修复时间分布：希望缺陷能够持续和及时的被发现，并能及时的修复掉，尽快去除价值流转过程中的阻碍
    • 缺陷库存：在整个开发过程中控制缺陷库存量，控制在一个比较低的水平，让产品始终处于接近可发布状态，奠定持续交付的基础

  • 交付质量

    • 单位时间问题数目：尤其关注那些对业务造成重大影响的故障，越少越好。
    • 线上问题解决时长：线上问题从发现到解决的时长，越短越好。

关于团队的激励，个人内在的驱动力（自驱力），要比任何考核、监督、管理都有效，尤其对研发类的行业或工作来说。我认为，“程序员”一定是要把编程当做兴趣爱好，才能在这行干的下去，如果是因为这行收入高而去学习了编程，又未产生兴趣，那多半是入错了行，工作的过程无法带来快乐不说，产出的价值也会低，甚至会产生很多负价值。现金激励是对自驱力成效最快，但持续效果最短的一种激励方式，人性本贪婪，与个人期望的差距控制不好，还会带来负面效果，而与组织的共同成长，带来的归属感和成就感，对自我的提升，适合的工作环境和制度，都会产生更好的效果。对于组织来说，激发人才的自驱力，从长远来看，才是节省资源且效果显著的终极解决办法。组织可能应该更多的从创造自由的工作环境和制度，建立长效的股权激励机制（或与组织发展联动的激励机制），打造学习型、自驱动的组织入手，从而实现团队的生态化管理。

对技术团队的管理，要了解技术人，要应用技术思维、技术的方式去管理技术人，没有哪个技术团队愿意被一个外行管理。

本系列文章是一个不依赖实际产品、团队、技术架构的，进行了泛化、抽象化的一个指南性质的文章。将分几部分来阐述“互联网产品的研发模式和提升研发效能”这个主题的关键点及可行实践，意在抛砖引玉。在实际落地时，可参考此指南，根据组织、产品及团队的特性，进行组合或优化使用。

1.引言
2.几个重要的观念
3.形而上
4.设计组织架构
5.1.工作模式设计——需求处理
5.2.工作模式设计——迭代规划
5.3.工作模式设计——其它事务
6.建立可视化协作机制
7.进行评估和激励
8.附录