寒冬来了，个人和组织都需要更加的高效

现在朋友圈里各种“互联网寒冬来临，…”、各种“* 公司裁员 %…”的文章，在煽动我们焦虑感的同时，确实也让我们看到了一些趋势。尽管我认为“寒冬”还谈不上，只是互联网原来太火，有不少泡沫，现在正是挤掉泡沫，修炼内功的时候。在整个行业回归理性的趋势下，动不动就加人这种简单粗暴的解决问题方式显然应该成为过去时。

那我们如何在人员相对更少的情况下，还把事情做好呢？

我认为答案是两个字：“高效”。下面我主要从产品技术层面，以我们做的数据中台和数据产品为例谈下，如何做到高效？

高效首先对外要做有价值的事情，对内要提升研发效率。产品技术团队的需求主要来自用户 / 客户，通过产品经理来把控的，所以做有价值的事情主要是对产品经理的要求。提升研发效率，对产品技术团队更加可控，是修炼产品技术团队的内功。

一、B 端产品经理如何做有价值的事情？

1. B 端产品经理应该是“跟着业务负责人走”（听起来有点媚上）。

绝大部分 B 端产品（通用的工具除外），无论对内还是对外，都有明确的业务方。比如：我们河洛 – 供应链协同决策系统的核心业务方是供应链计划，大麦 – 商品数据化运营系统的核心业务方是商品 BU。产品经理需要问出业务负责人的愿景，好的业务负责人对业务应该是有往后 2-3 步的推断和长远愿景的。产品经理基于业务的愿景结合业务的规划，才能做好产品的规划，进行前瞻的设计，让产品有顶层的逻辑和明确规划，避免产品成为需求任务的堆积，产品经理变成项目经理，产品研发团队沦为外包。B 端产品的最核心任务是根据业务负责人的愿景、规划，联合业务专家帮助业务负责人将业务中的知识提炼出来，落地在系统中。这样业务人员就能在组织的业务知识之上工作。业务里面每个业务人员可能有自己的利益和习惯，我们做 B 端产品的时候，不是为了每个业务人员做的，满足每个业务人员的利益，而是跟着业务负责人让业务组织的知识体系化、系统化、线上化，让组织的利益最大化。

2. B 端产品经理需要“问业务需求价值”。

业务负责人毕竟时间有限，主要确定方向和策略，产品大量的需求还是来自具体的业务人员。如果不能直接判断需求符合业务的大方向和策略，特别是评估出来研发成本很高的，就需要追问需求方需求的价值。比如：这个需求能降多少成本？这个需求能创造多少营收？这个需求是不是属于基础设施，后续很多其他需求都依赖它？对于大的功能需求 (涉及系统多、研发成本高），甚至需要业务方给出量化的效益，也让业务方对需求由更多的思考，让最终的优先级更加的有说服力。

3. B 端产品经理需要成为“很懂业务的通才”

B 端产品经理 (包含技术) 需要既有产品化思维、系统思维、数据化思维 (数据产品经理尤为重要)，又要深入理解业务，成为通才。产技团队要成为业务的合作伙伴，不是只向业务单向获取知识。业务有的业务知识，我们有的是系统化思维和数据化思维。我们与业务沟通时进行思维的联系和碰撞，一起从业务的信息里面提炼知识，并将知识系统化、体系化。创新来自于联系，只有和业务专家一起，将不同的知识建立联系，将不同领域的知识迁移，才能做出创新的产品。

二、研发团队如何提升研发效率？

大家都知道，提升效率最根本的办法就是分工协作。那么产品技术团队如何做好分工协作呢？

1. 分工

1). 人员上更明确的分工。

当然，这个要求是基于在中后台建设不是特别完善的情况下。如果中后台建设非常完善，前台人员完全可以模糊分工，往全栈化发展。

