“ 理论上，To B 的软件产品就是服务于客户需求的，但现实往往并非如此。”

01 “吐槽大会”

有一次，乙方过来拜访我们，这次拜访，一部分时间成了我们作为甲方对他们的“吐槽大会”。

该产品已经上线了一段时间，它提升了我们的平台能力，也为我们提供了更多的服务，但也存在一些“老生常谈”的问题一直没有得到解决。

对于该产品的主要问题和我们的期望，在会前双方都已经做了沟通，有具体的议程。这次来的，有对方的商务和某个模块的架构师与产品经理。为了避免太发散，从而能达到成效，我们也把问题和议程集中在某个模块。

在会上，该模块的架构师针对我们提出的问题，都给出了一些方案，但坦白说，我们对这些方案，不管是针对我们短期的问题，还是远期的期望，都不太满意。

对方也坦言，很多我们关注的根本性问题涉及到产品的底层设计，在他们这个层面无法解决，产品也不支持就单个模块进行升级和改造。而且，整体产品会收到各个客户的各种需求，我们提出的需求只是整个产品 backlog 里的一部分，不同客户间的需求，特别是涉及到底层设计的，可能会互相冲突，有时很难拿出一个两全的方案。

从我们的经验来看，即使我们通过不断施加压力，最终迫使对方交付了我们一直期待的需求，但在用户体验、质量、产品升级的可靠性等方面都会有各种各样的问题，还会有很长的磨合过程。

02 To B 的悖论

理论上，面向商业用户，也就是 To B 的软件产品就是服务于客户需求的，客户理应期待他们所有的需求都能被实现。但是 To B 产品并不是外包开发，它的底座是一个成型的产品，而且是服务于它的全部客户的“公共产品”，针对某个客户的定制化开发只能是锦上添花，会受到产品本身以及其他客户需求的约束，这种复杂性也导致了交付、升级周期很长和很多质量问题。双方的预期会有很大落差。

我曾经开玩笑说，做 To B 或外包的，往往都是双方老板很开心，执行的很悲催。乙方的商务、产品经理和服务，甲方的业务运营、IT 实施和运维团队，都是“夹心饼”，需要面对大量难解、无解的细节问题。当然，从职场的角度来说，这也产生了大量的工作机会。

做 To C 的产品经理的“话事权”会大很多，他们可以根据自己的洞见确立产品的整体规划和特性。普通用户对于产品特性和问题是没有话语权的。To C 的压力更多来自于竞品。

03 To B vs To C

To B 和 To C 的逻辑是完全不一样的。

从商业的角度来看

国内著名商业咨询顾问刘润总结得很好，To C 靠产品，To B 靠服务。

To B 商业最大的特点，是流程和复杂。甲方的干系人众多、意见纷繁、流程长而复杂。To B，除了依靠产品，更要依靠销售和服务，去磨，去耗，去说服。是持久战，是消耗战，是堑壕战。简单来说就是人海战术。

而底座产品的复用，是抵消这些成本的杠杆。这也决定了底座产品只能照顾到各个客户间需求的最大公约数。

To B 的另外一个特点是，甲方的决策者往往并不是产品的用户，所以产品好不好用这些细节问题，很多时候不是产品采购的决策因素。

To C 的决策者就是用户，虽然个体用户没有影响力，但作为一个群体可以“用脚投票”决定一个产品的生死。所以除了满足需求，好不好用也很重要。

从需求的角度来看

很多软件问题是由需求这个源头产生的。对于 To B 的项目来说，它们的需求往往是复杂而且全面的。

特别对于大多数的传统行业来说，推出一项新业务，往往都不是什么创新产品，都是市面上已经有的产品或服务，这些新业务是要在一片红海中挖掘机会。这就导致了这些业务的产品和服务范围必然是你有的我也要有，你没有的我就要有，要在同行已有功能和服务的基础上，推出更多的增值服务，才能形成差异化竞争。这导致的后果是，针对这些新业务的所谓“最小可用产品”，也就是 MVP，也会非常的大而全。

我们大部分的敏捷教科书都教导我们，MVP 一定要足够小，目标是尽快推出一个只具有最核心功能和卖点的产品，快速上市，从市场和用户那里获取反馈，也就是真实的日活和月活数据、用户行为数据，并根据这些反馈不断调整和优化产品，实现产品的持续迭代、优化和升级。我们所有人都一起见证了微信从一个相对简单的语言聊天工具，迭代成今天成为半个操作系统的平台产品的过程。但这是面向消费者，也就是 To C 的玩法。我们在非互联网的世界，绝大多数情况下面对的都是前面所说的 To B 的场景。

需求大而全带来的直接问题就是开发过程复杂，风险高，周期长，首次交付上线动辄需要一、两年的时间。后续升级也会遇到同样的问题。

从人员的角度来看

以下应该是几乎所有 To B 项目的常见场景：

在甲方，业务方有销售部门、售前产品设计部门、业务运营部门、售后客户关系部门等，他们都是项目的干系人，在项目执行过程中，他们的利益都要被照顾到。如果是强监管行业，要满足上线的要求，除了要满足客户需求和市场需要外，还要满足各种合规要求，有多个部门要打交道。 

在 IT 内部，也有大量的非功能性要求需要满足，系统才能上线，实施团队要和基础设施团队、架构设计团队、安全团队、流程管控团队、权限管理团队等打交道。 

系统要在生产环境上安全、平稳地运行，需要满足一系列非功能性需求点，涉及到安全、灾备演练、系统配置数据、权限控制等。这里又涉及到多个部门的不断沟通磨合。

在这样一个复杂、利益方纷繁的组织内，决策过程必然冗长且复杂。

在乙方，往往有与甲方对接的商务、实施、服务人员，但他们完全受制于实际做开发和交付的产品团队。产品团队往往是一对多的局面，不同客户的需求相互交织在一个产品和团队里，彼此形成了复杂的依赖关系，牵一发而动全身。

04 总结

现在很多原本做 To C 发家的大厂都越来越重视 To B 市场，To C 可能只能赚到人气和吆喝，但 To B 能赚到真金白银。但 To B 和 To C 是完全不同的逻辑和打法。To B 产品和项目的实施和维护，对于甲乙双方的执行方都充满挑战，如何破局，是一个很大的话题。欢迎大家留言交流分享。

觉得文章不错，顺手转发给朋友们吧。

分割线 卡通

相关阅读：

复杂（Complex）问题与繁杂（Complicated）问题，你怎么选

刘华：如何在复杂问题中找到最不坏的选项？

高级人才的价值在于管理复杂性的能力

关于作者

刘华（Kenneth）

• 著有书籍《猎豹行动：硝烟中的敏捷转型之旅》《软件交付那些事儿》

• 《图数据库实战》中文译者之一。

• 世界 500 强银行科技部云平台工程主管

• 敏捷、精益、DevOps 专家

• 公众号“敏于思 捷于行”博主

• 精通极限编程、Scrum、看板方法、测试驱动开发、持续集成、行为驱动开发、DevOps 工具栈、Docker、Kubernetes (Google Kubernetes Engine, GKE)

• 曾在 GDevOps、DevOpsDays Meetup、中国软件技术大会、ArchSummit、Top 100 等论坛发表主题演讲

• 阿里云、谷歌云认证架构师