| 来源： |
创业邦 |
发布时间： |
2012年07月09日 16:52 |
作者： |
曲琳 |
| |
这些“小喽啰”需要向腾讯、Facebook等产品巨头学习什么?
文 | 曲琳
自从微信为腾讯打下又一局漂亮仗，腾讯副总裁、腾讯广州研发部总经理张小龙就成为了国内IT圈的红人。前段时间他在“知乎”上回答了问题“什么是好的用户体验?”被不少同行转载。其实，“产品经理”早已是知乎上人气最高的话题之一，从这个“职位”横空出世开始，关于产品经理的经验分享就从未停止过。
在公认技术门槛越来越低的今天，想让产品脱颖而出，无疑是越来越难了。新产品总会遇到同质化竞争，于是互联网创业者将目光聚焦在一位位明星产品经理的身上。这些人貌似手持金钥匙。
但我们想讨论的问题是产品制度，即通过怎样的架构、流程来进行产品驱动与执行，或对产品经理等产品负责人进行督导。
在《创业邦》针对“产品制度”的调查中，绝大部分创业者都提到，从轻量级小团队，过渡到需要建立明确产品线、增加产品数量、增加团队人员、进行专业化细分的时候，总有那么一个时间点(甚至是很长一段时间)，会纠结于产品制度的问题：
究竟怎样的产品机制才适合自己的团队?
CEO本人是否应当是产品经理?与产品负责人如何打配合?
建立产品制度是否要辅以公司文化的传承?
Facebook、谷歌等跨国巨头的产品制度是否是过于理想化的?
拥有无数产品经理的腾讯，在制度上有哪点可以借鉴?
……
这是个因公司而异的话题，几乎每一家都在探索中，几乎每一家都走过自己的弯路。因此，我们寻访了一些创业者，其中有些曾任职于互联网大公司，成为它们产品制度中的一枚棋子;有些是产品经理出身，创业之后却坚决不设置产品经理职位。
从他们各自的产品制度中，我们可以归纳出以下几个切入点：
是将新项目设置为项目组，其中包括设计师、工程师、产品负责人，五脏俱全，还是以职能部门来划分，每个新产品都由整个团队流水线作战，这是个很基础的问题。很多公司会以此辟出一些“公共资源”，例如共用的设计师团队，共用的“代码库”或一些研发成果，可以做到一次开发，一劳永逸。
不同业务公司会使用不同的制度方式，但前提是对产品的切割能力。大公司如Facebook，看起来是一个整体产品，其实是将其拆分为各个小功能，每个功能的切分、更新也被作为新产品，重新进行部署。这些小更新、大功能是很容易接壤的，而CEO需要面对的挑战是，清楚地了解这些产品的界限，以及整盘棋的部署与变化。
移动时代到来，移动端的开发成为标配，单独做“移动”小组，还是把移动端的任务拆开分配下去?很多创业公司都曾经或正在面对这个疑问。
为什么要设置产品制度?三个最主要的目的是，根据“敏捷开发”(一种强调切分项目达到快速迭代的开发方法)的指导思想，使产品快速迭代;提高产品驱动力，使每个位置上的同事都能驱动创新;产品先拆分后组合，让整个产品更立体化，业务更有联系。
豌豆荚 技术与设计双驱动
受谁影响：谷歌，Facebook 特点：项目组形式，变“产品经理”为“产品设计师”
口述：联合创始人王俊煜(曾任谷歌中国前端工程师)
谷歌的产品制度中，项目的主要驱动者是工程师，但是谷歌与Facebook的工程师文化还不一样。Facebook的工程师思维蛮产品化的，用户需要这个事情，如果有这个技术就去实施;谷歌工程师是技术能达到就去做，即使项目看上去不是特别靠谱。金融危机之前谷歌全球有各种奇怪的项目，类似无人驾驶汽车，2008年以后开始砍掉一些，但是还会有新的冒出来。
谷歌的每个项目组有不同的搭配，大家的角色不像国内公司那样分明，我就曾被带到不同的项目，不停地轮换，兼任各种角色。只有工程师是流动性不强的，他们是项目真正的主心骨。
对于豌豆荚来说，核心竞争原则是“做得好不好用”，所以我希望创新驱动不仅来自技术，也要来自设计。这种情况下，两者的界限就很模糊了，所以我们干脆就把这两者的职责合并到同一个人身上：产品设计师。目前公司有六七个产品设计师，他们有一定的设计背景，还有比较好的产品决策能力。
每个项目的主要负责人并不是指派的，而是自然而然形成的。有些项目，类似于改进手机跟电脑之间连接的成功率，产品设计师帮不上太多忙，自然会有一个工程师来负责;有些功能例如照片同步，是从产品设计的角度去考虑的，产品设计师会更擅长来带队。我们没有设产品经理，是因为不希望有“经理”这个会被看做是高人一等的Title。
产品制度这个事情对我们蛮重要的，不仅是对产品的分工，还涉及整个公司的结构。我们想做一个设计与技术结合的公司，这种情况下就需要一个制度上的保证。制度慢慢推行之后，大概一个季度能有多达二十几个的新项目发布，其中有五六个比较大的项目。平时我会负责毙掉一些新项目，或者归到另外的组去。
我们不希望分工太细，把每个人都框在自己的范围里面，之外的事情就不能碰。为什么大家的招聘会那么严格?你招的不是这个人的体力，而是他的脑力。你可以把不同的人脑想象成不同的CPU，需要调度这些CPU来完成指定的工作，如果你限制了他的脑力发挥，他就丧失了自己独立判断的能力，对整体的生产力来说是个损害。
但是，这个制度的前提是保证透明度。例如我们按照媒介来分成几条产品线，PC端、安卓端、服务器端等，经常会有一些产品需要三个媒介一起来做。公司越来越大，信息不对称也会比较严重，我的任务是，让大家明白我们的主线是什么，在想Idea的时候不要太发散，提高内部合作的效率。
例如，有一个项目组现在尝试在墙上贴一大堆卡片，来告诉所有同事项目进度;我们每周会有一个全体大会，回答大家提的各种问题;设计团队每周会做两次设计讨论，看公司其他不同的产品，贡献关于设计方面的意见。我们的邮件也用得蛮猛的，以后可能会尝试用一下周报。
另外，我们不想成为谷歌、腾讯这种多产品的公司，更想成为Facebook或者说Twitter这种产品主线很明确的公司。以前我们的每一个项目都叫“豌豆荚xxx”，也有子品牌，如“豌豆荚手机精灵”、“豌豆荚守护精灵”，去年我们把后面的这一块儿去掉了，都叫“豌豆荚”，对用户是简化，对公司内部也是简化，希望大家不要觉得自己在做一个独立的产品。
今夜酒店特价 为了快速迭代
受谁影响：新蛋，Facebook 特点：职能部形式，前后台迅速联动
口述：CEO邓天卓(曾任新蛋美国商业分析师、数据运营产品经理)
我们的第一版产品上线非常快，一个月搞定，那段时间是想到一个功能就立刻上，所有人都扑过去。
后来很快发现问题：酒店后面的定单执行是非常复杂的系统，需要在短时间内构建一套完整的电商体系，结果系统只能支撑上10家酒店，一下子上了100家，用户一打开超级慢，所有酒店都出不来。
我觉得创业公司在小规模的时候，做任何事都可以非常快，但是会犯无数的错误。没有好的架构，也没有好的分工，一旦业务上有任何变化，系统都跟不上，而且根本不知道问题在哪里。这是一个痛苦的阶段，所有事情都是紧急的，永远都在打补丁。在我理解，任何性能问题都是架构问题，想提升性能就要全部推翻。我们索性踩刹车，业务我宁可不推了，把只用一个月时间搞定的第一版的所有错误，用4个月补了回来。
将前台逻辑挪到后台的时候，我们第一次意识到产品团队需要细分。所以目前我们是这样的架构：
软件部分被称作“产品实施部”，几大块的负责人都是产品经理：安卓、iOS、WP7、WAP这4个系统由两个产品经理负责;另一个产品经理负责所有后台CMS系统，相当于进销存系统，它能决定公司的软件能力;一个产品经理负责用户研究;最后两位分别负责交互设计和UI设计。每一个部门都可以驱动新项目，另外有一个领导来负责协调他们、控制产品节奏，相当于项目经理。
这套架构是一个保证执行力，保证整体效率的捷径，是我们摸索8个月的结果。横向按照功能或者实施路径来分，纵向按照前台、后台来分。制度的核心目标是快速迭代，而且每次更新都要让用户看出来。现在互联网行业对迭代的要求太高了，你三个月前用微博的玩法和现在一样吗?人们对于一成不变的东西已经很少有依赖感了。做互联网应用应当像拍美剧，为什么最快也要每周更新一集呢?因为每播出去一集就要尽快做调研，在下一集把需要的元素补进来。
另外我们把要销售的酒店也作为产品，称为“商业产品组”。我的工作相当于连接商业产品和软件产品，产品制度已经走得很顺了，基本上我现在要什么东西，两周以后一定能拿到，任何决策后面都连着一串变化，但是新想法的驱动点又很多，于是压力又转移到决策这里。
|
| |
|
| |
|
| |
|
|
|
|
|
