《A Seat at the Table》作者访谈录
本文要點
\\- CIO(首席信息官)和IT領導者們必須重新定義他們的IT組織與其他企業之間的關系,只有這樣才能利用DevOps帶來的敏捷和開發周期的縮短。\\t
- 傳統的觀點認為,IT部門是“業務”的一個獨立承包商,這樣的觀點阻礙了公司通過敏捷實踐來獲得收益。\\t
- IT領導者不僅要對企業當前的IT能力集負責,還要對其IT資產的潛在價值負責——公司需要以一種敏捷的方式支持未來的需求。\\t
- 敏捷的IT環境中,在“項目”的粒度上做出投資決策不再有意義;基于項目,不能確定成功或失敗,也不能確定當前的狀態或進展。\\t
- IT領導者的作用是獲取業務的結果,而不是交付給它的需求,而這反過來又要求我們的思考方式進行深刻的改變,重新思考管理、風險、團隊結構以及IT部門與企業的其他部分之間的關系。\
在《A Seat at the Table》一書中,Mark Schwartz詮釋了傳統的CIO角色是如何與軟件開發的敏捷方法相沖突的。他在書中探討了在敏捷環境中IT領導人應該是什么樣的,他建議CIO應該為IT部門設立愿景,并且要對業務成果負責。
\\InfoQ的讀者們可以下載《A Seat at the Table》一書的書摘。
\\InfoQ采訪了Mark Schwartz,采訪的內容有:Schwartz是如何看待業務和IT的交互方式的,以及該如何改善它;怎樣的企業架構能夠交付業務價值;一個敏捷的管理模型是怎樣的;IT領導者所扮演的角色以及IT領導者該怎樣消除障礙;以及Schwartz對于未來CIO的一些建議。
\\InfoQ:是什么促使你寫了這本書呢?
\\\Mark Schwartz:當我開始寫我的第一本書《 The Art of Business Value》的時候,我意識到我所寫的其中一個話題值得花費更多的筆墨。那本書是關于商業價值的,內容包括商業價值真正的含義是什么,它在IT環境中經常被濫用的現狀,以及它是如何指導我們的IT實踐的。其中的一章是關于CIO在為IT項目進行定義和解釋其業務價值方面所扮演的角色。在我進行寫作的時候,我發現在CIO的角色中存在著一些根本性的沖突。
\\試想:敏捷實踐會讓開發團隊直接與業務代表(產品負責人或者現場客戶)進行合作以實現價值。在這種情況下,團隊是獨立自主的,團隊只需專注于滿足業務需求。如果是這樣的話,誰還會需要IT管理者和領導者呢?業務的利益相關者進行需求的定義,然后由團隊本身來實現這些需求。
\\這個場景存在錯誤,我想通過寫一本關于它的書來探究其中存在的問題。當我對這一問題進行探究的時候,它變得越來越有趣。探究的結果就是這本書:《A Seat at the Table:IT Leadership in the Age of Agility》。
\\\InfoQ:這本書的受眾有哪些呢?
\\\Schwartz:我認為,IT領導者需要重新定義他們與企業其他部門之間的關系,因此,這本書是給他們寫的:CIO們以及他們的領導團隊。該書為改善IT部門與企業其他部門之間的關系提供了實踐指導,并在IT戰略的制定中采用了敏捷和DevOps的概念。
\\第二部分受眾是廣大的敏捷和DevOps社區。敏捷主義者們不會過多的談論CIO和高級IT領導者,他們更傾向于關注團隊。他們總是在驅動組織進行轉換的話題中提到IT領導者,IT領導者通常是導致他們的組織采取敏捷的一個因素。但是,在這之后呢?
\\由于這是一本關于IT部門和企業其它部分之間關系的書,我認為對于那些想要更好地理解如何與IT部門來進行合作完成業務目標的IT領導和管理者來說,這將是一個非常有趣的話題。
\\\InfoQ:在這本書中,你提到了IT部門經常被視為一個被企業所控制的承包商。我們是如何陷入這種困境的呢?
\\\Schwartz:當信息技術首次進入商界時,它是令人恐懼的,而且似乎是不可預測的。能夠管理這項技術的人看起來有點奇怪(讓我們面對現實吧,事實的確如此)。因為商界人士對IT界的起因和影響知之甚少,他們開始認為IT界的人在擺弄那些沒有商業價值的東西,就像是在玩一種叫IT的玩具。當他們看到IT項目總是遲于預期并且超出預算的時候,它就更加加強了這一想法:很明顯是由于極客們在做那些對項目成功沒有貢獻的事情,才使得IT項目遲于預期很多。實際上,真正的原因可能是IT工作是在一個高度不確定的環境中完成的,但是原因并不明了。
\\因此,非IT行業的人覺得他們需要某種方式來“控制”IT項目,并研究了很多方法來實現這一目標。業務部門為IT部門準備了一系列的需求,要求IT部門給出一個定價,然后會以該價格進行交付。這難道不是你和承包商進行交易的流程嗎?并且,IT部門應該提供具有良好客戶服務——當然,所謂的客戶是企業中的非IT人員。之后業務部門建立起一個管理流程,確保IT部門一直在做所謂的正確的事情。我們經常會談到“IT和業務”,就好像它們是兩個分開的、毫不相干的事情一樣。所有這一切都與承包商模型一致。退后一步,好好想一想:除了IT部門,企業中還有誰需要巴結自己的同事,就好像同事是自己的顧客一樣?除了IT部門,還有誰會被同事給出“需求”,還需要按需求進行交付?
\\\InfoQ:是什么使得改變IT部門與業務部門的交互方式變得如此困難呢?
\\\Schwartz:有許多事情阻礙了變革。
\\首先,請注意,這個承包商模型與瀑布模型是完全一致的。業務部門把他們的需求丟到了墻上給IT部門看,IT部門就需要制定一個計劃然后堅持執行。因此,當我們試圖轉型至敏捷時,在某種程度上我們就破壞了已經建立起來的整個結構,一種對IT部門的功能進行完全控制的結構。非IT人員頭腦中浮現出的最明顯的問題就是:如果沒有了gantt圖(甘特圖),如果需求在不斷的變化,我們該如何掌控一個IT項目呢?如果我們不能衡量IT項目是否遵守了計劃、保持了預算,我們怎么才能知道它做的是好是壞呢?這些問題是正常的問題嗎?還是之前的控制為先的模型中所遺留的問題呢?
\\第二個問題是,我們還沒有完全拋掉那些老套的概念。老觀念認為:IT人員都是極客,他們不懂該如何用非技術語言來闡述事情,他們很可能會去用技術解決問題,而不是專注于業務本身;業務人員都是些毫無頭緒的人,都是些能說會道的人,他們經常提出一些不可能完成的要求,并且他們經常會設法繞過IT政策。然而根據我的經驗,大多數IT人員都對支持業務非常感興趣,盡管他們喜歡使用某項技術,但他們還是會找到更好的方法來滿足業務需求;大多數的業務人員也都是很有技術頭腦的。
\\第三個問題是,我們所建立的剛性流程(unyielding processes)和監督機制(oversight mechanisms )是基于那些老舊的模型的。但凡是在組織想要進行轉型的地方,你都能感受到這種情況的出現。各種組織政策、合規制度、限制政策、IT標準、批示流程以及嚴格的預算實踐。有許多糟粕被放在組織的管理中,放到了那些認為管理IT就是對它進行控制的地方。
\\\InfoQ:我們該如何才能將企業架構從阻礙開發的架構轉型為能夠交付業務價值的架構呢?
\\\Schwartz:我的觀點是,CIO需要為IT設置一個愿景,闡釋清楚IT將如何支持企業實現業務成果。每一個企業的愿景都是不同的。這才是我們真正應該稱之為企業架構(EA,Enterprise Architecture)的東西,盡管這個術語在過去已經有了一些不同的含義。當我在這個意義上使用這個詞的時候,我會認為如今的EA表示的是企業已經具備的一套技術能力,也包括它的潛在能力——是企業在應對未來的需求時變得敏捷的能力。在任何時間,EA都應該有一個理想的未來狀態,它是基于CIO對企業戰略目標的理解的。
\\如果當前的EA是靈活的,并且具備有支持敏捷轉型的潛在能力,那么遷移至未來的狀態就會變得更加容易,成本也會更低。如果你這樣想的話,EA方法的實踐就不再是關于約束的了——它是關于啟用未來狀態的。
\\我們該如何轉型至這種EA實踐呢?一種方式就是讓EA變成一種親力親為的、有創造力的規章。EA的實踐者實際上可以從軟件工程師和基礎架構工程師開始實踐,這些工程師和其他工程師是一樣的。他們開發的也許是參考架構(reference architectures),也許是可重用的組件。他們所做的也許是重構了其他開發人員的工作,使得該組件更易于重用。我想嘗試的一件事是建立EA內部的“開源”社區,大家可以在里面設立一個目標,然后有許多開發者可以為該目標作出貢獻。
\\\InfoQ:一個敏捷的管理模型是什么樣的呢?
\\\Schwartz:由于敏捷方法是經驗性的,并且它是基于審查和自適應的,敏捷治理也必須是這樣的。計劃一個大的項目,做大量的假設,給它一個綠燈,然后等待它被完成或者被取消,這樣做已經不再有意義了。相反,我們必須在前進的過程中進行學習,并把所有的項目計劃、投資承諾和需求看做臨時的,在項目開始之后逐漸進行調整。例如,我們基于一個功能會對用戶產生價值的假設創建了這個功能,在之后發現事實上并不是這樣,我們要做的應該是重新審視我們的計劃,審視我們還有哪些沒有必要構建的功能,或者用我們所學到的來想出一些新的有價值的功能。
\\仔細想想,管理總是會與瀑布方法聯系在一起。我們為一個項目制定計劃,根據該計劃作出投資決定,然后試著執行這個計劃,因為這是作出投資決定的基礎。但是現在在這個環節中出現了脫節,因為我們實際要執行這個項目的方式是敏捷的,它會經常變化。此外,通過使用DevOps,我們可以非常頻繁地發布產品,然后從使用記錄中獲取有用的信息。在傳統的管理模型中,這部分信息并不能用于改進投資決策,因為我們的計劃早已制定完成。
\\\InfoQ:你在書中提到“對于IT系統來說,失敗是可以接受的。”你對此有何看法?
\\\Schwartz:使得我作出這一評論的原因是,我從業務部門領導那里聽到了這樣的話:“為什么能容許IT部門引入這些對業務有害的軟件錯誤呢?任何人都可能因為制造了這樣的混亂而被解雇。”這個問題讓我意識到,我們確實堅持認為,我們的其他部門從IT部門接受了許多他們稱之為“錯誤”的東西:系統宕機、硬件錯誤、安裝后使得系統不正常工作的補丁。IT人員會認為他們的工作做得非常棒,因為他們能夠對這些問題進行快速相應,并且展現出了他們高超的調試程序的技巧。但是企業的其他部門可能不是這么認為的。
\\我不是說我們能夠完全改變這種現狀,不確定性往往是我們工作中非常大的一個因素,并且意想不到的事情往往會導致出錯。但我認為,我們可以從一開始就在頭腦里建立起要構建高質量軟件的策略,通過編寫好的測試和立即解決問題、通過建立冗余來達成這一策略——你可能會說,還要建立良好的衛生習慣。
\\\InfoQ:IT領導的角色在敏捷和精益的世界中該如何表現呢?
\\\Schwartz: IT領導是負責業務成果的。我們總是這么說,但是同時又把IT部門看做是一個承包商,為“業務”提供產品和服務,然后從中獲取業務成果。IT部門總是潛藏于“在我開始做之前,你首先要告訴我需求”或者是“我們只是交付了需求中所要求的產品,所以它不好用不是我們的錯”這樣的說法背后。這不是真正意義上的關注于成果。
\\對此產生改變的是,通過使用DevOps、云服務等等,IT領導者可以更容易地參與到同企業其它部門的學習之旅中,嘗試做出假設、不斷改進想法、度量交付的價值以及貢獻創新的業務理念。現在,IT就能夠真正的做到為業務成果負責。
\\但是這并不意味著IT在孵化成果方面扮演著一個通用的角色。就像是CFO帶來了金融知識、CMO帶來了市場營銷的想法一樣,CIO們必須要把技術專長以及技術觀點帶到企業中來。CIO們需要通過深厚的專業技術視角來審視業務戰略決策。并且他們需要額外關注于目前所構建的技術架構的長期影響——當前的技術架構能否促進未來的敏捷性或創新呢?
\\\InfoQ:IT領導者們能做些什么來消除障礙呢?
\\\Schwartz:我注意到有一件事情很有意思:雖然發號施令(command-and-control)的領導方式在敏捷環境中并不那么有效,但是它常常能夠很好地消除障礙。我的確是有點在開玩笑,但是事實擺在我們面前,我們需要消除障礙,有時我們需要抓住一切對我們有用的東西。障礙的出現通常是有原因的——它們出現在一些地方的時候,它們能夠滿足一些需求。為了消除一個障礙,IT領導者必須首先要找出目標(intent)是什么,然后決定這個目標是否仍然有效,如果是它仍然有效,那么就要找出有什么更好的、更精簡的方法來實現這個目標。
\\我看到過各種各樣的障礙:限制條款、公司政策、現金流的限制、網絡問題、關鍵的審批人不在辦公室、丟失的文件,你能想到的全都會有。一個領導者必須要利用自己的創造力,找出該如何消除這些障礙,這樣才能保證團隊不會在一個沮喪的情況下繼續工作。
\\\InfoQ:你對未來的CIO有什么建議嗎?
\\\Schwartz:最重要的建議就是要有勇氣。這聽起來可能有些老套,但是我的意思是:IT領導者必要要意識到,我們所做的工作有很大的不確定性,即便是你做出了正確的決定仍然有可能會導致錯誤的結果。但是不論如何你都要做出正確的決定。為了讓你們員工們充分發揮他們的才能,你必須要替他們承擔風險。這需要勇氣。最后,我的建議是,對于IT領導者來說,與其在桌子邊等著不如直接去拿,直接對業務成果進行問責,而不是僅僅為其他業務部門提供良好的客戶服務或者是僅僅交付業務部門所要求的“業務需求”。如果有必要,請微笑著把另一把椅子也拉到桌上來。
\\\關于作者
\\Mark Schwartz?目前是Amazon Web Services(AWS)的企業戰略家,他與各大企業合作,幫助他們從云計算中獲取最大的受益。他上次的CIO角色是作為美國公民及移民服務局(US Citizenship and Immigration Services)的CIO,他領導了一次大規模的變革,向DevOps實踐、云計算以及以客戶為中心的設計方式進行轉型。Schwartz拿到了耶魯大學計算機科學以及哲學的碩士學位,他還拿到了沃頓商學院的MBA學位。他同時還是《The Art of Business Value》和A Seat at the Table: IT Leadership in the Age of Agility的作者。
\\查看英文原文:Q\u0026amp;A on the Book \"A Seat at the Table\"
總結
以上是生活随笔為你收集整理的《A Seat at the Table》作者访谈录的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: html5 弹性布局
- 下一篇: Codeforces Round #45