是 RD 同时也是 PM：做业务架构试试这样思考问题

一般来说，我们提供的开发者工具是针对我们在日常开发中遇到的痛点问题，经过深入研究和理解后，提出的一套解决方案。理论上，我们自己就是用户，且是深入理解痛点、需求到实现的专业用户，因此我们提供的解决方案理应是最理想的。然而在我深度参与了几个开发者工具项目后，发现产品思维和技术思维存在很大的区别。

业务架构组的工作

产品经理和程序员的“爱恨情仇”，是每个互联网公司员工都非常熟悉的日常。随着业务的日益复杂，程序员日常业务开发所依赖的平台、工具本身也会变得复杂。这时，可能会有一个名为“服务架构”的团队负责提供、优化研发日常使用的工具或平台产品。此时，产品经理（PM）和研发人员（RD）的角色往往会融合在一起：我们需要从研发的角度发现研发流程中的痛点，将共性问题提炼为需求，然后开发工具产品来解决这些问题。

服务架构组：连接基础设施与业务开发的桥梁

但是，我们经常会听到这样的抱怨：业务架构组就是代码外包和客服小组。因为我们每天大部分的工作时间都花在处理开发人员提交的各种 OnCall 工单上，进行问题排查。我们可能花费了很长时间，最终发现问题不在于我们自己的平台或工具，而在于上下游或用户的使用方式。当我们无法再忍受这种情况时，我们考虑在日志中加上大写加粗的“DO NOT INVOLVE ONCALL”，或者在 oncall 流程中设置更多的前置问题。虽然这样可以缓解问题，但也会让用户有更多的抱怨——提交 oncall 太麻烦了。如果用户能够自己解决问题，他们可能也不愿意在 oncall 流程上浪费更多的时间。

而对于我们团队自己的同学来说，有时也会怀疑自己工作的意义。Oncall 的工作十分枯燥繁琐，问题排查过程就像一个时间黑洞，一天过去后往往不知道自己完成了什么。在技术方面，我们有时会担心自己的技术深度不够，研发流程或研发工具的场景不如业务需求的场景具有明显的技术挑战，也不如基础技术做具体的存储或计算类项目有明确的深度和方向。

服务架构组的工作职责通常处于一个中间层。向下，公司级的基础设施为我们提供了通用的开发资源和工具链；向上，具体的业务开发团队需要针对产品经理（PM）提出的业务问题，用代码实现相应的业务逻辑。

在中间层，我们会将通用的基础设施与具体的业务场景相结合，重新组装成一个定制产品，以适应特定的业务场景。同时，我们也会发现业务流程中通用的、重复的步骤，并优化流程和工具链，以提升业务的质量和效率。在我看来，业务架构工作起到了承上启下的作用。由于业务的具体需求是多变的、快速发展的，而大的基础设施往往更注重通用性和稳定性，因此，定制化的需求就需要由我们来满足。

我们可以帮助业务团队简化重复步骤，减少他们需要了解和学习的技术细节，提供更多即开即用的工具，从而保障业务需求能够更快地上线。

在其他工程领域，这或许很容易理解：木匠制造一张桌子，不需要从设计一把锯子开始；制造锯子的工匠，也不需要自己去炼钢打铁。然而，在软件开发过程中，我们往往统称为开发人员，从而忽视了不同层次工作的角色重点。

试着用产品思维思考问题

我们既是开发者，也是产品的提供者；我们的用户也是一群开发者。因此，我们在思考问题时，需要从实现功能的程序员思维转换为提供解决方案的产品思维。

业务 PM 怎么思考问题

在关注业务需求的 PRD（产品需求文档）时，我们不难发现，业务的项目经理在讨论需求时会关注两个重要的问题：用户和迭代。

• 用户：解决的问题是什么

    谁是目标用户：新手和老手的需求不同，通用基建和业务线定制存在较大差异。因此，人群细分和产品泛化是重要的产品课题。

    用户的价值、增量的价值和迁移的成本：在定义收益时，需要考虑改变的成本。覆盖率治理的需求应该避免从五花八门变成六花九门。在提供新产品和解决方案时，必须考虑迁移成本，而不是教导用户做事或认为用户存在问题。同样，对于产品提供者（设计者）而言，当类似问题转向日常使用的手机 APP 场景时，逻辑似乎就有所不同了。一般意义上的互联网产品，会首先认为产品有问题，而不是用户有问题。试图教导用户做事的 APP 往往无法在用户手机中常驻。互联网产品经理们可能都在努力让用户的体验更加顺畅，而不是遇到用户时，抱怨这一届用户不行。

• 迭代： 解决问题的路径是怎样

    产品一般需要通过数据和调研反馈不断迭代问题，逼近本质。通过 A/B 实验验证想法，从用户调研和竞品研究中获得灵感。无论如何，在需要研发人员（RD）排期时，需要将需求拆解到合适的颗粒度，并规划好版本计划。

    这给我们带来了以下启发：

  • Oncall 本身就是理解需求、梳理需求的一种手段，是用户调研深入业务的一种方法，能够获取一手信息；

  • 需要从交付的工具本身，进一步关注到交付价值，提供解决方案；

  • 从目标出发考虑问题，而不是从能力出发。程序员容易单点优化，追求速度的提升；但解决问题的思路可能不止一种。问题的关键不一定在于速度。

  • 不能简单地将产品上线后就不再关注，需要进一步衡量问题的解决效果。

