蒂姆·利斯特 - 书籍合著者
- “人的因素。 成功的项目和团队》（原书名为《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) 将发表主题演讲 DevOops 2019 大会将于 29 年 30 月 2019 日至 XNUMX 日在圣彼得堡举行。 你可以买票 。 我们在 DevOops 等你！
来源： habr.com