「我覺得寫工程策略很難，因為好的策略其實挺無聊的，寫起來也無聊。而且大家一聽到『策略』就想到『創新』。」——卡蜜兒·福尼耶（Camille Fournier）
很少有公司真正搞懂自己的工程策略與願景。這種不確定的一個後果，是業界普遍相信這些文件「很難寫」。談起來常帶著某種神祕感，但其實它們只是再平凡不過的文件。真相是：好的工程策略很無聊，而且寫一份有效的策略，比寫一份糟糕的策略更容易。
一句話說完整套配方：
- 寫工程策略：寫五份設計文件，把其中的共通點抽出來——那就是你的工程策略。
- 寫工程願景：寫五份工程策略，預測它們往後兩年的影響——那就是你的工程願景。
如果你忍不住想把最聰明的點子塞進去，可以把它們放進「前置作業」：把所有最好的點子寫進一份大文件裡，然後刪掉它，之後永遠別再提。點子既已出清，你的腦袋就清空了、能專心面對接下來的工作。
真正持久有用的策略與願景，是由下而上、反覆迭代的組織學習的產物。因此，一切學習都在為組織的策略與願景添磚加瓦；即使你不直接負責這項工作，也有實際的步驟能從現在起就推進它。
何時、為何要寫#
在動手前，先問一個好問題：「我究竟該在什麼時候、為什麼要寫這些？」
- 策略是主動對齊的工具，讓團隊能快速且有信心地行動。它讓每個人（而不只是少數被授權者）都能做出原本可能要討論一週的快速決定。
- 策略也是收窄未來的磚塊：把眾多可能的未來收斂到足以寫出一份務實願景的程度。
判斷時機的兩個訊號：當你發現同一場討論已重演三四次，就該寫策略了；當未來模糊到難以判斷「值得投資什麼」，就該再寫一份願景。若這兩種困擾都不熟悉——先去做別的工作，之後再回來。
第一步：寫五份設計文件#
設計文件描述你在具體專案中所做的決策與取捨，公司裡可能叫 RFC 或 tech spec（Uber 一度莫名其妙叫它 DUCKS，後來才統一為 RFC）。一份好的設計文件會描述一個具體問題、盤點可能方案、並解釋所選方案的細節。
什麼專案該寫設計文件，終究是個人判斷，但作者有幾條實用準則：
- 能力會被眾多未來專案使用的專案。
- 對使用者有實質影響的專案。
- 任何耗時超過一個月工程時間的工作。
五份設計文件之所以是寫策略的理想原料，是因為它們具備爛策略所缺乏的東西：扎根於現實的具體細節。同一團隊的兩位善意工程師，很容易對抽象策略各自解讀；但當大家都在實作一個具體方案時，就很難繼續各說各話。
寫設計文件的幾個建議
- 從問題出發。 問題陳述愈清楚，解法愈明顯。若解法不明顯，就多花時間釐清問題。若卡在表述問題，把手上的東西給五個人看，問他們少了什麼——新鮮的眼睛總能看見真相。
- 模板保持精簡。 多數公司有設計文件模板，這是好習慣；但模板常被擴充到想服務太多目標，反而讓人不想寫。偏好極簡模板，讓作者自選最有用的段落，只對風險最高的專案要求詳盡細節。
- 廣泛收集、共同審閱，但獨自撰寫。 你個人不太可能握有寫出最佳文件所需的全部脈絡，動筆前先向相關視角（尤其是會依賴此文件產出的人）收集意見。但別把這種協作帶進「撰寫」本身——多數人是比較好的作者、而非好的編輯，把一份團體文件編成清晰文字，通常比找一位作者寫清楚更難。廣泛收集觀點，但獨自撰寫。 只是別在與他人審閱之前就愛上自己寫的東西。
- 好，勝過完美。 寫出一份夠好的文件並儘快給別人看，勝過為了邊際上的一點更好而拖延。給別人的設計回饋時尤其要記住這點：別期待別人的設計都要達到你最好的水準。愈資深，愈不該逼每個設計都達到你的巔峰之作——聚焦於把設計推向「好」，而不是死盯著自己的最佳作品當品質標準。
想寫出更好的設計文件？作者最好的建議是：實作完成後回頭重讀你的設計，研究「實作偏離計畫」的地方——是什麼造成了這些偏差？當然，還有——就是持續多寫幾份。
第二步：把五份設計文件綜合成策略#
寫完五份設計文件後，坐下來一起讀。找出在多份設計中反覆出現、而且難以達成共識的爭議性決策。作者最近的例子是反覆爭論「Redis 適合當持久儲存，還是只能當快取」——與其每次設計審閱都從零開始，不如把近期關於 Redis 的決策拿出來回顧、反思當初怎麼決定的，把它寫成一份策略。
好策略引導取捨、並解釋背後的理由；爛策略只陳述政策卻不解釋，於是與當初的脈絡脫鉤。缺了脈絡，策略很快就變得難以理解（他們當初為什麼這樣決定？），也難以隨脈絡變動而調整。
如果你是《好策略・壞策略》（Good Strategy, Bad Strategy）的信徒——那本書徹底改變了作者對策略的看法——你會發現這裡的策略定義，正是書中的「診斷」與「指導方針」兩部分，把「連貫的行動」留給了設計文件。
寫策略文件的最佳建議
- 從你所在的地方開始。 面對策略工作固有的巨大模糊，很容易癱瘓；但你就是得跳進去開始寫。等待缺失的資訊沒有用：每份缺席的文件都有它缺席的好理由。你寫的東西一定得改，若寫得特別糟，你會很快意識到要改。你現在所在的位置，永遠是最好的起點。
- 寫具體的東西。 一路寫到你開始「泛泛而論」時就停筆。若無法具體，就等你寫了更多設計文件再說。具體的陳述創造對齊；籠統的陳述只創造「對齊的錯覺」。
- 要有觀點。 好策略是有立場的；若沒有立場，就無法為決策提供任何清晰指引。但光有立場還不夠——你還得——
- 展示你的推導過程。 就像小時候數學課要「寫出過程」才能拿滿分，這裡你也必須展示觀點背後的理由。展示過程能為文件的第一版建立信心；更重要的是，它讓別人得以在脈絡變動時修改與延伸你的成果。
有些你寫過最好的策略，當下可能覺得「太顯而易見、不值得寫」。但「我們何時該寫設計文件？」值得寫；「哪些資料庫用在哪些場景？」值得寫；「該如何分階段從單體遷移到服務？」也值得寫。一旦放下「策略是才華展示」的想法，你就能寫得更多、也更隨性。若某份策略最後沒被用上，之後棄用即可。
第三步：把五份策略外推成願景#
隨著策略愈積愈多，你會愈來愈難推理它們彼此如何互動。比方說，一份策略是「少自營軟體、多依賴雲端方案」，另一份卻是「盡可能把複雜度卸載到資料庫」——若某個資料庫能卸載大量複雜度、卻不在你的雲端供應商目錄裡，這兩份策略該如何調和？
取五份近期策略，外推它們的取捨在未來兩到三年會如何演變。當你編修掉其中的矛盾、把線索編織在一起，你就寫出了一份工程願景。最終版本會給你坦雅·萊利（Tanya Reilly）所說的「對未來的堅實信念」，讓你更容易理解既有策略之間的關係，也更容易寫出經得起時間考驗的新策略。
寫出有用願景的重點
- 著眼兩到三年後。 公司、組織與技術變化都夠快，想得太遠很危險；但寫一份半年就過期的願景也沒用——半年內你能實際寫出幾份策略？聚焦兩到三年後；若公司相當成熟，可稍微拉長視野。
- 扎根於你的業務與使用者。 有效的願景以「服務使用者與業務」為根基，這種緊密連結讓願景與領導層的核心價值（使用者與業務）保持一致。爛願景把「技術精湛」當成自我證成的存在理由——這種觀點你的領導層永遠不會認同。
- 要樂觀，別狂妄。 願景應有雄心，但不該狂妄；要「可能做到」，而且是「若一切順利、最好的那個可能版本」。寫下「若每個專案都準時完成、沒有重大挫折，你能達成什麼」，而不是「若資源無限你能做什麼」。
- 保持具體。 願景愈具體愈有用。籠統陳述人人都同意，卻無助於調和相衝突的策略。要比你覺得舒服的程度再詳細一點；願景裡的細節多半是「示意性」而非「宣示性」——給人一點未來的味道，而非一項綁定承諾。
- 控制在一到兩頁。 現實是多數人不讀長文件。若你寫五六頁，讀者會讀不完就掉隊（或飛快略讀、根本不深入細節）。逼自己寫得緊湊，額外脈絡靠連結到其他文件，留給少數想看全貌的人。
別用初期熱度衡量願景#
寫完願景後，大家通常第一步是把它廣傳到整個工程組織。願景背後的功夫實在太多——一份願景要五份策略、每份策略又要五份設計文件——完成時很難不興奮。也正因如此，當回應幾乎總是平淡時，你很容易灰心。
回應平淡有幾個原因：
- 願景的核心讀者是「寫策略的人」，而這是相對小的一群。
- 一份好願景通常顯而易見到讓人覺得無聊，而非興奮。
別用願景激起的初期興奮來衡量它。改用這個方法：讀一份兩年前的設計文件，再讀一份上週的；若有明顯進步，你的願景就是好的。