提升IT产品研发效率的思考
前言
效率是任何企业经营管理的核心关注点，如何提升效率也是众公司不懈的追求。按工作性质企业可分为生产型与研发型两类，前者存在历史悠远且由于个体的工作产出可计件计量，大部分改进可量化（比如更新流水线可带来多大的产量提升），因而有比较成熟的提升效率措施，KPI考核则是其著名的经验总结，但研发型的企业则在如何提升效率上几乎裹足不前，以软件行业而言，KPI导向的考核是失败的，OKR的方式要做成也很困难，各类提升效率的做法也仅仅是以点盖面，局部适用，没有Get到本质。
当前提升效率的做法及问题
我们先看一下主流的一些提升效率做法：
- 加班：这是用得最多，但最无法提升效率的做法，应该明确的是效率是单位时间的产出，而不是工作时长，所以加班也许对加快进度有那么一点作用，但由于人每天精力最好的也就那么几个小时，所以效率肯定会下降
- KPI/OKR：这是试图以考核/激励制度的手段改进效率，KPI之于研发是各种水土不服，通过它做得好的项目也乏善可陈，OKR更像是一种正向激励制度，相比KPI改变了目标确立的方式，有很大创新，只是实施难度很大
- 271考核：有很多不同比例的变种，看似很有用，现状是大部分IT公司都在用，但各项目的效率还是无法提升
- 敏捷与DevOps：这是我比较认可的流程管理方式，但弊端是对个体素质要求过高，在国内恐不具备普适性，实施中也需要做一定地裁剪
- 各类奖金：比较常见于年终奖与项目奖，问题在于大部分公司这类奖金好差区分不明显，把差距拉大对公司的开支又将是不小的压力
- 期权股份：这更多的是留人的做法，对提升效率关系不大
- 文化教育：企业文化的确可以在一定程度提升效率，但问题是这是一种形而上的东西，要让员工认可很难，很多公司都推狼性文化，但做着做着就是成了没人性文化
- CMMI/PMO：试图以规范的流程及独立的项目管理机构解决研发核心问题的做法，从项目立项、执行到效果分析覆盖产品的整个生命周期，其目标是：
1）减少不必要的需求
2）明确权责划分
3）规范研发流程。
但CMMI不适用于新项目，新的项目需要不断试错，不能拿过程去衡量业务提出的需求是否合理，新的项目需要快速响应，明确的权责划分及规范的流程导致不够敏捷，另外CMMI对个体效率提升没有太多作用
效率提升的关键
首先明确影响产品研发效率的因素：
- 流程制度：没有规矩不成方圆，好的制度必定是以减化流程、明确分工但又强调沟通协作为核心构建。对比Scrum为代表敏捷流程与CMMI为代表的传统流程，前者理念先进但很少有公司可以做好，后者比较笨重，但在企业软件研发中有比较大的市场，所以没有绝对优劣的制度，制度的好差都是相对于适用的公司、团队而言
- 团队士气：研发是能动性很强的工作，工作产出无法量化。产出很大部分是看心情，一个员工心情好时一天可以coding 1000行代码，心情差时可能100行都不到
- 成员能力：巧妇难为无米之炊，成员的能力是产品研发的先决条件，能力与待遇成正比。任何公司都想用高岗，想组精英团队，但并不都有对应的财力支撑，所以绝大部分公司都是“低岗中用，中岗高用”美其名曰给成员成长机会，当然这没什么毛病
影响效率的因素还有很多，但这三个是最核心的：成员能力决定某产品公司能不能做，团队士气决定能做得多好多快，流程制度决定公司及产品能走得多远。
我认为提升效率最好的方案
在提出我的方案前先思考两个问题：
- 当前哪种组织形式效率是有目共睹的？
- 为什么总是说缺人？
第一个问题我的看法是众包及初创公司，第二个问题主要是团队士气不足，众包及初创公司没有大公司的财力，也没有太多的大牛及富足的人员配给，但却能做出让大公司瞠目的产出，靠得就是士气、斗志。要是有团队告诉你“别给我加人了，这些人就够了”那就成了。
我认为最有效的方案是：系统划小+责任承包+服务规约。
组织架构，整体分三个组
1.架构设计组，业务、产品、技术架构师组成，负责产品的业务架构及产品模块划分，形成标的及后续的成果验收
2.任务开发组，技术架构师、开发、测试组成，本组员工待遇分基础工资及项目分红，员工自由组队，参与项目竞标并完成任务
3.服务支撑组，技术架构师、开发、运维组成，负责两件事件：1）开发维护服务支撑平台，提供中间件、确保各个项目基于统一的服务契约下开发并可彼此协同，2）统一管理线上环境，提供CD流程、测试环境支持
研发流程说明
1、[架构设计组]公司商务或内部发起产品计划，业务与产品经理一同设计产品目标及功能，技术架构师将产品功能分块，形成一个个相对独立的微服务
2、[架构设计组]发布任务标的
3、[任务开发组]各团队参与任务竞标
4、[架构设计组]以利益最大化为原则，择优选择团队
5、[任务开发组]被选中的团队在服务支撑平台的服务契约下，按业务要求完成开发测试
6、[架构设计组]任务验收及费用结算
7、[服务支撑组]部署上线
优势
系统划小：更清楚地边界定义、最小化的需求反复、尽快速的版本迭代
责任承包：对员工而言最大化激发员工的积极性，做得越快越好收入越多，对公司而言更短的交付时间更少的成本投入，做到这个何来公司逼员工加班之说
服务规约：打通各服务，形成有机整体
方案答疑和外包的区别
劳务关系上归属公司，统一的团建、培训，稳定的工作地点及人际关系。
和众包的区别
责任承包本质上是众包，但由于有架构设计组提纲挈领及服务支撑组保驾护航，所以可以进行规模化产品研发。
以利益为导向的团队会不会导致人员不稳定
铁打的营盘，流水的兵，IT行业人员流动本身就很大，只要架构设计组和服务支撑组稳定就不会有太大问题。
不同团队做不同服务会不会无法集成
首先，康威定律告诉我们不要惧怕服务及团队地拆分，沟通得越多系统往往越不通用，而团队间沟通越少反而越可能会思考全面，系统的鲁棒性越高，再则架构设计组在拆分时就会明确边界，服务支撑组会提供统一的服务契约、管控环境。