为什么我们很难这么思考

我们很难直接完成这样的思维转变，主要难点可能包括：

• 知识的诅咒：自己学会了某个知识就无法想象不懂它的状态。而业务架构维护的各种开发者工具是我们熟悉某个领域知识后沉淀的产品，目的是简化该领域的工作。因此，当研发自己成为产品经理时，就会出现一些莫名其妙的设计： 一个需要简化用户理解的产品需要用户前置学习很多知识。

• 调研时无法发现真实问题：对于有经验的人来说，觉得这可能不是问题，但对于新手来说，他们可能会觉得自己不够出色，同时又非常渴望学习，从而隐藏了问题。

• 将实现呈现给用户：

  • 满屏幕按钮和步骤。

  • 把技术实现直接作为产品交互，或者直接抛出错误信息，而不是告诉用户应该怎么做。

微信

某内部平台

当然，这里的重点在于比较两种思维模式。趁手的工具重点在于解决问题，而不是拥有好看的用户界面。然而，许多由开发人员主导的工具，甚至我们自己都会自嘲说：“又不是不能用”。

过去，我们的定位是程序员，但现在我们所做的事情更多偏向于产品经理。或许未来真的会出现人人都是产品经理的情况？为他人提供解决方案是大家共同的生存之道，也是大家对“产出”的定义。

因此，我们需要从程序员思维转变为产品经理思维。根据我个人的经验，我们需要从以能力为导向的思考方式转变为以需求（问题）为导向的思考方式。即：我会什么，我做过什么，转变为我的问题是什么，我如何将问题拆解为我可以解决的规模。

需要注意的是：一个产品之所以成功，是因为它为人们解决了问题。这听起来似乎很基础，但却是了解如何构建优质产品的最重要的事情。构建新产品的第一步是明确你想要解决什么问题，以及为谁解决。在开始考虑任何解决方案之前，这一点应该非常清楚。

试试这样思考问题

• 全局思考

通过比较产品思维与技术思维，我们需要学会以全局视角思考问题，根据业务价值的高低来确定工作的优先级。困难程度与价值高低并不一定成正比，切勿死磕难题，应注重问题本身的价值。

产品思维	技术思维
需求理解	技术实现
全局目标	单点突破
迭代反馈	一步到位

  具体而言，我们可以尝试：

• 积极沟通协调，确定优先级，追求全局最优解。

• 写代码可能是最后一步，很多问题并非一定要通过写代码来解决。

• 在解决问题前，先构思好实现路径，将问题进行拆解到位，加入时间因素考虑，拿到反馈并不断迭代解决方案，逼近最优解。

• 更关注技术视野的宽度

    问题解决的全局思考：我们的目标是解决问题。在解决问题的过程中，我们应该以问题为核心，寻找最高效的解决方案。将多个代码进行整合比程序员自己去死磕、重新编写一套东西要高效得多。

    宽度是相对的：横看成岭侧成峰，我们应该辩证地看待技术深度与广度的问题。在服务架构的工作中，建立宽度比追求某一领域的深度更为重要。如果过于追求深度，可能会导致研究方向的偏差。只有当你拥有比一般业务更全面的视角时，才有可能想到更高效的解决方案。另一方面，看似 OnCall 这种纯消耗性质的工作，也可以成为一个专业领域。比平台工程（What is platform engineering？）平台工程是研究工作流的一门学科。平台工程师会为这些复杂的工作流程提供“金色路径”（Golden paths），即简单一致的工作流，让开发者能够高效地完成任务。同时，他们也会为整个系统“铺平道路”（paved roads），将各种工具与服务整合在一起，减少开发者的学习成本。

胶水的价值：服务架构的工作就像是一种胶水，将已有的工具平台重新连接成新的解决方案，服务于具体场景。看似没有深度的脚本侠，实际上也有很大的价值。平台工程师的“胶水”作用非常宝贵，因为它可以为开发团队提供高效的自助服务体验，降低开发成本。“胶水”代表着平台工程师将复杂的工具链通过整合形成一个易用的产品，这正是它为公司和团队带来价值的地方。

• 迭代思维：

  • 从最简化可实行产品（MVP）开始。

  • 交付不是终点，而是新的起点。

  • 关注落地效果：问题是否得到解决、解决的程度如何，以及是否需要更新认知。

迭代过程是一个无限游戏，既可以横向拓宽，也可以纵向深入。一个热衷于问题本身的团队比一个热衷于特定解决方案的团队更容易成功。这是因为即使团队在第一次、第二次或第 N 次尝试中都没有找到正确的解决方案，知道一个问题值得解决也会继续激励他们。