在軟件工程領(lǐng)域，任何脫離實際業(yè)務(wù)需求的架構(gòu)設(shè)計都是一種不負責(zé)任的行為，甚至可以稱之為"技術(shù)層面的形式主義"。這種設(shè)計傾向往往表現(xiàn)為過度追求技術(shù)新穎性、盲目采用復(fù)雜架構(gòu)模式，或者為了架構(gòu)而架構(gòu)的設(shè)計理念。很多技術(shù)債務(wù)也是由于架構(gòu)設(shè)計與業(yè)務(wù)需求脫節(jié)造成的。

多年的實踐，經(jīng)歷了很多的項目和工程架構(gòu)實現(xiàn)，整理了10點體會，可能不對，可能片面，都來自于過去的經(jīng)驗。

1.每個人都是凡人，無關(guān)職位

許多人從小就被灌輸"要做一個聽話的孩子"的觀念，這種觀念往往會在潛意識中形成對權(quán)威的畏懼心理。作為一位老碼農(nóng)，我也曾深受這種思維模式的影響。然而，隨著互聯(lián)網(wǎng)時代的到來，平等、開放、共享的互聯(lián)網(wǎng)思維正在重塑新一代年輕人的思維方式。

事實上，在當(dāng)今這個信息高度對稱的時代，真正的權(quán)威往往更傾向于傾聽不同的聲音，因為創(chuàng)新往往來自于多元觀點的碰撞。每個人都是獨特的個體，都擁有值得分享的經(jīng)驗和見解。當(dāng)我們能夠以平等的姿態(tài)進行交流時，不僅能更好地表達自己的觀點，也能從對話中獲得更多啟發(fā)。

在跨部門協(xié)作或多方參與的會議中，建立正確的角色認知至關(guān)重要。我們首先應(yīng)當(dāng)認識到，無論職位高低、資歷深淺，所有參與者都是平等的，其次才是各自承擔(dān)的特定角色——無論是負責(zé)技術(shù)架構(gòu)的軟件架構(gòu)師、專注實現(xiàn)的工程師、把握產(chǎn)品方向的產(chǎn)品經(jīng)理，還是統(tǒng)籌全局的項目經(jīng)理。這種認知能夠幫助我們摒棄職位帶來的心理隔閡，營造開放、包容的討論氛圍。

2. 概念清晰是關(guān)鍵

若自己對某些內(nèi)容不甚明了，很可能他人也同樣處于困惑之中。這種情況下，不妨大膽發(fā)問！尤其是在踏入新的角色崗位，或是接手全新的產(chǎn)品、項目之時，常常會在會議場合發(fā)現(xiàn)這樣的場景：有那么 1 - 2 個人正自信滿滿且語速極快地交流著，其余人則默默地點頭示意。而于我而言，一些專業(yè)術(shù)語或者由三個字母組成的首字母縮略詞頗為陌生。此時，往往會產(chǎn)生一種錯覺，覺得除了自己，其他人似乎都對這些內(nèi)容了如指掌。為了不暴露自己的無知，常常選擇保持安靜，只是默默點頭表示認同。

然而，倘若逼迫自己主動提出問題，促使演講者對自身觀點加以闡釋，便能夠助力其收獲清晰的認知，將那些復(fù)雜晦澀的內(nèi)容轉(zhuǎn)化為易于傳達的信息。實際上，這種做法是在為在場的每一個人提供幫助，畢竟十之八九的人同樣未能完全理解相關(guān)內(nèi)容。尤其在主題繁雜且發(fā)言者又是該領(lǐng)域?qū)＜业那闆r下，最為關(guān)鍵的能力就在于能將復(fù)雜之處轉(zhuǎn)化為清晰明了的表述，而我認為這恰恰是架構(gòu)師所承擔(dān)的重要角色之一。

明確概念至關(guān)重要。若涉及新術(shù)語，務(wù)必精準(zhǔn)界定其內(nèi)涵，即剖析該概念在時間與空間維度上的構(gòu)成要素；而概念的外延，主要是為便于理解及指明其潛在應(yīng)用場景。若僅闡述外延卻忽視內(nèi)涵定義，那便如同構(gòu)建空中樓閣，永遠無法切實落地。

