引子

上周末给项目组成员 demo 站内搜索，结果反响不大好。会后反思，最主要的问题在于，我和同事们对于什么才是“站内搜索“的重点，认识是完全不同的。

我：搜索无障碍，数据准确即时。

同事们：UI， UI，UI。

我 demo 的是数据层面的进度，而同事们期待的是 UI 层面的进度。这自然就南辕北辙，鸡同鸭讲了。

为什么会有偏差

为什么对于一个项目，大家的预期会有这么巨大的偏差呢？

当天的会议上，同事们的构成是这样的：

1. 一名技术 leader
2. 两个 QA，也就是测试人员。
3. 一个 UI 设计师。

逐次分析。技术 leader 虽然属于技术序列人员，但平时工作里更多扮演管理型 leader。对站内搜索的了解不深，不太可能对数据层面的进展多做关注。

两个 QA。我们公司的 QA 除了本职工作之外，也热衷于钻研用户体验相关的问题。UI 是与用户体验强相关的问题。严格来说，搜索结果的准确性也会影响用户体验，但相较于 UI 的第一印象，搜索毕竟是之后的操作。

一个 UI 设计师。分析结果同 QA。

综合来看，与会人员，限于专业或者立场原因，会更容易对 UI 产生共情能力。

他们可能在会议之前对阶段 demo 的预期是不错的 UI，能用的数据（准不准快不快都靠边站）。然而 demo 一开始，他们发现 UI 竟然是这个样子（我用最简陋的 UI 来做数据演示）。本来想看的是精装，结果看的是毛坯，心态崩了。

而反观我，作为研究站内搜索的工程师，我太知道搜索了，以至于想要把最重要的数据层面的进度汇报给大家。

总结一下，预期偏差是如何产生的：

1. 同事们因为专业或者立场原因，认为 UI 更重要。
2. 我因为专业原因，认为数据更重要。

如何修正

我花了点时间思索如何修正偏差，第一个尝试是，让同事们可以用我的视角来预期 demo。深思了一下，觉得不太可能。

同事们认为 UI 更重要，这并非无理取闹。在很多正式或者非正式场合，我们的 PM 也表达过类似的观点。如果要说服同事们，岂非首先要说服 PM？PM 可能也有他的观点：我们的项目是要给 VP 看的，数据可以假，但是界面得看的过去呀。我随便脑补几个画面，就就觉得无可反驳。

这也并非本公司的文化。14年从事企业网银开发，我们技术部觉得数据迁移，老接口适配是迫不及待的事情，但是到一期 demo 的前一个礼拜，科长看到白板界面，直接怒了。最后我们加班加点，把所有手头工作停掉，全力套页面模板，数据全部 mock，就为了给科长看新设计。

所以只能从我的方向来平衡。办法就是，优先把 UI 做到 80% 水平，再想其他。

真正的反思

“如何修正“里提到的办法其实就是“妥协”，用满足他人的办法来解决偏差问题，这其实并不是一个办法，但是用在工作里，很合适。因为工作嘛，能进行下去就可以了，不需要追求真理。

但是有些事情是必须追求真理的，比如创业。

如果我在创业，目标是做一款站内搜索 SaaS，我坚持数据第一，UI 可以滞后，可以简陋，可以用开源 lib 改吧改吧凑合用，甚至可以外包给第三方去做。因为搜索技术的核心是数据，UI 只是附带品。

这个时候，如果有同事，下属，甚至投资方，告诉我先去搞个好看的 UI，我应该会付之一笑，坚持将数据能力的提升放在第一位。

打工的逻辑是完全不一样的，打工的逻辑是，你先得保证事情能进行下去，你需要 leader 配合， QA 配合，设计师配合。有人不配合，你的工作就难做。大家都配合，你的工作不至于阻塞，这就问题不大。最后 UI 能出来，数据凑合能用，这就可以，不需要多么出色。

所以，相比较打工而言，创业是更能放大个人能力的。你知道什么事情更重要，就可以优先去做。如果你做得好，市场刚好也买单，你就能赚钱。

那真正出色的打工人是什么样子？我们办公室升迁最快的，并非我这样喜欢玩技术，抠细节的，反而是另外一种几乎截然相反的人，正好我身边就有这样一个。男，体胖，能喝酒，爱好广泛。除此之外，还有这些特点：

1. 当面反驳指责不留情面，但是不记仇，事后笑嘻嘻。
2. 交际能力强，能跟任何人闲聊，和我们这些喜欢在办公室还用 teams 说话的宅男完全是两个世界。
3. 英语很烂，但是说起来不慌不忙，说错了也不 sorry，从不觉得丢脸。