提姆·利斯特 - 書籍合著者
- 「人的因素。 成功的專案與團隊》（原書名為《Peopleware》）
- “與熊跳華爾滋：管理軟體專案的風險”
- 「腎上腺素瘋狂，模式殭屍化。 專案團隊行為模式"
所有這些書都是各自領域的經典著作，都是與同事共同撰寫的 。 在俄羅斯，他的同事最有名—— и ，他也寫下了許多著名的作品。
Tim 擁有 40 年的軟體開發經驗；1975 年（寫這篇 habrapost 的人都不是今年出生的），Tim 已經是 Yourdon Inc. 的執行副總裁。 他現在把時間花在諮商、教學和寫作上，偶爾也會去拜訪 世界各地的會議。
我們專門針對哈布爾採訪了提姆·利斯特。 他將為 DevOops 2019 大會開幕，我們有很多關於書籍等的問題。 採訪由會議議程委員會的 Mikhail Druzhinin 和 Oleg Chirukhin 主持。
邁克爾： 能簡單介紹一下您現在正在做的事情嗎？
提姆： 我是大西洋系統協會的會長。 我們公會有六個人，我們稱自己為校長。 三個在美國，三個在歐洲 - 這就是該行會被稱為“大西洋”的原因。 我們在一起已經很多年了，你無法數算。 我們都有自己的專長。 過去十年或更長時間我一直與客戶合作。 我的專案不僅包括管理，還包括需求設定、專案規劃和評估。 似乎開始不佳的項目通常結局不佳。 因此，值得確保所有活動都經過深思熟慮和協調，將創作者的想法結合起來。 值得思考一下你在做什麼以及為什麼這樣做。 使用什麼策略來完成專案。
多年來，我一直以各種方式為客戶提供諮詢。 一個有趣的例子是一家製造膝蓋和臀部手術機器人的公司。 外科醫生並不是完全獨立操作，而是使用機器人。 坦白說，這裡的安全很重要。 但是當你嘗試與專注於解決問題的人討論需求時......這聽起來很奇怪，但在美國有 （聯邦藥物管理局），該機構對這些機器人等產品進行許可。 在出售任何東西並將其用於活人之前，您需要獲得許可證。 條件之一是展示您的要求、測試是什麼、您如何測試它們、測試結果是什麼。 如果你改變了需求，那麼你需要一次又一次地經歷整個龐大的測試過程。 我們的客戶設法將應用程式的視覺設計納入他們的需求中。 他們直接將螢幕截圖作為要求的一部分。 我們必須把它們拿出來並解釋說，在大多數情況下，所有這些程序對膝蓋和臀部以及所有這些與相機相關的東西一無所知。 我們需要重寫需求文檔，使它們永遠不會改變，除非一些非常重要的基礎條件改變。 如果視覺設計不在要求之內，產品的更新會快很多。 我們的工作是找到那些涉及膝蓋、臀部、背部手術的元素，將它們提取到單獨的文件中，並說這些將是基本要求。 讓我們提出一組關於膝蓋手術的獨立要求。 這將使我們能夠建立一組更穩定的需求。 我們將討論整個產品線，而不是特定的機器人。
做了很多工作，但他們仍然到達了以前花費數周和數月重複測試的地方，但沒有意義或沒有必要，因為紙上描述的要求與構建系統的實際要求不符。 FDA每次都告訴他們：你們的要求已經改變，現在你們需要從頭開始檢查一切。 對整個產品的全面重新檢查正在扼殺企業。
所以，當你發現自己正處於某件有趣的事情的開始時，就會有如此美妙的任務，而第一個行動就設定了遊戲的進一步規則。 如果您確保這項早期活動從管理和技術的角度來看都開始順利進行，那麼您就有可能最終完成一個出色的專案。 但如果這部分偏離了軌道，出了問題，如果你找不到基本的協議……不，這並不是說你的專案一定會失敗。 但你將不再能夠說：“我們做得很好，我們所做的一切都非常有效。” 這些都是我在與客戶溝通時所做的事情。
邁克爾： 也就是說，您啟動項目，進行某種啟動並檢查軌道是否朝著正確的方向前進？
提姆： 我們也對如何將拼圖的所有部分放在一起有想法：我們需要什麼技能，何時需要它們，團隊的核心是什麼樣的以及其他類似的基本事情。 我們需要全職員工還是可以僱用兼職員工？ 規劃、管理。 諸如此類的問題：對於這個特定項目來說最重要的是什麼？ 如何實現這項目標？ 我們對這個產品或專案了解多少，有哪些風險以及未知因素在哪裡，我們將如何應對所有這些？ 當然，這時候有人開始喊“敏捷呢？！” 好吧，你們都很靈活，但那又怎樣呢？ 這個項目到底是什麼樣的，你將如何以適合該項目的方式把它拿出來？ 你不能只是說“我們的方法適用於任何事情，我們是一個 Scrum 團隊！” 這是無稽之談和無稽之談。 接下來你要去哪裡，為什麼它會起作用，重點在哪裡？ 我教我的客戶思考所有這些問題。
19年敏捷
邁克爾： 在敏捷中，人們常常試著不事先定義任何東西，而是盡可能晚地做出決定，說：我們太大了，我不會考慮整體架構。 我不會考慮很多其他事情；相反，我會立即向客戶提供有用的東西。
提姆： 我認為敏捷方法論首先是 2001年，讓業界大開眼界。 但另一方面，沒有什麼是完美的。 我完全支持迭代開發。 迭代在大多數專案中都很有意義。 但你需要考慮的問題是：產品一旦推出並投入使用，能持續多久？ 該產品是否可以使用六個月後被其他產品取代？ 或者說這是一款可以使用很多很多年的產品？ 當然，我不會點名，但是…在紐約及其金融界，最基本的系統非常古老。 這真太了不起了。 你看著它們，心想，如果你能回到 1994 年，告訴開發者：「我來自未來，來自 2019 年。 只要您需要，就可以開發這個系統。 使其可擴展，考慮架構。 然後它將在二十五年以上的時間內得到改進。 如果你再推遲一點開發時間，從大局來看就沒有人會注意到了！” 當您對長期的事情進行估計時，您需要考慮總共要花多少錢。 有時精心設計的架構確實值得，有時則不然。 我們需要環顧四周並捫心自問：我們的處境是否適合做出這樣的決定？
所以像「我們支持敏捷，客戶自己會告訴我們他想要什麼」這樣的想法——這是非常天真的。 顧客甚至不知道自己想要什麼，更不知道自己能得到什麼。 有人會開始引用歷史例子來論證，我已經看到了這一點。 但技術先進的人通常不會這麼說。 他們說：“現在是 2019 年了，這些都是我們擁有的機會，我們可以徹底改變我們看待這些事情的方式！” 有時您需要走出去並說：「讓我們徹底重新發明我們在這裡嘗試做的事情！」而不是模仿現有的解決方案，使它們更漂亮、更梳理。
我認為大多數客戶都不會這樣思考問題。 他們只看到自己已經擁有的東西，僅此而已。 之後，他們會提出諸如「讓我們把事情變得簡單一點」之類的請求，或者他們通常說的任何話。 但我們不是服務員，所以無論結果多麼愚蠢，我們都可以接受訂單，然後在廚房烘烤。 我們是他們的嚮導。 我們必須睜開眼睛說：嘿，我們這裡有新的機會！ 您是否意識到我們真的可以改變您這部分業務的完成方式？ 敏捷的問題之一是它消除了人們對什麼是機會、什麼是問題、我們甚至需要做什麼、什麼可用技術最適合這種特定情況的認識。
也許我在這裡過於懷疑：敏捷社群中發生了很多美妙的事情。 但我有一個問題，人們沒有定義一個項目，而是開始舉手。 我想在這裡問──我們在做什麼，我們要怎麼做？ 不知何故，神奇的是，客戶總是比任何人都更了解。 但只有當客戶從某人已經建造的東西中進行選擇時，他才最了解。 如果我想買一輛車，並且知道我的家庭預算有多少，那麼我很快就會選擇一輛適合我生活方式的車。 在這裡我比任何人都清楚！ 但請注意，有人已經製造了汽車。 我不知道如何發明新車，我不是專家。 當我們創建定製或特殊產品時，必須考慮客戶的聲音，但這不再是唯一的聲音。
奧列格： 您提到了敏捷宣言。 我們是否需要考慮到對這個問題的現代理解來以某種方式更新或修改它？
提姆： 我不會碰他。 我認為這是一份很棒的歷史文獻。 我的意思是，他就是他。 他已經19歲了，他已經老了，但在他的時代，他做出了一場革命。 他做得很好的是，他引發了反應，人們開始竊竊私語他。 2001年的時候，你很可能還沒有進入這個行業，但那時每個人都按照流程工作。 軟體工程學院，軟體完整性模型（CMMI）的五個等級。 我不知道這些古老的傳說是否告訴你一些事情，但這是一個突破。 起初，人們相信，如果流程設定正確，那麼問題就會自行消失。 然後宣言出現並說道：“不，不，不——我們將以人為本，而不是流程。” 我們是軟體開發大師。 我們知道，理想的過程只是海市蜃樓；它不會發生。 專案中有太多的特質，為所有專案提供完美流程的想法沒有任何意義。 問題太複雜了，不能聲稱所有問題都只有一種解決方案（你好，涅槃）。
我不想展望未來，但我想說，人們現在已經開始更多地思考專案。 我認為敏捷宣言非常擅長跳出來說：「嘿！ 你在一艘船上，而你自己正在駕駛這艘船。 您必須做出決定 - 我們不會建議適用於所有情況的通用配方。 你是這艘船的船員，如果你夠好，你就能找到到達目標的方法。 在你之前有其他船隻，在你之後還會有其他船隻，但從某種意義上說，你的旅程仍然是獨一無二的。” 類似這樣的事情！ 這是一種思考方式。 對我來說，太陽底下沒有什麼新鮮事，人們曾經航行過，還會再次航行，但對你來說，這是你的主要旅程，我不會告訴你到底會發生什麼。 你必須具備團隊協調工作的能力，如果你真的具備了，一切都會順利，你就會達到你想要的目標。
人件：30年後
奧列格： Peopleware 是否和《宣言》一樣是一場革命？
提姆： Peopleware...湯姆和我寫了這本書，但我們沒想到會發生這樣的事情。 不知怎的，它引起了許多人的想法的共鳴。 這是第一本書說：軟體開發是一項非常人力密集的活動。 儘管我們具有技術性質，但我們也是一個由人們組成的社區，他們正在建立一些大型的、甚至巨大的、非常複雜的東西。 沒有人能夠獨自創造出這樣的東西，對嗎？ 所以「團隊」的理念就變得非常重要。 不僅從管理的角度來看，對於技術人員也是如此，他們聚集在一起解決具有一堆未知數的真正複雜的深層問題。 對我個人來說，這是對我職業生涯中智力的巨大考驗。 在這裡你需要能夠說：是的，這個問題超出了我自己的處理能力，但我們可以一起找到一個讓我們感到自豪的優雅解決方案。 我認為這個想法最能引起共鳴。 我們的想法是，我們一部分時間獨自工作，一部分時間作為團隊的一部分，通常由團隊做出決定。 小組解決問題已迅速成為複雜專案的重要特徵。
儘管 Tim 發表了大量演講，但在 YouTube 上發布的演講卻很少。 你可以看一下2007年的報告《人民軟體的回歸》。 當然，品質還有很多不足之處。
邁克爾： 自從這本書出版以來，過去 30 年有什麼改變嗎？
提姆： 你可以從很多不同的角度來看這個問題。 從社會學角度來說…曾幾何時，在更簡單的時代，你和你的團隊坐在同一個辦公室裡。 你們可以每天都很親密，一起喝咖啡，討論工作。 真正改變的是，團隊現在可以分佈在不同的國家和時區，但他們仍然在解決相同的問題，這增加了全新的複雜性。 這聽起來可能很老派，但是沒有什麼比面對面的交流更好的了，大家在一起，一起工作，你可以走到同事面前說，看看我發現了什麼，你喜歡這個嗎？ 面對面的對話提供了一種過渡到非正式溝通的快速方式，我認為敏捷愛好者也應該喜歡它。 我也很擔心，因為實際上世界已經變得非常小，現在都被分散式團隊覆蓋了，而且都非常複雜。
我們都生活在 DevOps 中
邁克爾： 即使從會議程序委員會的角度來看，我們在加州、紐約、歐洲、俄羅斯……都有人……新加坡還沒有人。 地理差異相當大，人們開始更加分散。 如果我們談論開發，您能否告訴我們更多有關 DevOps 和打破團隊之間障礙的資訊？ 有一個概念是每個人都坐在自己的掩體中，而現在掩體正在倒塌，您如何看待這個類比？
提姆： 在我看來，鑑於最近的技術突破，devops 非常重要。 以前，您有開發人員和管理員團隊，他們工作、工作、工作，在某個時候出現了一個東西，您可以透過它來聯繫管理員並將其推出到生產環境。 關於地堡的對話就從這裡開始了，因為管理員是盟友，至少不是敵人，但只有當一切都準備好投入生產時，你才與他們交談。 你是否帶著一些東西去找他們並說：看看我們有一個什麼樣的應用程序，但是你能推出這個應用程式嗎？ 現在，整個交付概念已經發生了更好的變化。 我的意思是，有這樣的想法：你可以快速推動改變。 我們可以即時更新產品。 當我的筆記型電腦上的Firefox 彈出並說：嘿，我們已經在後台更新了您的Firefox 時，我總是微笑著，只要您有時間，您介意點擊此處，我們將為您提供最新版本。 我當時想，“哦，是的，寶貝！” 當我睡覺的時候，他們正在我的電腦上為我提供一個新版本。 這太美妙了，不可思議。
但困難在於：你可以透過更新軟體來實現這項功能，但整合人員卻困難得多。 我想在 DevOops 主題演講中表達的是，我們現在的參與者比以往任何時候都多得多。 如果你只考慮一個團隊中的每個人… 您將其視為一個團隊，而它不僅僅是一個程式設計師團隊。 這些人是測試人員、專案經理和其他一些人。 每個人對世界都有自己的看法。 產品經理與專案經理完全不同。 管理員有自己的任務。 協調所有參與者以便持續了解正在發生的事情而不發瘋就成為一個相當困難的問題。 有必要將小組的任務和適用於每個人的任務分開。 這是一項非常艱鉅的任務。 另一方面，我認為現在比很多年前好多了。 這正是人們成長和學習正確行為的道路。 當你進行整合時，你明白不應該有地下開發，這樣在最後一刻軟體就不會像玩偶盒子一樣爬出來：就像，看看我們在這裡做了什麼！ 這個想法是，您將能夠進行整合和開發，最後您將以簡潔和迭代的方式推出。 這一切對我來說意義重大。 這使得為系統使用者和您的客戶創造更多價值成為可能。
邁克爾： DevOps 的整體理念是儘早交付有意義的開發。 我看到世界開始變得越來越快。 如何適應這樣的加速？ 十年前，這是不存在的！
提姆： 當然，每個人都想要越來越多的功能。 無需移動，只需堆積更多即可。 有時您甚至必須放慢下一次增量更新的速度才能帶來任何有用的東西 - 這是完全正常的。
你需要跑、跑、跑的想法並不是最好的。 不太可能有人願意這樣生活。 我希望交付的節奏能夠設定專案自己的節奏。 如果你只是產生一系列小而相對無意義的東西，那麼所有這些加起來就沒有任何意義。 與其盲目地嘗試儘早發布東西，值得與首席開發人員以及產品和專案經理討論的是策略。 這樣還有道理嗎？
模式和反模式
奧列格： 你通常會談論模式和反模式，這就是專案生與死的區別。 現在，DevOps 闖入了我們的生活。 它是否有自己的模式和反模式可以當場終止該項目？
提姆： 模式和反模式一直在發生。 有話要說。 嗯，有一種東西我們稱之為「閃亮的東西」。 人們真的非常喜歡新技術。 他們只是被一切看起來很酷、很時尚的東西的光芒所迷住，他們不再問問題：這是否有必要？ 我們要達成什麼目標？ 這東西可靠嗎，有什麼意義嗎？ 可以說，我經常看到人們處於技術的前沿。 他們被世界上正在發生的事情催眠了。 但如果你仔細看看他們做了什麼有用的事情，往往根本沒有用！
我們剛剛和戰友們討論，今年是周年紀念年，是人類登陸月球五十週年。 那是在 1969 年。幫助人們實現這一目標的技術甚至不是 1969 年的技術，而是 1960 年或 62 年的技術，因為 NASA 只想使用有良好可靠性證據的技術。 所以你看看它就會明白 - 是的，它們是真的！ 現在，不，不，但你會遇到技術問題，只是因為一切都被推得太緊，從所有的裂縫中出售。 人們從四面八方喊道：“看，什麼東西，這是世界上最新的東西，最美的東西，絕對適合所有人！” 好吧，就是這樣……通常這一切都只是一個誘餌，然後就必須扔掉。 也許這都是因為我已經是一個老人了，當人們跑出去說他們找到了創造最佳技術的唯一、最正確的方法時，我對這些事情抱有很大的懷疑。 就在這時，我內心深處響起了一個聲音：“真是一團糟！”
邁克爾： 事實上，我們多久聽過下一個銀彈？
提姆： 沒錯，這就是事情的常態！ 比如說……好像這已經成為全世界的笑話了，但這裡人們常常談論區塊鏈技術。 它們在某些情況下實際上是有意義的！ 當你確實需要可靠的事件證據、系統正常運作並且沒有人欺騙我們時，當你遇到安全問題以及所有這些東西混合在一起時——區塊鏈就有意義了。 但當他們說區塊鏈現在將席捲世界，掃除其路徑上的一切？ 夢想更多！ 這是一項非常昂貴且複雜的技術。 技術複雜且耗時。 包括純粹的演算法，每次你需要重新計算數學，有最輕微的變化......這是一個好主意 - 但僅限於某些情況。 我的整個生活和職業生涯都是圍繞著這一點：在非常具體的情況下提出有趣的想法。 準確了解您的情況非常重要。
邁克爾： 是的，主要的「生命、宇宙和一切的問題」：這種技術或方法是否適合你的情況？
提姆： 這個問題已經可以跟技術組討論了。 甚至可能會引入一些顧問。 看看這個項目並了解 - 我們現在會做一些正確且有用的事情，比以前更好嗎？ 也許它會適合，也許不適合。 但最重要的是，不要因為有人脫口而出：「我們迫切需要區塊鏈！ 我剛剛在飛機上從一本雜誌上讀到了關於他的事！” 嚴重地？ 這一點都不好笑。
神話般的“devops 工程師”
奧列格： 現在大家都在實施devops。 有人在網路上閱讀有關 DevOps 的信息，明天招聘網站上就會出現另一個職位空缺。 “開發維運工程師”。 這裡我想請大家注意：您認為「devops工程師」這個詞有生命權嗎？ 有一種觀點認為 DevOps 是一種文化，但有些東西在這裡並不成立。
提姆： 一般般。 然後請他們立即對這個術語做出一些解釋。 讓它變得獨一無二的東西。 除非他們證明這樣的職缺背後有某種獨特的技能組合，否則我不會買它！ 我的意思是，我們有一個職位名稱，“devops 工程師”，一個有趣的頭銜，是的，下一步是什麼？ 職位名稱通常是一件非常有趣的事情。 假設「開發者」——它到底是什麼？ 不同的組織意味著完全不同的事情。 在一些公司中，高素質的程式設計師編寫的測試比其他公司的特殊專業測試人員編寫的測試更有意義。 那麼，他們現在是程式設計師還是測試人員呢？
是的，我們有職稱，但如果你問問題的時間夠長，最終會發現我們都是問題解決者。 我們是解決方案的尋求者，有些人擁有一些技術技能，有些人則擁有不同的技能。 如果您生活在 DevOps 已經滲透的環境中，那麼您正在從事開發和管理的集成，並且此活動有一些相當重要的目的。 但如果你被問到你到底在做什麼以及你負責什麼，事實證明人們從古以來就一直在做所有這些事情。 “我負責架構”，“我負責資料庫”等等，不管怎樣，你看——所有這些都是在“devops”之前。
當有人告訴我他們的職位時，我並不太聽。 最好讓他告訴你他實際上負責什麼，這會讓我們更好地理解這個問題。 我最喜歡的例子是一個人聲稱自己是「專案經理」。 什麼？ 這沒什麼意義，我還是不知道你在做什麼。 專案經理可以是一名開發人員，一個四人團隊的領導者，編寫程式碼，做工作，他已經成為團隊領導，人們自己認可他為領導者。 而且，專案經理可以是管理一個專案的六百人的經理，管理其他經理，負責制定時間表和規劃預算，僅此而已。 這是兩個完全不同的世界！ 但他們的職稱聽起來是一樣的。
讓我們以不同的方式扭轉這個局面。 你真正擅長什麼，有很多經驗，你有天份嗎？ 因為你認為你可以完成這項任務，你會承擔什麼責任？ 這裡有人會立即開始否認：不，不，不，我根本不想處理專案資源，這不關我的事，我是一個技術人員，我了解可用性和使用者介面，我不知道根本想管理大軍，讓我更好地去工作。
順便說一句，我是這種技能分離效果很好的方法的大力支持者。 技術人員可以在這裡隨心所欲地發展自己的職業生涯。 然而，我仍然看到技術人員抱怨的組織：我必須進入專案管理，因為這是這家公司的唯一途徑。 有時這會導致可怕的結果。 最好的技術人員根本不是好的管理者，最好的管理者也無法駕馭科技。 讓我們老實說。
我現在看到對此有很多需求。 如果您是技術人員，您的公司可以幫助您，但無論如何，您需要，確實需要找到自己的職業道路，因為技術不斷變化，您需要隨之重塑自己！ 在短短二十年內，技術至少可以改變五次。 科技真是個奇怪的東西…
“凡事都是專家”
邁克爾： 人們如何應對如此快速的技術變革？ 它們的複雜性越來越大，數量越來越多，人與人之間的交流總量也越來越大，事實證明你不可能成為「樣樣都專家」。
提姆： 正確的！ 如果你從事技術工作，是的，你肯定需要選擇一些特定的東西並深入研究它。 您的組織發現一些有用的技術（也許實際上會有用）。 如果你不再對它感興趣 - 我永遠不會相信我會這麼說 - 好吧，也許你應該轉移到其他一些組織，那裡的技術更有趣或更方便學習。
但總的來說，是的，你是對的。 技術同時向各個方向發展；沒有人可以說「我是所有現有技術的專家技術專家」。 另一方面，還有一些海綿人，他們真正吸收技術知識並為之瘋狂。 我見過幾個這樣的人，他們確實在呼吸和生活，與他們交談是有用且有趣的。 他們不僅研究組織內部正在發生的事情，而且總的來說，他們談論它，他們也是非常酷的技術專家，他們非常有意識和有目的。 他們只是努力保持在浪潮的頂峰，無論他們的主要工作是什麼，因為他們的熱情是技術的運動、技術的推廣。 如果你突然遇到這樣的人，你應該和他一起去吃午飯，並在午餐時討論各種很酷的事情。 我認為任何組織都至少需要幾個這樣的人。
風險和不確定性
邁克爾： 尊敬的工程師，是的。 趁有時間我們來談談風險管理。 我們在這次訪談中首先討論了醫療軟體，其中的錯誤可能會導致可怕的後果。 然後我們談到了登月計劃，其中一個錯誤的代價是數百萬美元，甚至可能有幾個人的生命。 但現在我在行業中看到了相反的趨勢，人們不考慮風險，不嘗試預測風險，甚至不觀察風險。
奧列格： 快速行動並打破一切！
邁克爾： 是的，快速行動，打破事物，打破越來越多的事物，直到你死於某事。 從您的角度來看，一般開發人員現在應該如何進行學習風險管理？
提姆： 讓我們在兩件事之間劃清界線：風險和不確定性。 這些是不同的事情。 當您在任何給定時間點沒有足夠的數據來得出明確的答案時，就會出現不確定性。 例如，在專案的早期階段，如果有人問你“你什麼時候完成工作”，如果你是一個相當誠實的人，你會說“我不知道”。 你只是不知道，那也沒關係。 你還沒有研究過問題，不熟悉團隊，你不了解他們的技能等等。 這就是不確定性。
當潛在問題已經被發現時，風險就會出現。 這種事情是有可能發生的，它的機率大於零，但小於百分百，介於兩者之間。 正因為如此，任何事情都可能發生，從延誤和不必要的工作，甚至到專案的致命結果。 結果，當你說 - 夥計們，讓我們折疊雨傘並離開海灘時，我們永遠不會完成它，一切都結束了，就這樣。 我們假設這個東西會起作用，但它根本不起作用，是時候停止了。 就是這些情況。
通常，當問題已經出現、當下正在發生時，問題最容易解決。 但當問題擺在你面前時，你並不是進行風險管理，而是在解決問題、進行危機管理。 如果您是首席開發人員或經理，您一定想知道會發生什麼情況，導致延誤、浪費時間、不必要的成本或整個專案的崩潰？ 是什麼讓我們停下來重新開始？ 當所有這些事情都發揮作用時，我們將用它們做什麼？ 有一個適用於大多數情況的簡單答案：不要逃避風險，要努力應對風險。 了解如何解決危險情況，將其化為烏有，將其從問題變成其他問題。 而不是說：好吧，我們會在問題出現時解決它們。
不確定性和風險應該是您處理的所有事情的首要考慮因素。 你可以製定一個專案計劃，提前查看某些關鍵風險，然後說：我們現在需要處理這個問題，因為如果其中任何一個出現問題，其他一切都無關緊要。 如果不確定是否可以做飯，您不必擔心桌子上的桌布是否美觀。 首先，您需要識別準備美味晚餐的所有風險，處理它們，然後才考慮所有其他不會構成真正威脅的事情。
再說一遍，是什麼讓您的專案與眾不同？ 讓我們看看是什麼會讓我們的專案脫軌。 我們可以做些什麼來盡量減少這種情況發生的可能性？ 通常你不能只是100%中和它們，然後問心無愧地宣稱：“就是這樣，這不再是問題，風險已經解決了！” 對我來說，這是成年人行為的標誌。 這就是孩子和成人的差別──孩子認為自己是不朽的，不會出錯，一切都會好起來的！ 與此同時，大人看著三歲的孩子在操場上跳躍，眼睛跟隨動作，自言自語：“哦哦，哦哦。” 我站在附近，準備在孩子跌倒時接住他。
另一方面，我之所以如此喜歡這個行業，是因為它有風險。 我們做事，而這些事都是有風險的。 他們需要成人的方法。 僅靠熱情並不能解決你的問題！
成人工程思維
邁克爾： 孩子們的例子很好。 如果我是一名普通的工程師，那麼我很高興能成為一個孩子。 但如何走向更成人的思維呢？
提姆： 對於初學者或成熟的開發人員來說同樣有效的想法之一是上下文的概念。 我們正在做什麼，我們將要實現什麼。 這個項目真正重要的是什麼？ 無論您是誰參與這個項目，無論您是實習生還是首席架構師，每個人都需要背景資訊。 我們需要讓每個人從比自己的工作更大的角度思考。 “我創作我的作品，只要我的作品有效，我就很高興。” 不，又不。 提醒人們他們的工作環境總是值得的（但不要粗魯！）。 我們共同努力實現的目標。 只要你的專案進展順利，你就可以像個孩子一樣——請不要這樣做。 如果我們真的衝過終點線，我們只會一起衝過去。 你並不孤單，我們都在一起。 如果專案中的所有人員，無論老少，都開始談論對專案到底重要的是什麼，為什麼公司要在我們都努力實現的目標上投資……他們中的大多數人都會感覺好多了，因為他們將看到他們的工作與其他人的工作如何相關。 一方面，我理解我個人負責的作品。 但為了完成這項工作，我們還需要所有其他人。 如果您真的認為您已經完成了，那麼我們在該專案中總是有工作要做！
奧列格： 相對而言，如果你按照看板進行工作，當你遇到某些測試的瓶頸時，你可以退出你正在做的事情（例如程式設計），去幫助測試人員。
提姆： 確切地。 我認為最好的技術人員，如果你仔細觀察他們，你會發現他們是自己的經理。 我該如何表達這個...
奧列格： 你的生活就是你的項目，你管理它。
提姆： 確切地！ 我的意思是，你承擔責任，你了解問題，當你看到你的決定會影響他們的工作等事情時，你就會與人們接觸。 這不僅僅是坐在辦公桌前，做你的工作，甚至沒有意識到周圍發生了什麼。 不不不。 順便說一句，敏捷的最好的事情之一是他們提出了短衝刺，因為這樣所有參與者的事態都可以清楚地觀察到，他們可以一起看到這一切。 我們每天都會談論彼此。
如何進入風險管理
奧列格： 這方面有正式的知識結構嗎？ 例如，我是一名 Java 開發人員，想了解風險管理，但不想透過教育成為真正的專案經理。 我可能會先讀麥康奈爾的《軟體專案成本是多少》，然後呢？ 第一步是什麼？
提姆： 首先是開始與專案中的人員溝通。 這立即改善了與同事的溝通文化。 我們需要先預設打開所有內容，而不是隱藏它。 說：這些都是困擾我的事情，這些是讓我徹夜難眠的事情，我今天晚上醒來，心想：天哪，我需要考慮一下這個！ 其他人也看到同樣的事情嗎？ 作為一個群體，我們應該應對這些潛在的問題嗎？ 您需要能夠支持有關這些主題的討論。 我們的工作沒有預先準備好的公式。 這與製作漢堡無關，而是與人有關。 「做一個起司漢堡，賣一個起司漢堡」根本不是我們的事，這就是為什麼我如此熱愛這份工作。 我喜歡管理者過去所做的一切現在都成為團隊的財產。
奧列格： 您在書籍和訪談中談到人們如何更關心幸福而不是圖表上的數字。 另一方面，當你告訴團隊：我們正在轉向 DevOps，現在程式設計師必須不斷地溝通，這可能遠遠超出了他的舒適區。 可以說，此刻他可能會非常不高興。 在這種情況下該怎麼辦？
提姆： 我不知道到底該怎麼做。 如果開發人員過於孤立，他們首先不會明白為什麼要完成工作，他們只會看到自己的部分工作，並且需要進入我所說的「上下文」。 他需要弄清楚一切是如何連結在一起的。 當然，我指的不是正式的演示或類似的東西。 我說的是這樣一個事實：你需要與同事就整個工作進行溝通，而不僅僅是你負責的部分。 在這裡，您可以開始討論想法、共同協議以使您的工作能夠很好地配合，以及如何共同解決常見問題。
為了幫助他們適應，他們經常希望派技術人員參加培訓，並討論培訓問題。 我的一個朋友喜歡說訓練是為了狗。 對人有培訓。 作為開發人員學習的最好的事情之一就是與同事互動。 如果某人真的擅長某件事，你應該觀看他們工作或與他們談論他們的工作或其他事情。 一些傳統的 Kent Beck 經常談論極限程式設計。 這很有趣，因為 XP 是一個如此簡單的想法，但它卻導致瞭如此多的問題。 對某些人來說，做 XP 就像被迫在朋友面前脫衣服。 他們會看到我在做什麼！ 他們是我的同事，他們不僅會看到，還會理解！ 糟糕的！ 有些人開始變得非常緊張。 但當你意識到這是最終的學習方式時，一切都會改變。 你與人們密切合作，有些人比你更了解這個主題。
邁克爾： 但這一切都迫使你走出自己的舒適圈。 身為工程師，你必須走出自己的舒適圈並進行溝通。 作為問題解決者，你必須不斷地將自己置於弱勢地位並思考可能會出現什麼問題。 這種類型的工作本質上是一種麻煩事。 你有意識地將自己置於有壓力的境地。 通常人們會逃避他們，人們喜歡成為快樂的孩子。
提姆： 能做的，你就可以公開地說：「一切都好，我能搞定！ 我不是唯一一個感到不舒服的人。 讓我們作為一個團隊一起討論各種令人不舒服的事情！” 這些都是我們共同的問題，我們必須解決它們，你知道嗎？ 我認為特殊的天才開發人員就像猛獁像一樣，他們消失了。 而且它們的意義非常有限。 如果你不能溝通，你就不能很好地參與。 所以，就說吧。 誠實、開放。 我很抱歉這讓某人感到不愉快。 你能想像嗎，很多年前有一項研究表明，美國主要的恐懼不是死亡，而是你猜怎麼著？ 害怕公開演講！ 這意味著在某個地方有人寧願死也不願大聲說讚美的話。 我認為你擁有一些基本技能就足夠了，這取決於你做什麼。 口語技能、寫作技能——但僅限於工作中真正需要的程度。 如果你是分析師，但不會讀、寫或說，那麼不幸的是，你將無法參與我的專案！
溝通的代價
奧列格： 難道因為各種原因僱用這樣的離職員工成本會更高嗎？ 畢竟，他們一直在聊天而不是工作！
提姆： 我指的是團隊的核心，而不僅僅是每個人。 如果你有一個非常擅長調優資料庫，熱愛調優資料庫，並且將在餘生繼續調優你的資料庫，就是這樣，酷，繼續下去。 但我說的是那些想住在專案本身的人。 團隊的核心，旨在開發專案。 這些人確實需要不斷地互相溝通。 尤其是在專案開始時，當您討論風險、實現全球目標的方法等時。
邁克爾： 這適用於參與專案的每個人，無論專業、技能或工作方式如何。 你們都對專案的成功感興趣。
提姆： 是的，您覺得自己充分沉浸在該專案中，您的任務是幫助專案實現。 無論您是程式設計師、分析師、介面設計師或任何人。 這就是我每天早上上班的原因，這就是我們所做的。 我們對所有這些人負責，無論他們的技能如何。 這是一群人在進行成人對話。
奧列格： 事實上，談到健談的員工，我試著模擬人們，尤其是被要求轉向 DevOps 的管理者，對這個全新的世界願景的反對意見。 作為顧問，您應該比作為開發人員的我更了解這些反對意見！ 分享管理者最擔心的是什麼？
提姆： 經理們？ 嗯。 大多數情況下，管理者面臨問題帶來的壓力，面臨緊急發布某些東西並進行交付的需要，等等。 他們觀察我們如何不斷地討論和爭論某事，他們是這樣看待的：對話，對話，對話......還有什麼其他對話？ 回去工作！ 因為談話對他們來說並不像是工作。 你不寫程式碼，不測試軟體，似乎什麼也沒做——為什麼不派你去做點什麼呢？ 畢竟已經有一個月的時間了！
邁克爾： 去寫一些程式碼吧！
提姆： 在我看來，他們擔心的不是工作，而是缺乏進展的可見度。 為了讓我們看起來離成功越來越近，他們需要看到我們按下鍵盤上的按鈕。 一整天從早到晚。 這是第一個問題。
奧列格： 米莎，你在想什麼。
邁克爾： 抱歉，我陷入了沉思，突然想起了一些事情。 這一切讓我想起了昨天發生的一次有趣的集會……昨天的集會太多了……而且這一切聽起來都很熟悉！
沒有工資的生活
提姆： 順便說一下，根本沒有必要整理「集會」來交流。 我的意思是，開發人員之間最有用的討論發生在他們互相交談時。 早上，你端著一杯咖啡走進去，有五個人聚集在一起，激烈地討論一些技術問題。 對我來說，如果我是這個專案的經理，最好只是微笑著去一些關於我的業務的地方，讓他們討論。 他們已經盡可能地參與其中。 這是一個好兆頭。
奧列格： 順便說一句，在你的書中有很多關於什麼是好的、什麼是壞的註釋。 您自己使用其中的任何一個嗎？ 相對而言，現在你擁有一家公司，而且是一家以非常非正統的方式構建的公司...
提姆： 非正統，但這個設備非常適合我們。 我們已經認識很久了。 我們彼此信任，在成為合作夥伴之前我們就非常信任彼此。 例如，我們根本沒有工資。 我們只是工作，例如，如果我從客戶那裡賺到錢，那麼所有的錢都歸我所有。 之後，我們向組織繳納會員費，這足以支持公司本身。 另外，我們都專注於不同的事情。 例如，我與會計師一起工作，填寫報稅表，為公司做各種行政事務，但沒有人付錢給我。 詹姆斯和湯姆在我們的網站上工作，沒有人付錢給他們。 只要你繳了會費，就沒有人會想到告訴你需要做什麼。 例如，湯姆現在的工作量比以前少了很多。 現在他有其他的興趣；他做一些不為公會而做的事情。 但只要他繳了會費，就沒有人會對他說：“嘿，湯姆，去上班吧！” 當你們之間沒有錢的時候，和同事打交道是很容易的。 現在我們的關係是不同專業的基本理念之一。 它有效，而且效果非常好。
最好的建議
邁克爾： 回到“最佳建議”，您有沒有一遍又一遍地告訴客戶什麼？ 有一個關於 80/20 的想法，有些建議可能會更頻繁地重複。
提姆： 我曾經以為，如果你寫一本像《與熊跳華爾滋》這樣的書，它會改變歷史的進程，人們會停下來，但是……好吧，看，公司經常假裝他們一切都很好。 一旦有不好的事情發生，對他們來說都是一種震驚和意外。 「你看，我們測試了系統，沒有通過任何系統測試，這又是三個月的計劃外工作，怎麼會發生這種情況？ 誰知道？ 可能會出什麼問題？ 說真的，你相信這個嗎？
我試著解釋你不應該對目前的情況太生氣。 我們需要把問題說出來，真正了解可能出了什麼問題，以及如何防止類似的事情再次發生。 如果確實出現問題，我們將如何應對、如何遏止？
對我來說，這一切看起來都很可怕。 人們在處理複雜、令人煩惱的問題時，仍然假裝只要祈禱並希望得到最好的結果，「最好的」就會真正發生。 不，事情不是這樣的。
實踐風險管理！
邁克爾： 您認為有多少組織從事風險管理？
提姆： 令我憤怒的是，人們只是簡單地寫下風險，查看結果清單然後開始工作。 事實上，對他們來說識別風險就是風險管理。 但對我來說，這聽起來像是一個問的理由：好吧，有一個列表，你到底要改變什麼？ 您需要考慮這些風險來改變您的標準行動順序。 如果工作中有一些最困難的部分，你需要解決它，然後再轉向更簡單的部分。 在第一個衝刺中，開始解決複雜的問題。 這看起來已經像是風險管理了。 但通常人們無法說出在編制風險清單後改變了什麼。
邁克爾： 然而，這些公司中有多少參與了風險管理？百分之五？
提姆： 不幸的是，我不想這麼說，但這是一些非常微不足道的部分。 但超過五個，因為確實有很大的項目，如果不做一些事情，它們就不可能存在。 這麼說吧，如果至少25%我會感到非常驚訝。 小專案通常會這樣回答這樣的問題：如果問題影響到我們，那麼我們就會解決它。 然後他們成功地讓自己陷入困境並進行問題管理和危機管理。 當你試圖解決問題但問題沒有解決時，歡迎來到危機管理。
是的，我經常聽到，“我們會在問題出現時解決它們。” 我們一定會嗎？ 我們真的會決定嗎？
奧列格： 你可以天真地做到這一點，只需將重要的不變量寫入專案章程中，如果不變量破壞，只需重新啟動專案即可。 事實證明非常花哨。
邁克爾： 是的，我遇到過這樣的情況：當風險被觸發時，專案就被簡單地重新定義了。 太好了，賓果遊戲，問題解決了，不用再擔心了！
提姆： 讓我們按下重置按鈕吧！ 不，事情不是這樣的。
DevOops 2019 主題演講
邁克爾： 我們進入本次採訪的最後一個問題。 您將在下一屆 DevOops 上發表主題演講，您能揭開您將要講述的內容的神秘面紗嗎？
提姆： 目前，其中六人正在寫一本關於工作文化、組織的潛規則的書。 文化是由組織的核心價值決定的。 通常人們不會注意到這一點，但在諮詢行業工作了多年，我們已經習慣了注意到這一點。 你進入一家公司，幾分鐘之內你就會開始感受到正在發生的事情。 我們稱之為「風味」。 有時這種氣味真的很好聞，有時卻很糟糕。 對於不同的組織來說，情況有很大不同。
邁克爾： 我也從事諮商工作多年，很理解你在說什麼。
提姆： 事實上，主題演講中值得談論的一件事是，並非所有事情都是由公司決定的。 您和您的團隊作為一個社區，擁有自己的團隊文化。 這可以是整個公司，也可以是一個單獨的部門，一個單獨的團隊。 但在你說之前，這就是我們所相信的，這就是重要的......在具體行動背後的價值觀和信念被理解之前，你無法改變一種文化。 行為很容易觀察，但尋找信念卻很困難。 DevOps 只是事物如何變得越來越複雜的一個很好的例子。 互動只會變得更加複雜，而根本沒有變得更乾淨或更清晰，所以你應該考慮一下你相信什麼以及你周圍的每個人都保持沉默。
如果你想快速取得成果，這裡有一個很好的主題適合你：你有看過沒有人說「我不知道」的公司嗎？ 在某些地方，你實際上會折磨一個人，直到他承認他不知道某些事情。 每個人都知道一切，每個人都是令人難以置信的博學多才。 當你接近任何人時，他必須立即回答問題。 而不是說「我不知道」。 萬歲，他們聘請了一群博學之士！ 在某些文化中，說「我不知道」通常是非常危險的；它可能被視為軟弱的表現。 相反，也有一些組織中的每個人都可以說「我不知道」。 在那裡這是完全合法的，如果有人在回答問題時開始胡言亂語，回答「你不知道你在說什麼，對吧？」是完全正常的。 並把這一切變成一個笑話。
理想情況下，您希望擁有一份可以持續快樂的工作。 這並不容易，不是每天都是陽光明媚、愉快的，有時你需要努力工作，但當你開始盤點時，就會發現：哇，這真是一個美妙的地方，在這裡工作感覺很好，無論是情感上還是智力上。 還有一些公司，你去當顧問，立刻意識到你無法忍受三個月，會驚恐地逃跑。 這就是我在報告中想講的內容。
蒂姆·李斯特 (Tim Lister) 將發表主題演講 參加將於 2019 年 29 月 30 日至 2019 日在聖彼得堡舉行的 DevOops XNUMX 會議。 你可以買票 。 我們在 DevOops 等你！
來源： www.habr.com