献给项目经理（以及那些梦想成为老板的人）。
编写大量代码很难，但管理人员更难！ 所以你只需要这本书来学习如何做到这两点。
是否有可能将有趣的故事和严肃的教训结合起来？ 迈克尔·洛普（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%将用于新电脑书籍的翻译，书目清单交给印刷厂 .
来源： habr.com