獻給專案經理（以及那些夢想成為老闆的人）。
編寫大量程式碼很難，但管理人員更難！ 所以你只需要這本書來學習如何做到這兩點。
是否有可能將有趣的故事和嚴肅的教訓結合起來？ 邁克爾·洛普（Michael Lopp）（在狹窄的圈子裡也被稱為蘭德斯）成功了。 您會發現關於虛構人物的虛構故事，這些故事具有令人難以置信的回報（儘管是虛構的）經歷。 Rands 以此方式分享了他多年來在大型 IT 公司（Apple、Pinterest、Palantir、Netscape、Symantec 等）工作期間獲得的各種（有時甚至是奇怪的）經歷。
您是專案經理嗎？ 或是想了解你該死的老闆整天都在做什麼？ 蘭德斯將教你如何在膨脹火雞的有毒世界中生存，並在功能失調的浮誇人的普遍瘋狂中茁壯成長。 在這個由瘋狂的天才組成的奇怪社區中，還有更奇怪的生物——經理人，他們透過神秘的組織儀式，獲得了掌控許多人的計劃、思想和銀行帳戶的權力。
本書不同於任何管理或領導手稿。 麥可·洛普（Michael Lopp）並沒有隱藏任何事情，他只是如實講述（也許並非所有故事都應該公開：P）。 但只有這樣，你才會明白如何在這樣的老闆面前生存，如何管理極客和書呆子，以及如何讓「那個該死的計畫」有一個圓滿的結局！
摘抄。 工程心態
思考：你應該繼續寫程式碼嗎？
蘭德斯關於管理者規則的書包含了一個非常簡短的現代管理「必須做的事情」清單。 這份清單的簡潔性源自於這樣一個事實：「必須」的概念是一種絕對，而對人來說，絕對的概念很少。 對一名員工來說成功的管理方法對另一名員工來說卻可能是一場真正的災難。 這個想法是經理「必須做」清單上的第一項：
保持靈活！
認為你已經知道一切是一個非常糟糕的主意。 在世界不斷變化的情況下，靈活性成為唯一正確的立場。
矛盾的是，清單中的第二項出乎意料地缺乏靈活性。 然而，這一點是我個人最喜歡的，因為我相信它有助於為管理成長奠定基礎。 這一段內容如下：
別再寫程式了！
理論上，如果你想成為經理，你必須學會信任那些為你工作的人，並將編碼工作完全交給他們。 這個建議通常很難消化，特別是對於新上任的管理者來說。 他們成為管理者的原因之一可能是因為他們的開發生產力，而當出現問題時，他們的第一個反應就是求助於他們完全有信心的技能，這就是他們編寫程式碼的能力。
當我看到新上任的經理「沉迷於」編寫程式碼時，我告訴他：「我們知道你可以寫程式碼。 問題是：你能領導嗎？ 你不再只對自己負責，你要對整個團隊負責； 我想確保您可以讓您的團隊自己解決問題，而無需您自己編寫程式碼。 你的工作是弄清楚如何擴展自己。 我不希望你只是一個人，我希望有很多像你一樣的人。”
好建議，對吧？ 規模。 管理。 責任。 諸如此類的常見流行語。 可惜這個建議是錯的。
不正確？
是的。 的建議是錯的！ 不是完全錯誤，但錯誤得足以讓我不得不打電話給一些以前的同事並道歉：「還記得我最喜歡的關於你應該如何停止編寫程式碼的聲明嗎？ 這是不對的！ 是的...重新開始程式設計。 從 Python 和 Ruby 開始。 是的，我是認真的！ 你的事業就靠它了！”
當我在 Borland 作為軟體開發人員開始我的職業生涯時，我在 Paradox Windows 團隊工作，這是一個龐大的團隊。 光是應用程式開發人員就有 13 名。 如果再加上其他團隊也持續致力於該專案關鍵技術（例如核心資料庫引擎、核心應用服務）的人員，那麼直接參與該產品開發的工程師就有 50 人。
我工作過的其他團隊都沒有接近這個規模。 事實上，隨著時間的推移，我工作的團隊的人數正在逐漸減少。 這是怎麼回事？ 我們開發人員集體變得越來越聰明了嗎？ 不，我們只是分擔負載。
過去20年開發商在做什麼？ 這段時間我們寫了一大堆程式碼。 代碼之海！ 我們編寫瞭如此多的程式碼，因此我們認為簡化一切並開源是個好主意。
幸運的是，多虧了互聯網，這個過程現在變得盡可能簡單。 如果您是軟體開發人員，您可以立即查看！ 在 Google 或 Github 上搜尋你的名字，你會看到你早已忘記但任何人都可以找到的程式碼。 可怕吧？ 難道你不知道程式碼永遠存在嗎？ 是的，他永遠活著。
代碼永遠存在。 好的程式碼不僅會永遠存在，而且會不斷發展，因為那些重視它的人會不斷確保它保持新鮮。 這堆高品質、維護良好的程式碼有助於減少平均工程團隊規模，因為它使我們能夠專注於現有程式碼而不是編寫新程式碼，並用更少的人員和更短的時間完成工作。
這種推理聽起來令人沮喪，但其想法是，我們都只是一堆整合自動機，使用膠帶將現有事物的不同部分連接在一起，以創建同一事物的略有不同的版本。 這是熱愛外包的主管的經典思路。 「任何知道如何使用 Google 並且有膠帶的人都可以做到這一點！ 那我們為什麼要花很多錢買機器呢？”
我們付給這些管理人員很大的錢，但他們卻認為這是胡說八道。 我再次強調，我們的星球上有許多才華橫溢且非常勤奮的開發人員； 他們確實非常聰明和勤奮，儘管他們沒有在認可的大學待過一分鐘。 哦，是的，現在這樣的人越來越多了！
我不建議你僅僅因為據稱有一些才華橫溢的同志正在尋找你的位置而開始擔心你的位置。 我建議您開始擔心它，因為軟體開發的發展可能比您更快。 你已經工作了十年，其中五年擔任經理，你會想：“我已經知道軟體是如何開發的了。” 對，你知道的。 再見…
停止編寫程式碼，但是...
如果您遵循我最初的建議並停止編寫程式碼，您也將自願停止參與創建過程。 正是因為這個原因，我不積極使用外包。 自動機不創造，而是生產。 精心設計的流程可以節省大量資金，但它們不會為我們的世界帶來任何新東西。
如果你有一個小團隊用很少的錢做很多事情，那麼停止編寫程式碼的想法對我來說似乎是一個糟糕的職業決定。 即使在有著無窮無盡的法規、流程和政策的怪物公司，你也沒有權利忘記如何自己開發軟體。 軟體開發也在不斷變化。 現在正在改變。 在你腳下！ 就在這一刻！
你有異議。 理解。 我們來聽聽。
「蘭德斯，我正在去擔任導演的路上！ 如果我繼續寫程式碼，沒有人會相信我能成長。”
我想問您：自從您坐在「我即將成為執行長！」的椅子上後，您是否注意到軟體開發環境正在發生變化，甚至在您的公司內部也是如此？ 如果你的答案是肯定的，那麼我會問你另一個問題：它到底是如何改變的以及你將如何應對這些變化？ 如果您對我的第一個問題回答“否”，那麼您需要換到另一把椅子，因為（我敢打賭！）軟體開發領域此時此刻正在發生變化。 如果你慢慢地但肯定忘記瞭如何開發軟體，你怎麼能成長呢？
我的建議是不要致力於為下一個產品實現大量功能。 您需要不斷採取措施來掌握團隊建立軟體的方式。 身為董事和副總裁，您都可以做到這一點。 還有別的事嗎？
「呃，蘭茲！ 但總得有人來當仲裁者！ 必須有人看到大局。 如果我寫程式碼，我就會失去視角。”
你仍然必須成為裁判，你仍然必須廣播決定，你仍然必須每週一早上和你的一位工程師在大樓裡走四次，聽他每週 30 小時的“我們都注定了”咆哮分鐘。！ 但除此之外，您還必須保持工程思維，而且您不必成為全職程式設計師才能做到這一點。
我保持工程心態的建議：
- 使用開發環境。 這意味著您應該熟悉團隊的工具，包括程式碼建置系統、版本控制和程式語言。 因此，您將精通團隊在談論產品開發時所使用的語言。 這也將允許您繼續使用您最喜歡的文字編輯器，它運行完美。
- 您必須能夠隨時在任何表面上繪製描述您的產品的詳細架構圖。 現在我指的不是具有三個單元格和兩個箭頭的簡化版本。 您必須了解產品的詳細圖。 最困難的一個。 不僅僅是任何可愛的圖表，而是一個難以解釋的圖表。 它應該是適合完整了解產品的地圖。 它不斷變化，您應該始終知道為什麼會發生某些變化。
- 接管執行其中一項功能。 當我寫這篇文章時，我真的皺起了眉頭，因為這一點有很多隱患，但我真的不確定你是否可以在不承諾實現至少一項功能的情況下完成第1 點和第2點。 透過自己實現其中一項功能，您不僅可以積極參與開發過程，還可以讓您定期從「負責一切的經理」角色切換到「負責實施一項功能的人」角色的功能」。 這種謙虛而不張揚的態度會提醒你小決定的重要性。
- 我還是渾身發抖。 似乎已經有人在罵我了：“經理親自承擔了職能的實現？！” （我同意他的觀點！） 是的，你仍然是經理，這意味著它應該是一些小功能，好嗎？ 是的，你還有很多事情要做。 如果你無法承擔該功能的實現，那麼我有一些備用建議給你：修復一些錯誤。 在這種情況下，你不會感受到創造的樂趣，但你會了解產品是如何被創造出來的，這意味著你永遠不會失業。
- 編寫單元測試。 當人們開始瘋狂時，我仍然在生產週期的後期這樣做。 將其視為您產品的健康檢查表。 經常這樣做。
又反對？
「蘭德斯，如果我寫程式碼，我會讓我的團隊感到困惑。 他們不會知道我是誰——經理還是開發人員。”
好的。
是的，我說：“好吧！” 我很高興您認為僅僅在開發人員池塘裡游泳就能讓您的團隊感到困惑。 很簡單：軟體開發中不同角色之間的界線目前非常模糊。 UI 人員所做的工作可以廣泛地稱為 JavaScript 和 CSS 程式設計。 開發人員越來越多地了解使用者體驗設計。 人們相互交流並了解錯誤、竊取他人代碼的情況，以及經理沒有充分理由不參與這種大規模、全球性、異花授粉資訊狂歡的事實。
此外，您想成為一個由易於更換的組件組成的團隊的一員嗎？ 這不僅會讓您的團隊更加靈活，還將讓每個團隊成員都有機會從不同的角度看待產品和公司。 在看到弗蘭克簡單而優雅的構建腳本後，您如何能更加尊重負責構建的冷靜人弗蘭克？
我不希望你的團隊變得混亂。 相反，我希望你的團隊能夠更有效地溝通。 我相信，如果您參與產品的創建和功能的開發，您將與您的團隊更加接近。 更重要的是，您將更接近組織內軟體開發流程的不斷變化。
不要停止發展
我在 Borland 的一位同事曾經口頭攻擊我稱她為「程式設計師」。
「蘭德斯，編碼員是一台無意識的機器！ 猴！ 編碼員除了編寫無聊的無用程式碼之外，不做任何重要的事情。 我不是程式設計師，我是軟體開發人員！”
她是對的，她會討厭我最初給新任執行長的建議：“停止編寫程式碼！” 不是因為我建議他們是程式設計師，而是因為我主動建議他們開始忽略他們工作中最重要的部分之一：軟體開發。
所以我更新了我的建議。 如果你想成為一個優秀的領導者，你可以停止寫程式碼，但...
變通。 記住成為工程師意味著什麼，並且不要停止開發軟體。
關於作者
麥可·洛普（Michael Lopp）是一位資深軟體開發人員，至今仍未離開矽谷。 在過去的 20 年裡，Michael 曾在多家創新公司工作過，包括 Apple、Netscape、Symantec、Borland、Palantir、Pinterest，也參與了一家慢慢被遺忘的新創公司。
工作之餘，邁克爾以筆名 Rands 運營著一個有關技術和管理的熱門博客，他在其中與讀者討論管理領域的想法，對不斷需要掌握最新動態表示擔憂，並解釋說，儘管創造產品的豐厚獎勵，您的成功只有歸功於您的團隊。 該部落格可以在這裡找到 .
麥可與家人住在加州雷德伍德。 他總是抽出時間騎登山車、打曲棍球、喝紅酒，因為健康比忙碌更重要。
» 有關本書的更多詳細信息，請訪問
»
»
對於 Khabrozhiteley 使用優惠券可享 20% 折扣 - 管理人員
支付紙本書籍的費用後，將透過電子郵件發送電子版書籍。
PS：書價的7%將用於新電腦書籍的翻譯，書目清單交給印刷廠 .
來源： www.habr.com