|0x00 研发效率提不上去的根因
数据，通常也会视为“研发部门”的一部分，自然也面临需求交付效率、数据质量、稳定性等一系列问题，其实在研发眼中，一切问题的根因似乎可以总结为“需求多、压力大”，有充分的时间，是可以解决掉质量相关的问题。
但事实上，大部分的公司，都是在业务的狂奔中去做需求，一旦业务发展停滞下来，要么意味着要人员优化了，要么意味着没什么需求可以做，程序员可以打酱油了，这都不是一种健康的发展状态。
因此，解决业务高速发展情况下的研发效率问题，是我们的一门必修课。在本文中，我试着把一些做不好的问题进行分析，挖掘共同的规律，并找到一些可以尝试解决的方法。
首先是原因的分析，我们很自然的会想到，业务在高速发展的阶段，创意是层出不穷的，不论是需求的可行化定制，还是人员配比的不合理（如研发对接多位需求方），都无法形成固定的分析思路，因此“更快的响应，更快的烟囱式开发”，就成为了这个阶段的主流。尽管我们可以参考Kimball的建模、阿里云的开发工具，但依旧无法形成有效的“质量沉淀”，时间久了，模型也就变得越来越差。
进一步分析，我们会发现，其实大多数情况下，我们的产品，服务化能力是比较弱的，换而言之，就是“抽象的不够充分”。本以为做一个平台，可以支撑很多的需求，但往往定制化的问题解决不了，又引入了产品和中台这两个概念，来同时兼顾一些特定的开发规范，反而加重了研发的工作量。况且，即便遇到一些合理的产品诉求，也往往因为优先级的问题，被挤压到比较靠后的阶段来做，当我们能够做通用功能的时候，一些历史包袱，就很难被甩掉了。但当我们会看为什么产品设计不好的时候，原因又往往出自于最前端的业务，也就是业务其实就没想好怎么做，或者是规则传递的非常模糊，导致产品不得不适应这些规则化和标准化很弱的场景，产生了“抽象能力”不足的问题。
如果数据能够和业务搞好关系，其实你会发现更多的原因。最典型的，就是目标没对齐，业务有自己的业绩导向，产品有自己的平台导向，研发有自己的价值导向，面对一个需求，我们很难纯粹的从领域建模的视角来做这个事情。有一句俗话讲：“开着飞机换引擎”，当不同业务方的利益、业务传到的压力、中台引擎的能力交织在一起时，做好一件事情，往往就变成了“艺术”，这也是绝大多数数据研发无法更进一步的“根因”。
|0x01 组织架构在研发过程中的问题
讲到项目管理，我们往往会想到三种典型的方式，一种是“项目制”，一种是“职能制”，最后一种则是“BU制”。
在业务的初创阶段，往往业务、产品、研发等角色都是在一个团队里的，专门为了支撑某个业务而启动，这种情况下，组织的效率是最大化的，因为每个人的目标和方向都是一致的。这就是“项目制”的阶段。
但是随着业务的扩张，不论是2C的用户方向，还是2B的客户方向，业务需要服务的群体越多，业务线也就会逐步扩张。但为了提升支持的效率，业务扩张的同时，往往又不可能同步的增产品、研发的规模，因为成本是很高的。因此横向的支撑，就成为了这个阶段的选择，也就是产研团队与业务团队分开管理，研发虽然都编在同一个组里，但需要支撑横向的很多不同业务线。
这时候技术架构就需要讲“应用方向”的故事了，比如电商的怎么做、流量的怎么做，以及流量的要配备A/B实验平台等内容。尽管业务线在变多，但总归是有共性的一些应用需求，因此做通用方案就是这个阶段最强烈的诉求，而“降本提效”也就成为了最常见的考核方式。这个阶段，可以称为“职能制”。
但业务总会增加，平台会越来越复杂，到达某个平衡线之后，两者的模糊地带就越来越多了。可以讲，因为需求持续的个性化和系统功能持续的复杂化，很可能业务和产品都搞不懂产品的定位和具体逻辑了，研发在这个阶段人员会变动频繁导致留下一个不大不小的坑，这时候势必技术团队要更加精细化的分工，否则损耗的就是各个团队之间的信任感。
一旦组织需要独立的产研团队来单独进行平台或者某项业务的建设时，中台也就会被抽象出来，以支撑更加复杂化的需求机制。
但这个阶段对于一线研发是不友好的，因为交互的关系又多了一层，即“中台”。而且提给中台的需求，往往又需要排期很长的时间，导致前台团队需要设计一些“反人类”的模型，虽然规模的成本降低了，但其实协作的成本却大大增加了，属于转移了矛盾注意力。
“BU制”是中台环境下的一种解法，但目前并不是最优解，因为跨BU的协作，其复杂性是最高的，一次性搞定太多关联方的利益，几乎是不可能的。
|0x02 当前尝试的一些解法
以上文章提到的这些问题，在公司发展到一定规模的时候，几乎都是必然碰到的，因此相对而言，也会有一些粗略的应对方法，本文仅阐述目前一些常见的做法。
最常见的应对方法，是以大促为代表的定期评审 + 需求冻结机制，也就是每年在关键节点前收集需求、统一评审和集中开发。这种情况的好处，是可以把整个需求的链路摸排清楚，并给出详细的解决问题排期，并且在关键节点保障质量的问题，并且，因为需求范围确定了，技术的价值更容易讲出来。但这种方式的弊端也比较明显，也就是需求的变化基本不会考虑在内，并且收集上来的需求，并不一定都能够完成，通常会进行一些讨价还价的会议，减少工作量。
第二种是推广OKR的使用，在前文描述中讲到过，各种矛盾有一个很重要的“根因”，就是大家的目标没有对齐，产生了很多不必要的内耗。因此通过OKR的方式，将O一层一层传递下去，拆到每个人的KR上，也是一种保障业务重要目标优先完成的方法。
第三种是通过工具来支撑，比如以Jira为代表的的项目管理工具，来有效的收集、组织和交付需求。这种模式通常需要PM的介入来保障各个项目之间的资源协调情况，会有一定的人员冗余，但相对于浪费的人力成本来说，还是很划算的一种方式。
但以上三种方法，又有一些的局限性，应对复杂协同还是多少有些力不从心，但在更完善的方法论被提出前，这几乎是研发团队“必然”形成的自组织方法，还是能够适应一定阶段的开发。
|0xFF 通过数据来解读研发
之所以想到用“数据”来衡量研发阶段，也是根据之前的文章，有关数据驱动建模发展的一些方法的引申。因为数据是应对“复杂性”的一种解题思路，尽管少有人做的成功，但并不妨碍更多人朝着这个思路来探索更多可能性。
在PMP中，绩效的汇总一共有三级，分别是绩效数据、绩效信息和绩效报告。对应到研发过程，就是研发行为的数据采集、研发行为的建模统计和研发行为的报告解读。
对于一线小二而言，因为通常工作都比较忙，因此数据的采集需要尽可能少的侵入到日常研发动作，所以在一些项目管理工具上做数据的记录，是更合适的，因为每个团队多少都会有自己管理需求的工具，本身需求状态的更新就是需要时间来操作，这里记录是更合适的。
当研发行为被统计上来后，我们就可以针对常见的研发过程，进行流程的梳理和每个阶段的数值统计，例如A阶段 - B阶段的平均用时，每个需求的平均交付时间，个人完成的需求数量等一系列的统计指标。最终讲这些指标在数据分析平台上可视化出来之后，一些关键的卡点问题也就能够清晰可见了。
最后就是针对指标结果做的分析报告，例如需求是否和业务的OKR有强相关性，分阶段的工作量是否存在不平衡的现象，以此解读部分不合理需求，并调整项目的资源排期，就是一件行得通的事情。
但数据来驱动业务发展，并不建议作为“KPI”，因为有人的地方就有江湖，而研发行为的数据造假，是一件很容易的事情，大力会出反效果。