本文涉及互联网公司a、b两家。仅针对局部结构做简单、粗暴、武断的分析。

a公司主要根据产品部门结构分析，b公司主要针对运营部门结构分析。挂一漏万，敬请指正。

 

a公司和b公司都是典型的互联网公司，系针对一个当下很流行的互联网平台级产品独立设立的“事业部”。

整个公司大体分为商务、运营、产品、技术四个大部门。这也是互联网公司的一般架构。

a公司约有500人，b公司约有1000人。

这意味着，a公司b公司各自的四个大部门各自有自己机体内部的分部门或者叫做分组（我称之为孙类吧）。

ok，大背景介绍完毕，现在，咱们开始跟a公司和b公司的朋友一起工作吧！

a公司

a公司的产品部门内部分组分为运营线、产品优化线、产品进化线；技术部门分为运营线、主产品线、平台线；运营部门最近在整合中；商务部门具体分类不清楚。（大体情况，仅为分析问题预设的条件）

小1为a公司运营组xx线的一只虾米，小1在产品上对接小2，小2为a公司产品组运营线小虾米；小2在技术上跟小3对接，小3为公司技术组运营线的虾米；

昨天，小1在领导的部署下，开始进行一个运营项目，找到小2进行产品设计，小2很顺利的搞定，交付给小3进行开发制作，最后顺利完成上线。

今天，小1a又开始进行另一个运营项目，找到小2a进行产品设计，小2a很顺利的搞定，交付给小3a进行开发制作，最后顺利完成上线。

明天，小1b又开始进行另一个运营项目，找到小2b进行产品设计，小2b很顺利的搞定，交付给小3a进行开发制作，最后顺利完成上线。

......

小22是公司产品组优化线虾米，他的职责是对现有的产品“不好用”“不爽”“不怀神”的地方进行打补丁式优化。

昨天，小22xxxx

今天，小22xxxx

......

小222是公司产品组进化线虾米，他的职责是对现有的产品进行“创新”“创造”。

昨天，小222xxxx

今天，小222xxxx

......

 

时间过去，产品越来越庞大。越来越多的产品点、线、面出现不耦合，不统一，甚至矛盾冲突。

 

小1和他的越来越多新老同事越来越忙，越来越累，kpi越来越像是唐僧念咒，越来越多滴开始骂“傻逼产品”，“难用死了”“其他的运营真笨，所有的产品儿都是笨蛋”

小2和他的越来越多新老同事越来越忙，越来越累，kpi越来越像是唐僧念咒， 越来越多滴开始骂“傻逼产品”，“难用死了”“其他的产品真笨，所有的技术和运营都是笨蛋”

小3和他的越来越多新老同事越来越忙，越来越累，kpi越来越像是唐僧念咒， 越来越多滴开始骂“傻逼产品”，“难用死了”“其他的技术真笨，所有的产品儿都是笨蛋”

b公司

b公司的运营部门内部分组则按工作内容分为内容运营、产品运营、策略运营；这三类人员分别base到各个产品模块里，例如：搜索、平台、推荐系统、激励体系、社区、名人、im、游戏、反垃圾等等，类似独立的以项目去聚合商务、运营、产品、技术人员。

还有有一点跟a公司不同，虽然b公司的人员和分组层级更多更复杂，但b公司没有专门的项目管理人员，而a公司专门配备了相当数量的项目管理人员。

我想说明神马？

聪明的您一定知道，相比b公司，a公司的组织架构不太合理。

用我的“分类学”（见上一篇博文）解释的话，就是a公司搞错了分类对象，商务、运营、产品、技术作为一种以工作内容为维度的分类，分类对象是产品的生产方。b的分类好一些，虽然过乱的交叉分组会导致沟通、生产成本提升，但b公司在实际工作中的分类对象是产品。即包含了产品生产者的生产需求和消费者的消费需求的对象——产品本身。

至于为什么搞错了分类对象会导致成本升高，我要引入几个概念（其实又是分类）：点工作、线工作、面工作、体工作。（“工作”也可以是“项目”）

体工作被定义为整个产品工作：

在a公司中，小1、小2、小3和他们的同事大多做的是点工作，1/5、1/10线工作，和1/10、1/15的面工作，体工作由最高boss发号施令；不同层级的虾米们把点点点点组成线，或是把1/5、1/10面整合成不同的运营面、优化面、进化面；再由更高点的大虾负责盯紧这些面最终形成xx体xx体。

在b公司中，每个底层小虾米同样都是在做点工作，但作为高一层级的虾米则要考虑体工作，虽然这个体工作可能只占到整个产品的1/30。但产品的沟通、建造、监督只需30份时间。

由于分类对象和未能基本使子类互斥，使a公司的组织架构更像是吃大锅饭，导致kpi摊到谁身上都不合理；又因为互联网产品大多没有形成高度的标准化工作单元，即便一些虾米们从体去思考问题，也要承担很大的沟通成本，还可能没有授权导致沟通失效，这样就出现了太多需要“优化”打补丁的救火队员了。同样对产品整体的伤害更是严重。

b公司同样存在分类分级过于复杂和分类标准不合理的地方。在沟通和执行层面更多需要大虾米付出更多成本。

解决方案

按照产品本身的属性结构进行大部门设置，例如：产品a、平台a；（互斥、平级）

按照各自的运营、产品、技术进行分部门设置；例：xx运营、xx平台运营、......；

再次根据产品、平台本身的属性结构进行孙部门设置；

基本结构是树状+网状；

形象点说就是分成以包含运营产品技术商务四类馅的1/10的小体。至于你把它想象成是4层的蛋糕或是4层馅的大饼就随你爱吃西餐中餐想象吧。

同时，针对特殊情况安排特别小组，特别小组应包含运营、产品、技术相应人员。

所有的分类都要找准分类对象，并应尽可能达到“穷尽所有，彼此互斥”。

 

初入产品儿这行，“以用户为中心的设计”的说法就从四面挤进脑袋里面成为产品设计、用户体验设计的金科玉律。

真的是这样么？“以用户为中心的设计”出现怕是对互联网产品公司架构仅是对产品生产者分类产生缺陷的弥补吧。

再加上人总是习惯从自己出发，喜欢当“代表”也喜欢“代表”~@#￥%……&*（）——+

但，强调“以用户为中心的设计”，又难免会矫枉过正。

“以用户为中心的设计”是不是个好的指导思想呢？下回书中再表哈。

 

再横向平移下哈，政府的组织架构基本是按照整体去划分的，但多次分类之后越来越多的出现“出了问题没理，有了利益多部门抢”的现象。

在一个复杂组织里面，由于分类对象的庞大和复杂，分类维度的筛选困难，多次的分层分级分类，很容易出现不互斥，不穷尽的分类情况。

我们看有看到当有大事或者特殊问题凸显出来的适合，往往会有一些多部门联合的“专案组”、“特别调查组”、“红头文件”、“特派员”等等新概念出现。

但那些同样重要但没有被激发的矛盾和问题怎么解决呢？

可喜的是，在基层一些地方出现了“综合审批大厅”之类的设置。

进步是可喜的。但道路依然曲折。关于分类的探索不能止步。