对技术服务的提醒

得到认可

刚才在胆量里没说的一点。我们经常会看到，一项新技术在公司内久久难以推行，因为业务主管百般阻挠。即使排除利益纠葛，仍然会发现一种发自心底的不信任存在。而这种不信任，又往往来源于对同事工作的不认可。

这个问题原因很多，也许没有通用的解决方案，但我说一个例子。

我们最近开始使用Codis，就是@goroutine 和几个家伙之前搞过的玩意儿。虽然他们最近已经独立开搞像Google Spanner但拥有更高级特性的TiDB（就是太牛了的意思）。由于我对他们比较熟悉和认可，所以在Codis尝试方面也多出很多底气。这种信任并非完全来自于出问题之后的直接电话支持，而是真心觉得活儿好。

反过来，这对很多服务也是一个提醒，特别是云服务。也许只要你得到合作伙伴的认可，或者至少让他们觉得，自己动手不会比你做得更好，你基本也就成功了。

对于大多数理性创业公司来讲，他们还是更愿意把精力放在自己的主要业务上，不会希望所有的服务都自己做，因为这个年代，唯快不破，创业等不起一辈子。

产品意识

回到开始那句话，“在对它不了解的情况下，仅通过google就能解决问题，不正说明它不难掌握有大量资料可查吗，实在不行还能翻代码。” 这话有些道理，然而却存在一个问题，这个问题就是：

作为一个使用者，是否有能力解决遇到的问题，与是否有意愿去遇到并解决问题，是两回事。

你有本CPU设计手册，你可以说处理器很简单，但我只想看个电影啊？给你Linux内核的源码，你可以说内核设计不难掌握，但我只想跑个游戏啊？何况他们是否因此就变得不难了，也是值得怀疑的。

这其实反映了技术人的产品意识。

很多技术人员喜欢玩酷的东西，他们愿意去探索新的领域，把不可能的变为可能。但是很多时候，他们做出来的东西却很难使用。

有的库可以增加很多参数，参数之间却有耦合，导致你在采用的时候需要写很多设置代码，而有点库却只需要一行代码；有的服务功能众多，却需要用户学习繁杂的步骤，而有的服务却可以开箱即用；有的服务功能可以实现，却会有很多不稳定甚至崩溃的情况出现，等等。

对于实现的工程师来讲，可能最大的区别在于，你是否考虑从用户的角度审视过自己的东西。即使这个服务也许只是为其他技术人员使用的。

技术人员可以，也应该，让技术人员更幸福。