每一款軟件，都是從一行代碼開始的，並以此爲基礎發展起來的。Walmart 網站亦不例外。在過去的幾年裏，我們推出了一系列的功能，我們的銷售額以驚人的速度增長。僅就用戶的交易流（購物車和結賬）而言，我們工程團隊的規模成倍增長，我們的代碼庫也隨之增長。
伴隨着成長的陣痛，軟件熵（software entropy）也開始出現了，產品開發人員不得不管理幾個交叉關注點以及他們的功能工作和時間表。爲了提高效率，需要構建通用抽象（common abstractions）、與其他內部平臺的接口、修復常見問題，並且不留任何破損的窗戶。爲此，我們需要從整體上解決問題，來處理多個團隊和應用，而不僅僅是手頭上的項目。爲了更有針對性地解決這個問題，我們成立了專門的團隊來幫助完善我們的平臺。
譯註：軟件熵（software entropy）是指軟件的無序程度。軟件熵可用來說明軟件在經過不斷修改後，無序程度提高的現象。 Ivar Hjalmar Jacobson 用以下的方式描述 “軟件熵”：熱力學第二定律說明在一個封閉系統內的無序程度不會下降，只會上升或維持定值，其無序程度可以用熵來表示。此定律似乎也可適用在軟件系統內，在系統經過修改後，其無序程度（或稱爲熵）會上升，這可稱爲 “軟件熵”。Andrew Hunt 及 David Thomas 用破窗理論來說明如何避免在軟件開發過程中軟件熵的增加。
關鍵是爲我們的開發人員和最終用戶擴展我們的平臺。
但是，改進這個平臺到底意味着什麼呢？
這條大道過於寬泛，我需要的是方向和重點。爲了幫助回答這一問題，讓我們先從這三個簡單的問題開始吧。
定義團隊的三個問題
Why？——我們的使命（宗旨）
引用 Simon Sinek 的話，以 “Why？” 開頭。
“我們的團隊爲什麼會存在？” ——這似乎是一個基本的問題，無需動腦，對吧？
然而，深入挖掘並明確定義你的核心目標和使命，是弄清楚自己在團隊中做什麼和不做什麼的基礎。對於每個團隊成員來說非常重要的是，明確自己的角色，明確自己存在的理由，從而在工作中找到真正的意義。
What？——我們的目標（重點）
一旦我們知道 “Why？” ，那麼下一步就是進一步分解它，找出 “What？”。
“我們重點關注的領域是什麼？”
在這個基礎上，我們列出了有助於實現我們首要任務的關鍵目標。這些目標有助於提供亟需的重點，這反過來又轉化爲確定正確的解決途徑。
How？——我們的原則（價值觀）
現在，我們已經知道了 “Why” 和 “What” ，那麼指導我們執行的關鍵因素就是知道 “How？”。
“我們如何運作？”
現在，我們定義了核心價值觀和運作原則，這些原則有助於我們的團隊樹立正確的文化和思維方式。
現在讓我們看看我們是如何使用 “Why？What？How？” 這些問題來爲我們的平臺團隊奠定基礎的。
Why？
我們的使命： “我們的團隊爲什麼存在？”
“使開發人員能夠以高速度、高質量和高性能構建可擴展的應用程序。”
What？
目標： “我們重點關注的領域是什麼？”
- 優化迭代速度
“一家公司的創新速度受制於迭代速度。”
這一理念的核心原則是，重要的是快速行動，爲用戶提供服務，然後基於經驗在其上進行迭代。對於開發人員來說，這幾乎意味着能夠更快、更有信心地交付功能。
開發人員的生產力
爲開發者加快不同階段的軟件交付速度。
開發+發佈工作流
我們的重點可以分爲兩部分：
- 開發工作流：這裏的目標是使本地開發和測試儘可能快，儘可能輕鬆。
- 基礎設施的細節：除了合併一個拉取請求外，將其投入到生產環境，還涉及到使用各種工具和基礎設施。這需要團隊/平臺之間強有力的協作。
降低准入門檻
新員工的入職並不難，但影響卻很大。如果做好了，它將促進團隊合作，讓員工有種歸屬感，並降低員工流失率。
爲了降低新開發人員的進入門檻，構建正確的工具和文檔是很重要的，這些能夠讓我們更快地融入團隊，並對 “系統知識” 說 No。
- 解決常見問題
如果有平臺的話，就可以防止團隊爲解決常見問題並在整體上更有效率而 “重新發明輪子”。
要找出常見的問題，首先要了解開發人員的痛點和導致開發速度減慢的摩擦區域。我們可以通過收集反饋和通過工程關鍵績效指標定量地獲取這些信息，並結合對產品未來方向的理解，可以幫助形成一幅偉大的路線圖，並選擇正確的戰鬥。
- 鼓勵最佳實踐
性能很重要
默認情況下，讓它變得更快：性能優化應該直接在應用程序中進行。這一目標是爲開發人員提供正確的能力，讓他們開發的功能以最小的努力實現性能優化。
定義指導原則
共同定義最佳實踐和架構指南。通過工具、審查、文檔來倡導和鼓勵他們。提供輔導，參與討論，並幫助工程師交付高質量的代碼。
及早發現問題
確保我們擁有正確的工具/流程，使開發人員能夠驗證並檢查常見的隱患，如代碼氣味、Bug 和性能下降等，又如迴歸檢查、CI 框架鉤子、殭屍程序和性能綜合測試。
- 對團隊進行教育和賦權
“成爲 10 倍工程師的祕訣就是，幫助你身邊的 10 名工程師，讓他們的工作效率提高一倍。”
分享知識
通過技術講座和文檔分享你的知識、經驗和最佳實踐，是激發和提升團隊集體專業知識的好方法。
- 不斷嘗試
“任何想法都不會因爲有人這麼說就是真的。要通過觀察和實驗獲得的證據來檢驗想法。如果一個心儀的想法沒有通過精心設計的測試，那它就是錯的！”
——理查德・菲利普斯・費曼
控制實驗
作爲一個平臺團隊，要嘗試不同的解決方案，擁抱更新的技術，跳出框框思考，不斷改進和突破，這一點很重要。每當我們發現任何問題的有前景的方法時，我們都鼓勵大家通過概念證明進行嘗試，然後進行事後回顧結果，並做出相應的選擇。在完全推出關鍵的功能之前，應始終進行 AB 測試和分析。
質疑你的選擇
用戶在進化，代碼也在進化。一年前的模式在未來可能會成爲反模式。隨着產品的進化，新的需求不斷出現，而早期的優秀框架很可能會成爲滿足新需求的限制因素。爲了獲得解決問題的最佳方案，能夠質疑現有的選擇是必不可少的，也是實驗性思維的關鍵部分。
How？
原則： “我們如何運作？”
1. 接受所有權和問責制
像領導者一樣思考
“這都是關於從任何崗位、任何方向的領導。當今的整個組織結構，需要人們步入領導的思維模式，從不同的層次推動想法、項目和舉措，其不同之處在於規模。”
通過問責制建立信任
問責制就是讓自己對自己說過要做的事情負責。它是指貫徹和履行你所擁有的事情。這樣做會讓你感到被信任，因爲團隊知道你會兌現你的承諾。這就建立了一個信任鏈，而信任鏈是任何成功團隊的基礎。
- 理清優先順序
“很多時候，我們都有很好的想法。但它們還不如我們能爲客戶做的最重要的事情。我們必須做出艱難的選擇。”
——Sheryl Sandberg
與願景和目標保持一致
瞭解我們爲什麼要做我們正在做的事情，以及它給我們的開發人員帶來的影響。現在，請理清我們短期目標和活動的優先順序，使其支持我們的長期願景。
培養理清優先順序的思維模式
Sheryl Sandberg 廣爲人知的一個問題是： “這樣做絕對有必要嗎？” 這種思維模式有助於我們確定優先順序，並將重點放在最重要的工作上。在開始任何任務之前，要了解你的約束條件（如時間限制、依賴關係等）並估計投資回報率。
- 專注影響力
帕雷拓法則（也稱爲二八定律或 80/20 法則）
你往往會從 20% 的工作中獲得 80% 的影響力。
80/20 法則有助於將注意力集中在對我們目標影響最大的事情上。通過專注這些事情，你可以產生更好的影響力。
超越完美的迭代
讓開發人員/用戶瞭解情況，從中學習，並在此基礎上進行迭代，這一點非常重要。 這有助於我們更快地驗證想法，根據需要糾正方向，並最終做到隨着時間的推移而不斷完善。
專注於你能控制的事情
明智選擇你的戰鬥。雖然這句話是陳詞濫調，但卻是事實。抱怨自己不能完全控制的事情，只會導致消極和怨恨。當我們不再擔心那些因素，而是將注意力集中在我們能夠控制的事情上時，成功就會到來。
- 開放和數據驅動
公開協作
我們搭建的平臺就是我們的產品，我們支持的團隊就是我們的用戶。我們的協作方式就像一個內部開源（又名內源）團隊。 我們不希望任何一個人或團隊來決定我們如何爲所有團隊解決問題。關鍵是與團隊成員分享你的計劃，並通過設計評審或其他溝通渠道鼓勵公開反饋和建議。
幫助團隊完成平臺變更
通過對團隊的支持，來讓變更不那麼痛苦。平臺級的變更在很大程度上依賴於溝通來宣佈新的功能和突破性的變更。對於任何可能影響多個團隊的重大更改，請始終研究提供漸進遷移路徑的方法。
數據驅動的思維模式
“沒有數據，我們只有一個觀點。”
——Edward Deming
強大的團隊是由數據驅動的。捕獲數據並指定度量標準，以驅動決擇、優先級和評估權衡。重視數據和事實，而不是假設和觀點。
- 保持好奇，不斷學習
問題和答案一樣，都非常值得尊重。
沒有問題是沒有意義的，沒有問題是不好的問題。團隊達成共識的唯一方法就是提出問題，並區分事實和假設。這種對話至關重要，因爲這樣才能對做什麼和如何做有一個明確的理解，並有助於推動構建更好的產品。
強見解，弱堅持
“讓你的直覺引導你到一個結論，無論多麼不完美 —— 這是 “強見解” 的部分。然後證明自己是錯的 —— 這是 “弱堅持” 的部分。用創造性的方法進行懷疑，從中尋找那些不自洽的信息，或指向一個完全不同方向的指標。最終你的直覺將和一個新的假說將從這些廢磚爛瓦中復現，準備着再次被無情地顛覆。你會驚訝的看到，這一系列錯誤的預測將會以多快的速度給你提供一個有用的結果。”
——Paul Saffo
在接受變化的同時擁有強見解的能力：鼓勵不同的觀點，並使矛盾的觀點浮出水面，這些觀點可能會給我們當前的選擇帶來漏洞，並是我們能夠更快地學習和迭代。
快速試錯，學得更快
這不僅僅是 “快速試錯”，同樣也是 “學得更快” 。目的是進行快速、廉價的實驗，一夥的寶貴的見解，並在整合新學到的知識整合到系統的基礎上改變路線。
保持學習
重要的是，我們要把自己的技能當作是動態的東西，需要不斷地維護和提升。關鍵是要不斷學習，不斷進化，以適應新的情況。簡而言之就是：閱讀、傾聽、接受自己不知道的東西，做事情、並傳授解惑。
- 感同身受，尊重他人
共情
我們是一個團隊。我們應該經常設身處地地爲其他開發人員着想。在這裏，問題可以幫上很大的忙，例如：
- 這個技術決策對我們的開發人員有什麼影響？
- 我們如何才能讓其他團隊更容易採用這種變更？
建立一支多樣化的團隊使我們能夠從不同的角度提出問題，更好地理解問題，並幫助我們的開發人員做出正確的選擇。
尊重人類，而不僅僅是尊重代碼
歸根結底，我們只是一羣人類在一起工作，創造出一系列由 0 和 1 組成的模式，以便計算機能夠理解。重要的是要看到人性的一面，要做到 “求大同，存小異”。最優秀的產品總是由偉大的團隊打造的，而不僅僅是偉大的個人。
結語
自從組建平臺團隊以來的過去幾年裏，我們所做的一切都是以我們的使命、目標和原則爲指導。它確實爲我們提供了明確的重點和方向，無論組織一級的優先事項如何變化。將站點速度提高 50% 以上就是我們的主要成就之一。我們這樣做，既沒有影響現有的功能，也沒有進行任何影響其他項目的大規模重寫。你可以在這場演講中瞭解所有這一切。其他一些關鍵貢獻包括通過新的 mono repo 設置，實現了更快的本地開發、故事書集成、自動的 perf（軟件性能分析）和無障礙功能（Accessibility，縮寫 a11y）檢查，簡化了跨 Web 應用的日誌/監控，在 10 分鐘內就能找到問題的根源，以及改進工具。
我想給大家留下最後一句話：平臺和軟件在不斷髮展，我們今天構建的東西，肯定也會隨着時間的推移而改變、過時。這只是進步，我們最終要繼承的是我們的學習、友誼和回憶，這些都將伴隨我們前進。重要的是，要在團隊中樹立正確的文化，讓工程師們能夠快樂，爲他們的工作而感到自豪，並作爲一個團隊共同成長。努力工作，但也別忘了要有樂趣。乾杯！
作者介紹：
Vasa，Walmart 實驗室 FE 平臺技術經理，專注 JS 和 Web 性能分析，愛好健身、電影、揹包旅行、園藝，信奉終身學習的信念。
原文鏈接：
https://medium.com/walmartlabs/building-a-platform-team-d915221d5654