在goto柏林2015大會上，skyscanner工程部高階副總裁bryan dove談了如何從組織內部開始改變，開發者和管理者如何協作來了解和採用現代軟體工程實踐。\
infoq就過去10年中主要技術的發展以及它們對我們建立軟體產品的方式的影響採訪了他。infoq還問了這樣的問題，就是管理者和開發者可以做些什麼來探索和發現更好的協作方式，他們如何互相支援，讓自己和企業取得更大的成功。\
infoq：在過去的10裡，我們看到的新技術發展主要有哪些？\
\\dove：過去的10年見證了技術商品化的巨大進步，以前，只有世界上最大的軟體公司才擁有這樣的技術。這種商品化讓新公司更容易快速交付價值，以及擁有可以輕鬆擴充套件到消費網際網路需求規模的技術，而且成本更低。今天，一家全新創業公司所依賴的軟體棧，其中的幾乎每個元件在過去的10年中都已經建立了出來，而且是作為開源專案。hadoop/mapreduce是受google的map-reduce**所啟發，然後是yahoo的實現及後續的開源。nosql引擎是受amazon的dynamo**所啟發，例如，由facebook構建和開源的cassandra。還有其他常見的構建塊，如docker、mesos、mongodb等等。所有這些都是在過去10年中建立和發布的，已經將建立和擴充套件技術平台的工作量降低了乙個數量級，甚至更多。\
除了軟體外，我們還見證了公有雲的出現，這始於2023年推出的aws。這種巨大的變化已經將規模經濟帶給了大眾，隨著向公有雲硬體經濟的轉型，資本部署已經從昂貴的資料中心和硬體轉移，幾乎全部集中到了員工身上，用以資助ip建立和支付。
infoq：這些發展對我們建立軟體產品的方式有什麼影響？\
\\dove：類似於我上面提到的，基本的影響是建立為客戶提供價值的產品比以往任何時候都更簡單更快捷。以前，公司需要從頭開始構建所有技術，而從頭開始針對網際網路規模進行構建真得很困難。今天，任何公司都可以選取一整套開源技術，以最小的努力實現龐大的規模。在skyscanner，我是工程部的高階副總裁，我們為創業公司提供了api的免費入門版本，在github.com/skyscanner上開源了多個內部專案，我們內部也使用了多項開源技術。
infoq：您在演講中舉了乙個例子，您做了一些很棒的工作，但沒有告訴管理者。您能詳細描述下發生了什麼嗎？您學到了什麼？\
\\dove：我提到的場景是這樣的，我正在做一些我認為對公司最有利的工作。在微軟工作的時候，我同sql server領導團隊建立了內部合作關係，共同構建一些新的分析軟體，用於消費網際網路規模的大資料系統。我覺得自己正在做的工作，對於團隊、我的業務和公司而言都是正確的。\
我犯的錯誤是，我沒有考慮我將管理者置於了怎樣的位置。他們不知道有關進展或同sql領導團隊的合作關係的細節，因為這是由我直接管理的。這讓他們面臨著乙個風險，就是有人可能會問他們，我們的業務如何協同，而他們並不了解細節。\
關於經驗教訓，我得出了兩個重要的結論，它們影響了我此後的思維。一是選擇了過度溝通和徹底透明。以前，我在我的團隊裡這樣做了，但現在，我在組織裡所有的方向（例如，管理者、同事、團隊）上都以這種方式操作。二是我現在在簡化同同事和管理者的溝通上投入了更多的精力。由於我的同事和管理者每天都會從許多資料來源收到大量的資訊，我設法為他們提供關鍵事項的小標題，然後期待他們問更多資訊，如果他們想的話。如果他們詢問所有細節，我當然會分享，但我會等著他們問，而不是預先就同他們分享，以此幫助他們首先專注於關鍵事項。如果你為人們提供了標題、結論和建議，那麼他們總會詢問更多的細節，如果他們需要的話。在skyscanner，我們使用「訊息片段（snippet）」機制來分享資訊，以防止資訊過量。
infoq：您展示了開發者如何建立乙個管理者待辦事項列表，他們可以將希望管理者幫忙的事項列在上面。您能舉幾個在您待辦事項列表上的事項作為例子嗎？您的管理者是如何幫助您的？\
\\
infoq：管理者如何幫助開發者更好地工作？\
\\dove：我認為，作為一名管理者，你對工程團隊的職責是圍繞少數幾個原則展開的。首先，我發現daniel pink的著作《驅動力》中的三個原則非常適合工程師——自主、專精、目的。我幾乎每天都會考慮這三個原則，挑戰自我，向團隊授予更多的許可權，讓他們有更大的自主權，而不是最初那種可能讓我感覺舒適的程度。在我看來，分布式自主是擴充套件大型團隊最重要的因素，這也是skyscanner所重視的東西。\
下乙個原則是徹底透明。關於分布式自主，其中乙個常見的、讓人糾結的邏輯是，擔心個體無法作出正確的決定。開始的時候要相信，我團隊中的每個人都是聰明、能幹、理智的，然後我的工作就是為他們提供他們需要的所有資訊，讓他們能夠作出對企業而言最好的決定。任何擔心某個人不能作出正確決定的跡象都應該立即引發這樣一種想法，就是我沒有向他們提供足夠的資訊，讓他們能夠作出最好的決定。我個人傾向於徹底透明（比如，分享一切，只要它不是違法的，而且是我分享的資訊），因為這樣，我就可以少做一些用於篩選同團隊分享的資訊的決定。現在，我的團隊擁有了同我一樣的情境，處於一種更有利的位置，不需要請求批准就可以作出對企業而言最好的決定。\
再下乙個原則是了解細節及複雜性。工程師需要相信，他們的管理者了解他們正在做什麼，並且了解那有多難。花費時間和精力獲取這種知識讓管理者能更好地掌握團隊中正在發生的事情，同他們的工程師建立信任關係，讓他們相信管理者完全能夠恰當地評價他們的貢獻。\
最後乙個我認為對管理著至關重要的原則是公開錯誤。我們從失敗中學到的東西遠比從成功中學到的多，這已被人們反覆引用重申。不過，作為一名領導者，你需要創造乙個環境，人們歡迎錯誤，將其視為學習機會，而不是應該譴責的東西。關於這件事，我發現了一項特別有用的技術，就是把乙個我在領導者崗位上所犯的錯誤，盡最大可能公開地向我的團隊描述。然後每次我犯了錯誤都會重複這樣做。作為一名領導者，暴露那種程度的弱點需要很大的勇氣，但是如果你不願意這樣做，你怎麼能期望你的團隊那樣做？通常，我要麼會通過郵件更新、部落格來做，要麼會在職工會議上討論它，分享我犯的錯誤，為什麼那是乙個錯誤，我學到了什麼，以及我會做什麼來避免再次犯同樣的錯誤。通過這樣一次又一次的反覆做，強化了這樣乙個概念，錯誤正是學習的機會，有弱點，犯錯誤，並從中學習，不用為此不安。\
在skyscanner，我們有辨別失敗並在整個企業內分享經驗教訓的程式。這幫助我們建立了一種公司文化，對於什麼有效、什麼無效、如何從錯誤中學習並進一步推進，我們持開放和誠實的態度。我們將這稱為「反敗為勝」，這個概念基於這樣一種理念，就是沒有錯誤就無法學習，因此就無法進步。這種失敗理念可能會讓一些人不舒服——更不用說在真正遭遇失敗時分享經驗。不過，在skyscanner，我們相信，我們需要接受失敗，如果我們想繼續取得成功。這樣的失敗案例為我們提供了重要的經驗教訓，讓我們距離成功更近了一步；它們是影響重大決策的風險、測試和試驗的結果，進一步推動我們走向成功。
infoq：開發者能做些什麼幫助他們的老闆取得成功？那如何幫到他們自己？\
\dove：為了幫助他們的老闆取得成功，工程師有幾件可以做的事。首先，了解老闆的目標很重要。就像你作為工程師有目標一樣，你的老闆有一系列衡量其工作的目標。其次，願意分享榮譽。harry truman說過，「如果你不在乎誰獲得榮譽，那麼你獲得的成就會讓你吃驚」，當你是團隊的一部分時，尤其如此。如果你關注你已經交付了什麼以及為使用者帶去的價值，那麼誰獲得榮譽就不重要了。乙個將這些內容記在心裡的工程師可以通過這樣的方式幫助他的老闆，比如將工程師新構建的東西的細節給老闆講解，讓他們的老闆在公開場合做演示文稿，或者傳送他們的郵件。他們的管理者因為向企業交付了同他們的目標一致的價值而獲得認可，而團隊作為乙個整體就可以慶祝成功了。\
在skyscanner，我們使用「目標和主要成果（objectives and key results，縮寫為okr）」流程來確保我們的目標在整個公司內都是一致的，並以公司內任何人都容易發現的方式發布出來。這很重要，可以確保整個公司內正在開展的工作保持完全透明。
bryan dove是skyscanner的高階副總裁。他的職責是在全球十個規模正在加速增長的辦事處中領導並推動skyscanner工程團隊的發展。bryan為skyscanner帶去了超過15年的工程領導經驗。在加入skyscanner之前，bryan是amazon web service s3的工程部總監，他在那裡領導團隊推出了多個面向客戶的新特性，包括s3事件通知和s3跨區域複製。再之前，bryan在微軟擔任多個角色，作為skype資料工程的負責人，他建立並領導了乙個全球分布式團隊，構建skype的實時大資料架構。
\檢視英文原文：change from within: developers and managers working together
改變從內部開始 開發者與管理者的協作
在goto柏林2015大會上，skyscanner工程部高階副總裁bryan dove談了如何從組織內部開始改變，開發者和管理者如何協作來了解和採用現代軟體工程實踐。infoq就過去10年中主要技術的發展以及它們對我們建立軟體產品的方式的影響採訪了他。infoq還問了這樣的問題，就是管理者和開發者可...
改變從內部開始 開發者與管理者的協作
在goto柏林2015大會上，skyscanner工程部高階副總裁bryan dove談了如何從組織內部開始改變，開發者和管理者如何協作來了解和採用現代軟體工程實踐。infoq就過去10年中主要技術的發展以及它們對我們建立軟體產品的方式的影響採訪了他。infoq還問了這樣的問題，就是管理者和開發者可...
做為管理者認知的改變
開發tyc負責一單11月版需求，臨近提測時間，他反饋有很重要的功能沒有開發，導致臨時把工作分給其他開發，其他開發趕工寫出來的 質量不佳，可能有冒煙不通過的風險。lxj的反應不是指責tcy，而是考慮以後怎麼盡量避免出現這種情況，想到要求每個開發每天匯報 今天做了什麼工作，明天打算做什麼工作，提前發現風...