六年产品开发的经验与教训

（这些经验教训确实非常珍贵，虽然更多的是从技术开发的角度，但是对于每一个产品团队来说，都有实际指导意义，为了避免少走弯路，好好看看吧！）

本文记录了个人在过去六年时间里从事互联网产品开发的经验和教训，其中，多数都是教训。 公司技术团队办公区整面墙的白板上一直写着三组词：Breaking Things(打破事物)、Clarity(清晰)、Simple (简单)。这是对整个产品技术团队的期许，其中首要、也最重要的是，随时准备”打破一切”。

那就从”打破一切”开始吧！

1. 乐于”打破事物”，永远不要害怕”打破事物”

”Breaking Things” 的想法冒出来是现在的项目从零开始进行到差不多一年半之后。因为在之前，我们已经抛弃了自己的那些需要被打破的东西，每天横冲直撞就是在打破那些别人舍不得打

破的。经历十多年互联网的转型，虽然不是数字原生代，我们已经逐渐了解隔段时期就必须忘掉所有的”经验”。

但今年年中突然有一天，我们发现自己也不自觉地期望减少改变，担心看似正常运转的系统因为调整出现问题。当看到我们自己开始被害怕技术的正常调整带来负面影响时，我们意识到害怕打破的杂草已经在埋下种子，而选择开始打破，打破我们自己所积累的过去：代码模块可以被抛弃和替代，没有希望的产品可以被放弃，可以抛弃原来的常规建立新的系统，在调整中容许犯下错误、犯下大错。

”打破事物”是艰难的，放弃已有的东西，是和人的常规心理相违背的。”打破事物”是艰难的，当飞机还在地面上组装时，出点问题也不怕，但是，某个阶段之后的打破却是”在飞行中换引擎”。 2. 结构比细节更重要

结构的选择比细节的选择更重要。或许因为角色不同，我比较倾向于从结构的视角去考虑问题，而很多时候不得不把众人的注意力拉回结构选择。

把注意力放在细节上是非常容易有安全感的，做选择的人会觉得一切在他的可控范围之内，从而形成一种虚假的安全感。而结构的选择是不能给人安全感的，因为这时的选择明显受到大环境的影响、需要很多人达成共识，没人能有掌控感。

这就是有趣的地方，结构的选择实际上会给人更大的掌控感，但在此过程中却人人都缺乏它。人不会相信想象的事物，直到真正地看到它；当我们看到它时，结构已经被细节隐藏起来了。 ”产品经理”这个概念这几年已经远远超出了互联网行业，深入人心，但特别多的人把它想成” “交互细节”，这是对它极大的误解。细节是可变的，结构才是稳定不变的。比如，功能特性都是细节，是随着时间不断变化的，而接口才是结构，它应该是相对稳定的。 3. 简单

我们常常无法选择最简单的，有各种各样的原因阻拦我们做到这一点，其中最大的原因是懒惰。因为懒惰，我们不愿意多痛苦一步；因为懒惰，我们忍受各种让系统变得复杂的杂乱事项；因为懒惰，我们用复杂的方式去达成目的。最终，由于懒惰，我们事后付出更多的气力。 ”简单”被提起经常是从设计的视角出发，从产品与技术的角度出发还可以有新的认知。任何一个技术系统，都是要持续运行与维护的，如果在开发阶段想尽一切办法达到简单，那么就自然

地减少了后续成本。国内最简单的婚恋网站51230.com创始人之一邵光荣在这一点上有更深的体会，他说”越简单，才是越可持续的”。真正优雅的方案，也都是简单的。

要始终相信存在有某种更简单的选择，然后努力去找它。委员会式决策或相互妥协，从来不能走向简单；只有愿意放弃自己的看法、选择能找到的最佳方案，才可能走向简单。 4. 快速

快速就是对的。Facebook 办公室的几条口号之一是，”Code Wins Argument”。快速就是，不要把时间浪费在争论上，用具体的代码、产品来验证对错。不是花时间在争论，而是直接用实现来验证对错。

在互联网业，我的感受是一个季度等于其他领域的一年；而在移动互联网，一个月相当于其他行业的一年。在互联网之初有本书叫”21 个狗年：我在亚马逊的日子”，狗的一月相当人的一年。 移动互联网时代，我们每个月过的都是”一年”。之前一年的很多具体的产业洞察、技术能力、技术实现、产品功能，现在都已经变得毫无意义。用这样的”一年”来理解，能最好地解决快速的问题：没有人会花一年的时间来争论，是吧? 5. 在自建与集成之间平衡

在技术领域里面，一项功能是自行开发、还是采用已有的通用技术产品，这是个问题。 我们在自建和集成之间来回转，有些选择了集成，但最后发现某一天几乎把所有的集成过来的全部抛弃，有些选择了自建，但后来发现采用通用服务更简单快捷。这个选择，可能是一个持续调整的过程，改变并不是说明之前选择的错了。

