今年年初，告別效力6年的b公司，我踏入了乙個完全未知的新領域。
從toc到tob，從使用者端到雲端，從研發角色到效能管理。不到兩個月的時間裡，我感覺彷彿回爐重鑄了一遍，又進入當年剛畢業那會「一問三不知」的狀態。
所幸這次的困怠沒有持續太長時間，到目前為止，我想我已經可以靜下心，先將部分體會記錄下來。
如果要將乙個團隊比作人體結構，我想曾經所在的技術崗位應該類似於人的肢體，這個崗位負責拆解需求，尋求問題的最優解，進而落地乙個產品構想。
古人總將運籌帷幄的將領在統兵時形容為「如臂指使」，也是這個道理。技術崗位就如同團隊的四肢，能否解決問題基本取決於團隊內相關技術人的能力上限。
那麼效能管理，或者說專案管理應該視為什麼呢？ 我以為，這個崗位類似於人體的「神經節」。所謂的神經節，指的是這個崗位本身不能產生「官能」價值，它的價值更多的是來自資訊有效傳遞、分發，以及在一定範圍的決策意義。
在崇尚團隊結構扁平化，崇尚職能管理去中心化的今天，傳統意義上專案管理這個概念已經逐步被邊緣化，團隊規模小的創業團隊往往沒有類似崗位，而團隊規模擴充套件到一定程度上之後，也通常會有團隊內不同的角色（部門經理，產品，甚至測試），分攤了來自專案經理的業務以及所產生的的價值。
那麼是否說，這個崗位就會慢慢消失內？
就我觀測到某a公司內的專案現狀來說，這個崗位未必會消失，但是它的位置以及價值與我之前預想的場景相比，正在發生變化。
我所base的崗位，全稱叫做「專案交付經理」（release manager）。
最初我以為它是個用於管控交付產物以及**規格的崗位，類似scm，結果發現不太一樣。
後來我認為它是個類似pm（project manager）的崗位，用於管控交付週期，結果仍然不太一樣。
後來的後來，我發現這個崗位涉及的方方面面，有流程管理，有規範定義，有制度建設，甚至從某種意義上而言，還可以定義研發策略。如果套用gof的設計模式理論，這個崗位有類似建造者模式（builder pattern）與**模式（proxy pattern）的味道。
這個崗位的生產價值在於「交付」，而交付的內容卻涉及方方面面。
神經節不是大腦，或者說現階段不是大腦。
因此通常來說，專職的專案管理人難以全權決定專案的走向，他們更多的是在乙個專案範圍內改善專案迭代節奏，或者在問題發生之後想辦法彌補因為延期帶來的專案補償問題。
但是從目前的現狀看來，以交付為目的的專案管理，正在逐步擴充套件所屬的職權範圍。他們開始更多在自己這一層想辦法解決盡可能多的產品問題，決策與判斷，而不會直接將這些問題透傳到更高一層。
可以想象一下，大量的專案問題，包括一些產品方向和運營策略問題，都在專案管理層面被消解掉。好比邊緣計算中邏輯端點已經將大量計算工作在本地處理了，彙總到雲端的只剩下最有價值的結論性資料。
而專案內決策與判斷的快速響應能力，以及相關問題處理範圍，決定了這個崗位的寬度。
然而這些是不夠的，交付問題的源頭應該在流程制度的建設方面。不同的產品，不同的團隊，抽離不出共性的問題製成規範，做不到「書同文，車同軌」，從產品的定義階段就有「邏輯」可以依賴，到最終發布製品版本需要包括的產物規範，這些都是專案管理應該可以深挖的方向。
交付只是一種手段，圍繞交付過程如何打造乙個簡單明確、易於執行的流程才是關鍵。
發布經理的崗位後續是否有高階崗位呢? 就像盜賊的高階職業是刺客一樣：）
很遺憾，以我目前的經驗值，還沒法斷定它的高階崗位有哪些。但就從工程能力，以及可以覆蓋方向上來說。我可以假設這個崗位上限至少有如下特徵。
至於是否還有其他的特徵，還有待我在這個崗位待更長的時間才能發掘。
實際上，從研發崗位轉型專案管理最好的機會應該有三種：
而目前這三點我都不具備，可以說天天遊走在「人設崩塌」的邊緣，稍有不慎就社會性死亡了。
但即使這樣，我依然認為這個決定是近年來我做過的最有價值的乙個決策。這是乙個非常有價值也非常有挑戰性的嘗試，如果最終能夠勝任，它將會為我的職業生涯短板提供最強力的支援。
關於我將如何度有史以來最慘烈的試用期，塵埃落定的某一天，也許我會記錄下來。