[心得筆記]架構師如何決定控制力道的界線

最近在看《軟體架構原理：工程方法》這本書，其中有一段講到身為架構師應該如何拿捏介入團隊實作的力道我覺得滿實用的。作者示範了兩種極端的架構師人格特質，以及列出幾項可以量化的點，透過這幾項量化後的分數加總決定應該施加多少介入的力道。

架構師的人格特質

• 空談的架構師：
  • 不考慮實作細節，常常與開發團隊失聯。當完成非常高階的架構圖後便從一個專案換到下一個專案。
  • 成為空談架構師的可能原因：
    • 不了解業務領域、業務問題、使用的技術。
    • 開發軟體的實際經驗不夠。
    • 未考慮架構方案實作的可能影響。
• 控制狂的架構師：
  • 想控制軟體開發的每個細節，做的每個決策太細太低階，導致開發團隊受到太多的限制。
  • 成為控制狂架構師的可能原因：
    • 一個人剛從開發人員轉變成架構師時。
• 有效的架構師：
  • 根據專案、公司規模及文化來決定應該使用多大的力道介入專案，在空談的架構師與控制狂的架構師之間取得平衡。

控制介入力道評分考量點

• 團隊熟悉度：團隊成員有多熟悉、如果彼此越熟悉越不用太多介入。相反，團隊成員越新，就越需要介入控制促進彼此間的合作，並且減少團隊內的小團體。
• 團隊大小：超過12人是大團隊、低於4人是小團隊。團隊越大，控制應當越多；團隊越小，控制可以少一些。
• 整體經驗：團隊資深/資淺成員的比例。他們對技術與業務領域有多清楚，資淺人員有多少人需要指導。
• 專案複雜度：很複雜的專案需要架構師更常與團隊接觸、並在問題發生時提供協助，因此得對團隊有更多的控制。相對簡軍的專案因為很直接，所以不需要太多控制。
• 專案長短：專案的長度是短(2個月)、長(2年)、或平均(6個月)。長度越短，需要的控制較少。相反地，專案越長，需要的控制越多。

評分量化示範

情境1

結論：所有因素都納入考量，以展示有效的架構師在一開始扮演推助者的角色，而不是在日常跟團隊的互動上介入太深。架構師必須回答問題，也得確定團隊步上正軌，但大部分情形下架構師應當放手，讓有經驗的團隊做他們最擅長的事：快速開發軟體。

情境2

結論：其中團隊成員彼此熟識，但團隊較大(12位成員)且大部分是資淺(無經驗)人員。專案相對複雅，時程長短是6個月。此案例的累穨分數是+20，顯示一位有效的架構師應介入團隊的日常活動，並承擔指導及教練的角色，但又不會到打亂團隊的地步。

總結

以往認知上只能憑帶過或參與過專案的經驗來自由心證評斷一個架構師應該介入多少力道到團隊互動上，這本書直接將考量點給量化了。將團隊熟悉度、團隊大小、整體經驗、專案複雜度、專案長短這幾項納入考量，我覺得滿實用很值得參考。