第二十二章：我的角色不只是寫碼

應用理論：BART (邊界、權威、角色、任務) - Role (角色)

清晰的「邊界」和「權威」，為「創世紀」專案搭建了堅實的結構框架。但艾佛勒知道，一個組織不僅僅是流程和規則的集合體，它歸根結底是由一個個活生生的「人」組成的。如果個體成員對自己在系統中的「角色」認知不清，再完美的框架也無法高效運轉。

這觸及了BART模型的第三個維度 角色 (Role)。

「角色」，不僅僅是職位說明書 (Job Description) 上的那個頭銜，比如「後端工程師」或「產品經理」。它更是一個動態的、與系統互動的心理定位。它關乎「我是誰？」、「別人期望我做什麼？」以及「我期望自己貢獻什麼？」等一系列問題。

在過去的「星雲科技」，團隊成員對角色的理解普遍是狹隘和僵化的：

• 工程師的角色，被認為是「寫出能運行的代碼」。他們很少關心代碼的商業價值或用戶體驗。

• QA的角色，被認為是「找出Bug」。他們與質量的關係是「事後發現」，而非「事前預防」。

• PM的角色，被認為是「傳達需求和跟蹤進度」。他們常常被動地在業務和開發之間傳話，缺乏對產品方向的主導權。

這種狹隘的角色定位，是導致部門牆和本位主義的深層原因。每個人都只掃門前雪，不管他人瓦上霜。

艾佛勒的目標，是幫助團隊成員擴展和重塑他們的角色認知，從一個個孤立的「功能執行者」，轉變為對整個產品價值負責的「共同體成員」。

他沒有採用說教的方式，而是設計了一系列巧妙的「角色互換」練習，融入到「創世紀」專案的日常工作中。

練習一：「客戶的椅子」

在專案的啟動會議上，艾佛勒在會議室的正中央，擺了一張空椅子。

他宣布，「從今天起，這張椅子，代表著我們的『客戶』。在我們做任何重要的技術決策之前，我都會邀請一位同事，坐到這張椅子上，代表客戶發言。」

第一次被邀請坐上這張椅子的，是資深後端工程師大衛。艾佛勒問他：「大衛，現在你就是我們的客戶。對於我們即將開始的資料庫重構，你最關心的是什麼？你對我們有什麼期望？」

大衛坐在那裡，感到了前所未有的不適。他不能再用技術術語來思考了。他必須站在一個非技術用戶的角度。他想了很久，說：「我……我希望這個過程不要影響我的正常使用。我希望你們遷移資料不要出錯，不要把我的訂單搞丟了。我希望完成之後，網站的速度能變快一點。」

這幾句樸實的話，比任何技術指標都更有力量。它讓在場的所有工程師都意識到，他們的工作，最終是為了一個活生生的、有具體期望的「人」服務的。

在整個專案過程中，「客戶的椅子」成了一個固定的儀式。工程師、QA、PM輪流坐上去，這極大地拓寬了他們的視角。

練習二：「QA For a Day」(一日QA體驗)

為了解決開發與QA之間的長期對立，艾佛勒推動了一個小型的「角色互換」計劃。他讓幾位開發工程師，花一整天的時間，跟著QA團隊一起工作。他們親身體驗了QA是如何根據需求文檔設計測試用例，如何手動執行那些繁瑣的回歸測試，以及如何精確地覆現和記錄一個Bug。

前端工程師馬克在體驗結束後，感觸極深。他在回顧會上說：「我以前總覺得QA是來找茬的。今天我才明白，他們的工作有多麼重複和需要耐心。而且我發現，如果我們當初在開發時能多考慮一些邊界情況，就能為他們省去大量的測試時間。我第一次感覺到，質量，真的是我們開發人員的責任，而不是QA的。」

這次體驗，比一百次強調「質量重要性」的會議都更有效。

練習三：重塑「產品經理」的角色

艾佛勒與CTO穆拉提一起，對PM的角色進行了重新賦能。他們明確指出，PM的角色，不再是「需求傳聲筒」，而是「產品的CEO」和「團隊的首席Why講述者」。

在「創世紀」專案中，產品經理安娜被賦予了更大的權威。她不再只是傳達指令，而是需要向團隊清晰地闡述「我們為什麼要做這件事？」以及「它如何幫助我們的用戶和業務？」。她開始花更多的時間與用戶溝通，並將用戶的故事和痛點帶回團隊。

同時，她也被要求去學習基本的技術概念，以便能更好地理解工程師們面臨的挑戰。她不再是團隊的「局外人」，而是真正融入其中的「指南針」。

通過這些持續的、嵌入在工作中的練習，團隊成員們的角色認知，開始發生深刻的變化：

• 工程師們開始意識到，自己的角色不只是「寫代碼」，而是「通過技術解決用戶問題，並為產品質量負責」。

• QA們開始將自己的角色，從「Bug發現者」，轉向「質量的賦能者和教練」，他們開始幫助開發團隊建立更好的測試策略。

• PM們則真正開始扮演起「產品願景的守護者和溝通者」的角色。

當每個人都擴展了對自身角色的理解後，一種奇妙的化學反應發生了。他們不再需要管理者在後面時刻監督和推動，一種源於內在的、對共同目標負責的「主人翁精神」，開始在團隊中生根發芽。