人员分工上以我们部门为例，对每个部门员工来说就是按照角色做自己。我们原来中台系统的产品经理是技术兼着，现在都分配了相应的产品经理；我们原来有的技术数据开发和应用开发都做，现在也都逐渐专注在自己的角色。对部门里面的每个组来说，明确各小组的职责。因为电商是有很长业务过程的，我们一些角色是按照业务过程设置，我们明确了对接个业务过程的负责人，比如：负责营销的数据产品经理，负责供应链主题域建设的数据开发。

2). 技术上更明确的分层。

解决复杂性的核心原则是关注点分离，现在我们产品技术面对的系统 (从整个业务系统集合看) 基本都是复杂问题。分层让不同的层关注不同的问题，让下层不依赖上层，让不同团队负责不同的层按照不同的时间节奏来进行演化（往往越往上的层变化越频繁）。分层后，不同团队负责不同层，让更专业的人做更专业的事情，进而提升质量和效率。分层后，越下面的层（中后台），在越大范围内共享，避免了重复建设，进一步提升了质量和效率。

做好分层，要“明确不同的层的职责”。比如 DW 层是保障核心指标在细粒度上的计算口径；基础技术层提供通用技术层，比如持久化、通信等；领域层表达业务概念，决定了系统的能力范围。

做好分层，还要明确“需求拆到不同层的原则”。比如一个数据需求，哪一部分应该在 DW 层算，哪一个部分应该在 DM 层算，哪一部分应该在统一查询处理，哪一部分应该在 app 层处理。

3). 产品上更明确的范围。

中台系统是为了更好的支持研发，整体的需求规划和落地都是产品技术团队掌控，要划清各系统之间的边界，严格控制重复建设。前台产品，因为业务场景的需求，是不能也不应该避免功能的重叠。特别是数据产品，业务系统往往根据业务过程是内聚的，但一个数据指标往往来自多个业务过程，且需要被多个业务方使用的。前台产品无法控制功能的重叠，但是要控制重复的层次，将重复控制在上层（参见上一节的分层）。

2. 协作

分工本身只能带来局部效率的提升，如果不能很好地协作，整体的效率甚至会下降。产品技术团队要协作好，要做到以下几点：

1). 提升项目管理能力。

大部分项目还是中心化管理的，项目管理者是项目团队协作的中央控制器，项目管理者的能力对项目成败的影响很大，所以项目管理者需要加强项目管理的能力。大部分单产品或单业务过程的项目，没有专职的 (也不需要) 项目经理，需要相关的项目管理者加强项目管理能力。在我们团队主要是产品经理、技术负责人、数据架构师承担项目管理者角色。

2). 开好需求确认会。

需求确认会是产品技术团队最重要的协作场合。需求确认会上，产品、应用开发、数据开发 (数据系统特色) 要真正做好交互评估、技术评估和数据评估，避免后续的返工，进度的失控。具体讲，前端开发人员要能够针对交互评估用户体验的问题，甚至给出更好的交互建议；应用开发要评估产品的功能是否符合逻辑，进而评估可行性和实现成本；数据开发要评估指标计算口径的合理性和实现成本，并确认指标的计算分别落在哪一层。

3. 基于 (仓颉) 指标协同。

指标是数据团队各角色协作的基础。这个是数据团队特有的，不再展开。

总结一下，在互联网行业回归理性的情况下，需要更高效的工作。产品技术团队要做到高效，对外产品经理要做更有价值的事情，对内研发团队通过更明确的分工、更顺畅地协作提升研发效率。根据各自团队的特征，可以进行更加细分的方法来让组织更加的高效。

作者简介：

魏文庆，现任网易严选数据技术及产品部总监。

2007 年浙江大学计算机硕士毕业后入职网易杭州研究院，从事前端开发，后历任技术主管、技术经理、技术总监。曾负责网易摄影、网易企业邮箱、易信公众号等产品开发，以及网易前端微专业。2015 年开始内部创业，孵化敏捷 BI 平台 – 网易有数，任网易有数总经理，负责产品研发和商业化。2017 年开始负责网易严选数据技术及产品部，从 0 到 1 搭建网易严选数据中台和数据产品体系。