一个十字（+）表示使者可以逐步到达目的地，两个十字（++）表示天猫座，三个十字（+++）-立即驰gall。 因此，军队中的奔跑被非正式地称为三个十字架的诱惑 ，后来这种表达进入了俄语，这意味着当局最快地执行了命令。 [维基百科]
焦油坑（英语：Tar pit）-1）一个不可解决的问题，2）沥青湖（地下沥青到达地面，形成天然沥青的区域）。 [英俄词典]沥青中捕获的动物无法逃脱，因此此类湖泊是挖掘史前骨骼的好地方[Wikipedia]。
“想象力代表了试图从树脂中解放出来的恐龙，猛mm象和剑齿虎。 不管野兽有多强壮或敏捷，最终他将注定要死亡。 在过去的十年中，这样的tar坑一直是大型系统的编程工作……” [1，p.16]凭借这一引人注目的图像，弗雷德里克·布鲁克斯（Frederick Brooks）的经典著作开始了，首先在遥远的1975年看到了光明。 在同一古老的1987年出版的另一本经典著作也没有更好的开篇： “那时该项目正在消亡” [2，p.23]。 数年过去了，人类进入了一个新的世纪，但在2014年，另一个畅销书也以同样的永恒故事开始： “ 2010年3月3日，联邦调查局决定暂停进行大规模且有希望的信息管理现代化计划……该局试图更新其计算机系统十多年来，看来灾难已经降临了他们” [3，p.14]。
在布鲁克斯问世44年之后，我们可以怀着清晰的良心再说一遍：现在，当您阅读这些内容时，下一个项目，就像它的前任一样，正在同一焦油坑中沉没。 项目管理成功的机会少于投硬币的机会，而且似乎增长不多：
根据Standish-Group的CHAOS研究[4]
为什么管理科学（已在6版的PMBoK和数十本其他厚书中体现）的进步已有40年了（！）从未导致管理本身质量的提高（除非，当然，通过了解管理质量达到特定点的可能性）？ 为了解决这个问题，我们从著名的布鲁克斯书中确定的任何项目的主要问题开始。
第一个问题：正在创建的产品的复杂性
如果您问到第一个遇到的IT专家-“神话般的人工月中最主要的是什么？” -答案很可能是：“所有工时都不同，新工人与旧工人根本不一样。” 甚至Brooks都将这本书开头所制定的规定称为“法律”（“如果项目没有按时完成，那么增加劳动力将使项目延迟更多”）。 但这只是一个经验性的观察，众所周知，至少有一次“换马过马路”。 问题是在所有工作月数不同时如何计划一个项目？
因此，“神话人月”成为畅销书，这为这个问题提供了答案。 以下是Brooks如何表达对基本设计问题的理解：
“ ...软件开发的经典困难源于实体的复杂性及其随着规模的增长而非线性增长。复杂性导致开发团队成员之间的沟通过程中出现困难，从而导致产品错误，超过开发成本，延迟了工作计划的执行。复杂性是原因枚举的困难，甚至更多的原因是对程序所有可能状态的理解，从而导致程序的不可靠性...结构的复杂性导致了困难 在程序的开发和新功能的添加过程中，因此没有副作用...“ [1，p。 167]
该项目与任何其他生产之间的根本区别在于，其中创建的项目是首次生产的 [我们知道，“增加访问站点的计数器等许多任务也被称为”项目”，但我们所说的是真实的项目]。 像任何真实事物一样，此新产品（无论是软件还是硬件）都由大量能够进行最意外交互（负-沙利度胺和正-伟哥）的组件组成。 很难预见所有这些将如何协同工作，这实际上需要“更好的头脑”，而不是无休止的“工时”：
“杰出的项目是由杰出的设计师创建的。 创建程序是一个创造性的过程。 强大的方法可以赋予创造力以力量，并使他们自由，但它不能激发或激发忙于繁琐工作的人……因此……我相信，我们唯一，最重要的努力就是开发教育优秀设计师的方法” [1 ，第 185-186]
从布鲁克斯的基本立场（设计是创造力 ，而创造过程不能由人群进行），“神话人月”的全部真实内容直接遵循：“建筑师独裁”的要求和“第二个项目的效果”，以及建议“抛弃第一个版本的计划” 。 但是它也遵循布鲁克斯最被遗忘的观点-在项目管理中“没有银弹 ！ ” 项目的复杂性是客观的，无法借助新的编程语言（甚至是图形语言）或通过连接人工智能来克服。 有必要每次都应对复杂性，如果设计师的才能不足以解决这个问题，那么该项目将不会成功。
Brooks项目的主要敌人是所创建产品的复杂性 。 随着新代码的每一行，以及技术文档的每一页，这种复杂性不断增长，并且呈非线性增长。 同时，经理可支配的资源更少-到项目结束为止的剩余时间以及预算结束之前的剩余资金：
在交叉点或之前不久，很明显该项目实际上比最初预期需要更多的金钱和时间：
FBI下一个名为“哨兵”的项目于2005年立即开始。 发行价格为4.51亿美元，Sentinel系统将在2009年全面投入运营。2010年3月，承包商洛克希德·马丁（Lockheed Martin）迟交了一年，仅完成了一半项目，支出了4.05亿美元。 据独立专家称，要完成这项工作，还需要六到八年的时间，另外还要花费3.5亿美元。 [3，第17-18页]。
但是，让我！ 如果自1975年以来，我们知道项目的复杂性在不断增长，例如呈二次方增长，那么-是什么导致预算和团队以同样的方式二次方增长？ 在您可以增加资金的情况下 ，为什么所有新一代的经理都继续领导项目，并且预计成功率将达到30％？
现在，该继续下本书了。
第二个问题：协作的复杂性
如我们所知，举世闻名的畅销书《人文》（“ staffing”译为俄语的“人为因素”）始于《神话》一个月之后的十二年。 “大约有百分之十五的项目以一无所有而结束……在大型项目中，情况更糟，崩溃涵盖了百分之二十五的项目，其持续时间为二十五人年。” [2，p.24]这写于1987年（苏联还活着！），参考1981年的研究（勃列日涅夫还活着）； 今天有什么？
根据2015年CHAOS报告[5]
今天，平均每个开发人员每年花费10万美元，加上额外的管理费用，我们得出的25个人年的费用约为3-6M美元。 正如您所看到的那样，这种情况多年来一直没有改变 ：26％的中型项目和43％的大型项目预期会失败，而我们对此无能为力。 但是为什么会这样呢？ Demarco和Lister向开发人员询问了失败的原因，这是他们的回应：
“在绝大多数情况下，技术领域的失败并没有单一的原因。 大多数情况下，我们民意调查的参与者将“政治”称为崩溃的原因
这根本不是正在开发的产品的复杂性，也不是资源的不足，就像人们在看布鲁克斯十字架时所期望的那样！ “政治”是指团队内部和外部人员之间的关系（Demarco和Lister首选将其称为“社会学”）-开发人员认为，这就是阻碍成功的最主要因素。
想想这个事实 ：乍一看对成功最感兴趣的那些人（开发人员，老板和客户），为了这个项目而团结起来，在其中安排了“政治”，这使项目崩溃了！ “我们遇到了敌人，而他就是我们” [6]； 该项目揭示了第二大敌人-他自己的团队。
从直觉上很明显，参与项目的人员越多，他们在组织联合工作上花费的时间就越多，而实际开发产品的时间就越少。 问题是少了多少 ：
图 2来自文章Putnam，Myers [7]
Putnam和Myers收集了491个软件开发项目的数值特征（从35到95,000行代码），得出的结果几乎令人难以置信。 规模相当的项目几乎同时由不同数量的团队完成，而数量较大的团队需要的时间不短，但更多 。 布鲁克斯定律（“增加开发人员-减慢项目速度”）不仅在项目中断时起作用，而且从一开始就从添加第九位程序员开始起作用。 如果以臭名昭著的人月数表示相同的结果，您将获得更具表现力的时间表。 由不同数量的团队来解决同一问题需要多少钱（按月薪）：
图 文章3，来自Putnam，Myers [7]
所获得的数据大致符合一个完全奇妙的模式：团队中开发人员的生产力与其规模成反比。 在这种情况下，任何团队的开发周期都将相同，这大约是普特内姆和迈尔斯的数据所证明的。 信不信由你，每个人的私事； 但是即使您不相信，您也必须承认，花在政治上的时间与团队的规模呈非线性增长，因此，在大型团队中实际工作的时间要少得多。
Demarco和Lister撰写的这本书包含了许多“社会学”的例子，用维护团队中的“秩序”的工作代替了该项目的工作。 开放空间办公室，老板可以在那里看到谁在逃离工作（而员工却在不断分散他们的注意力）； 详细的计划和持续的要求以满足截止日期（加快并导致错误数量的增加）； 小规章制度（这使您花费大量时间报告已完成的工作，并将员工的积极性从代码转变为“纸条”）。 所有这些措施似乎对于组织联合工作都是必要的-但是，在充分实施这些措施后，它们不再为工作本身留出时间。
现在我们可以理解为什么“仅增加资金”方法不起作用。 随着工作的现代化安排（开放空间，紧迫的期限，详细的报告），项目规模的增加不会导致生产力的显着提高。 相反，项目团队越大，通过同意谁在做什么以及在谁的立场上解决问题，它完全陷入书面工作的风险就越高。 Demarco十字架终结了以“广泛”方式提高项目有效性的尝试。
但是，如果我们改变组织联合活动的基本原则怎么办？ Demarco和Lister早在1987年就建议这样做： 为了有效地管理智力工作领域的人员，有必要采取与上述措施相反的措施。 [即 法规，标准化，解雇之苦以及禁止任何主动行动]。 假定在《 Peopleware》中已相当清楚地写出了“相反的”措施应该是什么样子[实际上，没有]。 让我们再次查看项目成功图。 本书的结果仍包含在任何经理的必读中吗？ 看不见的东西。
那为什么呢 有效的项目管理道路上真的有另一个十字架吗？
第三个问题：计划新计划的难度
乍看之下，完善项目管理的第三个障碍是指导创作过程的正确方法的特殊性质。 早在1986年甚至在Peopleware发行之前，在一篇文章[8]中就描述了一种这样的方法，现在通常称为Scrum。 几年之内，在1993年，杰夫·萨瑟兰（Jeff Sutherland）首次在项目中使用了Scrum的各个元素，并对结果感到满意：
我们在六个月内按时将软件产品按时交付给了Easel，并且没有超出预算，并且出现的错误数量最少-没人能做到。
然而，仅在二十年后的 2014年，[3]就发布了对Scrum主要思想的详细描述。 一直以来，Scrum作为一种半宗派的方法而存在，实际上是从教师传授给学生的，并且仅通过口耳相传而获得了普及。 问题在于，直接遵循其理念的Scrum的主要概念不适合任何合理的控制逻辑：
这是我不断向领导层重复的内容：“只有在看到团队将如何行之有效时，我才能说出最后期限” [3，第28页]。
如果说“项目管理”是指确保在预算范围内按时生产具有指定属性的产品，那么事实证明Scrum根本不是“管理”！ Scrum哲学的中心是绝对拒绝提出最高限度的“固定期限”（与实际团队及其绩效隔离开来），而这种拒绝的第一个结果是完全不常规的项目规划方法：
我去了公司的负责人，并说我们正在放弃甘特图。 被听到的消息激怒了，他要求作出解释。
-您在职业生涯中遇到过多少甘特图？ 我问。
“有数百个，”他说。
-有多少是真的？
“没有，”他回答，思考了一会儿。
然后，我解释说，到本月底，我们将为他提供一个功能完整的系统的一部分，而不是不必要的图形和表格，他本人将能够对其进行测试，并亲自查看开发是否朝着正确的方向前进 [[3，p.50]
在萨瑟兰讲的一个故事中，老板同意尝试。 但是我们知道“幸存者的错误”是什么，并且我们很清楚地知道，这样的老板中有十个人会派遣这样的“项目经理”。 老实说，“我们将在一个月内工作并展示一些东西”是什么废话？ 那是什么白痴？
从Sutherland的书中，我们可以很准确地知道哪一本书：已经尝试使该项目成为经典方法并且遭受灾难性失败的一本书。 只有陷入困境的领导者敢于一无所获，敢于放弃管理“资源-仅在使用计划之下”的基本原则。 当然，在使用Scrum二十年后，对他的态度有所改变，但是即使到今天，大多数谈话“我将在组建团队并开始工作时也要说出术语和数额”仍然冒着这种风险。
Scrum意识形态与该项目的普遍想法（“客户同意付款，承包商进行以下工作……”）相反，以至于该问一个问题：为什么Sutherland被迫采取这样的革命性步骤？ 真的不可能让甘特图“打勾”并专注于组织团队的工作（例如，在每天的例行会议上，其中许多人看到了Scrum中最重要的事情）？
从萨瑟兰在他的《甘特图》一书中所表现出的强烈热情来看，一个人不能：
在管理项目时，传统上需要两件事-问责制和可预测性。 这种方法将不可避免地导致大量文档，表格和图表的出现。。。花了几个月的时间来提供所有细节的最小细节，防止出现单个故障，不超支财务资源并按计划进行。 [3，p.23] 唯一的麻烦是，一旦这个完美的计划面对现实，它就会立即崩溃。 但是，经理们并没有把计划本身及其实施方法丢进垃圾桶，而是假装该计划行之有效…… 事实上，他们是为骗人而向人们付费的 。 [3，第20页]
他们为撒谎而付出代价-就是这样！ ( « ») , . , , (« !»). :
, , , , [3, .23]
: ( ) ( ), . «», , :
( , ), , « », . : «, , , ».
— ! [9]
, « » . , , . « - » , . (« ») . , - .
? ? — . () — . — .
. , «» . , ( «»). , . , — , . , .
- [1] . « - », , -, 2007
- [2] ., . « : », , -, 2005
- [3] , . “混乱。 », ., , , 2016
- [4] de.wikipedia.org/wiki/Chaos-Studie
- [5] CHAOS REPORT 2015
- [6] We have met the enemy
- [7] Putnam, Myers «Familiar Metric Management — Small is Beautiful-Once Again», 1998
- [8] , « : » (1986),
- [9] .. « !», ., 1966