此外，當(dāng)有人使用廣為人知的概念卻發(fā)現(xiàn)其含義與自身理解存在偏差時，也需及時澄清。畢竟許多人對概念邊界的認知較為模糊，容易引發(fā)混淆，我亦常有此類經(jīng)歷。

3. 文檔決策

在項目管理中，有一條至關(guān)重要的原則：如果沒有形成書面記錄，就等于這件事從未發(fā)生過！這個觀點在會議管理、技術(shù)探索和項目決策中尤為重要。

在快節(jié)奏的工作環(huán)境中，不要天真地認為參與者會記住會議的所有細節(jié)。一個人的工作記憶容量有限，48小時后就會遺忘約70%的新信息。如果會議結(jié)果確實需要后續(xù)跟進，書面記錄就是確保執(zhí)行力的關(guān)鍵。缺乏書面記錄往往導(dǎo)致重復(fù)討論、決策模糊和執(zhí)行偏差，這種低效的溝通方式會顯著延長項目周期。

這一原則同樣適用于架構(gòu)領(lǐng)域。概念驗證（POC）、技術(shù)實驗、探索性研究、架構(gòu)設(shè)計直至工程實習(xí)——這些投入了大量時間和資源的努力，其成果必須以書面形式固化。這不僅是為了知識傳承，更是為了避免重復(fù)勞動和確保技術(shù)決策的可追溯性。

關(guān)于記錄的形式，建議根據(jù)信息的重要性選擇合適的載體：

• 對于重要決策和長期參考的內(nèi)容，建議使用Confluence或Wiki等知識管理平臺
• 對于中等重要性的內(nèi)容，可以在演示平臺中存檔
• 對于日常決策，電子郵件或聊天記錄也是可接受的記錄方式

特別要提醒的是，不要依賴會議錄音。數(shù)據(jù)顯示，超過90%的會議錄音從未被重聽。錄音只能作為補充材料，而不能替代結(jié)構(gòu)化的書面記錄。有效的書面記錄應(yīng)該包含：關(guān)鍵決策、責(zé)任人、時間節(jié)點和具體行動項，這樣才能真正發(fā)揮其價值。

4. 定義所有權(quán)人

所有權(quán)也是至關(guān)重要的，擁有一個明確的所有者，他們有責(zé)任和動力去加強和推動進步。經(jīng)驗數(shù)據(jù)表明，具有明確責(zé)任人的項目成功率比責(zé)任模糊的項目高出40%。 這里的責(zé)任人，不僅定義了他的責(zé)任，而明確了他的權(quán)力邊界。 責(zé)、權(quán)、利明確才是定義所有權(quán)。

合作很重要，但總有一天你必須做出決定，繼續(xù)前進，即使沒有成功地達成共識。這個時候，在考慮到所提出的所有權(quán)衡之后，既定的所有權(quán)人應(yīng)該做出決定，并允許每個人進入實現(xiàn)目標(biāo)的下一步。過度的討論和協(xié)商可能導(dǎo)致決策癱瘓。數(shù)據(jù)顯示，約23%的項目延期都是由于過度追求共識而延誤了決策時機。

如果沒有明確的所有權(quán)人，預(yù)期的成果就不會產(chǎn)生，或者機會從時間中溜走。我們陷入了某個階段而無法前進？這往往是由于缺乏決策或沒有人站出來推動進展。

5. 使用架構(gòu)合約

每當(dāng)負責(zé)領(lǐng)導(dǎo)一個跨越多個業(yè)務(wù)單元與開發(fā)團隊的技術(shù)架構(gòu)項目時，都意味著會面臨諸多相關(guān)利益所有者，因此務(wù)必創(chuàng)建某種架構(gòu)契約。

當(dāng)某個產(chǎn)品或項目僅由單一業(yè)務(wù)單元負責(zé)開發(fā)時，產(chǎn)品需求能夠被較為清晰地定義為初始需求，畢竟顯而易見的是，所有的技術(shù)工作均由該單一業(yè)務(wù)單元所擁有。然而，倘若一個大型項目涵蓋跨業(yè)務(wù)組的協(xié)作，且每個業(yè)務(wù)組都各自提供特定的功能、服務(wù)或組件，那么僅依賴以最終用戶為核心的產(chǎn)品需求便遠遠不夠了，因為在各業(yè)務(wù)單位之間明確劃分責(zé)任變得至關(guān)重要。

