關於產品，關於運營，關於「全棧pm」（三）

hi all

前兩天離職了，事情比較多，就耽擱了本系列的更新。

不過因為這第三章涉及到公司和團隊管理問題，所以不能貿然亂寫，所以我這些日子也花了一些時間，和一些資深行業的朋友們交流和探討，也有點收穫。

總之，事情正在起變化。

——

從我個人來講，我非常非常喜歡流水線。

我一度認為流水線是大工業時代的智慧結晶，完美，有序，高效率。種種一開始高成本高門檻的發明創造，藉由流水線，逐漸走入尋常百姓家，成為我們生活中不可缺少的一部分。

靠著精準的分工和低廉的人力，我們才憑著高效率和低成本逐漸構建了改革開放後的工業大國。

改革開放後的大多數中國企業家，對流水線都是有情懷的。

在大多數行業，把一個事情拆細，讓低成本的勞動力也能做，是企業家夢寐以求的事情。因為在這些行業，分工的明確，流水線的順暢，會對效率和用人成本帶來顯而易見的提升。

但在互聯網行業，這提升似乎變得不那麼確定了。

在開發領域，我們經常會發現，某些問題，與其花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都應該在任何一個項目中進行符合其自身的開拓性工作。

三、工作中的配合應該密不可分，必要時候交叉工作。（就是所謂「算了我來做，但是你得看著我怎麼弄」）

企業的團隊能力結構本身的需求，絕不是面面俱到面面強，比如一個電商網站，你臨時起意想做一個搞笑評論回復大搜集，你非要去招一個專門在糗百知乎這樣網站做內容運營的老手級以上的人，是完全沒有必要的。所以在結構的搭建上，找到一個強某方向的全棧帶隊，剩下就是靠學，參考，做到在企業項目本身的「專」和能力覆蓋面上的「廣」。

這樣，一個新人，從一開始的重複性垃圾活熟悉項目，熟悉環境，熟悉公司，又會逐漸隨著開拓性工作的深入，很容易看出來發展的潛力和個人的態度。繼而對公司平衡不同項目間的能力結構產生正面的價值。一個老手也不用擔心跳槽，因為項目是無窮無盡的（只要公司不倒閉），又因為能力的全面涉獵，總能做一些開拓性的工作。

說到這裡插一嘴，前兩天有個獵頭得知我離職，然後給我推薦工作，說某個app要找一個新業務的產品負責人。我好奇問，為啥這家公司不讓自己以前的中層幹部，找個最靠譜的來挑這個新業務呢？獵頭說是因為管理層覺得以前的中層幹部沒人干過這個事情，所以得找外面有經驗的人來。我說如果一個公司，一個新業務所有人都沒幹過或者涉獵過，那怎麼保證這個新去的人一定能幹好呢？怎麼保證和以前資源的協同和配合能順暢呢？萬一幹了倆月發現這個業務似乎不靠譜，是腦熱的結果，那是不是要辭退這個新來的人？後來獵頭就不置可否nn了。

流水線的企業，應對新行業發展的能力，其實是非常弱小的。

二、成本控制。

這就是赤裸裸的談錢了。

我們假設有一個團隊，6個人，1+2+3的結構。

1個資深專家：月薪30k（不用太介意這個值準不準，以現在的情況看只能更高）

2個老手：月薪15k*2=30k

3個新手：月薪8k*3=24k

總共84k的團隊。

這我覺得是一個差不多的平均值。

傳統流水線情況下，會隨著團隊工作經驗的發展，系統支持的增加，導致工作性質從開拓性轉為挑戰性到垃圾活的情況越來越多。

這樣工作能力需求就會自然而然降低。新手級工作從找一個8k的人，降低到5k，甚至降低到3k找一個實習生來就可以干。

但假設大家都不跳槽，這個成本就一直維持在84k。

而又因為工作性質的穩定，導致這個團隊很難被剝離或者去做新的事情，導致成本一直高居不下，最後撐不下去，只能集體裁員（前陣子某某公司裁掉某業務群在zhihu鬧得沸沸揚揚莫過於此）

但全棧式管理情況下，這個狀況就會改觀。

