mql中的做多与做少
“计划的收益Swift减少：少计划，做更多，学到更多，重新设计治理方案，以期及早杀死人。”
新年快乐！ –新年的第一篇博客文章总是带有特殊的责任。 幸运的是，SpamCast的成名汤姆·卡格利（Tom Cagley）向我提出了一个幻想问题：
如果您有任何建议要给CxO高管，那将是什么？
我想给他们很多建议，但是有一条建议吗？
一条建议是通用的，涉及各个行业。 对我一无所知的所有公司提供一条建议。
强硬。 当我最终想出答案时，我知道我必须解释一下。
我必须认真思考。 我立刻知道，这将是连续数字主题的主题。
最终我想到了这个：
“计划的收益Swift减少：少计划，做更多，学到更多，重新设计治理方案，以期及早杀死人。”
我相信这是普遍的事实。 对任何事情进行足够长的计划，您最终都会计划出解决任何问题的方法。 当我运行我的扩展XP游戏时，我经常看到团队计划出一些好的工作方法。
一些计划会增加很多价值。 但是学习速度变慢并且继续变慢。 在某些时候，您根本不会学习更多，而在此之后的某个时候，您的学习会适得其反。 正如经济学家所说： 投资收益正在减少。
稍作计划会增加很多价值。 但是，每多一分钟的计划，就会比前一分钟增加价值。 计划一点，做一点。
在我们现代技术驱动的世界中，有两个因素使这一点特别正确。
一：边做边学使用现代技术更快
技术进步了：摩尔定律意味着我的MacBook Air的功率是我在1980年代学会编程的6502 BBC Micro的100倍。 这反过来比1960年代后期的IBM大型机具有更大的功能。
这意味着我们的工具功能更强大：当今的Python I编程不是最强大的语言，但它比6502汇编程序和BBC Basic更强大。 添加开源库，Python比1960年代的COBOL强大得多。
结果，需要数月或数年才能创建的东西需要数小时和数天。 计划一个OS / 360 COBOL程序的一周时间，这将需要6个月的编写时间。 我计划在下周底之前在云中运行的Python程序计划了一周。
当我说计划时，我指的是计划的各个方面：研究，需求，进度，架构设计及其他。
当然，进行一点规划是完全有意义的。 我愚蠢的是不去煮咖啡，想一想我要做什么。 但是计划只是学习，是关于未来的体验。 今天，我们工具的强大功能意味着未来更加紧密，而了解它的最快方法就是创造它。
一旦达到这个未来，就应该停止，重新审查并重新计划。 最快的学习方法是交替思考（即“计划”）和采取行动（边做边学）。做点事情，看看有什么用，然后花时间反思和学习。
做事也是学习。 任何时候的问题是：最快的学习方法是什么？ 在开始计划时，很快就会变得更快。
二：延误成本改变了一切
一旦意识到延误的成本，您就会看到不同的世界（如果您不知道延误的成本，请查看我的时间价值配置文件。
现在请记住：计划时间就是时间，计划延迟启动。 保持计划，分析，与潜在客户交谈，绘制虚构的项目计划或完善体系结构（在开始构建之前），所有这些都会延迟将产品推向市场的时间。
这种延迟是很糟糕的，因为它会增加风险：在您的产品投放市场之前，您有创建任何人都不想要或至少没有人愿意付费的产品的风险。
这种延迟意味着您的产品将获得更少的收入，这就是延迟的成本。 潜在的客户可能已经找到了其他解决方案，竞争对手可能首先找到了解决方案，或者技术的进步可能会使您的产品过时。
坦白说 ： 我不是说没有计划 。 稍作计划是非常有用和有价值的。 所以，请计划！
我的意思是：计划一点，做一点。 重复。
然后停止，反思，评估和计划更多一点，然后再做一点。 交替进行计划和执行。 我并不是说Shewhart周期 （即Deming周期或PDCA）是一样的，其他六种方法也是如此。
问题是：许多高管被教导要计划计划。 没有人会为过多的计划而烦恼，如果您足够努力，大多数故障都可以归结为无法计划更多的故障。 最终，如果您计划足够，您将永远不会有任何失败，因为您将永远不会做任何事情。
这使我想到了该行政建议的最后一部分：“重新设计治理，以期及早地将其杀死。”
组织治理绝大多数基于我们知道自己在做什么的假设。 仅允许非常了解的事情开始。 那激励人们去计划计划。 当某些事情确实开始时，存在着将其关闭（惯性和承诺升级）的偏见。
这需要改变。 由于我们无法事先知道，我们需要能够在工作进行中做出React。
组织需要准备好在结果不明确的地方开始工作。 然后，治理需要终止没有表现出希望的倡议。 换句话说，早期的大门不需要那么严格，而后期的则需要更多。 如果治理没有经常杀死计划，那么要么治理不起作用，要么您没有承担足够的风险。
翻译自: https://www.javacodegeeks.com/2020/01/plan-less-do-more.html
mql中的做多与做少
941
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
