IT技术博客大学习 共学习 共进步

以产品线划分组织架构

2010-11-11 19:40:11 浏览 3,082 次

    请先阅读:前端开发是做产品么

    几位同行私下聊了下,我也意识到前文把“部门”和“团队”概念混淆了。有个很重要的观点,既然都可以,那讨论的只是相对更好,显然不分最好,如此管理成本最低。是的,我认为如果所有人的水准相当,并且价值观一致,那确实没问题,但现实可能么?

    由此可见,以某种逻辑为基准的组织方式为主线的管理体制还是有必要。基本得到公认的,是以“产品线”划分公司组织架构最理想最高效,如此一个产品的所有参与者受共同价值观的驱使,所有人的节奏和目标理应一致,理论上肯定1+1>2。早年流行的“事业部”组织架构即如此,各事业部其实是相对独立的产品或产品群体系。

    难么“团队”做何解释?如果把“部门”看作纵向结构的话,那么“团队”就是横向结构。“部门”以产品线为分类逻辑,“团队”以专业技术为分类逻辑,有点类似信息架构中的“模糊组织体系”。根据产品三要素中“商业、设计、研发”的结论,其中“商业”为产品线划分的依据,我把“设计、研发”分别定义为两大专业技术团队,而不管是一两人还是几百人,基本所有成熟的互联网产品都有。

    在实际工作中,有创业公司、小公司、大公司、集团公司之分。提取其中的共性结论可知,创业公司通常只做一个产品,小公司通常只做两三个产品,大公司和集团公司都会做多个产品。但从公司的核心价值来看,其实大公司和集团公司做的多个产品多为对产品的细分和拓展,形成产品群,其主体还是几个“大”产品。区别在于,大公司可能为产品群设立独立的“事业部”,而集团公司可能让各产品群成立更独立的“子公司”。当然,形成规模的集团公司“子公司”其实也就是“大公司”,比如“阿里巴巴”是个集团公司,目前旗下包括“阿里巴巴网络有限公司、淘宝网、支付宝、阿里云计算、中国雅虎”。以公众认知度较高的“淘宝网、支付宝”而言,它们其实都是相对独立的“大产品”,其模式三言两语能说清楚,但目前他们各自已经是大公司规模了。2007年,中国雅虎曾经改组为“新媒体事业部、通讯事业部、搜索事业部”,其道理也类似,它们各自是相对独立的产品线。另外,互联网产品的规则是逆水行舟――不进则退,因此阿里集团曾经的“阿里妈妈、阿里软件”这样的产品该合并就合并,该消失就消失(其团队均已合并进了淘宝)。

    把互联网产品的发展和演变规律讲清楚,可见“以产品线划分组织架构”并不是什么新鲜事。但传统做法是在各大产品体系之下,设立相对独立的部门,比如运营部、产品部、研发部,并根据这样的“专业职能”形成主体管理结构。近两年业内在推行一种小团队孵化产品的做法,美其名曰“内部创业”,不管产品大小,均形成绝对“产品线”主体管理结构。早期的常见做法,是从各专业技术团队抽调人手,安排到某地封闭开发,所有人在短期内仅对此产品负责。长期执行下去,即成为产品创新的一个原则。好处毋庸置疑,据我所知,在大公司里这种做法是Google首创。

    但“产品线”主体管理结构不是说把传统的“运营部、产品部、研发部”都给抹掉,因为其专业性也需要特殊的管理体制和考核机制,至少也应该是隐性存在的。也就是说,“以产品线划分组织架构”并不影响“专业设计团队、专业研发团队”的存在,“产品线部门+专业技术队伍”两条线的机制有什么好处,我有两个观点:

    第一,考核问题,绝对以产品负责人(产品经理)100%考核专业技术人员(设计师或工程师)的做法有失公允,产品负责人不一定也不需要对专业技术精通,因此起码应该分出30-40%的比例给其专业技术团队的负责人考核。的确,专业技术人员均对产品的商业价值负责,但在管理角度,两方面牵制的做法有益无害。

    第二,员工发展问题,互联网技术领域内专业技术更迭很快,尤其“专业技术队伍”的同事需要互相学习和沟通。专业技术人员在各自领域有归属感很重要,在同一个公司或集团公司之内,互通有无,不管对公司还是个人都有好处。举个可能不恰当的例子,搞文化艺术的与修水电站的其实很难有共同语言。

    相对前文,我还是坚持“前端开发”不应属于“研发”体系的观点,本文稍微把问题拔高了一点。其实暗合刚刚结束的UCD2010年会主题――全民体验,不管白鸦把支付宝UED拆了,还是唐沐继续经营腾讯CDC,我觉得都值得尝试。还是希望更多大公司的实践者多改革实践,以提升咱们中国互联网产品的整体素质。期待2011有新的变化,以便UCD2011有个更值得关注的主题。

    要说工作背景,我也算是什么部门都呆过。其实对我来说,部门也好,职位也好,都是浮云。我也知道,在任何场合“人因”都是首要问题,合格的人才懂得自我约束和协调。但如何把有限资源的价值最大化,管理,还是需要一点点技巧的。

建议继续学习

  1. Tencent-ISD组织架构 (阅读 5,764)
  2. 如何对待开发团队中那个拖后腿的人? (阅读 3,841)
  3. 利用设计工具成为个人设计团队 (阅读 3,241)
  4. 招聘的绑架 (阅读 3,061)
  5. 无线产品团队总结 (阅读 3,044)
  6. 在淘宝大半年的零散体会 (阅读 2,984)
  7. 细节魔鬼与精简团队 (阅读 2,842)
  8. 好事多磨 (阅读 2,803)
  9. 研发团队的角色和构成 (阅读 2,762)
  10. 为什么我在一个人战斗? (阅读 2,740)