階段論，產品化思維與管理模式的思考

階段論

有一個很有意思的事兒，任何個體、團隊、公司或者其他帶有成長屬性的事物，它們都有類似的生命週期。比如著名 SWOT 分析法（也稱TOWS分析法、道斯矩陣）即態勢分析法，20世紀80年代初由美國舊金山大學的管理學教授韋裡克提出，經常被用於企業戰略制定、競爭對手分析等場合。

如果大家真的瞭解這4個字母的意思，S是優勢，W是弱勢，O是機會，T是威脅。按照企業競爭戰略的完整理念，戰略應是一個企業能夠做的（即組織的強項和弱項）和可能做的（即環境的機會和威脅）有機組合。

強與弱，機會與威脅，都是不斷的在轉換的狀態，在不同的階段都有其獨特的價值，有時你覺得你覺得是威脅讓你有了危機意識，很有可能它會變成你一輩子裡最難得的機會，有時你覺得非常強大，可能只是巔峰時的轉瞬即逝的輝煌。生命裡最好玩的就是不確定性，能夠讓你身在其中卻捉摸不定，如果把握好趨勢，你得到的將是更多美好。

還有一個類似的概念，叫波士頓矩陣，就是我們常說的四象限分析法。明星產品、現金牛產品、問題產品、瘦狗產品。上圖也涵蓋了這些，首先從最右上角的問題產品開始，這其實是創造期，它可能會失敗（威脅），也可能會變成明星級產品（機會），如果是明星級產品，它可能是一失足成千古恨，也可能是變成現金牛產品。現金牛的產品，你要做的是維持好這個狀態，讓它足夠長，將巔峰輝煌延長，越長越好。瘦狗型產品要方式它過快消亡，你能做的就是降低這個可能性。

你會發現所有過程都挺難的，從無到有的創造很難，做到現象級的明型產品依然很難，做成現金牛產品又要擔心盛極必衰，到了止不住衰亡時（瘦狗），你又要大手一揮，從中攫取最後更多利益。

人之渺小，多得意於此刻。處在任何一種狀態，它都不是絕對的，更多的時候是要能夠清楚自己所處狀態的階段是什麼，才能在趨勢裡更好的做出決策。現時是公平的，它給了每個人一樣平等的選擇，只是有的人懂得早有的人懂得晚而已。有時，我喜歡一個人在高速上開車，我看到的電光火石間的機會與威脅，我更喜歡面對心跳的刺激而能夠做出更好的選擇。

如果你迷惑，一份清單，一頁紙裡畫好四象限，足夠了！

技術人通常都短缺產品化思維

瞭解PMP的人大多都知道專案干係人的概念，它指的是積極參與專案或者其行為能影響專案的計劃與實施或其利益會收到專案執行或者完成情況影響的個人或組織。識別干係人是專案管理時最重要的準備。我一直都覺得，干係人更多的是利益平衡中的重點。

那麼，我們看待專案裡的事兒，如何去識別重點？

對於精於運營之道的公司來講，必然會大量的做各種營銷活動的。按目前的做法，幾乎一個活動要5人/天的工作量，也就是說每個月至少有1到2個人被搭進去。短期看，這是沒問題的。但問題卻也是極為明顯的。現在是運營遷就開發，不敢安排更多活動。且不論商業損失，就是開發自身也是極為難受的。

那麼更好的做法是什麼呢？

關於創業，《rework》一書裡講的最為直接，抓自己的癢處。比如自己缺少erp系統，寫了一個，然後做成erp服務提供給更多人使用。首先是滿足自己，然後抽象成通用需求，其實更準確的講是，開發一次，複用的價值就非常大了。這和生產是類似的，買個機器10000，投入5年可以賺10萬，投入是一次性的。以後的投入是日常的生產投入，都是賺錢的生意。

對於現狀而言，如果有很多人精力投入，而且是無止境的投入，那麼它就是瓶頸。它就是目前的干係最大的迫於解決的問題。如果不解決，你沒法有更多精力做更多的事兒。技術本身並沒有價值，支援好業務它才有價值，如果能過技術創造業務價值，那就是更大的價值。

活動類的需求做成系統的非常多，比較典型的是h5場景應用，還有更高階的以表單形式切入市場的金資料等。對於營銷活動型別是可以列舉的，對於活動頁面的複雜性是可以預見的，對於給運營用的系統可以再簡單一點，甚至不客氣的講能用就好，他們是你的同事，能夠給你一定的耐心讓你成長。

