从我个人来讲，我非常非常喜欢流水线。我一度认为流水线是大工业时代的智慧结晶，完美，有序，高效率。种种一开始高成本高门槛的发明创造，借由流水线，逐渐走入寻常百姓家，成为我们生活中不可缺少的一部分。靠着精准的分工和低廉的人力，我们才凭着高效率和低成本逐渐构建了改革开放后的工业大国。
改革开放后的大多数中国企业家，对流水线都是有情怀的。
在大多数行业，把一个事情拆细，让低成本的劳动力也能做，是企业家梦寐以求的事情。因为在这些行业，分工的明确，流水线的顺畅，会对效率和用人成本带来显而易见的提升。
但在互联网行业，这提升似乎变得不那么确定了。
在开发领域，我们经常会发现，某些问题，与其花8k一个月的工资，找4个经验，能力都勉强的工程师，不如直接花30k找一个高级工程师来解决。这种现象的出现，就是因为在开发领域，智力和经验层面上的差距绝不是可以堆人就解决的。人一多，协同，调配，联调，方案等等全是成本，而且经验丰富的高级工程师踩过的每一个坑，都将是在工作上的宝贵财富。
工程师界有一句非常高频出现的话，叫“算了还不如我自己来吧”。
这句话背后其实涵盖着很多问题，但核心都可以归结到“对协同效率的担忧”。那么为什么一百多年来，在工业革命中发挥重大作用的流水线，在新时代的互联网开发领域变得不那么好使了呢？这问题怕是得写一大篇论文来回答，我们今天就不展开讲了。
总之，现在越来越多的公司，在招开发人员时候，除了特定的某些技术/算法岗位，基本上都奔着较全面的方向去找的。有兴趣的同学可以去拉勾上看看相应的JD，基本都是五六行技术方面的涉猎要求。甚至像滴滴EP（工程生产力部门）这种直接就奔着全栈去招了，我前两天刚看到一个1-3年经验的php工程师职位，需要的熟练+掌握技术就是c/c++/shell/ajax/js。很多工程师可能就会想，你说我一个做php的，怎么就跑去滴滴写js去了呢….开个玩笑。
而招来之后怎么管理呢？基本脱不出项目制，矩阵式的管理结构。
自由到极限，那便是google那种，你只要募集到足够多愿意跟你干某个项目的人，你就可以自认为项目经理开干。或者你今天做这个有点烦，想干点全新的事情，那便可以找个项目团队自由加入。工程师的管理架构上只有大事业部门，剩下你具体做什么，从外人看起来其实都非常乱。
稍微规矩点，那便是百度那种。大部门下面有小部门，小部门有若干方向。而每个方向里面也是挺自由的，而且非常容易发生“哎哟我们有个新事情想干，组织上决定了，就由你来做其中的xxx”，所以也较难出现一个工程师干很多年还在一个岗位上维护的事情。你所谓的经理（汇报关系上的）可能同时自己也有一个项目要做，同时也是很多和你类似的工程师的指导者。完美的打破了那种”管理半径不超过8个人”的定式（当然这种管理肯定不是强干预，这之后我们再说）。
这种结构是非常适合工程师文化的，因为如上所说，工程师干的事情，并不是简单堆人便可以解决的问题。
引用工程师的例子，我是想说，在互联网行业的非技术领域，团队的管理和工作模式构建，也在发生变化。
目前国内大多数互联网公司的非技术领域，都有着非常森严的部门等级制，这和技术领域的相对开放形成了鲜明的对比。
比如当我们谈到一个中大型公司的coo，那意味着他下面还会有品牌总监，公关总监，渠道总监，客户关系总监等等总监们下属的部门，然后部门里就可能会有媒体经理，策划经理，活动运营经理等等小部门，继而小部门里又会有新媒体专员，文案专员，活动策划专员…甚至再夸张点，每个专员还会带一两个只做特定事情比如发发微博，搞搞微信，当当客服的实习生。
这种管理构架是典型的大国企风格，再往前导，就是流水线式的工业化思维。
可能有些同学就会说了，啊锤老师我知道，这种管理模式，会带来各种乱七八糟的问题，例如市场反应慢，一场舆论抱怨危机可能都发酵到很大规模了，才会让coo之类知道（或者他直接从已经很大规模的舆情上直接知道了），再例如项目协同合作难，一件事情如果要多个部门联动，如果不是公司高层亲自带队上阵，基本等于铁定流产了。
这些问题，其实我认为反而都是小事。
大事在于，这样的层级结构，会让员工，将过多的精力牵扯进政治资源的争夺和人际关系的维护上。例如你是一个负责微博的实习生，有个顾客抱怨了一个问题，你觉得可能公司产品确实有点问题，你想提一些建议。但马上，一层一层的层级首先会让你觉得紧张，让你觉得人卑言轻，让你产生一种“哎，我就是个小角色，人家会听我的么”..这种负面情绪，很多时候如果不是特别大的问题，你就放弃了。
这种等级制带来对员工积极性的压迫，我认为是比等级制产生无数问题本身更重要的事情。
你是专员，你的汇报对象就是经理，你是经理，你就不能绕过你的总监去直接跟coo讲话。这不是公司提倡不提倡开放和公平的问题，而是很多时候，把你丢在那个位置，我们从小收到的教育和耳濡目染父辈们的情况就已经让人下意识的形成了那种规则。所以尽管有些公司将公平平等提倡的再响，也不会真正形成平等的氛围。
所以有些公司（常见于互联网中小型公司，因为巨头都或多或少都将工程师文化和产品运营文化整合的较好，或者一个文化成为另一个文化的附属体系，关于公司文化问题我以后再说吧），我们就会经常看到公司文化的割裂，一方面是技术部门的开放透明，看起来非常国际接轨，创新开放自由平等，另一方面是产品运营部门的森严等级制，像足了老国企事业单位的风格。
全栈pm的数量增多，可能就是互联网公司文化建设层面上，破这个局的钥匙。
从公司用人的角度，有几个核心问题需要时时刻刻放在第一优先级考虑
能力结构
成本控制
协同合作
晋升路径
我们分头来谈。
一、能力结构
能力出现结构是一个很现实的问题，因为你不可能招到全水平一样的精英。很多公司标榜自己：“只招最好的人”，其实很多时候都是招聘时候的口号而已。能力结构主要包括两个层面，一是不同工种之间的能力配合，一是同一工种之间的工作分配。
比如要搞一个内容运营的活动，涉及到活动落地页设计，宣传文案，推广，用户互动等等工种，那搞一个项目组，是否都能涉及到，能力是否均衡，是否在某个特定工种上有短板，短板是否致命等问题，就是团队能力配合的范畴；具体的工作有哪些，比如在用户互动上谁去做采编，谁来做一线互动，谁来做抽奖，谁来最后push内容，这就是工作分配的范畴。
如果你发现有一个工种团队没有，你要去招个专门的人来才能做么？你如果让团队已有的其他工种的伙伴去做，他们愿意学习么？他们愿意去做这个工种里可能存在的垃圾活么？他们做这些工作对他们来说有好处么？
这些问题会出现在每一个企业主的脑海中。
如果我们将这些所有的工作划分为三类：开拓性工作（没经验没参考，有极大挑战，不一定搞的定），挑战性工作（有经验有参考，有挑战，老手可搞定），垃圾活（有经验有参考，无挑战，新手即可做）。正常来讲，一个活儿，总会从刚开始出现时候的有挑战还不一定搞的定，随着经验和失败的积累，变成可搞的定，直至最后形成套路和规范成为没什么挑战的机械重复劳动。传统流水线式的企业的最大利益，就是高级人才永远做有挑战的困难点，中级人才去做有挑战但是可以搞定的，刚毕业的年轻人和实习生去反复做那些大家都不愿意做的垃圾活。
这会出现什么问题呢？
新手-老手-专家之间的鸿沟，在这种构造中几乎是不可跨越的。
流水线的特征就是让人永远做自己擅长做，能一定做的达到预期的事情。诚然，企业都想找高级人才或者超级人才，但成本，意愿，方向，甚至机缘都不一定让企业主找到真正靠谱的高级人才。又或者找得到，但是因为工作本身可挑战的事情不多，导致高级人才又流失掉（之所以人能成为高级人才，肯定是有着强力的自我进步驱动的，所以你这边挑战一降低，就自然会导致人家想出去看看）。很多企业都在说我们要内部培养人才，内部晋升，但如果采用流水线式的框架，就几乎不可能让新手触及到那些真正有利于他们成长和挑战的事情，即使是让他们参与了某个挑战性的项目，但因为工种的搭配不同，导致他们也很难真正从中得到学习和成长。
能力结构的不均衡和固化，导致了团队内部成长机制的无效化，任何一个有潜力的人才，如果想实现从新手-老手-专家的跨越，无论是能力岗位还是薪水诉求，往往到最后只能跳槽了。这无疑是令人痛心的。
所以我们需要用全栈pm的思维来重新打造产品运营团队。
用一张图来说，如下。
我觉得不用多说了，聪明人一眼就看出来这是啥意思了。（请忽略比例问题，我就画个示意图而已，这个比例都可以调，但一定要都俱到）
简单说几条
一、每个全栈pm都不应该拒绝垃圾活。（垃圾活，从改善工作流程，更底层贴近用户，理解项目逻辑等等方面，是非常有利于全栈成长的。这一点以后有空了再说）
二、每一个pm都应该在任何一个项目中进行符合其自身的开拓性工作。
三、工作中的配合应该密不可分，必要时候交叉工作。（就是所谓“算了我来做，但是你得看着我怎么弄”）
企业的团队能力结构本身的需求，绝不是面面俱到面面强，比如一个电商网站，你临时起意想做一个搞笑评论回复大搜集，你非要去招一个专门在糗百知乎这样网站做内容运营的老手级以上的人，是完全没有必要的。所以在结构的搭建上，找到一个强某方向的全栈带队，剩下就是靠学，参考，做到在企业项目本身的“专”和能力覆盖面上的“广”。
这样，一个新人，从一开始的重复性垃圾活熟悉项目，熟悉环境，熟悉公司，又会逐渐随着开拓性工作的深入，很容易看出来发展的潜力和个人的态度。继而对公司平衡不同项目间的能力结构产生正面的价值。一个老手也不用担心跳槽，因为项目是无穷无尽的（只要公司不倒闭），又因为能力的全面涉猎，总能做一些开拓性的工作。
说到这里插一嘴，前两天有个猎头得知我离职，然后给我推荐工作，说某个app要找一个新业务的产品负责人。我好奇问，为啥这家公司不让自己以前的中层干部，找个最靠谱的来挑这个新业务呢？猎头说是因为管理层觉得以前的中层干部没人干过这个事情，所以得找外面有经验的人来。我说如果一个公司，一个新业务所有人都没干过或者涉猎过，那怎么保证这个新去的人一定能干好呢？怎么保证和以前资源的协同和配合能顺畅呢？万一干了俩月发现这个业务似乎不靠谱，是脑热的结果，那是不是要辞退这个新来的人？后来猎头就不置可否 了。
流水线的企业，应对新行业发展的能力，其实是非常弱小的。
二、成本控制。
这就是赤裸裸的谈钱了。
我们假设有一个团队，6个人，1+2+3的结构。
1个资深专家：月薪30k（不用太介意这个值准不准，以现在的情况看只能更高）
2个老手：月薪15k*2=30k
3个新手：月薪8k*3=24k
总共84k的团队。
这我觉得是一个差不多的平均值。
传统流水线情况下，会随着团队工作经验的发展，系统支持的增加，导致工作性质从开拓性转为挑战性到垃圾活的情况越来越多。
这样工作能力需求就会自然而然降低。新手级工作从找一个8k的人，降低到5k，甚至降低到3k找一个实习生来就可以干。
但假设大家都不跳槽，这个成本就一直维持在84k。
而又因为工作性质的稳定，导致这个团队很难被剥离或者去做新的事情，导致成本一直高居不下，最后撑不下去，只能集体裁员（前阵子某某公司裁掉某业务群在zhihu闹得沸沸扬扬莫过于此）
但全栈式管理情况下，这个状况就会改观。
矩阵式的结构会提供一种能力之外的晋升路径，作为企业的管理者，随时都可以将人抽离（因为工作在团队内部都是全覆盖的，不存在哪个核心工作必须只有特定的人来做的问题），这样就可以让好钢真正用在刀刃上。例如让资深专家去挑战一个全新的业务负责，让老手成长为本项目或者别的项目团队的头，让新人晋升，补足更低级更便宜的新人进来做垃圾活。
很多时候，企业成本的增加不是因为工资开的高，而是因为工资高的人，工作中有大量内容是不符合他们能力和挑战的。
全栈式管理提供了一种足够灵活的调配自由度，让人能更好的发挥与他们pay相符的价值。而不是让一个高薪人才，持续拿着高薪，但是却做一个相对极其稳定的业务。毕竟，企业总要发展，总要有新的不断的挑战冒出来。
三、协同合作
部门间协同合作是个老生常谈的话题。几乎每个职场人都遇到过部门间扯皮，推诿，甩锅的问题，大小公司都有。
流水线是天然的扯皮生成器。
某公司，有一个平台，平台上有消费者（流量获取），有广告（商务拓展），有系统（平台产品运营）。
然后老板说，x季度收入为何这么挫？
流量获取部门说：我们搞来那么多流量，因为系统烂和商户少，转化率不行
商务拓展部门说：我们拉来那么多客户，但是系统烂和流量少，导致收入降低
平台产品部门说：我们已经优化的很牛逼了，但是商户又少，流量又少，自然收入不行。
三个部门都会玩命找出来大量证明自己很牛逼，工作很有成效，整体kpi（收入）不行都是别人的锅。总之我们看到的就是高管会上所有人都在互喷。
这都是流水线带来的结构性问题，不信我们把三个部门的头换个个，他们分分钟就会说这个问题不是由我现在所在的部门背锅的。
都承担责任到最后就是都不承担责任。
所幸这家公司似乎意识到了问题，现在的情况是这三个大部门统归一个很有权力，很资深的公司元老副总裁管。
这还是高级层面的，低级层面扯皮更多。比如每个部门内部就会更玩命的甩锅和推卸责任。
很多公司致力于宣扬一种理念，就是自我反省啊，自我检讨啊什么的。
但结构决定了所有的自我反省和检讨，都只能是暂时的场面话，说出来好听，但实际上都会去甩锅，这是制度决定的，不是人决定的。
天天惦记着甩锅，真正在协同合作之中，就会尽可能的去划清界限和责任，甚至会衍生出类似于“留邮件存档，防止耍赖”等行为（这在刚刚所述那一家公司尤其典型，每个人都默认别人是不靠谱的，需要留邮件来存档）。
说到底，完美的协同合作是不存在的，我们只能尽可能的趋近。
全栈式管理是趋近的一种方式。
在协同中有这么两个核心要素是对协同配合程度起制约的：
同理心（是否理解别人的工作）
责任分配（是否顾忌到责任问题而导致清晰边界引发的甩锅）
很多时候，我们所谓“隔壁部门的就是不配合”，基本就是因为大家之间有隔阂+责任太明确，生怕出现“这件事情你干好了都是你的功劳，干差了便推到我身上”的情况。
全栈式管理可以在这两个层面有很好的优化。
1、一个公司的主营业务上，基本所有的工作，负责项目带队的专家级全栈pm都涉及到，而且未来和过往也有大量需要别人配合的时候，所以很容易产生同理心。说白了就是你干的事，如果我干过，那我知道会有哪些坑以及你需要付出多少，或者我没干过，但我未来可能要干，所以我也得尊敬你的意见。
这样就可以减少我们常见的“这个事情明明那么简单，你们怎么这么久才弄完”之类的质疑。（这话很常见吧，别人对自己说的时候，你心理苦么？是不是想骂一句“你懂个J8”）
2、责任问题。
全栈项目团队的责任是相当明确的，即：项目负责人背一切锅，项目团队成员一起背锅。
比如项目进度慢，原因可能有多种，例如开发人力不足啦，出现意想不到的问题啦。对，都是你们的锅，你说这我怎么解决，万一服务器挂了三天，也是我的锅么？对，都是你的锅，谁让你不早早和你的boss沟通来因为不可抗力而延缓项目，或者提前想到调配方案。
你说别的部门不配合，为什么不配合，你有调动别的资源么？你有预先和人家打招呼么？别人没有配合你的义务，你有好好和别人沟通请求支持么？你的沟通能力体现在哪里？某件事情需要某个高管审批，你不会直接给他打电话？你如果不好意思，不会让我帮你打？…..
大家不要笑，我被这么真真切切的喷过很多次。（PS：我以前的部门老大从我入职第一天起就这么喷我，我受益颇多，而他现在也是一家行业第一的公司的ceo，在这里要感谢一下他）
不要甩，你当这个项目的负责人，你就得背这个锅，哪怕是天灾，也是你的锅。
所以没任何责任，这个项目谁负责，产品谁负责，谁就是背锅，你搞不好和隔壁团队的关系，你搞不好研发同学的资源情况，你不知道谁休假谁回老家谁生病，全是你的锅。
相当明确是不是？这样责任一揽子包的情况其实反而有利于所有人的配合协作，因为别人也有可能某一天做某个项目，那时候他为了争取你的资源支持，就不会这时候故意给你小鞋穿，而又因为这件事情责任都在你，所以他也不担心做好做坏被你推锅，反而会尽心尽力帮你弄。
其实很多时候，作为公司的领导者，心里真的对谁的锅了如指掌，但还是需要有一个人出来站着扛这些压力。
这就是全栈pm的责任。
四、晋升路径。
BAT的技术团队，早在好几年前就都实现了内部职级体系，基本是和曾经老国企的技术体系是一脉相承的。因为技术和管理之间的鸿沟还是蛮大的，不是每个人都会喜欢去做管理，那么如何让精研技术的人有自己的一套评价体系就显得很重要。
BAT的开发人员，从入职第一天起就被告知技术的晋升路径，你从t几晋升到t几，你从p几晋升到p几，什么条件下可以晋升，怎么评选，需要你有什么样的能力。
这是大公司内部的一套游戏规则。
但产品运营团队还是不能简单套用的。
B家的孙云丰09年时候，仿照T（技术序列）搞了一个产品序列的晋升路径，大体也氛围10个级，然后刚毕业就是p3p4啦，工作几年就是p5p6啦，优秀人才就是p7p8啦之类的，后来用户体验团队也搞了u系列还有商务的b系列之类的。管理是一条单线m系列，如果你在专业上比如达到了某个程度，你就可以申请转管理。AT两家其实也都差不多，这方面信息大家知乎上随便搜搜就可以有些了解了。
这种专业+管理区分开的双轨制，是很适合技术团队管理的。
但真的适用于非技术团队么？我看未必。
我在本系列文章中的一、二中曾经讲到，互联网的非技术领域，天生就是最后要转管理的。
也就是说管理是一个归宿，你迟早要从带小项目，变成带大项目，小产品线的负责人变成大产品线的负责人。你想安安静静像工程师一样做一个钻研技术的美男子是不可能的，因为你的责任和能力越大，你要涉及和打交道的人越多。产品运营是面向人的专业，而不是面向机器。
所以BAT里就会出现一些奇怪的现象，某个产品线里面，又有几个高级专业人才，又有几个管理人才，一个新人，在这种强行矩阵式的结构里，面对2个负责人，经常就迷糊了方向。
一方面，你有一个项目负责的人，带着你做项目，另一方面，你汇报关系上的那个管理者，也无法给你提供你干的事情的指导，因为你干的事情可能他也不懂。
所以不是东风压倒西风（项目负责人在部门话语权大于管理负责人），就是西风压倒东风。往往项目驱动的产品线，管理负责人基本就跟没有实权一样。我认识一个在B家工作的小同学，入职半年愣是没和自己汇报关系上的管理负责人没当面交流过。
不能这么做。
全栈pm的晋升路径的前提，就是要将管理和专业合二为一。
第一，分职级，职级对应不同的薪水待遇及头衔。
这是必要的，我建议在稍具规模的公司之中，都应对pm进行职级划分，而不要以管理title划分。比如你最简单就分3级，稍微复杂点分5级也就够用了。不同的职级对应不同的薪水待遇，这样以后如果出现某些工作大量都是重复性劳动，找一个低职级的新手也能胜任，控制成本。
第二、项目制，按职级进行管理权限的设定。
将产品运营的各项目标，拆成或大或小的项目，然后用高职级的员工去带领低职级的员工做。在评价项目之中也可以引入打分制等等方法，来衡量项目目标达成的好坏。在项目之中，低职级员工的汇报关系就是高职级员工。
那么这里就有些朋友问了，这样按职级进行管理权限设定与传统的部门总监-经理-专员有何区别呢？
区别在于你可以很容易调整不同项目之间同职级的管理者，但你极难裁撤掉一个部门的总监或者经理。而且作为低职级的员工，去新的项目或者别的项目当中高职级的负责人，成为一种新的可能，避免在传统流水线的结构中，只能等自己的老大走掉自己才能晋升的困境。
到最后，一家公司应该能稳定的输出职级，就是别人都会以“我是这家公司xx级的pm”为一种标准来衡量，我觉得现在市面上，也就百度的t系列可能能达到这个水准（当然这两年也水了不少，某T10大哥前两天忧心忡忡的抱怨道）。
这种晋升路径远远好过于传统的金字塔型晋升路径，也减少了很多办公室政治问题。
而且公司没那么多官僚结构，更容易打造基于产品项目的内部个人品牌，其实对互联网公司来说也是一件非常好的事情。（比如创始人不用太担心某个核心业务只牢牢掌握在某个非常有资源的部门手里，导致一挖走一片，鸡蛋总是不能放在一个篮子里的）
而且效率真的不会低。
以上就是第三篇的内容了。
可能有些同学会对这一篇讲的内容不甚了解或者感觉有点模糊，因为主要是从管理者的方面出发来探讨制度方面的顶层设计。但我觉得写出来，大家看看，也没坏处，毕竟不是每个人都有过当公司管理层的经验的，理解你的boss怎么想问题的也是很有用的。
推行pm全栈化，是需要公司层面自上而下来推动的，与其说这是一种个人的职业定位，不如说这是一种管理方式和理念。
流水线式的工业时代管理模式已经不适用于信息革命的新浪潮了。
反正我已经在自己的公司这么实践了，我们公司就两种人，写代码的和不写代码的，目前的研发团队也基本都是全栈工程师。
随着实践的深入，我会随时和大家分享可能出现的问题和经验。
总之，感谢阅读。
相关阅读：
关于产品，关于运营，关于“全栈pm”(一）
关于产品，关于运营，关于“全栈pm”（二）
