近期筆者因為工作原因，開始啟動team內部部分技術項目的重構。在事情啟動的過程中，內部對于這件事情的定性和投入有一些爭論，但最終還是敲定了下來。其中部分爭論點主要在于產品形態，因為事情涉及到跨部門合作，所以產品形態怎么符合雙方的利益是比較重要的。在這個前提下，然后才是技術設計上面，怎么能夠迎合長久合作的需要。

因此，今天筆者就簡單聊一下，怎么去做到讓技術架構設計和預期產品形態能夠做到有效平衡。

首先，因為產品形態決定技術結果，所以需要經過討論去確定核心的產品效果。筆者所在的team距離具體業務比較近，而面臨的跨部門合作場景主要是和infra部門合作，那么這里面的分歧點就是，infra部門對于業務需求提倡開放性，而距離具體業務比較近的部門則更加傾向于打造相對封閉而有競爭力的產品。為了解決這個分歧，最終討論產品效果是讓infra提供架子，筆者team的能力作為核心組件接入，這樣就能夠達到雙方對于最終產品效果上的共識。當然，不同企業不同部門情況不統一，但這個事情還是要確定的。

其次，由產品形態反推技術設計，必然涉及到架構演進的部分，從現有的技術架構出發，怎么演進到最終態，花費多少時間多少人力，如果要拿技術/業務結果的話有哪些階段性產出，不同階段之間架構演進會有什么樣的變化，每個階段投入產出比怎么樣，這些都是作為架構師需要去考慮的。在筆者的case里面，筆者所要重構的是一套變更風險觀測基建，所以架構演進主要采用分模塊演進的方式，第一階段面向觀測能力，提供統一的技術接入和調度協議；第二階段面向觀測調度，提供類流水線+低代碼的編排方案；第三階段將整套調度編排做持續迭代，適配各類業務變更觀測場景，并完善數據度量分析等周邊功能。這樣，這套變更風險觀測基建，就可以兼顧短期和長期的落地需要，逐步成為公司內部標準化的方案。

最后，在實際執行技術架構實現的過程中，也需要保持足夠的主動性，推動研發和非研發的事情都得到解決。雖然下面的話有點阿里味，但道理是沒有錯，那就是因為相信，所以看見。以這樣的基礎，跨部門合作也會更加有凝聚力，大家也更愿意互相信任，讓整個事情做到成功。當然，悲觀的來講，唯一不變的是變化，也許一些宏大的技術構思，最終也會因為種種原因無法落地，但這并不重要。重要的是，你能夠用技術掌控人，解決人的問題，這才是作為一名技術架構師存在的價值。