KPI 驱动的技术项目指的是表面上是为了切实解决某一问题,但实际上却是为了满足 KPI 或 OKR 需求应运而生的项目,在开源项目和公司内部都有可能出现。

技术项目是需要进行长期维护的(尤其是开源项目),但如果 KPI 已经完成,则要么维护者的迭代动力骤降,要么项目早晚会面临交接给其他团队成为边缘项目的命运,而其中的主要原因显然是这类技术项目很难为维护者们带来持续的收益,边际成本却日益上升。同时,纯粹的 KPI 驱动也容易导致技术实现的一地鸡毛。

可见,纯 KPI 技术项目对于项目的使用者来说是很不友好的,那么当一个项目具有哪些特征时我们就应该保持警惕并思考是否还要使用该项目呢?

KPI 驱动的特征

公司特征

对于开源项目,可以纵观该公司的开源历史,如果发现该公司曾经建立很多被行业公认的 KPI 项目,那么这很可能是公司体制导致的问题,这家公司的后续项目也大概率会不断出现纯 KPI 驱动的技术项目。

团队特征

受长期的 KPI 压力、TL 甚至上层领导做事风格和内卷的影响,有的团队做技术类项目时很容易出现纯 KPI 驱动的情况,这种情况其实比公司层面的 KPI 项目更值得警惕,因为公司家大业大,可能还会为了口碑做些基础维护,而一旦某个团队的项目没了长期价值,人手有限时团队是很难再倾斜资源进行项目维护的,因此对方团队的运行状态和相关历史也是值得关注的一点。

银弹项目

我们常说「没有银弹」,但技术项目的两个核心出发点就是「创意」和「差异化」,而在技术基建日益成熟的今天,「创意」是可遇而不可求的,因此很多项目都是基于「差异化」来立项的。

而差异性在实操中意味着要比同类项目「强」,要让行业和老板觉得项目足够牛,因此在进行功能设计和文档描述时常常会把项目形容成对应垂直领域的「银弹」。

但我们知道鱼与熊掌不可兼得,大部分这样的尝试都意味着存在 tricky hack 甚至只是单纯吹吹牛,这样的项目在稳定性和安全性上都存在着不小的风险。

生态封闭

与「银弹」项目类似,短期 KPI 驱动的项目通常需要的是功能强大而不是生态欣欣向荣,原因大概是功能可以用人力成本直接换取收益,而生态的建立周期和实际效果很难量化,常常满足不了有限的 KPI 周期要求。另外公司内的项目如果定调过于开放还可能影响利益分配甚至导致竞品的快速涌现。因此很多此类项目不会主动选择开放生态。

对建议的听取力度

当一个技术项目出现在公众视野中时,通常已经有了一个较完整的形态,对于很多团队来说此时实际上已经达到了 KPI 预期,项目自然也就进入了慢速甚至减速发展期。

因此我们可以通过建 Issue 、提需求的方式测试对方团队对建议的听取力度,进而从对方的态度中对项目的性质和进度一探究竟。

解决了锦上添花的问题

这在公司内部更为常见,即以某个已有系统为基础进行二次开发来支持特定场景的需求。但由于二次开发意味着项目没有自主权,底层依赖的功能迭代可能会导致项目无法使用甚至直接被原系统取代,因此无论这类项目在立项时是不是以 KPI 为出发点,最终都很难逃脱因收益问题导致的被边缘化的结局。

技术实现细节

这需要我们耐心了解项目的具体实现,从单测、注释和代码架构上寻找蛛丝马迹。架构缺乏设计、代码逻辑混乱、大量魔改等现象都预示着该项目有很有可能是完全以 KPI 驱动的。

该一刀切地拒绝使用 KPI 项目吗

KPI 是利益这一概念的具体体现,而无利不起早,如果没有利益的驱使只靠用爱发电,那么很多技术项目实际上只会停留在想法阶段进而没有被进一步孵化的机会。

对于 KPI 驱动的技术项目,作为使用者的我们要结合我们自身的需求,考虑好使用该项目带来的收益和可能承担的风险的比例关系,正收益就用,反之则远离。

这与风投似乎有些相似,引用某个项目是看好了他的某些功能或发展潜力,但未来会如何是无法准确预测的,提前制定好退场策略会大大降低我们的风险。