产品研发组织的三个顽疾及破解
- 2019 年 12 月 11 日
- 笔记
本文起源于一次部门周例会，在这次例会中，我们可爱的产品经理和研发经理，在工作汇报过程中，清晰地“演示”了互联网公司中产品研发工作的常见问题，也是严重且根深蒂固的三个问题。
本文通过对这几个问题的探讨，希望能对今后的工作有所启发和指导。针对每个问题，通过四步阐述：现象(问题表象)、导致(的后果)、分析(原因）、建议(方案）。
技术架构边界不清导致复杂性和风险性
现象
l 变更很小但与许多场景关联，需要大量人工回归测试。
l 变更很小但业务逻辑纠缠在一起导致代码很复杂，难于修改和判断正确性，需要大量时间且风险很高，建议重写代码。
l 系统功能经常因依赖系统/模块问题导致不工作，且不能降级提供服务 和 直观定位问题，立即告诉使用方问题原因和建议行为，或者立即通知系统方发生什么故障，指导人工干预。
导致
复杂性导致小变更需要慢修改和大测试，工作受困于技术的历史负债，无法轻装上阵，严重降低研发团队的生产率和产品质量。
系统故障无论是系统自身引起还是依赖服务引起，用户都会认为是所用系统的问题，时常要为依赖服务的故障背锅。当然事后解释有些用处，但总是太被动且效果有限。
分析
这些问题的直观原因就是代码复杂，代码复杂的直观原因就是各类元素多、元素之间的关系多、代码行多，要知道普通人舒服处理要素的数量在3~7个，更多就会蒙圈。
元素及关系多因为没有很好地抽象和封装为高内聚低耦合的模块/组件/对象/服务等。另外一种常见原因就是思考问题的方法和模型不当。傅盛说过：复杂性往往来自高维简单问题到低维的映射。举个例子是以地球为中心，太阳系各个行星的轨迹很复杂，如果以太阳为中心，轨迹简单明了。
另一个问题是回归测试需要投入大量人工进行，正确做法是通过积累自动化测试案例，保障回归测试自动进行。不过要做好自动化回归测试同样依赖一个好的设计，便于测试案例针对接口契约进行。
建议
解决复杂性并不容易，软件架构与设计是一个很专业和很庞大的领域，这里简单提一些方法。
如何才能减少系统元素数量？通过抽象技术和封装技术，隐藏复杂性到组件之内，组件通过稳定的接口契约交互，而不用关心接口内的行为（组件边界内部的实现行为）；通过分层技术，可以逐层进行封装，逐步逐层把大系统复杂性限制在可控范围内。
抽象及封装技术不仅仅是降低复杂度，更是组件/服务独自演进的基础，边界清楚了就能各自行动，纠缠在一起大家谁都动不了。
系统边界要隔离，弄一个防护的安全地带，依赖的系统外服务出了问题，要及时能监控到、把故障隔离到局部范围、避免连带问题、能进行降级服务。
自动化回归测试是很重要的手段，核心还不是自动化测试工具，而是积累足够多、覆盖完全的自动化测试案例，它保护对系统的修改没有引起新问题。
工作边界不清导致大量串行和同步工作
现象
l 其他团队没有空档能配合我们排期，暂停当前的需求设计开发等工作。
l 缺少配套要素支持工作开展，如设备没到位则不上线，测试环境不具备则不验证等。
l 业务方还没有提交我们需求文档，后续工作还没法开展。
l 研发都在忙于某某项目，没时间开发这个需求，所以没有对这个需求进行详细设计。
导致
被依赖工作不能开展阻碍依赖的工作的开展，相互依赖的各方越多，互相阻碍的概率越大，影响也越大。
此时，更多的合作伙伴没有成为工作的加速器，反而成为工作的障碍。
串行方式在上游工作未完成之前，阻碍下游工作开展；同步工作在任意一方没有准备好则无法开展。这两种类型的工作比较多时，会大幅度降低资源利用率和灵活性，进一步影响效率、工期、成本等。
从精力管理视角来看，这会干扰甚至打乱自己和团队的工作节奏，节奏不整齐，效率自然低。
分析
这些问题是由上游、下游、供应商、同级伙伴、所需资源之间的依赖性导致。实际上依赖是天然存在的，否则大家就没关系了，实际做的方法是降低依赖程度。
互联网公司出现此问题更多是组织管理问题，主要情景有：
l 事情很多做不完，既然有好理由放一放就先忙那些推脱不掉的事情。
l 自己先行做完自己的事情后，其他事情后续未必跟的上来，这样白白浪费自己工作，毕竟互联网公司的很多需求一旦停下来就可能永远没机会再做了。
l 边界的定义未必到位，基于定义的边界先行开展工作，后期难免要修改，浪费自己精力。
l 还有些工作，双方都认为应该对方做更好，这样子谁先做工作就有更大可能承担那些模糊地带的工作。
建议
降低依赖的重要方法还是界定清楚边界，大家按照之间的约定完成各自工作，然后交由下游或者需求方，降低自己工作节奏受外部因素的影响。例如产品经理的输出是经过评审的产品需求文档，无关目前是否有研发开发；测试人员设计测试案例的输入是需求文档、输出是测试案例，不需要系统已经开发完成；开发工作按照接口完成和验证，无需其他相关模块是否完成。
降低依赖的另一个方法是拆分工作，依赖程度不同的部分拆分开来，那些不依赖的部分就可以先做起来，例如设计的/干活的/检查的/签字的等分开。
以“巧妇难为无米之炊”为例，没有米时也可以先把锅、水、柴等准备好。没有足够的生产机器就可以先部署在少量机器上，进行试用、支持早期少量业务，业务量提高后再进行扩容。即使业务方没有提交需求，产品也可以基于理解做部分产品设计，业务方提交需求后再进行补充修正。
业务流程优化的许多方法有助于依赖降低，有许多这方面的资料，从流程视角看，尽可能缩短关键路径，减少那些串行和同步进行的工作，增加独立的自由开展的工作。工作之间关系不应该是串行和同步，而是叠加和轮动。
如果是组织管理导致的问题，由于合理原因和不合理原因都可能存在（借口推脱和怕浪费自己工作两种情况更常见），管理者需要清楚实际缘由，针对性应对，不能简单地统一处理。如果是借口，指导团队降低依赖性让工作正常开展。
工作缺少规划和重点，开展起来忙闲不均、效率低下
现象
l 对业务方(上游)需求以被动响应式方式接收，也就是完全由业务方提需求、提啥就是啥、不提就没有。
l 开展哪些重点工作由业务方(上游)要求什么决定，也就是工作重点挑选完全由业务主导。
l 工作的节奏主要由(上游)给予的压力决定。也就是工作的紧急程度完全由业务方说了算。
导致
产品团队不能主动挖掘、引导、完善合理需求，以及难以拒绝不合理需求。
难以在业务方要求基础上，主动结合产品规划、演进路线、需求关联关系、技术难度、开发工作量、割接风险等对业务方进行影响，做出更合理的建设计划和步调。由于接收的需求都是眼前要做的，很少有机会从一大堆中挑选更合适的去做。
业务方催的紧就忙死，催的不紧就闲会，这种重点失衡、节奏失衡自然导致效率低下。
分析
被动响应式的工作基本上是"脚踩西瓜皮、滑到哪里算哪里"，也就不会有什么清晰的整体规划和有效的中长期工作计划。
实际工作中总会有做不完的需求，不会无事可做。但整体规划和重点工作挑选的不足，会严重影响工作的组织安排。可能工作特别忙但没有做到重点，导致最终结果(绩效)一般。可能工作不怎么忙，所做事情重要性也不够，结果就更糟糕。多数情况下，会有选择地做“重点”需求，拒绝一部分“不重要”需求。但由于整体规划和重点内容缺乏且达成共识，本能的择优缺乏有效支撑，准确度有限，总体效率自然也就低了。另外，这种情况下需求方频繁感受到的是"被拒绝"，抱怨自然难免。
缺少整体规划必然缺少重点，重点是从整体工作或一组工作中挑选出来的，缺乏整体就难以有效地挑选重点。
陷入日常的琐碎需求，就缺少大块时间和充分准备(紧急事务会撕碎大块时间)，解决那些高难度的重要问题和重点需求，业绩自然就不会好；日常琐碎需求，数量繁多导致思考和准备仓促，风险和故障却并不见少。
业务方由于缺乏对技术的深入理解和关注，所提要求不会结合技术实际情况。虽然双方均难于成为对方领域专家，但业务人员理解技术相对技术人员理解业务更困难一些。缺少对产品建设理解的业务方，提出的要求必然具有不合理成分，无法让双发利益最大化。
建议
业务团队和研发团队本质关系还是甲方和乙方的关系。如果定位错误，例如是平等关系、业务方有求于研发团队，后续的一系列工作都会出现问题。但在一个公司内部，清晰做出恰当定位且能有效贯彻执行动作不变形，其实并不容易，毕竟人性使然。
看看业界这种关系乙方都是怎么做的：
l 主动、深入理解甲方(业务方)需求（否则凭啥让你干），深入挖掘甲方进一步需求（不能做完一单就丢了）。
l 维护好双方关系，腿要快、嘴要甜、脑要灵、能自己干的就不要麻烦对方，能替对方干的就不要对方自己干（拓展服务内容）。
l 不刷滑头但要聪明做事，收钱时不要手软。
公司内部业务方和研发团队不是市场上的甲方乙方。基本规则还是乙方服务要专业，甲方回报要足够。研发团队的专业性表现在洞察业务需求、主动积极服务、维护良好关系；业务团队的回报足够体现在充分配合研发工作、努力争取研发资源、积极宣扬研发工作价值。
研发团队能力成熟度重要标识是：与业务方一起建立产品整体规划和重点事项，能在多长时间内让实际工作内容与规划内容保持一致，当然是时间更长更一致的能力更高。
最后再多唠叨一句：坚持“要事第一”的原则。此原则顺利执行的前提是具备全局观和前瞻性，否则就无法从一堆事中挑选出重要的事。
