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

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

1.每個人都是凡人，無關職位

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

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

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

2. 概念清晰是關鍵

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

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

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

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

3. 文檔決策

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

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

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

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

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

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

4. 定義所有權人

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

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

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

5. 使用架構合約

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

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

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

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

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

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

6. 不要盲目地相信指令

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

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

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

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

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

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

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

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

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

8. 避免過度設計

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

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

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

9. 退一步海闊天空

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

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

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

10. 真正的敏捷

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

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

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

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

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

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

一句話小結

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