自建，则可以构建一体化的整体效果，集成，则可以快速达到目标。一般而言的原则是，核心的业务，应该尽量采取自建；而非核心的，则采用通用产品。 关于这一点的补充原则是，只自建那些有长期价值的、会长期开发和升级维护的特性。对那些一次性、日抛型(月抛型)的特性，可以考虑直接否定掉。

这种一方面这样、另一方面怎样的原则，往往听起来没什么价值，但在工程领域就是这样，绝对的原则往往脱离工程领域的实际情况。

这一看似模糊的事项成为我们自认为需要记取的教训，是由于对它的体会贯穿于每一天，它让我们更好地理解工程原则。有这种工程方面的考虑，是因为我们从一开始就订立了平台化开发的路径，因而具体产品和背后的工程化体系是并重的。

6. 持续地重建

重建，如果用开发的术语讲，是”重构”。对于技术团队来讲，需要一段时间就重构代码，也包括重构整个产品结构，以保证代码不会在持续开发、增加功能过程中变得不可维护，从而由资产变成负债。 朴素地讲，重构，就是通过梳理调整，始终保持代码是资产，因为，可维护的代码才是资产，可运行的代码不一定是。

在移动互联网方面，代码的过时速度(特别是客户端部分的)，远快于互联网，这使得重构必须缩短时间间隔。过去，我们常常会把代码留给下一拨人去解决(多数时候他们会骂代码很差，有时选择自己从零开始重写)，在移动互联网时代时间快到只能我们自己解决问题。

在产品特性方面，也需要不断地重建。一个又一个新版本，可能是表面上没什么变化，但实际上必须是根本性的变革。这种变革，需要放弃许多之前投入了资源的特性，可能需要做出更艰难的舍弃。重建是必须的，否则，产品在生长的过程中会逐渐失去活力。 7. 早集成、早测试、早把产品推向市场

早集成、早测试、早把产品推向市场，早比晚好。丰田式精益(lean)生产有一条核心原则就是，早把问题暴露出来，以便更早解决。比如，发现问题，”任何人”可以停下整个生产线的设计，就是把问题暴露出来。看着平静的水面，我们常会不自觉地估计水面下也是平的、很安全，降低水位把石头露出来，就可以强迫我们面对问题、解决问题。

在开发的过程中，尽早把各个模块集成，可以发现模块之间的那些空隙；尽早把产品推向用户，可以在实际试运行过程中发现产品设计问题；尽早正式运营产品，可以通过市场来实际检验对产品的诸多假设。

没有”更早”，是过去几年的最为惨痛的教训。麻烦的是，等到发现没有”更早”的教训之时，这是为数不多难以弥补的教训。

8. 关注核心数据，永远别自我欺骗

找到那些真正有价值的核心数据，关注这些数据的变化，永远不要自我欺骗。数据统计分析系统，常常是最后一刻才想起来要做，实际上，它应该是整个项目规划时就重点投入的功能特性。 数据没那么复杂，没什么大数据，一个简单的数据图表就可以解决问题。如果用简单的数据表不能理解，那么谈什么大数据只是空谈。

在《精益创业》中，作者提到一种”虚荣指标”式的自我欺骗，其中主要提到的是累计用户量。移动应用上最大的虚假繁荣正是累计下载量，实际上我们都知道，没有持续回来的用户，不过是过客，再多的过客都不过是个数字而已。 9. 建立技术人主导的团队

最后，或许也是最重要的，以移动互联网为主要业务的公司，应该建立技术人主导的团队。至少在产品开发方面，应该建立技术人员主导的团队，而不要把工程师看成沉默的程序员。 只有技术人员主导的产品技术团队，才是健康的、能长期发展的，因为技术是现在所有变化的核心源头。

强调技术驱动很容易讲，但真正做的公司与团队，应该很稀少。有很多种说法，工程师不懂战略也不理解战略，出于中国教育原因工程师不懂产品，出于不再一线工程师不懂需求这些不过是他人用来试图掌握主导权的说法而已。

和所有人一样，技术人员也有长期养成的思维惯性，比如有的人喜欢考虑所有的可能情况，导致他设计的解决方案过于复杂；有的人比较容易妥协，导致他接受并不正确的方案；有人常倾向性地选择自己熟悉的技术方案，而不愿意尝试新的。这是别的领域也存在的人性。

另一方面，技术人员有一种常见的惯性是有价值的，技术人会更倾向于建立 “ 能长期运行的系统”，”长期”意味着在设计时已经考虑了它的长期价值，”系统”意味着会考虑它的方方面面、特别是那些缝隙；”运行”意味着最终的交付成果一定是运转的”活”系统。

如果可以回到过去，这里教训就是，给每一个工程师更大的技术产品主导权，并为产品技术团队争取更大的主导权。

这就是我六年来的工作总结和收获，希望这些心得能够给读者一些启发和帮助。