產(chǎn)品經(jīng)理通常難以對每個技術(shù)服務(wù)或組件的需求作出精準(zhǔn)定義，因為這是終端用戶無法直接感知到的技術(shù)細分層面。故而，制定技術(shù)“合約”是必不可少的。

在技術(shù)合約之中——除了細致入微的書面要求之外，還應(yīng)配備圖表說明。組件圖自然是首要之選，但時常會發(fā)現(xiàn)某些功能方面的細節(jié)在這一步被遺漏了，所以要運用序列圖來強化契約內(nèi)容，因為它們能夠清晰直觀地展現(xiàn)服務(wù)與組件之間的責(zé)任劃分，進而明確各小組的分工。

隨后，每個業(yè)務(wù)單元的核心干系人（如架構(gòu)師和工程師）應(yīng)當(dāng)對技術(shù)合約進行審核并簽字確認，以此確保各方認知的一致性與連貫性。

這或許看似理所當(dāng)然，但令人驚訝的是，多個團隊常常在推進過程中自以為彼此步調(diào)一致，而實際情況卻是他們之間存在著差距，甚至持有相互沖突的觀點。一個單一的產(chǎn)品需要有且僅有一個統(tǒng)一且明晰的技術(shù)愿景。

6. 不要盲目地相信指令

總是給自己提出問題和挑戰(zhàn)假設(shè)的空間，保持獨立思考的能力和勇于挑戰(zhàn)既定假設(shè)的精神非常重要——這種品質(zhì)對于身處領(lǐng)導(dǎo)崗位的人而言尤為難得。然而，真正的專業(yè)精神恰恰體現(xiàn)在這種敢于質(zhì)疑和反思的勇氣中。

在任何情況下，都切勿讓他人肆意剝奪你那寶貴的自主權(quán)利。要始終保持獨立思考的能力，緊密貼合自己內(nèi)心深處的聲音，這聲音往往是經(jīng)過多年深入學(xué)習(xí)與豐富實踐經(jīng)驗的沉淀與凝練而成。

誠然，最終的決策或許并非總能如你所愿。每個人都應(yīng)當(dāng)擁有屬于自己的決定權(quán)，而這個關(guān)鍵的決策者并不總是你。但是，一定不要就此沉默，而是要勇敢地說出自己的想法，積極地表達出你的反饋意見，努力讓自己成為討論過程中一個有價值的參與者。

7. 提出問題伴隨著解決方案

這是我最重要建議，幾乎適用于所有的行當(dāng)。

發(fā)現(xiàn)一個問題很容易，但是盡量不要過來就指出問題 ，這常常被認為是批評或者抱怨。相反，總是至少為問題制定一個解決方案，理想情況下是制定幾個替代解決方案，每個解決方案都有自己的權(quán)衡，并且只將問題與潛在的解決方案一起呈現(xiàn)。通過展示前進的方向來推動變革，而不僅僅是發(fā)泄。

采用"問題-解決方案"的方式能夠帶來顯著優(yōu)勢：

• 展現(xiàn)專業(yè)能力和責(zé)任心
• 促進建設(shè)性討論
• 推動問題實質(zhì)性解決
• 提升個人影響力

選擇的解決方案可能是你沒有想到的替代方案，這沒關(guān)系。通過提出至少一些解決方案，然后可以啟動創(chuàng)新并思考如何改進。

8. 避免過度設(shè)計

致力于為每個特定的案例精心打造相應(yīng)的架構(gòu)，這無疑散發(fā)著巨大的吸引力。畢竟，我們每個人內(nèi)心深處都懷揣著對完美工作的執(zhí)著追求，期望自己所負責(zé)的每一個項目、每一項任務(wù)都能毫無瑕疵。

然而，在這看似美好的追求背后，隱藏著完美主義帶來的重重阻礙。過度地對設(shè)計進行架構(gòu)化處理，會引發(fā)一系列負面效應(yīng)。其中最為突出的表現(xiàn)便是開發(fā)時間的急劇膨脹。開發(fā)人員可能會陷入無盡的細節(jié)優(yōu)化和架構(gòu)調(diào)整之中，導(dǎo)致項目的推進速度變得異常緩慢。從長遠的視角來看，這種過度投入所帶來的額外付出往往并不能得到與之相匹配的回報。

