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

六年产品开发的经验与教训 （这些经验教训确实非常珍贵，虽然更多的是从技术开发的角度，但是对于每一个产品团队来说，都有实际指导意义，为了避免少走弯路，好好看看吧！） 本文记录了个人在过去六年时间里从事互联网产品开发的经验和教训，其中，多数都是教训。 公司技术团队办公区整面墙的白板上一直写着三组词：Breaking Things(打破事物)、Clarity(清晰)、Simple (简单)。这是对整个产品技术团队的期许，其中首要、也最重要的是，随时准备”打破一切”。 　　那就从”打破一切”开始吧！ 　　1. 乐于”打破事物”，永远不要害怕”打破事物” 　　”Breaking Things” 的想法冒出来是现在的项目从零开始进行到差不多一年半之后。因为在之前，我们已经抛弃了自己的那些需要被打破的东西，每天横冲直撞就是在打破那些别人舍不得打破的。经历十多年互联网的转型，虽然不是数字原生代，我们已经逐渐了解隔段时期就必须忘掉所有的”经验”。 　　但今年年中突然有一天，我们发现自己也不自觉地期望减少改变，担心看似正常运转的系统因为调整出现问题。当看到我们自己开始被害怕技术的正常调整带来负面影响时，我们意识到害怕打破的杂草已经在埋下种子，而选择开始打破，打破我们自己所积累的过去：代码模块可以被抛弃和替代，没有希望的产品可以被放弃，可以抛弃原来的常规建立新的系统，在调整中容许犯下错误、犯下大错。 　　”打破事物”是艰难的，放弃已有的东西，是和人的常规心理相违背的。”打破事物”是艰难的，当飞机还在地面上组装时，出点问题也不怕，但是，某个阶段之后的打破却是”在飞行中换引擎”。 　　2. 结构比细节更重要 　　结构的选择比细节的选择更重要。或许因为角色不同，我比较倾向于从结构的视角去考虑问题，而很多时候不得不把众人的注意力拉回结构选择。 　　把注意力放在细节上是非常容易有安全感的，做选择的人会觉得一切在他的可控范围之内，从而形成一种虚假的安全感。而结构的选择是不能给人安全感的，因为这时的选择明显受到大环境的影响、需要很多人达成共识，没人能有掌控感。 　　这就是有趣的地方，结构的选择实际上会给人更大的掌控感，但在此过程中却人人都缺乏它。人不会相信想象的事物，直到真正地看到它；当我们看到它时，结构已经被细节隐藏起来了。 　　”产品经理”这个概念这几年已经远远超出了互联网行业，深入人心，但特别多的人把它想成” “交互细节”，这是对它极大的误解。细节是可变的，结构才是稳定不变的。比如，功能特性都是细节，是随着时间不断变化的，而接口才是结构，它应该是相对稳定的。 　　3. 简单 　　我们常常无法选择最简单的，有各种各样的原因阻拦我们做到这一点，其中最大的原因是懒惰。因为懒惰，我们不愿意多痛苦一步；因为懒惰，我们忍受各种让系统变得复杂的杂乱事项；因为懒惰，我们用复杂的方式去达成目的。最终，由于懒惰，我们事后付出更多的气力。 　　”简单”被提起经常是从设计的视角出发，从产品与技术的角度出发还可以有新的认知。任何一个技术系统，都是要持续运行与维护的，如果在开发阶段想尽一切办法达到简单，那么就自然地减少了后续成本。国内最简单的婚恋网站51230.com创始人之一邵光荣在这一点上有更深的体会，他说”越简单，才是越可持续的”。真正优雅的方案，也都是简单的。 　　要始终相信存在有某种更简单的选择，然后努力去找它。委员会式决策或相互妥协，从来不能走向简单；只有愿意放弃自己的看法、选择能找到的最佳方案，才可能走向简单。 　　4. 快速 　　快速就是对的。Facebook 办公室的几条口号之一是，”Code Wins Argument”。快速就是，不要把时间浪费在争论上，用具体的代码、产品来验证对错。不是花时间在争论，而是直接用实现来验证对错。 　　在互联网业，我的感受是一个季度等于其他领域的一年；而在移动互联网，一个月相当于其他行业的一年。在互联网之初有本书叫”21 个狗年：我在亚马逊的日子”，狗的一月相当人的一年。 　　移动互联网时代，我们每个月过的都是”一年”。之前一年的很多具体的产业洞察、技术能力、技术实现、产品功能，现在都已经变得毫无意义。用这样的”一年”来理解，能最好地解决快速的问题：没有人会花一年的时间来争论，是吧? 　　5. 在自建与集成之间平衡 　　在技术领域里面，一项功能是自行开发、还是采用已有的通用技术产品，这是个问题。 　　我们在自建和集成之间来回转，有些选择了集成，但最后发现某一天几乎把所有的集成过来的全部抛弃，有些选择了自建，但后来发现采用通用服务更简单快捷。这个选择，可能是一个持续调整的过程，改变并不是说明之前选择的错了。 　　自建，则可以构建一体化的整体效果，集成，则可以快速达到目标。一般而言的原则是，核心的业务，应该尽量采取自建；而非核心的