組織敏捷性 意味着組織能夠快速和敏捷地對內部問題、外部威脅和不斷變化的客戶需求作出反應。最高管理層喜歡這個術語，因爲它使組織聽起來很時髦，並且能夠處理其發展方向中遇到的所有事情。您也許聽過 CEO 或組織中的其他最高級管理人員做過有關敏捷性的激動人心的演講。他們可能談到公司如何爲充滿競爭的行業中出現的所有情況做好了準備。“我們爲將來做好了準備！”“我們將全力以赴，以求在競爭中制勝！”“我們公司有最優秀的員工！”
這聽起來非常不錯，尤其是在它出自最高管理層之口的時候。您可能對這些宣傳信以爲真，並開始在考慮到敏捷性的情況下着手設計和規劃。這並不容易，因爲最敏捷的體系結構方法被認爲是脆弱的，或者與在企業環境中交付價值的能力不相干。
在該過程中的某個階段，您也許會開始產生一些挑剔的疑問。也許使公司可以快速開始、停止和轉向的新企業設計遭到質疑，因爲管理層沒有“馬上看到對該設計的需要”。也許您遭遇到管理鏈中這樣的人，他們無休止地詢問更多詳細信息，卻假裝擁有所不具備的能力。也許從來不允許您與業務單位交談，因爲管理層更喜歡處理那些交流。
不可對這些疑問等閒視之。聽他們講吧，直覺正在告訴您，儘管組織可能談到敏捷性的話題，卻並沒有往敏捷性的方向走。要有效地爲組織進行設計，您需要獲得組織中某種級別的信任。準確瞭解組織關於敏捷性的立場，可以幫助您在下一個項目過程中節省寶貴的時間和精力。如果發現組織不如應有的那樣敏捷，本文中的技巧可以幫助您扭轉這種局面。
缺乏敏捷性的最先預測指標之一是架構師在組織食物鏈中的位置。環顧四周：您是否參與了有關項目預算、優先順序、資源和項目選擇的決策過程？現在或曾經是否有任何人詢問過您有關應該實現某個項目的意見？
如果您對上述所有問題都作否定回答，那麼您可能處於組織食物鏈的最底層。情況很可能是狼羣在您四周環繞，只留下殘渣碎片等您去處理和實現。
作爲架構師，您需要成爲狼羣中的一員。您的知識和專業經驗應該得到重視和發掘，而不是去做其他所有人的掃尾工作。如果認爲自己處於組織食物鏈的最底層，您需要開始改善自己在組織中的地位。也許這意味着在會議期間大膽陳述，或更積極地參與高端組織團隊，這些團隊與體系結構關係甚少，但是與組織的政策休慼相關。要點在於，您需要提高自己的姿態，以便在考慮組織變更時，體系結構成爲其他人首先 想到的事情。
每個項目都有參與者。每個人都想成爲英雄，並且都想創造將在組織中帶來積極影響的神話。如果您始終處於這些參與者的前列，就可以與他們構建友善關係，這種關係將確保他們在下次考慮某個變更時想到您。如果您處於食物鏈的最底層，就只能是事後諸葛亮，情況就太糟糕了，因爲這樣會使組織的敏捷性大打折扣。
組織中的項目是如何分配的？您是否在團隊中工作？如果是，那就太好了。團隊協作是強有力的敏捷性預測指標，因爲它促進了多個人協作，並且使組織可以發現和實現最有可能的想法。如果項目通常是分配給個人，則您所看到的組織就不如應有的那樣敏捷。
這並不是說您沒有非常好的想法。但是當人們單獨工作時，很容易陷入交流的真空中。單獨一個人，您只有自己的想法。在團隊環境中，您有自己的想法加上其他每個人的想法。只需傾聽其他人所具有的不同體驗，即可集思廣益並激發創新的火花。
如果組織不相信團隊協作，則應該在下一個項目上使用該概念逐步說服管理層。務必小心對待，因爲如果管理層以爲您是在請求幫助，就可能會認爲您很脆弱且無法處理該項目。應該從以下角度逐步表達您的想法：爲了最大化參與者價值，您希望嘗試一種協作方法，即在項目的初始自由討論階段涉及架構師、業務參與者、IT 操作和支持人員，以及其他人員。闡明這種方法應該有助於您更好了解項目的目標、約束和要求。
這種方法使您至少可以獲得部分團隊協作好處，並將您直接置於前面提到的狼羣前面。至少有一些參與者會感激您對他們的特定需要的興趣，並在後面出現其他項目時想起您。
您上次與業務單位聯繫人面談是在什麼時候？我的意思是說，真正 坐下來並與他們討論其需要、他們的將來預期，以及他們爲了使業務更高效地運作所希望看到的更改？
如果上個月還沒有與業務單位會過面，您就沒有幫助組織保持敏捷。在實現幫助之前等待業務單位的認可，這並不是真正的敏捷。要保持敏捷，組織必須不斷地向上、向下和橫向更改。通過與業務單位聯繫人會面，您可以更好地確定變更可能會在何時發生，以及將會需要多大程度的更改。
當您失去警惕的時候，就很難以受控的方式作出更改。相反，您被迫對情況作出反應，並疲命於糾正突然的更改所導致的問題。即使您目前正在進行設計和構建，與業務單位進行定期、一致的聯繫也會幫助您密切關注將來。
交流是任何敏捷組織中的主要力量。它可以促進敏捷性，因爲它存在真正的彈性，讓人們更緊密地彼此協作，並整合了來自整個組織中的新想法和信息。但是，存在一個常見的誤解，以爲組織中的文檔越多，交流效果就越好。（請原諒我歇斯底里地嘲笑這種想法。）我曾經在存在這種概念的組織中工作過，儘管文檔可能是實現交流的很好手段，但它遠遠不是真正的交流過程。您可以爲希望的所有事物編制文檔，但是如果沒有人閱讀或理解該文檔，就不存在交流了。
僅當兩方或更多方交換信息並且 各方可以彼此交互以達到對所涉及主題的相互理解時，纔會實現真正的交流。這是一項通過學習得來的技能。人類通過口頭或書面語言、歌唱、眼睛接觸、觸摸、手語和身體語言進行交流。甚至動物也以非口頭的方式進行交流。
因此，簡單的文檔編制行爲並不意味着您在與任何人交流。您只是在爲流程或其他主題編制文檔，以便在以後出現問題時可以參考該文檔。文檔是參考資料或教程，而不是某種形式的交互式交流。它只提供很少或沒有提供對話機會，以便消除誤解或讓人們辯論文檔中的內容。如果組織大量依賴文檔，這是它輕視敏捷性的很好跡象。真正的敏捷性需要整個組織中不斷的交流。
只是因爲其他人認爲文檔可以取代良好的舊式雙向交流並不意味着您需要這樣做。要改進組織中的敏捷性，應該集中於客戶的要求，並以他們能夠理解的語言與他們交談。有關如何在組織中有效地交流的更多信息，請參閱 Obtain approval for your process change recommendations。
您是否注意到許多公司的組織圖表充滿雜亂的虛線？例如，您可能要正式地向 Joe 報告，但您在組織圖表中可能還有指向 Greg、Sandra 和 Vasundhara 的虛線。Joe 處理您的年度審覈，但除此之外，除了接收新任務，您很少看到他或與他交談。您每天更緊密地與其他三個人一起工作。在敏捷性不是管理層的最優先考慮事項的組織中，這種虛線類型的報告系統非常典型。
此類報告過程迫使人們至少間接地向多個人報告。在上述示例中，您要向四個人報告。那樣如何能敏捷呢？您受到不同方向的牽引，各個方向具有不同的目標和各不相同的管理風格及預期。您也許讓其中一方滿意，卻不斷地惹惱另一方，因爲您的表現不符合他們的規定。
當組織認爲一個角色等同於一個人時，此類報告非常普遍。他們預期架構師爲組織需要的所有一切完成設計。您可能是個天下難找的優秀架構師，但是很難在所有事情方面滿足所有人的需要。如果您正在組織中體驗到這種情況，這是最難扭轉的局面之一，因爲如果您抱怨或建議採用新方法，他們就以爲您不能勝任多重任務或學習新的技能。
在此情況下，應該與您要向其報告的每個人（無論在組織圖表中是否帶虛線）坐下來面談，並闡明各自的預期。這可以幫助您確定是否一個人（舉例而言）預期要佔用您一半的時間，以及另外三個人是否也做同樣的預期。預先建立有關時間限制的邊界，要遠勝於嘗試處理所有事情卻誰也無法滿足。在初始會談之後，儘量至少每月與各方會談一次。越多的人瞭解您在做什麼和各自項目部分的進展情況，您就越有機會讓所有各方都滿意。要改變組織中的此類糟糕的敏捷性是極其困難的，因此要保護您自己，並保留有關您的時間都花在何處的書面文檔。
中國古代哲學家老子的諺語已翻譯成多種版本。其中一個版本“軟件架構師之道 (The Tao of the Software Architect)”提供了有關敏捷性概念的啓蒙思想。下面摘錄其中一段（建議您閱讀完整的翻譯版本（請參見參考資料））：“真的旅行者沒有固定的計劃，沒有意向中的目的地。真的藝術家讓直覺自由指引他的創作。真的科學家不拘泥於概念，而讓思維面對事實。因而，架構師普度衆生，不拒絕任何人。他準備利用所有解決方案，而不浪費任何既有成果。”
 |
|
當您考慮自己的組織是否真正敏捷或者只是討論敏捷性時，要讓自己的思維保持開放以成爲敏捷性的化身。結果是您也許會教會組織中的其他人明白一兩個道理。