<文稿：这是今年自己在年会上的一个发言稿整理>

我们思考再三，觉得还是回归做事的本质来谈技术。也谈谈我们在2018年以来做事的一些心得。

2018的反思关键词：服务、简单、试错

传递有价值的服务；最小化迭代，简单及有效；敢于试错

第一个反思：传递有温度的服务

       “传递有温度的服务”，这是18年初我们做的第一个反思。我们越发的觉得，技术研发们在很多时候，更多的是在交付结果，不是价值。而这个结果往往是冰冷的，没有能量的传递，也没有价值的回馈。在无数次的交付过程中，形成了一种固化冰冷的模式，大家在这个模式中习以为常。于是，我们总是在角落里被微弱的感知，服务背后的价值也很难传递出来。能唤醒我们的除了问题，就是故障，或者进度不满足要求，在那个时候我们是相当的被动，再想起价值时，却早已遍体鳞伤。

       举个我们的服务现状：前端来一个电话，出了一个问题或接了个项目，可能不知道找谁，但可能先从技术驱动，这个服务链条可能先要找到对应的产品，然后与市场负责人沟通，最后再回到技术。但我们的第一反应，“这事可能不是找我，你要先找某个产品，然后再找运营，而后是负责人，最后才是技术驱动”，于是前端挂掉电话，再去拨打这四个人电话，逐一沟通，然后在协调，最后又回到到技术。

       这种案例给我们极大的我们反思，既然这个事情是在我们这边开始驱动，也许我们只要花几分钟时间，把相应的人拉个群，说下流程，讨论下需求，这个问题可能很快就迎刃而解，而且也获得最佳，最短的处理方式。在必要的时候还能提供最优的解决方案。但我们就是无法向前再走一步，浪费了前端大量的时间。我们最大的问题，就是把思维固化在只处理单节点上，而看不清我们在整个服务链条的价值作用。

       说到底，我们还是没从心底认为技术本身是为产品服务，服务才是技术展现的基石。产品、业务、市场不会跳过需求跟我们谈技术，虽然我们交付了结果，貌似我们完成了这个使命，但因为我们没有多思考一步，而使得这件事情没有闭环，我们的价值没有呈现。于是，就这样一次次的错过传递价值的机会，还有可能给人以不好的印象，甚至是负能量。

       我们反思：这种冰冷的服务印象在交付中如此慢慢地累积，从而影响了信任链条的构建。

信任其实也是很简单的事情：

所谓信任，就是明知道这个事情以我们的能力可能做不了，或者行不通，人家还愿意相信你能做成；

所谓信任，就是明知道这个事情你可以做，他也能做，甚至有可能他做的更好。但人家还愿意把事情交付给你，因为觉得你靠谱

所谓信任，就是有时候，我们在用各种术语，各种专业理论解释一件事的时候，虽然人家听不懂，但仍然觉得你说的好有道理。“嗯，你说的很对，就这么办！”

因为没有传递有温度的服务，所以我们很难跟人形成信任，于是我们的价值链没法形成。

这是我们思考的第一个技术价值链：

服务-信任-价值-能力

       我们深知没有一个需求方跳过服务跟我们谈能力的，我也从来没见过需求方直接找技术先沟通什么算法，架构，然后再谈需求，于是纵然我们有再好的能力，也没法通过服务的入口得到释放（你即便是全栈工程师又如何？），但这个价值链看似简单，但要让研发短时间都形成这种思维模式，也不太容易，我们也走了很长一段路，正在慢慢转变。因为研发思维，有时候就像人的性格一样，是植入到基因里的，确实不好扭转，但我们会认真践行，也希望如果有做不好的地方，大家直接反馈，我们立即纠正。

第二个反思：把复杂留给自己，把简单呈现给大家

       想到一个场景，说是在一个商品页面上，增加一个搜索商品功能，产品是这么描述的，做个搜索框，要求能搜到用户想要的商品，不要做的太复杂，简洁，美观，大方，效果就做成跟百度搜索一样就行，简简单单就好。听到这样的需求，技术哥们都要疯掉，百度搜索框的简单，是其背后成千上万工程师，产品和科学家的努力，是无数个算法和框架的支持。

       这个事情对我们有启发，我们的场景刚好相反，我们当下的场景就是，技术见到相对复杂的业务，就跟产品大谈复杂度，难度，不好实现，底层不好支持，工时长，成本高。更有甚者说这个太复杂，底层支持不了，做不了，你们得改需求。还有就是这是历史遗留问题，是客观原因，可能做不了。我想在做的很多产品是有同感。

       有个产品让我们印象深刻，就是体脂秤，就是我们原来最自然的想法，就是体脂秤要把数据从称上传到我们手机，那肯定称上面要安装网络设备（不然蓝牙，SIM卡，或是红外之类的）。但这个产品恰恰不是这样，他是通过将地址和结果转化为二维码，再通过扫描二维码到服务端解析，最后推送到手机。 这样体脂秤就不需要安装任何网络设备，降低了成本，还规避可能因网络造成的各种问题。这是多么极简的设计，用李善友教授的话，多么Amazing啊，但我们为什么想不到呢？

       我们就这个问题认真做了反思，到底是哪个驱动点不对，使得我们的思路走不到这一点，后来想到，原来有“需要降低成本，减少网络故障”这一需求驱动，所以其实就是两个点（一个是体脂秤上有数据，一个是要在手机上看到数据），这让我们想起了第一性原理，找到那个最初因。

       我们不要忽视、小看或者抵触某些我们看似复杂的需求，因为那个需求背后可能隐藏这新逻辑的创新和极简的设计。

这是我们思考的第二个技术价值链：

直奔目标，以终为始，大道至简

       我们要做的就是尽量让结果简单，技术逻辑的复杂和难点，留给自己思考，不要把产品需求讨论，变成技术方案讨论，变成历史债务的，我们是服务单元，首先是要解决问题，而非回避问题，抵触问题，甚至将问题复杂化。

第三个反思：越是愿意承担，就成长越快

       我们内部决定，年初一开始，但凡技术有参与最终导致问题发生，并无法界定职责边界的，都技术承担。我们并非喜欢自虐。我们希望聚焦问题本身，剥离干扰解决问题的所有主观因素。我们越发觉得，当我们不刻意关注责任边界的时候，反而越容易回答看待问题的初心，越容易找到合理和最优的解决方案，而自己和团队也是越容易通过问题的解决而获得成长

       记得一个故障，我们一个架构师，从客户端，到服务端，到防火墙，到CDN，到，是什么力量让他能这样关注问题本身，我想一定是去边界化，不再聚焦责任。 那天我们也借这个事件在团队中做了一次分享。一个故障问题的解决，处理，汇总，分享。我们收获了近22个技术知识点，这种问题的承担，对我们来讲，实在是太划算。所有的成长都是在试错中习得的，最好的创新和认知收获，有时就来自对问题的解决。

       问题背后，永远埋藏着深知，只是谁承担，谁就越接近认知真相。

这就是我们思考的第三个技术价值链：

用于承担，敢于试错，学会总结

       我们对待错误只有一个标准，我不会杜绝犯错误，因为这是我们成长的源泉。但要杜绝不犯同样的错误，不犯低级错误。

…………