一家领先的 SaaS 公司的 CTO 找我去给他的软件团队做指导。

“他们的 bug 太多了”，他说。

“他们总是没能赶上预估的进度”，他说。

“他们没有对功能进行良好的规划”，他说。

“出了问题，他们只会责怪产品经理，而产品经理就反唇相讥。”

经过三十分钟的讨论，我们发现了一些问题：

QA 团队被想要快速发布软件的工程团队催；

工程团队被想要看到新功能的产品团队催；

产品团队被销售团队催，销售团队认为如果他们能够向客户推出承诺的新功能，就能完成销售目标；

销售团队因为新的销售不是现有客户而获得佣金；

客服团队的业绩根据现有客户满意度和离开平台的人数来衡量的。

最后我问道：

“为什么你更重视潜在客户，而不是现有客户？”

他们感到很震惊，因为他们意识到这正是他们正在做的事情。

SDD 开发周期

我们可以将这个系统称为销售驱动开发（SDD：Sales Driven Development）。销售团队需要源源不断的新功能来完成销售目标。

那么这与“太多 bug”有什么关系呢？

当前的客户只能得到工程团队留下的残羹冷炙，因为已经没有什么可以激励他们为这些客户提供更好的服务。

看看下面这个逻辑：

“为什么他们有这么多 bug？”

“他们没时间修复它们。”

“他们为什么没有时间？”

“他们必须赶上进度。”

“他们为什么要赶进度？”

“产品团队已经向销售团队做出承诺了。”

“产品团队为什么要答应他们？”

“为了完成销售目标，销售团队向潜在客户承诺新功能很快就会完成。”

“为什么销售团队会做出这样的承诺？”

“客户在征求建议书上标出来了。”

“为什么那个功能那么重要？”

“我们不知道。”

“那个功能用来做什么？”

“我们也不知道。”

Bingo！

这是很多问题的根源

团队开发没有人会使用的功能，他们不知道为什么要开发它们。他们已经沦为了数字管道工。

然而，令人感到震惊的是，工程团队仍然关心着产品和客户！事实上，他们最大的抱怨是没有资源去修复 bug 或者对现有功能做出一些小改进，让现有的数千名付费用户受益。

即使在一个糟糕的系统中，工程师仍然会表现出强大的积极性去构建真正对人们有用的高质量软件。

接下来该怎么办？

现在，他们知道工程流程实际上是为谁服务的（销售部门），并确认工程流程是否应该为其提供服务。

一旦了解这一点，就可以在销售、客服、产品和工程团队之间调整财务激励。

好了，赶快行动吧。

当每个人都朝着同一个方向前进时，事情的进展会比你想象的顺利。