矩陣式的結構會提供一種能力之外的晉陞路徑，作為企業的管理者，隨時都可以將人抽離（因為工作在團隊內部都是全覆蓋的，不存在哪個核心工作必須只有特定的人來做的問題），這樣就可以讓好鋼真正用在刀刃上。例如讓資深專家去挑戰一個全新的業務負責，讓老手成長為本項目或者別的項目團隊的頭，讓新人晉陞，補足更低級更便宜的新人進來做垃圾活。

很多時候，企業成本的增加不是因為工資開的高，而是因為工資高的人，工作中有大量內容是不符合他們能力和挑戰的。

全棧式管理提供了一種足夠靈活的調配自由度，讓人能更好的發揮與他們pay相符的價值。而不是讓一個高薪人才，持續拿著高薪，但是卻做一個相對極其穩定的業務。畢竟，企業總要發展，總要有新的不斷的挑戰冒出來。

三、協同合作

部門間協同合作是個老生常談的話題。幾乎每個職場人都遇到過部門間扯皮，推諉，甩鍋的問題，大小公司都有。

流水線是天然的扯皮生成器。

某公司，有一個平台，平台上有消費者（流量獲取），有廣告（商務拓展），有系統（平台產品運營）。

然後老闆說，x季度收入為何這麼挫？

流量獲取部門說：我們搞來那麼多流量，因為系統爛和商戶少，轉化率不行

商務拓展部門說：我們拉來那麼多客戶，但是系統爛和流量少，導致收入降低

平台產品部門說：我們已經優化的很牛逼了，但是商戶又少，流量又少，自然收入不行。

三個部門都會玩命找出來大量證明自己很牛逼，工作很有成效，整體kpi（收入）不行都是別人的鍋。總之我們看到的就是高管會上所有人都在互噴。

這都是流水線帶來的結構性問題，不信我們把三個部門的頭換個個，他們分分鐘就會說這個問題不是由我現在所在的部門背鍋的。

都承擔責任到最後就是都不承擔責任。

所幸這家公司似乎意識到了問題，現在的情況是這三個大部門統歸一個很有權力，很資深的公司元老副總裁管。

這還是高級層面的，低級層面扯皮更多。比如每個部門內部就會更玩命的甩鍋和推卸責任。

很多公司致力於宣揚一種理念，就是自我反省啊，自我檢討啊什麼的。

但結構決定了所有的自我反省和檢討，都只能是暫時的場面話，說出來好聽，但實際上都會去甩鍋，這是制度決定的，不是人決定的。

天天惦記著甩鍋，真正在協同合作之中，就會儘可能的去劃清界限和責任，甚至會衍生出類似於「留郵件存檔，防止耍賴」等行為（這在剛剛所述那一家公司尤其典型，每個人都默認別人是不靠譜的，需要留郵件來存檔）。

說到底，完美的協同合作是不存在的，我們只能儘可能的趨近。

全棧式管理是趨近的一種方式。

在協同中有這麼兩個核心要素是對協同配合程度起制約的：

1）同理心（是否理解別人的工作）

2）責任分配（是否顧忌到責任問題而導致清晰邊界引發的甩鍋）

很多時候，我們所謂「隔壁部門的就是不配合」，基本就是因為大家之間有隔閡+責任太明確，生怕出現「這件事情你干好了都是你的功勞，干差了便推到我身上」的情況。

全棧式管理可以在這兩個層面有很好的優化。

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全棧化，是需要公司層面自上而下來推動的，與其說這是一種個人的職業定位，不如說這是一種管理方式和理念。

流水線式的工業時代管理模式已經不適用於信息革命的新浪潮了。

反正我已經在自己的公司這麼實踐了，我們公司就兩種人，寫代碼的和不寫代碼的，目前的研發團隊也基本都是全棧工程師。

隨著實踐的深入，我會隨時和大家分享可能出現的問題和經驗。

下一篇第四篇，我將重點探討具體的一些工作方法和系統支持層面的問題，比如怎麼切分項目，怎麼調配人力，怎麼設定目標，怎麼讓團隊整體成長。

總之，感謝閱讀。

ps：隨意轉載，無需跟我聯繫授權。

第一篇：https://zhuanlan.zhihu.com/p/21378316

第二篇：https://zhuanlan.zhihu.com/p/21387997

第三篇：https://zhuanlan.zhihu.com/p/21570740

....

（部分同學說還是寫進專欄里比較好，我本來那專欄是想專門留著給寫摩托車用的，不過還是算了就方便起見放進去吧，懶得重新申請一個了）