本文要談的不是軟件產品的生存策略，而是作為軟件開發人員在團隊中的生存問題——按理來説，這也像前兩篇所講的一樣屬於「人為因素」問題。

團隊類型

無論是不是與互聯網相關，在一家靠提供軟件及服務吃飯的公司裏，只要具備一定規模了，就會分化出業務型團隊和支撐型團隊——

分工細化的前提是流程環節比較複雜，並且因操作規範化程度不夠或其他什麼原因導致不能自動化，無法用機器取代人工，因而要拆分出子環節並找到對應的人去處理。

歐雷《反思軟件開發：軟件生產》

業務型團隊專注於「開源」，即「創收」，給公司的產品添磚加瓦以帶來更多收入或流量；支撐型團隊負責「節流」，也就是「提效」，讓業務型團隊的事情能夠更快、更好、更有質量地落地。

工作價值

當被問起「你某段時間做了什麼有價值的事情」時，會如何作答？

相信有很多人會「自信滿滿」地説自己為業務帶來了多少收入和流量；也有不少人「滿心激動」地羅列自己為讓業務更好落地做了多少貢獻。

正當你在向別人對自己做的一些自認為很有價值的事情大談特談時，對方問了一句：「你做這些的價值是什麼？」你聽了之後的第一感受很可能是不爽，並且疑惑：「這麼有價值的事情都沒看出來哪裏有價值？」

問的人不一定是惡意，有可能是你的表述沒讓他 get 到你所認為的價值點，也有可能是他雖然 get 到了你所認為的價值點但他認為沒價值。

前者是表達力和理解力的問題，這一般不是大問題，換個方式闡述；而後者則是價值觀問題，這會影響站隊，也就是與另外一個人或羣體的匹配度、融合度。

從上面的團隊類型劃分看，直覺上會認為做的事情只要符合團隊的職責定位，能夠讓團隊變得更好，就是有價值的。從「團隊」這個整體來看也許是這樣，但深入到團隊內部去看呢？

「有無價值」是「評價」，「評價」受「人的意志」影響，只要被「人的意志」影響就是「主觀」的，無論這個「人的意志」是一兩個人的還是很多個人的。

所以，個人或團隊做的事情是否有價值，最終還是靠直系上級的價值觀去定性——做的事情的效果是立竿見影還是需要量變到質變，直系上級本人和其他同事或被支撐的團隊認不認可。

如果做的事情在比較長的時間後才體現出（巨大的）威力，那時你可能已經因為當初直系上級認定你做的事沒價值而被裁了或自己走了。

生存困境

上文中的內容看起來可能覺得「很正常啊」、「這都沒什麼」，那下面開始説一些我覺得會讓人沮喪的事實。

總看我文章和了解我的人都知道，我的從業經歷是既在業務型團隊幹過也在支撐型團隊待過，不管是在哪種類型的團隊中，都積極主動地做了很多基建方面的工作。

並且我也管理過小小團隊，可以用不同的視角去儘可能全方位地闡述——

業務型前端

職業發展與成長的問題圍繞着每個人，對於研發人員來説，對於在業務型團隊中的前端工程師來説尤甚。

在業務型團隊中，前端工程師的主要職責就是完成產品需求，保障產品質量和上線時間。想封裝 UI 組件庫、腳手架、開發框架？不是有現成的開源項目和支撐型團隊的項目嗎？有重複造輪子的必要？需求做完了嗎？能讓團隊賺錢嗎？

在業務型團隊中，業務跟前端有什麼關係嗎？前端只是實施環節之一，前端工程師僅僅是個搬磚的，基本只能在實施的可行性、合理性上插插嘴，想砍需求或左右產品發展方向？呵呵呵……

業務型團隊的前端工程師，把代碼寫得沒什麼 bug 是「應該的」，這是「本職工作」。如果 bug 多，不僅會被合作的人投訴，還會被他們和上級認為能力不行。