• 頁面切圖非常麻煩，花費很多精力，通過psd、sketch生成h5頁面也不是難事，以後能夠讓運維直接上傳，然後處理一點事件和顯示元件，是否更高效？瓶頸出現在技術這邊，技術就應該解決它，讓別人變成瓶頸。否則終生無出路的。

• 靜態化，放到cdn上，可以更低成本的抗壓，轉移壓力到服務商，其實就是能用錢解決的問題都是小事

• 限流，給後端更多保護。秒殺類活動高併發，瞬時流量非常大，你能做的就是更好拆分，利用快取來限流

• 分而治之，舉例活動入口和檢視活動結果是可以分開的，錯誤頁、指引介紹頁面頁是獨立的。

• 切面為了技術而技術，看到好的優點，也要面對它的缺點。比如vue在h5裡應用並非那麼理想，壓縮後20+kb的大小還是非常大的，是否開啟了分塊載入，是否編排頁面載入順序，是否能夠使用bigpipe等優化，在弱網路環境下，才是最考驗人的時候。技術情懷是沒用的，落地的都是實實在在的東西，合適的才是最好的。

• 配置化，比如限流的redis是阿里提供的服務，運維並不在我們這裡，如果單臺或者高配版本也扛不住怎麼？能夠多加幾臺？按照請求數和臺數求餘數，來判定走哪臺快取機器。在後臺，針對單個活動可配置是非常重要的，彈性伸縮是一方面，其實基礎建設做不到位也是白搭的

• 資料視覺化，趨勢可以預估，流量其實很難預估，實時統計資料會顯得尤其重要，任何決策沒有資料作為依據，都是拍屁股想的。一遍看著資料量上上漲，一遍調整配置資訊，在活動預熱階段就已經準備好要用多少臺伺服器了。

想要把這些寫好並不容易，麻雀雖小，五臟俱全。技術人通常都短缺產品化思維，這是非常可怕的，有非常好的需求明確自己的癢處，不去解決，那麼技術的意義又何在呢？在不同階段中識別瓶頸並解決，我想，這才是好的技術人的價值。

人還是要有危機意識的，年底了，你有什麼能拿得出手的東西向老闆拿紅包呢？勤勤懇懇的支撐好業務是一方面，如果能錦上添花，一定是更好的。讓老闆看不到你的天花板，你才有更多升職加薪的機會。

管理模式

小作坊式的管理通常都是頭痛治頭腳疼治腳，永遠都是應急，被需求追著跑。無數的血淚史都已經給我們敲響警鐘了，但還是會發生，讓人心痛不已。我們先不要完全否定，再回到階段論看，它的問題到底在哪裡。

公司初期，人員不多，業務也不多，來一個需求接一個需求是非常正常的事兒，事實上，公司在生存線上掙扎，哪有精力給你做技術規劃。公司成長期，人員突增，你會發現之前的模式依然適用，就是10人對接11個專案，依然能夠做的很好，每個人忙的時候是不亦樂乎，閒的時候也是不亦樂乎。但是，這階段的SWOT是什麼呢？優點是沿用已有成功經驗，大家很舒服，缺點忙的忙閒的閒，不像一個團隊，威脅是在有誘惑的情況容易離職，其實最大的問題是大家的存在感，要讓大家有團隊意識，能夠集體去應對困難，已經不是個人英雄注意的階段了。上面SWOT裡唯一沒講的就是O機會，你只要知道了癥結點，害怕無解麼？

團隊人數一定，工作量一定，10個人應對20個需求，每個人2個，一定會閒的閒死忙的忙死，需求的難易程度是無法做到平均的。那麼換一種方式呢？5個人一組去應對10需求，所有人是同進退的，要麼都閒要麼都忙。明顯是以團隊方式更優。

再說一下歸屬感的問題，獨立完成某個專案是孤獨的，並非每個人都具有這種能力，技術人在技術上並非全棧，並非都善於溝通，所以諸多因素結合在一起是非常痛苦的事兒，有時候鬱悶了，不懂又無人可問，別人沒做過這個專案，你問了也白搭，於是只能自己扛。另外一個問題就是個人成長，個人因專案經驗的成長是非常小的，我之前曾經總結的學習三法，第一的就是跟人學是最快的，其次是讀書，最差是自悟。如果溝通尚且不多，又何來的交流學習呢？有人要離職也是非常正常的。

統一大家的思想，做共同的事兒，榮辱與共，利益相關，那就從一個team做起吧！

全文完

歡迎關注Cnode官方公眾號【node全棧】

如果想參與評論，請點選閱讀原文連結，進入國內最專業的cnode論壇

你身邊如果有朋友對Node.js或全棧感興趣，可以轉發給他們看看哦，O(∩_∩)O先謝過