那么，为什么没有新作品呢？比赛中的胜利在哪里？您两个月运行并收集文件是什么意思？还有什么其他创造力？你为什么没有时间呢？您还应该雇用什么其他秘书？你是什么意思我要走了？您是否真的认为没有我们也可以应对？好吧，祝你好运。
像这样的话描述了一个很好的领导者，他很好地领导了国家机构“在机翼下”的出色舞蹈团生活，当他解释了为什么“从机翼下”离开时。
案子沉入了灵魂tk。我只是在进行一次实验（一次），以赶走其他富有创造力的人-程序员-非核心，但“及时，重要，必要和强制性的工作”。
如果会发生什么？
我已经在不同公司的项目，开发，工厂程序员以及提供修订服务上多次进行了此实验。信不信由你，结果总是一样的。
如果程序员不再担心最后期限而只是一个接一个地解决问题，而又没有任何分心的事情，那么生产力将翻倍。因此，如果您重新打开“捕捉时间”模式，则系数完全相同-两次，只有这次的生产率被其除以。
最重要的是：对于我一生，程序员仍然没有按时完成任务。如果确实如此，那么只是偶尔地，是偶然的。或以降低生产率为代价。
这里的一切都很简单。我不会证明程序员永远不知道解决问题将花费多长时间的公理-关于该主题的文章和书籍很多。如果您是程序员，则不需要证明。当然，也有例外-类似的重复性任务-但这是例外。
我们的大部分工作都包含着许多不断变化的未知数，不断重复的旧任务，分包商的惊喜以及对依赖项的更新，设计错误等。
您打算如何进行这项工作？从根本上讲，有四种方法-幻想，保留，数量和流量。
“计划”方法
幻想是将批生产计划方法应用于程序员的工作。例如精益或MRP。所有“古典经理”，尤其是他们各自的种姓-“经理”，都使用这种方法。您只需要从程序员那里挤出计划的人工成本，而忽略他的所有哭声，例如“该死，我什至不知道我要在那里面对什么”，然后在甘特图上绘制漂亮的香肠。并每天重绘。
为了以防万一，将马匹的份额简单地添加到计划的人工成本中时，储备就是诸如约束理论之类的方法。所得的数字也被绘制为甘特图上的香肠。重绘的次数较少，但几乎总是重绘。
数量是指解决计划的时间不是解决计划的时间，而是生产力。例如，Scrum中使用了这种方法-知道团队工作的大致速度（以故事点为单位），您可以计划每个冲刺的工作量（在同一SP中）。因此，所有冲刺任务具有相同的截止日期。
流是只有速度的时候。任务排好队，程序员坐下来一一解决。日期未知，但可以计算出来-了解队列中任务的速度和数量。最主要的是不要让程序员自己对术语的计算感到困惑。
利弊
甚至讨论一种奇特的方法都没有意义-这是行不通的。不仅如此-它还会产生持续不断的压力和笨拙的重新安排工作。如果其他人不参与重新计划，则可以居住，但是这种情况很少发生。通常，程序员每天都会被诸如“告诉我截止日期”，“您何时完成此任务？”之类的问题所困扰。或“所有的截止日期都过去了，你会工作吗？”即使程序员对任何时髦的技术一无所知，程序员也可以自然而和谐地节省时间。
由于帕金森定律的作用，时间的节省使您免于麻烦，但是却降低了生产率-工作需要花费所有时间。在某些情况下，这种方法适合所有人-例如，适合工厂程序员。没错，在程序员辞职之前，他通常会意识到自己的工作速度低于市场要求。
截止日期已到，因为时间储备可以是实际劳动力成本的百分之几千。如果业务或流程的结构使关键指标正好赶上了截止日期，那么时间预留方法非常适合。
像Scrum这样的批量方法可以使您的生产率大致提高一倍，因为减少帕金森定律的影响，并专注于或多或少的实际生产力，而不是幻想和时间储备。但是，冲刺仍是最后期限，因此帕金森定律，时间保留和操纵故事点的尝试都继续有效。人就是人-程序员和经理。程序员希望成为优秀的员工。经理们习惯于只考虑那些“满足最后期限”的员工，而这些员工至少要精打细算。所有这些都将简单地以不同的方式来称呼-就像“所有积压任务必须在sprint中执行，这里没有任何便利”。他们还会为此业务提出其他一些KPI，因为想象力并不丰富。
流中没有这样的问题，因为 他们没有理由-计划程序员的工作，并尝试以一种或另一种方式估计工作的时间。流程保护了程序员工作的本质-创造力。当然，我想说的是纯粹的创造力，但这没有发生。但是，纯度更高。生产力是Scrum的两倍。
有趣的是：对程序员或工作的执行者的保护，已包含在上述任何方法中。但是当应用于程序员时，总是会忘记保护。
什么方法的基础
例如，奇怪的是，精益也基于流动的思想，因为在装配线上发明。这样做的想法是尽可能均匀，和谐地安排工作。这样，链中的每个表演者一方面总是有事要做，而另一方面则是在他面前没有队列。只有最小的所需净空。对于程序员来说，这是一项任务。尝试将这个想法交给精益专家的经理-他甚至都不了解它的含义，因为当我阅读有关精益制造的Wikipedia文章时，跳过了关于保护表演者的部分。
在关于储备的约束理论中，保护执行链接通常是基本假设。程序员坐在那里，几乎总是瓶颈。 CBT对瓶颈有何看法？是的-他必须受到保护。消除所有非核心工作量（包括安排自己的工作），避免停机，不要因愚蠢的问题和会议而烦恼。以瓶颈工作的速度组织工作流程。好吧，TOC的经理专家承认这一点-您是否已经思考了很长时间了，如何保护程序员免于愚蠢？
好吧，Scrum与流量有关。在那里，“不干扰人们工作的原则”被提升为绝对原则，并体现为在冲刺期间最大程度地保持团队自治。然后-请过来，看看发生了什么，选择下一场比赛的任务，在淋浴间戳一戳。在冲刺期间，甚至不要在附近呼吸。谁在Scrum中工作-您怎么说？在冲刺过程中没有人碰到你，是吗？
总
随地吐痰，随处可见。供程序员坐下来进行编程。我没有计算截止日期，没有幻想劳动力成本，没有安排一百次优先事项，没有参加会议，没有参加愚蠢的通信和聊天。
但是，无论您在哪里随地吐痰，哪里都没有流动。无论使用哪种方法，经理，客户，白痴都会找到理由，使程序员从一些极其重要的废话中脱颖而出。
您随时可以返回信息流。或返回。然而，需求将－以及返回和维持。不断监视程序员的工作困扰。特别是那些对程序员的工作一无所知的人。