Posted in SNS, 产品经理, 产品运营九月 18th, 2009bookye
我们经常把互联网产品称为“轻产品”（快速产品响应），不过就今天很多互联网大公司的流程来说，我们很难将自己的产品称为“轻产品”。现在我们越来越纠结复杂的流程影响了产品的快速反应，产品或者运营提出一个小小的需求，到最终这个需求变成产品或者产品改善，少则需要一周，多则个把月。有时候，我们觉得不是不能快速响应，只是困于流程过于复杂。我们不是没有创新，有时候创新的成本太大了。
在大互联网公司里面，我们难以避免的，就是必须严格遵循的流程规范，哪怕是创业团队亦是如此：需求收集-需求讨论-mrd-评审-prd-UC-UC评审-TC评审-研发-嵌套代码-测试-上线等等，有些大公司的团队甚至比这个流程更加复杂。我其实一直很纳闷，难道流程越复杂，我们就能创造出越好的产品吗？我一直比较讨厌，创业团队中，还流行WBS这样的东西，做这样的东西不是为了体现你的专业水平的，不会做也未必是坏事。当我们创业团队所处的互联网公司越大，我们越会被这些看似更加专业、标准化的东西束缚。最终我们的“轻产品”变得像庞大笨重的机器。
前几天业内的几个朋友都在讨论新浪这样的大公司，其创业产品“新浪微博”却能非常快速的响应，大家为之赞叹不已。那天我们讨论中发现，用户反馈给新浪微博团队的意见和建议，竟然几分钟能解决一个，这样的快速反应不是我们所谓的“紧急发布”，而是互联网创业团队必须要具备的。
我们看到如今在互联网上快速崛起的站点产品，都是走“轻产品”路线。我曾经写《正在爆发的互联网革命》一书中提到Facebook，其活跃用户量超过250万，月流量超过10亿次时，其技术负责人达斯汀都是直接用root权限在线改代码的，甚至都没有源程序控制措施。其他twitter亦是如此。06-07年底，我在校内网那段时间内，校内网一直都是小需求，运营或者产品可直接坐在开发旁边，盯着开发改代码的。其实时至今日，在校内网（人人网）几千万用户的情况下，依然如此：小需求，运营和产品可直接让开发做修改，而不用经过复杂的需求流程，也不需要做相应的产品测试。在当初我所在的校内网团队中，甚至都没测试工程师一职位（现在应该是有的了），快速响应是如此的有效。因此在这样的情况下，是允许无数次尝试和创新的。错了，没关系，几分钟内便可改正。（这样的快速反应，不但没对站点用户、安全、数据造成任何大的影响，反而加速创新产品的创新速度。）另外如今的开心网也是如此，这就是为什么新浪的团队出了新浪反而能创造出这么成功的站点的原因之一。
为什么创业团队必须走“轻产品”路线？有时候我甚至觉得规范是为了明确责任来创造出来的，流程规范的东西，中国人很难把握好，利用好。创新团队有时候没必要考虑过多的用户体验，这句话的意思是流程是能减少错误的发生，但反过来也影响了错误改正的速度。很多创业团队初期上线的产品，核心功能没什么大问题，而细节体验、小BUG一大堆，如果没快速的反应，不但不会让其有很好的口碑（快速响应对用户来说反而可以看作是一种友好的交互，用户也乐于参与其中，甚至为之口碑宣传，我今天写这篇博客就是一个很好的案例：对新浪微博、校内网、开心网等无私宣传。），反而造成初期用户的快速流失。拉回一个流失用户的成本是巨大的。所以最佳的执行方案可以是：对于核心功能，应该慎重，走严格的流程，把基础打好才能上线，但是对于非核心内容，就应该走快速修改上线的路子。
“让用户和网站共同成长”，是网站发展用户黏性的关键。我们看到开心网从始至今都把每天的进度放到首页，后来校内网（人人网）也学习模仿，这一点点小细节，看似没什么用，其实是将该产品及该产品背后的团队鲜活地展现在用户面前。以人为本的SNS产品，尤其应该如此。快速应该是SNS产品蓬勃的生命力，成功的SNS产品不能为复杂的流程所束缚捆绑。用事实说明问题，Facebook、Twitter、校内网、开心网等等成功的SNS产品，哪个不是“轻产品”的呢？另外我还没见过一个成功的SNS产品是源自复杂规范的流程下诞生的。
最后身为淘江湖产品运营，也有希望我们的创业团队同样能在我们的SNS创业过程中，能够保持一种快速响应的状态。以此共勉。
