技术心，产品情-朱赟的财新博客-财新网

前不久遇到一个这样的问题。一个已有的产品，因为种种原因需要重新实现。这个产品属于核心产品之一，其多项功能都是常常用到的。但是因为一些功能是经年累月逐渐加上去的，所以早先的设计时的一些假定早已不成立，就时不时会遇到一些很难修的 bug，或者修了一个 bug，又会不小心引起另一个 bug。

重新设计的时候，主要有两个方案。一个方案，可以保留现有的所有功能，也可以避免大部分遇到的 bug，但是，技术细节和底层模型变得异常繁琐。在实现中，更容易出新的实现相关的 bug，而且对很多常见情况的处理也会略有性能上的损失。

另一个方案，技术设计简单清晰，易于实现和维护，性能上也肯定会更优。美中不足的，是之前产品的功能的某一两项，可能不再能支持，或者以别的方式来支持。当然，这几项都属于特定情况下需要的功能，并不是主要功能。

题图：by 丫头非常骄傲

如果你是技术负责人，你会怎么做呢？

如果你选择第一个方案，也就是保留所有功能，实现变得更复杂。好处是你和产品的沟通更简单，因为你不需要他们做任何变动。坏处是后期的实现和维护代价会变高，而且这个变高的代价性价比很低。

如果你选择第二个方案，那就意味着你需要去说服产品在一段时间内将不能支持的几个功能下架。你得让你的产品经理理解你的出发点，看到你遇见的所有的问题。但是系统变得更简洁且稳健。当然，你还必须有一个合理的方案，如果后期需要支持这些功能时，怎么处理。会不会反而把现在的系统变得比第一个方案还糟糕。这里还要包括怎么把这个功能的缩减给你的用户解释或传达。

我这么说出来，似乎答案比较明显。但是身处其中的技术人，不仅需要知道产品和技术上的权衡利弊，能够对两种方案的得失做出准确的评估，还需要比较强的沟通能力让产品和你坐到一条船上，更需要在设计中留下余地，对未来的扩充有个设想。

而总有时候，因为这个度没有把握好，或是没能说服产品，而导致工程师们疲于实现一个过于繁杂而不必要的系统，甚至 bug 百出。

前不久和一个资深的产品经理聊天，她说的一个故事让我记忆深刻，笑完了，却挺有感触。

她之前工作的公司有很多人技术功底特别扎实。后来，其中的三四个一起去创业了。有一天她和他们凑巧一起聚聚，就聊到那几位创业在做的东西。这几位对于他们在解决的技术问题特别兴奋，而且提到他们在开始想法的基础上，发现并解决了多个技术难题。言语间极有成就感。这位产品经理就问：你们解决的问题的应用场景是什么。这几位说了，结果都是一些特别非主流，特别特殊情况的问题，一万个用户里可能只有一个甚至还不到会在意。

从这位产品经理的角度，她是可以理解的，因为技术人对解决问题的热爱，尤其是解决技术难题的热情，是技术人的本能之一。但是她觉得，这并不是一个很好的产品的故事。确实，这家小公司虽然技术做的极好，产品却是不了了之。

她还说，其实很多时候，并不是产品不在乎技术，而是很多信息，技术人没有能够很好的反馈给产品。如果技术人能够帮助产品了解技术难点，全面理解不同方案的利弊，长远的潜在优势和劣势，几乎所有的时候，产品都是愿意帮助推进一些对技术也有利的决定的。也正因为此，有产品思想的技术人、或是有技术基础的产品人，就变得特别可贵。

当然，也不乏一些纯粹做技术的公司，或是公司做到一定规模，因为产品需求，把技术做到一个极致的公司（比如谷歌）。但是很多时候，能做出一款很炫很实用的产品，不见得一定会需要最复杂的技术架构，尤其很多成熟的技术已经可以全盘使用。技术做到极致，也未见其产品就超越所有同类产品。他们之间有关联，但不成正比，越往深处越是如此。

这就说到一些技术人找组找工作。

你会发现，有时候你加入前觉得很牛的公司和组（因为产品很牛），结果加入之后发现技术不过尔尔，甚至大跌眼镜。如果你加入的目的，是技术上的成长，学一些新的东西，你可能会有点失望。或者你因为朋友前辈推荐，进了一个公司，公司工程师都很牛，但是公司增长却让人扼腕。

如果是技术人，搞清楚自己想要什么，保留一颗技术心，但同时对产品怎么做多一些思考。不仅对一个技术方案会做、能做、知道怎么做，合适的时候，也要问一问自己应不应该做。

话题：