想做些基建工作去提高效率和減少質量問題？可以啊，但不能影響正常需求的開發。並且，做那些東西只能算是你的個人提升，因為沒讓團隊賺更多錢啊，不算你「不務正業」就不錯了，頂多在考評時認為你還算有上進心吧！

這樣看來，業務型團隊中前端工程師的天花板實在是太低了，很容易就會遇到發展瓶頸。

就算可以給團隊中的所有項目代碼做重構，等全部重構之後呢？做的這些重構會讓你的上級和其他同事表揚你，讚賞你，更看重你，提高你的重要地位，讓考評結果有利於升職加薪嗎？若是不能，這是不是在自嗨，自我感動？

如果還留在這樣的體系中，擺在面前的基本就三條路：轉到支撐型團隊；做前端負責人；轉做產品方向。

支撐型前端

「支撐型團隊」聽起來有些高大上，給人以技術屌炸天的樣子，使業務型團隊的人心馳神往——在技術上相對來説是有些優越性，畢竟靠提供技術性服務吃飯，但也沒那麼誇張。

在這裏，「支撐型團隊」是指那些提供通用開發工具等的公共技術部門，或提供像低代碼平台、數據智能服務等門檻較高且相關資源集中的中台部門。

進入支撐型團隊之後，心想終於可以不用考慮那變幻莫測的業務而專心做自己喜歡的技術相關的事情了！

真的是這樣嗎？真的是這樣嗎？？真的是這樣嗎？？？

且不説前端工程師在有的支撐型團隊中的處境實際跟在業務型團隊一樣，想想支撐型團隊的業務方是誰？是業務型團隊！

如果做的技術工作不能滿足或者滿足不好業務型團隊的需求，那麼做的這些工作的價值和意義在哪裏？在與業務型團隊對接過程中出現問題，或者對接後他們業務上出現問題，沒準還會被投訴。

所以，縱然不在業務型團隊，也會受到變幻莫測的業務的影響，即使會相對小些。

就算相較於業務型團隊能夠將更多的心思放在技術上，天花板更高一點，瓶頸也會晚一點遇到，但又能做啥呢？

工具庫？UI 組件庫？腳手架？開發框架？跨端方案？配置平台？監控平台？低代碼平台？還有呢？

這些東西，第一次做會覺得很新鮮很有收穫，但上進的你如果在業務型團隊中時就做過一遍了，或者換到了另外一家公司的支撐型團隊做同類事情時，就很可能會發現沒什麼新鮮玩意，思路和做法都差不太多。

那麼，對於你來説，再做這些事情還有價值嗎？有什麼價值？

當按照團隊負責人的規劃、指示按部就班地做那些東西時，你就像在業務型團隊中一樣僅僅是個搬磚的，沒任何亮點，仍然是可替代性很強的螺絲釘，沒什麼區別。

對於研發人員來説，對於在支撐型團隊中的前端工程師來説，與在業務型團隊中最大的不同就是自己的直接業務是技術，比在業務型團隊中更懂自己的業務，更有可能去左右發展方向。

要想左右方向，體現自己的價值，就得弄清楚團隊的價值是什麼，挖掘問題的根本原因，提出更好的、能解決真正問題的思路和可行方案，去説服團隊的負責人和其他人以及業務方。

支撐型團隊的職責是大家所津津樂道的「提效」，也是大多數軟件工程師的「本能」。

然而，也許很多人沒想到的是，引以為豪的「提效」在某些情形下卻成了剝奪他人飯碗的「屠刀」，自己變成了「幫兇」。更為滑稽的是，自己可能就是被剝奪飯碗的那些人中的一個，變相「自殺」了……

這背後的邏輯是——「提效」提高了產能，如果組織整體營收沒有相應的增長，即那些業務型團隊不夠給力，就會勞動力過剩，進而加大組織運營成本；為了生存，組織會想辦法減少開支，從而通過各種形式減員。

前端負責人

