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

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