摘要： "行成於思，毀於隨"——韓愈 在阿里從一線前端工程師到技術 TL（Team Leader） 也三年有餘了，最重要最難的就是做規劃，你可能會遇到如下幾個問題： 業務壓力巨大，前端是瓶頸，如何做合適的規劃？如何提高規劃的成功率？規劃的雷區是什麼？如何尋找規劃的線索？我的老闆不是前端，如何做出被認可的成績？今年4月份參加了阿里集團前端委員會組織的 TL 培訓（老師都是阿里的前端大牛），爲期三天，收穫頗豐，特別是關於前端 TL 如何做團隊規劃方面，整理課堂筆記時，就想結合自己這一年在阿里拍賣業務中的規劃實踐做下總結。
"行成於思，毀於隨"——韓愈
在阿里從一線前端工程師到技術 TL（Team Leader） 也三年有餘了，最重要最難的就是做規劃，你可能會遇到如下幾個問題：
業務壓力巨大，前端是瓶頸，如何做合適的規劃？如何提高規劃的成功率？規劃的雷區是什麼？如何尋找規劃的線索？我的老闆不是前端，如何做出被認可的成績？今年4月份參加了阿里集團前端委員會組織的 TL 培訓（老師都是阿里的前端大牛），爲期三天，收穫頗豐，特別是關於前端 TL 如何做團隊規劃方面，整理課堂筆記時，就想結合自己這一年在阿里拍賣業務中的規劃實踐做下總結。
本文會引用課堂上多位阿里前端大牛老師的觀點。
一般技術規劃路徑如下：
（藍色部分爲本文重點論述部分）
一、先從團隊特徵說起
做規劃，先要定義清晰自己團隊的特徵與發展的階段。因爲特徵不同與發展階段不同，規劃的選擇就會截然不同。
1. 識別團隊特徵
在阿里梓騫老師關於建團隊的論述中，有一塊團隊行爲曲線的總結特別好，是團隊比較核心的特徵。
（上圖來自梓騫老師 PPT ）
我的團隊特徵（某財年阿里拍賣業務前端團隊）：
背景：從淘寶技術部到垂直支撐業務團隊行爲：處於潛在團隊，共同目標不清晰、協同不夠、缺乏長期目標人員構成：6 人，平均層級偏低業務發展情況：創業型，高速發展，局部瓶頸業務重點關鍵字：DAU、用戶體驗（業務老大高頻強調）資源富裕度：負，人員嚴重不足，前端成爲業務發展瓶頸TL 彙報對象：產品經理當識別完團隊特徵，最迫切的事往往可以呼之欲出，比如招聘是第一等大事，“廢話，給我找個不缺人的前端部門...”，莫急，本篇不講招聘...
發現上個財年推進的事，印證了團隊行爲目標：努力將潛在團隊引領成真正的團隊。
如何做？
尋找團隊共同目標增強團隊協同明確清晰短期目標與長期目標從團隊特徵中尋找規劃的邊界：
清晰的邊界與基準、對規劃內容優先級判斷，對落地成功率有至關重要影響。
二、尋找規劃線索
尋找規劃線索是最耗時間的階段，作爲 TL 你有可能每天都在觀察尋找規劃的線索。
尋找線索，除了 TL 本身的思考外，需要具備外交能力，多問，如下圖：
可以從四個方向去尋找鏈接，聊得越多，聊得越透，線索會浮現得越多。
下面針對去年比較有體感的點展開論述。
1. 向上管理
向上管理是拔赤老師比較強調的內容，如果你的老闆不是前端，向上管理特別有必要，你需要消除“語言差”、做必要的前端核心概念“科普”。
一般業務/產品老闆的關注點是：流量、轉化、跳失、體量、用戶體驗、規模化、模式/產品創新等，要了解清楚現階段老闆的關注點是什麼，從自己團隊的維度思考試圖給出到達路徑，這是非常重要的規劃線索。
向上管理不是有事沒事找老闆嘮嗑，而是注意溝通的有效與質量，提問題最好帶着初步的解決方案，業務/產品老闆的時間有限，又存在“語言差”，相對複雜的內容務必準備 PPT。
2. 腦暴共創
腦暴共創是非常好的，自下而上的輸入方式，而且你可以觀察出下屬的關注點，爲後面尋找規劃項目執行者提供線索。
你可以挑個風和日麗的週末，一整天與團隊同學們關在一個咖啡館或風景不錯的會議廳。
因爲共創會的成本相對較高，所以需要注意必須是主題式的共創，可以安排上午人員做主題式彙報，下午討論聚焦。
另外還需要一個控場能力比較強的主持人，防止主題失焦，控制時間，共創需要的是高密度的信息。
除了與下屬的腦暴共創，也可以組織與協作方的共創，參加業務方的共創。
3.關注業務痛點
從業務痛點出發尋找的線索，確定規劃後一般有充足的時間落地，是很靠譜的線索，但要注意抽象與提取，業務痛點更多是單點的現象，而我們需要做普適性的思考，這樣才能充分發揮技術的價值，當然也要避免“過度設計”。
三、價值聚焦
1. 前端規劃四問
要解決什麼核心業務問題？創造什麼核心價值？爲什麼要做這件事？爲什麼是我們做？是單點，還是相對通用？以什麼樣的模式和方式來解決問題或創造價值？業務邊界，系統邊界如何取捨？問題在集團的大圖位置和現狀是什麼樣的？優勢？劣勢？終局思考和實現路徑是什麼樣的？結合前端，我個人認爲有核心四問：
做成了會如何？（核心價值、終局構想）是我團隊最重要的事嗎？有沒有更簡單的方案？與業務的鏈接是什麼？終局構想特別重要，決定了規劃內容的價值天花板，圓心老師給我們講了案例，Pandora.js 做規劃時，就要求是開源的，要服務外部應用，這個定位改變了 Pandora.js 從 0 到 1 的結構，如果一開始只是定位於爲集團 node 應用服務，那麼日後開源必然面臨大量改造成本。
在前端團隊多年，體感比較深刻有二點，前端容易將問題複雜化，喜歡用大的平臺去解決小的問題，前端容易爲了技術而技術，與業務“失聯”。
2.來自大牛靈魂的拷問
要讓評審者學到點什麼在前端技術的橫向影響對業務中其他角色或業務的影響對未來的判斷是否是重複造輪子是否是“技術投機”，缺乏業務場景適用性思考解決問題與痛點，遠比構思複雜技術方案更重要，避免無差異重複造輪子或“技術投機”，着重預判規劃落地後的影響力與價值論證。
3. 規劃推導
規劃推導分正推：從線索->本質痛點或問題->解決方案->目標，反推：從目標->解決方案->本質痛點或問題->線索。
二個過程都需要，你需要通過反推，去論證推導與路徑的正確性，比如你的目標是提高 50 張頁面 50% 的性能，推到解決方案，發現只能提高 10 張頁面 10 % 的性能，就會發現解決方案是不靠譜的，需要再思考。
所有的線索都是現象，你需要去剖析現象背後本質，思考：
什麼問題導致了出現這些現象？痛點夠不夠痛？解決方案的設計要思考：
調研是否充分，集團是否有現成方案？是自己做，還是引進？還是引進後二次定製？預計投入資源，投入產出比如何？目標的設計要思考：
能夠體現規劃價值可量化，可衡量，有影響可達到一般寫規劃時候，我們是先寫目標，再寫解決方案，而在實際推導規劃時，一般是有個大概的解決方案，然後預判可能達到的目標。
舉個簡單的推導例子（過程做了簡化）：
所以最後決定打包在一塊，項目名是業務有體感的體驗升級，目標是業務有體感的跳失率，將前端技術體系的建設包在了裏面，同時也解決其他協作方的痛點。
4. 控制力
如果一件事件你也能做，別人也能做，且比你做的好，那麼就要想想要不要做這件事。
控制力還體現在邊界梳理，能跟其他崗位或其他前端團隊合作是非常好的，但一定要理清楚邊界，權責清晰纔能有效促進規劃成功。
四、規劃落錘
價值聚焦完後，已經識別出最有價值的事，但未必是團隊當下最重要的事，所以有規劃落錘階段，有如下幾件事：
規劃內容按照重要性排序產出規劃 PPT產出關鍵里程牌時間點排兵佈陣、資源調度李牧老師說，“TL的核心素質是判斷力與前瞻性”，這個階段就很考驗着二個能力。
1. 長期規劃
價值聚焦完發現可做的事很多，如何辦呢？這是好事，就可以試圖做下長期規劃，可以是三年規劃、二年規劃，並不是說非得一年建設完所有體系，羅馬不是一天建成的，畫張三年大圖，給自己以指引。
明確團隊技術體系的演進方向，窮盡所有高價值的事，每個季度覆盤調整這張大圖，讓團隊有共同的目標。
拔赤老師建議 “技術規劃以一年爲最小單位，每季度做詳細覆盤，跟的勤，就不怕跟丟”。
2. 勇氣與吸引力法則
有時你認爲最有價值也是團隊最重要的事會受到其他人的挑戰，比如有人堅持認爲現在資源緊張，不應該額外投入資源去做這件事。
這時就是很考驗人的勇氣的時候，選擇接受，那麼這件事就從你的規劃移除，人員輕鬆了，產品滿意了，但技術體系、體驗沒發生變化；選擇堅持，那麼人員工作強度變很大，協作方說不定會投訴。
你肯定也有面臨這種選擇的時候，無關對錯，但我們需要有勇氣面對挑戰，做對的事，不要慫。
吸引力法則（你關注什麼，就會將什麼吸引進你的生活）告訴我們，有勇氣去要求，篤定你的判斷，有策略的執行，周圍自然會發生你所希望的變化。所以關注於對的事，別被困難嚇倒。
還有個策略，跟你的老闆或上游來個“對賭”吧？
一定要發聲營銷
技術團隊的 PR 意識相對淡簿，而前端團隊在業務的影響力又相對較弱，所以特別需要 PR。
發戰報是最有效的營銷方式，但需要注意個注意點，如果戰報對象是業務方、協作方，不懂前端技術，戰報需要包裝，讓他們能看的懂。
別寫做了什麼技術方案之類，別人看不懂，也沒時間看。
技術產品宣傳：
技術產品宣傳分社區與公司內，辦法很多，發放宣傳禮品是個討喜的辦法。
去年自費做的二個宣傳品：
原文發佈時間爲：2018-05-15
本文作者：劍平