有的人會天真地以為做了前端負責人就可以高枕無憂了……我不否認會存在這種情況，但更可能的是——

不僅繼續做着一線開發工作，即履行好普通業務型團隊中前端工程師的職責，還要做團隊管理、項目管理相關工作。

自己部門裏的事情還好説，當遇到跨部門協作時，責任劃分和資源協調會相當麻煩。

由於組織架構調整和人員變動造成的踢皮球現象時有發生，想找到個人諮詢問題得兜兜轉轉繞上一大圈兒，很多時間過去了才可能問到，當然也有得不到答案的可能。

自己或下屬遇到對方不配合時，得自己跟對方 leader 或找自己上級跟對方 leader 的上級去溝通。這類事情就算是同部門也會遇到。

作為業務型團隊的前端負責人，按照人們的慣性思維，得要比其他的前端工程師更懂業務吧？但問題是，怎麼去懂業務？

要真的懂業務，首先得對那個領域感興趣吧？不感興趣的話如何做到真的懂業務？不喜歡數學的人把數學考高分讓我膜拜下？

那些説自己懂業務的人真的懂業務嗎？？？能發現當前產品架構和商業模式中存在的問題並提出改進方案嗎？？？

作為業務型團隊的前端負責人，按照人們的慣性思維，得要比其他的前端工程師更懂管理吧？但問題是，如何做好管理？

「管理」是什麼？是揮舞着手裏的權力大刀逼迫就範？還是用各種技巧、手段畫個大餅誘惑並套路他們？

抱有這類想法甚至如此行動的人不懂「管理」，更別説懂人性了。真正的「管理」是創造舒服的環境，去激發他人工作的主動性，成就他們自己進而成就團隊——

最理想的管理，應該能夠激發出下級的熱情，喚起風雨同舟的使命感、成就感，讓他們覺得工作不只是維持生存、生活的手段，同時也是自我實現的方式，最終達到自驅動、自組織、自管理的效果；最理想的組織形態，是基於共同願景的去中心化或弱中心化組織。

歐雷《反思軟件開發：人為因素（下）》

先搞清楚「管理」到底是什麼，再去想用什麼樣的方式去很好地表達那個詞的深刻內涵——這實際是個社會學問題。

不過説實話，這種中間角色，職級和拿的錢很可能跟其他人差不多不説，還容易做得上下不討好——既背鍋被上級訓斥，又被下屬説自己擺架子、不是人，委屈只能自己含淚吞下去。

做產品方向

當要轉做產品方向時，那就是對團隊的業務領域很感興趣，雖然不一定很瞭解。不瞭解可以去學習，但不感興趣肯定就沒轍了。

做產品方向不一定就是當產品經理，業務線負責人、架構師等也都需要很懂業務，這幾個都比較適合前端工程師去轉型。

其實，這條路的阻力還是挺大的。要補充大量缺失的知識並提升認知能力和思維方式自不用説，「願景」或者説「共識」可能會成為最大的阻礙。

當自己在產品的定位、功能和形態有比較強的觀點時，雖然業務領域和團隊的是一樣的，但定位、目標等有可能相左。

這時該咋辦？説服團隊負責人？不大可能。屈服順從？一是自己會覺得不甘心、憋屈，二是又回到了一開始的問題——自己做的事情的價值在哪？

總結

很多文章從正面、積極的方向去談論前端工程師的職業發展與成長，就像人類社會總是傾向於去宣揚好的、正能量的事情，讓人們吸上名為「安逸」、「快樂」的奶嘴兒，從而忘記自己身邊危機四伏。

本文試着從反面、消極的方向去探討前端工程師在職業發展與成長中可能面臨的問題、困境與矛盾，試圖喚醒大家的危機意識。

我並未像文章標題一樣給出「生存策略」，而是指出「生存問題」希望大家去針對性地尋找適合自己的「生存策略」。

本文其他閲讀地址：個人網站｜微信公眾號