而敏捷方法的核心要點之一在于，精準(zhǔn)地識別并放大每個階段中真正具有價值的元素，然后將主要精力聚焦于此。通過這種方式，能夠在確保項目價值得以最大程度實現(xiàn)的同時，有效地避免陷入過度設(shè)計和完美主義的誤區(qū)，從而保障項目的高效推進和可持續(xù)發(fā)展。

9. 退一步海闊天空

當(dāng)項目陷入停滯狀態(tài)，出現(xiàn)原地打轉(zhuǎn)的跡象時，退一步，找出根本原因。半數(shù)以上項目的延誤都源于未能及時識別和解決根本性問題。

• 是因為缺乏所有權(quán)人嗎？
• 是否缺乏充分的授權(quán)（人，錢，時間）？
• 這是一個沒有實現(xiàn)的共識愿望嗎？
• 是否有新的利益相關(guān)者需要重新作出決定？
• ...

工程停滯是多重因素疊加的結(jié)果。建議采用"5Why分析法"深入挖掘問題本質(zhì)，同時建立預(yù)防機制。發(fā)現(xiàn)問題是成功的一半，但只有系統(tǒng)性地解決問題才能確保持續(xù)前進。

10. 真正的敏捷

我相信敏捷方法論，但是只有當(dāng)它們真正是敏捷的時候。

在現(xiàn)實世界中，我們常常目睹這樣的景象：眾多公司長期以來深深扎根于傳統(tǒng)的瀑布式開發(fā)模式，其組織架構(gòu)、工作流程以及企業(yè)文化都已與瀑布方法緊密交織。然而，面對市場快速變化的挑戰(zhàn)以及追求更高效開發(fā)過程的需求，這些公司試圖踏上敏捷轉(zhuǎn)型之路，卻又難以徹底擺脫瀑布模式的束縛。他們在保持既定的最后期限、僵化的范圍劃分以及繁瑣沉重流程不變的基礎(chǔ)上，生硬地添加上某種形式的敏捷方法，而 Scrum 往往是首選的 “裝飾”。

于是乎，在這些公司的日常運營中，“站會”“沖刺”“史詩”“用戶故事” 等敏捷專業(yè)術(shù)語開始頻繁響起，表面上看似在積極采用敏捷實踐。但深入觀察其實際操作就會發(fā)現(xiàn)，其核心思維方式依舊深陷線性的泥沼，仍然被固定的框架禁錮，未能擁抱應(yīng)有的靈活性。當(dāng)這種貌合神離的情況發(fā)生時，企業(yè)只是徒增了實施 Scrum 等敏捷實踐的表面成本，卻未能收獲敏捷方法本應(yīng)帶來的諸多益處，如快速響應(yīng)變化、提升團隊協(xié)作效率以及更快交付有價值的產(chǎn)品增量等。

換句話說，這樣的企業(yè)不幸陷入了兩個世界的夾縫之中，形成一種稱之為 “WaterGile”的境地。

留在瀑布公司通常有合理的理由ーー比如當(dāng)所在的行業(yè)需要承諾的時間表和范圍時。但是，如果真的決定引入敏捷，要確保自己致力于真正成為敏捷，不要讓自己我稱之為 “WaterGile” 的組合方法所拖累。

誠然，有些公司出于行業(yè)特性的特殊考量，如所在行業(yè)對明確的時間表和精確范圍有著嚴格要求并需要對外作出承諾等情況，選擇留在瀑布模式陣營往往存在其合理之處。但是，對于那些毅然決定引入敏捷方法的企業(yè)而言，務(wù)必確保自身全身心地投入到真正的敏捷轉(zhuǎn)型進程中，避免陷入這種既不像瀑布也未得敏捷之利的困境。

一句話小結(jié)

這十點體會都不是什么科學(xué)，只是30年碼農(nóng)生涯中再架構(gòu)設(shè)計過程中的個人理解，每條規(guī)則都有例外。盡管如此，我還是希望這些建議可能對大家有所幫助。